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.


Noël à UltraDNS

Première rédaction de cet article le 25 décembre 2009


Les services du fournisseur d'hébergement DNS UltraDNS, filiale de NeuStar, ont été complètement interrompus mercredi 23, apparemment suite à une attaque par déni de service. Avec UltraDNS, est tombé le service DNS de plusieurs gros clients notamment Amazon et Walmart.

Comme d'habitude, il n'y a pas beaucoup de détails techniques disponibles. Et tout ce qui est publié n'est pas forcément correct. Il semble bien que l'attaque était une DoS contre les serveurs DNS d'UltraDNS et, si c'est bien le cas, il pourrait s'agir de la première attaque DoS réussie contre un service DNS complètement anycasté. En l'absence d'autres informations, il est toutefois difficile d'en déduire quelle technique exacte a été utilisée. Le marketing ultra-agressif d'UltraDNS, et notamment leur habitude détestable d'appeler directement les Directions Générales, en crachant sur le logiciel libre et en expliquant au Directeur que son équipe technique utilise des logiciels gratuits d'amateurs, fait que beaucoup de gens ne pleureront pas sur les malheurs de ce fournisseur. Les concurrents directs d'UltraDNS ne se sont pas privés de rappeller cette attaque réussie. Mais il faut quand même se rappeler que les attaques par déni de service sont les plus difficiles à contrer, qu'il existe une offre assez vaste de mercenaires prêts à travailler pour n'importe qui et que personne n'a encore la solution miracle contre cette vulnérabilité.

Quelles étaient les motivations de l'attaque ? Certains se sont étonnés que les attaquants ne soient pas sensibles à la magie de Noël. Mais c'est sans doute justement la proximité de cette date qui est responsable. Noël est depuis longtemps une opération commerciale et non plus la célébration de la naissance du barbu palestinien qui voulait que tout le monde s'aime. Des entreprises comme Amazon font une bonne part de leur chiffre d'affaires dans les jours précédant Noël. C'est donc logiquement à ce moment que les extorsions se font, de même que les sites Web de paris en ligne reçoivent ces demandes au moment du Super Bowl. Le plus probable est donc qu'Amazon a refusé de payer et que les gangsters ont attaqué l'entreprise par son point le plus faible (Amazon n'a, bien à tort, qu'un seul fournisseur DNS en tout et pour tout).

Quelques articles sur le sujet :


L'article seul

RFC 2777: Publicly Verifiable Nomcom Random Selection

Date de publication du RFC : Février 2000
Auteur(s) du RFC : Donald E. Eastlake, 3rd (Motorola)
Pour information
Première rédaction de cet article le 22 décembre 2009


Ce curieux RFC répond à une question apparemment paradoxale : comment tirer au hasard de manière publiquement vérifiable ? Par exemple, les membres d'un des comités de l'IETF, le Nomcom, sont choisis au hasard. Comment permettre à tous les participants à l'IETF de vérifier que le tirage était bien aléatoire, alors que l'opération se fait sur l'Internet, sans qu'on puisse vérifier le ou la roulette ?

Une solution traditionnelle est de désigner une autorité arbitraire, considérée comme digne de confiance, et dont on n'a pas le droit de remettre l'honnêteté en doute. C'est ce que font toutes les loteries qui se déroulent « sous contrôle d'huissier ». Une telle méthode, basée sur la confiance aveugle en une entité particulière, ne colle pas avec la culture IETF.

Une autre méthode est proposée par notre RFC 2777. Utiliser un certain nombre de sources d'entropie, publiquement consultables, et les passer à travers une fonction de hachage qui garantira la dispersion des résultats, rendant ainsi très difficile d'influencer ceux-ci. Et chacun pourra faire tourner l'algorithme chez lui, vérifiant ainsi que le résultat est honnête.

La section 1 du RFC rappelle le problème original, la désignation du Nomcom (Nominating Committee, cf. RFC 2727) de l'IETF. Mais, depuis, la méthode de ce RFC a été utilisée dans bien d'autres cas.

La section 2 décrit les étapes à suivre :

  • Identifier les candidats possibles (le RFC décrit le cas du Nomcom mais cette étape existe pour toute désignation),
  • Publication de l'algorithme et des sources d'entropie utilisées, pour permettre la future vérification. Cette étape est indispensable car la possibilité de tous les participants de contrôler eux-même l'honnêteté du processus est vitale. (À noter que c'est justement cette possibilité qui est retirée au citoyen dans le cas de mesures anti-démocratiques comme le vote électronique.)
  • Faire tourner l'algorithme et publier le résultat.

Ça, c'était le principe général. Maintenant, le gros problème est évidemment le choix de bonnes sources aléatoires. Toute la section 3 est vouée à cette question. La source doit produire un résultat qui ne peut pas être facilement influencé et qui doit être accessible publiquement. (La section 6 détaille les problèmes de sécurité.)

La section 3.1 analyse les sources possibles et en identifie trois :

  • Les loteries sérieusement organisées, notamment celles faites par l'État. Notez qu'une loterie particulière peut être truquée mais, d'une part, l'algorithme repose sur plusieurs sources, d'autre part les gens qui sont prêts à truquer une loterie le feront plutôt pour des gains financiers, pas pour perturber l'IETF.
  • Les résultats financiers comme le prix de vente d'une action à la clôture de la Bourse ou le volume d'actions échangée en une journée. Ce ne sont pas des nombres aléatoires mais leur valeur dépend des actes de beaucoup d'opérateurs séparés, en pratique, le résultat exact sera imprévisible.
  • Les événements sportifs mais ils posent pas mal de problèmes pratiques comme les risques d'annulation ou de retard.

Attention à ne pas mettre les plus mauvaises sources en dernier, car, avec la connaissance des autres sources, publiées avant, un attaquant qui peut influencer la dernière source aurait un pouvoir excessif.

On pourrait penser qu'il faut multiplier le nombre de sources, pour limiter le pouvoir de nuisance d'une source manipulée. Mais le RFC note que le mieux est l'ennemi du bien : chaque source supplémentaire est également une source de problème, par exemple si elle ne produit aucun résultat (évenement annulé, par exemple). Il recommande environ trois sources.

Aucun des types de source cités plus haut ne produit une distribution uniforme. C'est une des raisons pour lesquelles on doit les faire passer à travers une fonction de hachage (cf. RFC 4086) pour obtenir cette uniformité. Une autre raison est que, pour certaines sources, leur valeur approximative peut être influencée (le cours en Bourse d'une action peut grimper ou descendre selon la volonté d'un gros opérateur) mais pas la totalité des chiffres. Le hachage empêchera donc ledit influenceur d'obtenir le résultat qu'il désire (section 3.2).

La section 3.3 calcule la quantité d'entropie nécessaire pour sélectionner P vainqueurs parmi N possibilités. Par exemple, pour 100 candidats et 10 places, il faut 44 bits d'entropie. (À noter que la fonction de hachage MD5, utilisée par notre RFC en suivant le RFC 1321 ne fournit « que » 128 bits d'entropie.)

Un algorithme détaillé est ensuite présenté en section 4. Les valeurs obtenues des diverses sources sont transformées en chaînes de caractères (en les séparant par des barres obliques). Ce sont ces chaînes qui sont ensuite condensées par MD5. Un exemple complet figure dans la section 5. Notez la précision avec laquelle les sources sont définies !

Une mise en œuvre de référence figure en section 7. Je l'ai rassemblée dans une archive tar. On la compile ainsi :

% make
cc -c -o rfc2777.o rfc2777.c
cc -c -o MD5.o MD5.c
cc -lm -o rfc2777 rfc2777.o MD5.o
rfc2777.o: In function `main':
rfc2777.c:(.text+0x16a): warning: the `gets' function is dangerous and should not be used.

et on l'utilise ainsi (sur l'exemple de la section 5) :


% ./rfc2777 
Type size of pool:
(or 'exit' to exit) 25
Type number of items to be selected:
(or 'exit' to exit) 10
Approximately 21.7 bits of entropy needed.

Type #1 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
9 18 26 34 41 45
9 18 26 34 41 45 
Type #2 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
2 5 12 8 10
2 5 8 10 12 
Type #3 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
9319
9319 
Type #4 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
float 13.6875
13.6875

Type #5 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
end
Key is:
 9.18.26.34.41.45./2.5.8.10.12./9319./13.6875/
index        hex value of MD5        div  selected
 1  746612D0A75D2A2A39C0A957CF825F8D  25  -> 12 <-
 2  95E31A4429ED5AAF7377A15A8E10CD9D  24  ->  6 <-
 3  AFB2B3FD30E82AD6DC35B4D2F1CFC77A  23  ->  8 <-
 4  06821016C2A2EA14A6452F4A769ED1CC  22  ->  3 <-
 5  94DA30E11CA7F9D05C66D0FD3C75D6F7  21  ->  2 <-
 6  2FAE3964D5B1DEDD33FDA80F4B8EF45E  20  -> 24 <-
 7  F1E7AB6753A773EFE46393515FDA8AF8  19  -> 11 <-
 8  700B81738E07DECB4470879BEC6E0286  18  -> 19 <-
 9  1F23F8F8F8E5638A29D332BC418E0689  17  -> 15 <-
10  61A789BA86BF412B550A5A05E821E0ED  16  -> 22 <-

Done, type any character to exit.

On note l'affichage de la clé (les valeurs séparées par des barres obliques) et celui du nombre de bits d'entropie nécessaires.

Outre les exemples de sélection du Nomcom qu'on trouve dans le RFC, cette méthode a été utilisé pour sélectionner le préfixe xn-- des IDN. Voici la description de la méthode et l'annonce du résultat.

Un autre exemple intéressant sera l'utilisation de ce RFC 2777 pour sélectionner les /8 à donner aux RIR lors de l'épuisement final des adresses IPv4.


Téléchargez le RFC 2777


L'article seul

Ethnologue, le livre, la liste de toutes les langues vivantes

Première rédaction de cet article le 18 décembre 2009


L'organisation missionnaire SIL International publie un excellent livre, « Ethnologue, languages of the world », qui tient à jour une liste de toutes les langues vivantes avec leur(s) nom(s), leur nombre de locuteurs, et plein d'autres renseignements. Le livre papier étant très cher (cent dollars états-uniens), on peut se contenter de ce qui existe en ligne, sur http://www.ethnologue.com/.

Ethnologue est le site de référence sur les langues vivantes, toujours le premier cité dans toutes les discussions. Pour avoir une idée de son contenu, on peut lire l'Introduction to the Printed Volume, disponible en ligne. Elle indique la méthodologie, les informations collectées, etc. Parmi les plus originales, l'attitude des locuteurs par rapport à leur propre langue. En sont-ils fiers ou pas ? Ce n'est pas la même chose que l'usage. En France, aujourd'hui, les langues régionales comme le breton bénéficient d'une image de marque très favorable (après des siècles de répression) mais ont très peu de locuteurs (et en nombre décroissant). Au contraire, des langues amérindiennes très vivantes et très parlées sont mal perçues par leurs locuteurs, qui s'excusent parfois de ne pas bien parler espagnol. Ethnologue affiche donc, quand elle est connu, cette attitude. On peut ainsi trouver que le kurde du nord ou le lisu font l'objet d'une appréciation positive de la part de ses locuteurs alors que ceux du créole anglais guyanais sont plus partagés et ceux du qiang du nord plutôt critiques...


L'article seul

RFC 5744: Procedures for Rights Handling in the RFC Independent Stream

Date de publication du RFC : Décembre 2009
Auteur(s) du RFC : R. Braden (ISI), J. Halpern (Ericsson)
Pour information
Première rédaction de cet article le 18 décembre 2009


L'infrastructure juridique des « nouveaux » RFC, désormais répartis en plusieurs voies selon leur source, continue à se mettre en place. Ce RFC 5744 décrit les procédures pour les droits liés aux RFC soumis par la voie « indépendante » (RFC soumis par un individu, ni l'IAB, ni un groupe de travail de l'IETF). Actuellement, il existe des dizaines de documents approuvés techniquement, qui attendent dans la file du RFC Editor car ils ont été soumis par cette voie et son statut n'a pas été clarifié depuis le déploiement des « nouveaux » RFC (RFC 5620). Sans doute vont-ils enfin être publiés mais on ne sait pas encore quand.

C'est que la publication d'un RFC, acte essentiellement technique au début, est devenue une grosse affaire juridico-politique. Des centaines de pages de discussions juridiques ont été noircies sur les problèmes de droits donnés par les auteurs (incoming rights, cf. RFC 5378) et les droits (forcément inférieurs ou égaux) que reçoivent les lecteurs (outgoing rights, cf.RFC 5377). Ces deux derniers RFC ne concernaient que les documents produits par l'IETF et, depuis, les documents produits par des individus languissaient sans statut et ne pouvaient être publiés.

Après tant de débats, il est ironique de constater que la procédure pour les RFC « indépendants » est finalement très proche de celle des RFC « IETF ».

Pour se saisir du contexte, la section 2 de notre RFC 5744 rappelle que le systèmes des voies (streams) a été défini dans les RFC 4844 (et RFC 4846, spécifiquement pour la voie indépendante). Cette dernière est une vieille tradition, et permet de publier des RFC qui sont proposés par des individus isolés, ou bien qui ont rencontré le veto de certaines parties à l'IETF (comme le RFC 4408). Tout RFC n'est donc pas le produit d'un groupe de travail IETF.

Depuis le RFC 5620, qui « éclatait » l'ancienne fonction de RFC Editor, la responsabilité des RFC soumis par voie indépendante revient au Independent Stream Editor, qui ne sera finalement désigné qu'en février 2010.

La section 3 pose les buts des nouvelles règles. Reprenant la politique traditionnelle, suivie informellement depuis l'époque de Jon Postel, elle pose comme principe que l'utilisation des RFC doit être la plus libre possible (« Unlimited derivative works »). Toutefois, tous les RFC de la voie indépendante ne sont pas équivalents. Certains sont des republications de documents édités ailleurs (par exemple par d'autres SDO) et les auteurs ont donc la possibilité de demander des restrictions supplémentaires. À noter que ces principes s'appliquent également au code inclus dans les RFC.

Enfin, les règles formelles elle-mêmes, en section 4. La procédure est proche de celle des autres RFC, l'auteur devant donner certains droits pour permettre la publication (par défaut, il donne presque tous les droits, en gardant évidemment l'attribution de son travail). Les termes exacts (le boilerplate) seront fixés par l'IETF Trust.

Le respect de la procédure par l'auteur ne préjuge pas de l'adoption du RFC. L'éditeur de la voie indépendante, l'ISE, reste seul juge de l'intérêt de publier le RFC. Le choix d'un auteur de ne pas permettre la réutilisation du RFC (« no derivative worlks ») peut, par exemple, être motif de rejet.

L'implémentation de cette politique nécessite une action de la part de l'IETF Trust, décrite en section 5. Celui-ci devra accepter la responsabilité de la gestion des droits de propriété intellectuelle pour ces RFC « indépendants » et devra écrire les termes exacts qui seront inclus dans chaque RFC.

Quant aux questions de brevets et de marques déposées, elles sont réglées dans la section 6. Les règles des RFC 2026 et RFC 8179 s'appliquent aux RFC de la voie indépendante comme aux autres : toute prétention de propriété intellectuelle doit être déclarée, de façon à ce que l'ISE puisse décider en toute connaissance de cause (notez bien qu'en pratique, cette règle est parfois violée). Comme d'habitude à l'IETF, il n'y a pas d'a priori sur les conditions de licence des brevets (tout est théoriquement possible) mais notre RFC précise que les termes de licence les plus favorables possibles seront privilégiés, notamment des licenses gratuites, voire implicites.


Téléchargez le RFC 5744


L'article seul

RFC 5656: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer

Date de publication du RFC : Décembre 2009
Auteur(s) du RFC : D. Stebila (Queensland University of Technology), J. Green (Queen's University)
Chemin des normes
Première rédaction de cet article le 15 décembre 2009


Les algorithmes de cryptographie de la famille des courbes elliptiques prennent de plus en plus d'importance, concurrençant les traditionnels RSA et DSA. Ce RFC spécifie l'utilisation de certains de ces algorithmes dans le protocole SSH.

Il y a déjà plusieurs RFC qui utilisent les courbes elliptiques : les RFC 4050, RFC 4492, RFC 5349, etc. SSH n'est donc pas, et de loin, le premier protocole IETF à en bénéficier. Mais il est plus répandu et l'intégration des courbes elliptiques leur donnera donc une bien meilleure exposition.

Outre des avantages techniques comme des clés de faible taille (voir la section 1 du RFC pour des chiffres précis), l'intérêt des courbes elliptiques est que, compte-tenu du risque toujours existant de percées soudaines en cryptanalyse, il est prudent de garder « plusieurs fers au feu ». Si une nouvelle méthode de factorisation en nombres premiers apparait, menaçant RSA, la disponibilité d'algorithmes utilisant les courbes elliptiques fournira une solution de repli.

Notre RFC 5656 étend donc SSH, tel qu'il est spécifié dans les RFC 4251 et RFC 4253. Pour davantage d'information sur les courbes elliptiques, il renvoie à « SEC 1: Elliptic Curve Cryptography » et « SEC 2: Recommended Elliptic Curve Domain Parameters ».

La section 3 de notre RFC attaque les détails pratiques de l'algorithme ECC. Le format des clés (section 3.1), l'algorithme utilisé pour la signature (nommé ECDSA), avec la fonction de hachage SHA-2 et l'encodage de la signature y sont normalisés.

Un protocole d'échange de clés utilisant les courbes elliptiques, ECDH, occupe la section 4. Un autre, ECMQV, figure en section 5 (mais seul ECDH est obligatoire dans SSH).

Le tout est enregistré dans le registre des paramètres SSH, tel que décrit en section 6. Comme le terme de « courbes elliptiques » désigne une famille, pas un seul algorithme, il faut ensuite préciser l'algorithme exact utilisé. Trois courbes elliptiques sont ainsi mise en avant, nommées nistp256, nistp384 et nistp521. Un mécanisme utilisant l'OID de la courbe est prévu pour celles sans nom (section 6.1). Ces courbes peuvent être utilisées pour ECDSA (section 6.2), ECDH (section 6.3) et ECMQV (section 6.4). Ainsi, le nom complet de l'algorithme utilisé pour ECDSA avec la courbe nistp256 est ecdsa-sha2-nistp256.

Comment vont faire les mises en œuvres de SSH avec ces nouveaux algorithmes et interopéreront-elles avec les anciennes ? Oui, répond la section 8 : le protocole SSH a toujours prévu un mécanisme de négociation des algorithmes utilisés et les programmes ignorent simplement les algorithmes inconnus (section 8.2). La section 8 couvre d'autres problèmes concrets comme les performances des nouveaux algorithmes (en général meilleure que celle de RSA ou DSA, en raison de la taille plus faible des clés).

Une très riche section 9 analyse en détail les caractéristiques de sécurité des courbes elliptiques et leur résistance à la cryptanalyse. D'abord, il faut bien retenir que « courbes elliptiques » désigne une famille, pas un seul algorithme. Certains membres de la famille sont plus vulnérables que d'autres, par exemple à des attaques comme la descente de Weil. Il faut donc considérer avec prudence une courbe qui n'est pas listée dans la section 10 (qui résume la liste des courbes utilisées pour SSH).

Ppur les courbes ainsi spécifiées, il n'existe pas actuellement d'autres attaques que la force brute. Les seules exceptions concernent les algorithmes pour ordinateurs quantiques (comme celui de Shor). Or, ces ordinateurs ont déjà le plus grand mal, à l'heure actuelle, à additionner 2 + 2 et le RFC note qu'il est peu probable qu'ils deviennent une menace réelle dans les prochaines années. Les lois de la physique et celle de l'ingéniérie ne sont pas faciles à faire plier !

La section 10 rassemble les caractéristiques des courbes obligatoires (section 10.1) et recommandées (section 10.2), donnant pour chacune l'OID attribué. Toutes sont dérivées de normes NIST. Ainsi, nistp256 a l'OID 1.2.840.10045.3.1.7. Tous ces algorithmes sont enregistrés dans le registre SSH, suivant le RFC 4250.

La mise en œuvre la plus répandue de SSH, OpenSSH, a intégré ces algorithmes à courbes elliptiques sa version 5.7, livrée en janvier 2011 (voir un résumé en http://pthree.org/2011/02/17/elliptic-curve-cryptography-in-openssh/). Il y a quelques années, un interview d'un des développeurs indiquait qu'un des problèmes était celui des brevets logiciels (il parlait aussi de l'absence de normalisation, ce qui n'est plus vrai avec la sortie de notre RFC).


Téléchargez le RFC 5656


L'article seul

Google peut même prévoir nos recherches

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


On savait déjà que Google pouvait prévoir les épidémies de grippe, rien qu'en examinant les recherches pour des termes liés aux symptômes de cette maladie. Maintenant, on peut en apprendre bien d'avantage sur la prédictabilité des recherches en lisant « On the Predictability of Search Trends ».

Cet article d'août 2009 est une publication de chercheurs de Google étudiant quelles recherches dans le moteur sont prévisibles et lesquelles ne le sont pas. Ainsi, la moitié des requêtes les plus populaires sont prédictibles un an à l'avance, avec une prédictabilité particulièrement forte pour les catégories comme Santé ou Voyage... Au contraire, des catégories comme Distractions sont peu prévisibles, trop liées à des modes très changeantes. (Et, si vous vous demandez quelle est la définition formelle de « prédictabilité », elle figure dans l'article, avec toutes les mathématiques nécessaires.)

Pourquoi Santé ou Voyage sont-elles prévisibles ? Parce que les requêtes dans ces deux catégories obéissent à des logiques saisonnières. De même que Shopping a une pointe parfaitement prévisible avant Noël... C'est une information utile pour les gens du marketing et les annonceurs.

Mais il est plus instructif de regarder les requêtes qui étaient en théorie prévisibles mais qui ont dévié par rapport aux prédictions. Ainsi, la catégorie Chômage a nettement grimpé au dessus des prévisions de Google à l'été 2008, marquant la crise financière que tous les experts et ministres niaient. Si on veut de l'information exacte, il faut regarder les requêtes Google plutôt que les médias...

En revanche, les requêtes au moteur de recherche portant sur des vacances au Mexique ont été en dessous des prévisions à partir d'avril 2009, sans que les requêtes pour d'autres destinations de vacances ne subissent le même sort. C'est sans doute le résultat de l'épidémie de grippe.

Bref, Google fournit une vision de notre société bien plus riche que les simples et amusantes tendances.


L'article seul

RFC 5731: Extensible Provisioning Protocol (EPP) Domain Name Mapping

Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 14 décembre 2009


Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux noms de domaine.

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 5730, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping, on pourrait aussi l'appeler une classe) pour les noms de domaine.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

On note que ce schéma, se voulant adaptable à de nombreux registres différents, ne colle parfaitement à la politique d'aucun. Par exemple, <infData> est spécifié ainsi :


    <sequence>
      <element name="registrant" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="contact" type="domain:contactType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="ns" type="domain:nsType"
       minOccurs="0"/>

ce qui veut dire que des « règles métier » très courantes comme « un titulaire et un seul » ou bien « au moins deux serveurs de noms » ne sont pas respectés avec le schéma EPP seul.

Ce RFC remplace son prédécesseur, le RFC 4931 mais ce ne sont que des modifications de détail, résumées en annexe A. Elles vont en général dans le sens d'une plus grande latitude laissée aux implémenteurs.

Voici un exemple d'une réponse à une requête <epp:info> (section 3.1.2) pour le domaine example.com (comme avec whois mais, typiquement, non public) :


<response>
  <result code="1000">
    <msg>Command completed successfully</msg>
  </result>
  <resData>
    <domain:infData
     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:name>example.com</domain:name>
      <domain:roid>EXAMPLE1-REP</domain:roid>
      <domain:status s="ok"/>
      <domain:registrant>jd1234</domain:registrant>
      <domain:contact type="admin">sh8013</domain:contact>
      <domain:contact type="tech">sh8013</domain:contact>
      <domain:ns>
        <domain:hostObj>ns1.example.com</domain:hostObj>
        <domain:hostObj>ns1.example.net</domain:hostObj>
      </domain:ns>
      <domain:host>ns1.example.com</domain:host>
      <domain:host>ns2.example.com</domain:host>
      <domain:clID>ClientX</domain:clID>
      <domain:crID>ClientY</domain:crID>
      <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
      <domain:upID>ClientX</domain:upID>
      <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
      <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
      <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
      <domain:authInfo>
        <domain:pw>2fooBAR</domain:pw>
      </domain:authInfo>
    </domain:infData>
  </resData>
...

On y voit les serveurs de noms du domaine, ns1.example.com et ns1.example.net, son titulaire, identifié par un code, ici jd1234, sa date de création, le 3 avril 1999, etc.

De même, pour créer un domaine, on appele <epp:create> (section 3.2.1) avec des éléments de l'espace de nom urn:ietf:params:xml:ns:domain-1.0, par exemple :


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">2</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.com</domain:hostObj>
          <domain:hostObj>ns1.example.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>jd1234</domain:registrant>
...

La liste complète des commandes EPP utilisables pour ce type « domaine » figure dans la section 3.

La syntaxe utilisable pour un nom de domaine est celle du RFC 1123, bien plus restrictive que celle utilisée dans le DNS (section 2.1). Ce type « domaine » ne peut donc pas être utilisé pour tout nom de domaine légal.

Chaque domaine a un « statut », ceux mis par le client (typiquement un registrar) étant préfixés par client (section 2.3). Par exemple, clientHold indique que, à la demande du registrar, ce nom, quoique enregistré, ne doit pas être publié dans le DNS.


Téléchargez le RFC 5731


L'article seul

Publication des sites Web qui refusent les adresses de courrier légales

Première rédaction de cet article le 13 décembre 2009


J'ai prévenu (ou tenté de prévenir) un certain nombre de gérants de sites Web que leurs formulaires refusaient des adresses de courrier légales : « Arrêter d'interdire des adresses de courrier légales ». Mais je ne gère pas de listes des sites qui sont dans ce cas (il y en a hélas, trop). Inspiré par l'effort de Thierry Stoehr, pour les sites qui refusent les liens entrants, je publie désormais les messages d'erreur de ces sites en microblogging, sur Twitter et identi.ca.

Dans les deux cas, j'utilise le hashtag #ral pour « Refus d'Adresses Légales ». C'est joli et puis il est libre.

J'essaie de prévenir le webmestre avant, pour qu'il puisse corriger. Mais, la plupart du temps, il n'y a pas de mécanisme de réponse. Et, lorsqu'il y en a un, il est exceptionnel que le problème soit résolu.


L'article seul

Sélectionner les « commits » Subversion d'un auteur particulier

Première rédaction de cet article le 13 décembre 2009


Un des gros avantages de Subversion par rapport à CVS est de disposer d'une API qui évite analyser la sortie texte des commandes. Voici un petit utilitaire qui se sert de cette API pour n'afficher que les commits d'un certain auteur.

Il s'utilise ainsi :

% svnlog.py smith
2009-June-29 13:29 (8761): "Log message 1"
2009-June-29 13:28 (8760): "Log message 2"
...
% svnlog.py jones
2009-July-10 14:34 (8789): "Log message 3"
2009-July-07 11:49 (8781): "Log message 4"
...

Il est écrit en Python, avec la bibliothèque pysvn. Le code est svnlogbyauthor.py.


L'article seul

Mon premier vrai programme en Go

Première rédaction de cet article le 8 décembre 2009


Mon premier « vrai » programme en Go est un client whois, une mise en œuvre du RFC 3912.

Go, créé par Google, est surtout intéressant comme langage de programmation « système ». Il est donc concurrent de C et C++, sur un créneau où il y a relativement peu de candidats (certains, comme D, n'ont eu aucun succès). Certains commentateurs s'étaient étonné que Google crée encore un nouveau langage de programmation lors qu'il y en a déjà des milliers mais, contrairement aux langages fonctionnels, les langages « système » sont bien plus rares.

Le code de mon client whois est en whois.go. Mon point de départ avait été socketgo. (Un autre programme de niveau de complexité analogue est un client pour l'entrepôt de données de Rennes, gostar.go.) Quelques points qui m'ont interpellé pendant le développement du client whois :

  • Le compilateur qui a un nom différent selon le type du processeur (très énervant, pour écrire des Makefile portables, ce n'est qu'après que j'ai appris à mettre include $(GOROOT)/src/Make.$(GOARCH)),
  • La très bonne documentation des paquetages standard,
  • La conversion obligatoire des string en []byte, les premières étant nécessaires pour l'affichage et les seconds servant aux entrées/sorties (j'ai créé un Buffer pour cela, y avait-il une meilleure solution ?),
  • La séparation entre la création d'une variable (où on peut lui donner une valeur avec :=) et sa mutation ultérieure (où on doit utiliser =),
  • L'absence d'exceptions, probablement le plus gros manque du langage,
  • La déclaration automatique d'une variable, avec inférence de types, ce qui m'a rappelé Haskell,
  • Et, bien sûr, comme tous les débutants en Go, le fait qu'une variable déclarée doive être utilisée, sous peine du désormais célèbre message XXX declared and not used.

Mon deuxième programme, pour illustrer le parallélisme en Go est un serveur du protocole echo, NoNewContent. Plus perfectionné et tout aussi parallèle, un serveur de noms en Go.

J'ai aussi fait un exposé en français sur Go. Je stocke mes liens vers des ressources Go en http://delicious.com/bortzmeyer/golang.


L'article seul

RFC 5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions

Date de publication du RFC : Novembre 2009
Auteur(s) du RFC : D. Harrington (Huwaei / Symantec)
Pour information
Première rédaction de cet article le 8 décembre 2009


Ce n'est pas tout de normaliser des protocoles. Pour qu'ils ne rendent pas la vie impossible aux administrateurs réseaux, il faut encore qu'ils soient faciles à administrer. Cela peut être plus facile si ces questions opérationnelles ont été prises en compte dès le début. Ce RFC 5706 demande donc que tout nouveau protocole fait à l'IETF reçoive, dès le début, une sérieuse attention pour ses problèmes de gestion. Le faire a posteriori est en effet souvent moins efficace.

Ce RFC est essentiellement composé d'une liste de recommandations (très détaillées) aux auteurs de nouveaux protocoles, expliquant les étapes qu'ils doivent suivre pour que leur protocole soit « gérable ». Cette liste est résumé dans l'annexe A, qu'il suffit normalement de suivre pas-à-pas pour que le protocole soit complet.

La section 1.1 resitue la question : cela fait longtemps que l'IETF demande aux auteurs de protocole de prévoir les mécanismes de gestion pratique dès le début. Un cadre existe pour cela, autour du SMI (modèle décrivant les variables du protocole) du RFC 2578 (et du protocole qui lui est le plus souvent associé, SNMP ; voir le RFC 3410). Mais ce modèle est trop étroit et ne couvre pas l'intégralité de ce qu'il faut savoir pour le déploiement et l'administration d'un protocole. Sans aller jusqu'à formellement imposer une section Management Considerations dans les RFC (comme il existe une Security Considerations obligatoire), notre RFC 5706 demande une attention sérieuse portée, dès le début, aux questions de gestion et d'opération des réseaux.

La différence entre « gestion » (management) et « opération » (operation) est décrite en section 1.2. Les opérations, c'est faire fonctionner le réseau, même sans mécanisme de gestion. La gestion, c'est utiliser des mécanismes qui ont été créés dans le but d'améliorer les opérations.

Contrairement à l'idée dominante à l'IETF depuis quinze ans, et depuis les grandes luttes entre SNMP et CMIP, il n'est plus envisagé (section 1.3) d'atteindre le Graal du mécanisme unique. Toutes les solutions sont désormais acceptables, pourvu qu'elles marchent. (Parmi les échecs du SMI, on peut noter celui décrit par le RFC 3197. Aujourd'hui encore, les serveurs DNS sont gérés par des mécanismes non-standard comme la commande rndc de BIND.)

Le RFC 5706 va donc donner des lignes directrices et des conseils, plutôt que des obligations. C'est donc un assouplissement par rapport à l'ancienne politique de l'IESG qui exigeait une MIB (description des variables en suivant le SMI) pour tout protocole, au grand désespoir de certains auteurs.

Les sections 1.4 et 1.5 rappellent l'histoire tourmentée des mécanismes de gestion des réseaux TCP/IP. Par exemple, une date importante avait été le RFC 1052 en 1988, qui séparait le langage de modélisation (celui qui sert à écrire la MIB) du protocole d'accès aux données (aujourd'hui SNMP). Une autre avait été le RFC 3139 en 2001, qui listait les obligations d'un mécanisme de gestion. Le RFC 3535 en 2003, faisait le bilan des mécanismes utilisés et critiquait notamment la dépendance vis-à-vis d'un format binaire, celui de SNMP.

La première grande section de notre RFC 5706 est donc la section 2, consacrée aux opérations : comment le nouveau protocole va t-il fonctionner ? Il ne suffit pas pour cela que le protocole soit lui-même bien conçu. Il doit aussi s'insérer dans l'environnement humain et technique existant. Ses concepteurs doivent donc réflechir au déboguage, à la configuration, à la mise à jour depuis une précédente version...

Comme exemple de mauvaise interaction avec l'existant, le RFC cite l'exemple du damping de BGP (RFC 2439). Lorsqu'une route annoncée en BGP change trop souvent, les routeurs BGP commencent à ignorer cette route. Mais cette technique n'avait pas pris en compte l'interaction avec d'autres techniques comme la path exploration et avait donc créé autant de problèmes qu'elle en avait résolu, menant certains administrateurs à couper le damping.

Avant même que le protocole ne fonctionne, il faut le configurer. C'est le but de la section 2.2 qui commence en rappelant un sage principe du RFC 1958 : « tout ce qui peut être configuré peut être mal configuré ». Ce RFC (et son lointain successeur, le RFC 5505) recommandait de préférer les configurations automatiques. Pour les cas où une valeur par défaut a un sens, il faut éviter toute configuration (mais permettre de connaitre les valeurs effectivement configurées).

Parfois, il y avait déjà une version plus ancienne du protocole qui tournait (ou bien un ancien protocole jouant le même rôle). La norme doit alors prévoir un mécanisme de migration, dit la section 2.3. D'autres principes de ce genre forment le reste de la section 2.

La section 3, elle, s'occupe de la gestion de réseaux. Il ne s'agit plus uniquement de faire marcher le réseau, il faut encore le faire marcher bien. Cela passe par l'identification des entités à gérer, puis de la méthode à utiliser. L'ancienne approche qui répondait à toutes ses questions par « il faut écrire une MIB » a montré ses limites. Un ensemble de variables n'est pas un protocole, d'autant plus qu'elle ne concerne en général qu'une des deux extrémités de la communication. Comme le dit le RFC 3535, « une MIB est souvent une liste d'ingrédients sans une recette ». L'introduction de la section 3 donne des pistes pour améliorer les choses.

Un des credos principaux de l'IETF est l'interopérabilité, couverte dans la section 3.1. Appliquée à la gestion du réseau, l'interopérabilité veut dire qu'on devrait pouvoir choisir librement le programme utilisé pour gérer un équipement, et l'utiliser quel que soit l'équipement réseau qu'on gère. Cela implique un protocole standard de gestion.

Beaucoup d'équipements réseau peuvent être gérés via une page Web (elle-même souvent très peu standard, avec abus de fonctions qui ne marchent que sur certains navigateurs, même si le RFC ne mentionne pas ce point), ou parfois via la ligne de commande. Mais cela ne suffit pas. Si on gère des dizaines d'équipements différents, ce qui est courant dans un réseau de taille moyenne, la complexité devient vite unsupportable. Pour que la gestion du réseau soit simplifiée et soit automatisable, une normalisation de ces interfaces est nécessaire.

Historiquement, tout le monde était d'accord sur le papier avec une telle approche. Mais, en pratique, ces interfaces, même celles en ligne de commande, plus faciles à spécifier, n'ont jamais été standardisées. L'IETF n'a pas aidé, en se focalisant sur un seul schéma de données (le SMIv2 du RFC 2578) et un seul protocole (SNMP, du RFC 3410). Ces mécanismes ne convenaient pas à tous et les « autres » interfaces, ignorées de l'IETF, étaient développées mais sans norme unificatrice. Désormais, l'IETF a une vision plus ouverte, et considère d'autres langages de schéma (comme les W3C Schema) ou d'autres protocoles (comme Netconf, dans le RFC 6241, ou syslog, dans le RFC 5424).

La normalisation est plus facile à dire qu'à faire. Normaliser au niveau de la syntaxe est déjà délicat mais, idéalement, il faudrait aussi normaliser la sémantique, pour qu'un même nom décrive bien le même concept partout. Cela impose de développer des modèles, aussi bien des modèles d'information que des modèles de données. (La différence est expliquée dans le RFC 3444 et la section 3.2 couvre les modèles d'information.)

Un protocole ne fonctionne jamais sans pannes. La très riche section 3.3 se penche sur la gestion des pannes. Bien sûr, les mécanismes de gestion du réseau ne vont pas réparer la panne tout seuls. Mais ils peuvent aider à la diagnostiquer. Par exemple, tout protocole devrait avoir un mécanisme de détection de la vie d'un élément du réseau, pour pouvoir répondre à la question simple « Est-il encore en marche ? ». C'est le but de protocoles aussi variés que l'ICMP echo du RFC 792, du protocole echo de TCP ou UDP (RFC 862, mis en œuvre dans des programmes comme echoping et malheureusement presque abandonné aujourd'hui), les appels NULL dans Sun-RPC (section 11.1 du RFC 1831), etc.

Dans un ordre surprenant, la section 3 passe ensuite à la gestion de la configuration (sous-section 3.4). Quels paramètres de configuration, lesquels survivent au redémarrage, que dit le RFC 3139, etc. Cette section, comme le reste du RFC, est trés détaillée, abordant même le problème de l'internationalisation (et, oui, il faut permettre l'UTF-8 dans les fichiers de configuration). D'autre part, le RFC demande également qu'on puisse vérifier la configuration avant de la charger dans l'équipement réseau, pour éviter de laisser celui-ci dans un état invalide, voire de gêner le bon fonctionnement du réseau.

Pour beaucoup d'opérateurs, notamment dans les réseaux traditionnels de téléphonie, il n'y a pas de gestion de réseau sans comptabilisation du trafic. C'est le sujet de la section 3.5, qui renvoie au RFC 2975, et qui dit bien que la comptabilisation n'est nullement obligatoire, qu'elle doit faire l'objet d'un choix réfléchi.

Plus importante est la gestion des performances : tout le monde veut que le réseau aille vite. Pour cela, le point de départ (section 3.6) est de mesurer les performances, pour déterminer, par exemple, si un changement les améliore ou bien les dégrade. Deux groupes de travail de l'IETF se consacrent à ce sujet, BMWG pour les mesures en laboratoire et IPPM pour celles dans la nature.

La sécurité est un gros sujet en soi, lors de la configuration d'un système, et est traitée dans la section 3.7. Par exemple, un nouveau protocole devrait comporter une analyse des menaces et des solutions possibles. Certains protocoles prévus pour la gestion de réseau ont une utilisation directe en sécurité. Par exemple, les traps SNMP et syslog sont couramment utilisés pour alerter les administrateurs sur des phénomènes qui peuvent être une attaque.

Une fois les problèmes des opérations (section 2) et de la gestion (section 3) ainsi décrits, qu'en faire, lorsqu'on définit un nouveau protocole ? Documenter, dit la section 4. Il devrait idéalement y avoir une section Manageability Considerations dans les RFC, juste avant les Security Considerations, et contenant les informations essentielles pour ceux qui auront à opérer et à gérer le nouveau protocole. Si le ou les concepteur(s) du protocole estiment que cette section n'a pas lieu d'être pour leur création, alors ils devraient l'indiquer explicitement (ce qui garantit que l'absence d'une Manageability Considerations n'est pas un oubli). Le premier RFC à avoir suivi cette règle (avant même qu'elle soit formalisée) est apparemment le RFC 5440 (dans sa section 8).


Téléchargez le RFC 5706


L'article seul

Guerre à la Terre

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


Sortant tout juste de la seconde guerre mondiale, la France et ses voisins devaient s'ennuyer car plusieurs œuvres d'un genre récent, la science-fiction, mettaient en scène des conflits à côté desquels la récente guerre semblait une suite de simples escarmouches. Si E. P. Jacobs, dans Le Secret de l'Espadon imagine comme ennemi de mystérieux « jaunes » tapis au fond de l'Asie, Marijac, dans le magnifique Guerre à la Terre, enrôle des envahisseurs extra-terrestres (aidés toutefois par des collabos jaunes).

Cette BD avait d'abord été publié dans Le Coq Hardi en 1946 et 1947. Elle doit l'essentiel de sa diffusion d'ajourd'hui à sa réédition par Glénat en 1975. Si le tome 1 se trouve assez souvent chez les bouquinistes, le tome 2 est bien plus rare. Moins tiré à l'époque ?

Sur la forme, on y trouve les caractéristiques de la BD de l'époque, notamment les très longs textes, y compris pour expliquer ce que tout lecteur voit bien sur l'image (« L'avion pique à travers la masse de nuages »). La récente guerre fournit plein d'idées de scénarios, les progrès techniques et l'imagination font le reste (notez les progrès considérables de l'aviation terrestre d'un tome à l'autre : d'avions classiques dans le tome 1, les terriens sont passés à des engins dignes de Flash Gordon dans le tome 2). Par contre, le scénariste n'est pas toujours d'une grande rigueur : la Tour Eiffel, détruite dans le tome 1, a subitement ressuscité dans le tome 2 (pour être à nouveau jeté à bas)

Le fond politique est nettement conservateur, souvent raciste (les fusées ennemies qui « sèment la panique dans les quartiers indigènes » ou bien la « race jaune fanatique »). La seconde guerre mondiale étant à peine terminée dans le tome 1, tous les Alliés le sont encore (français, états-uniens et soviétiques). La guerre froide se déclenchant rapidement, les gentils soviétiques ont disparu du tome 2, où les combats ne sont plus menés que par les franco-états-uniens. Le contraste avec Les Pionniers de l'Espérance est net.

Les dessins (deux dessinateurs différents, pour les deux tomes) sont splendides. La peinture de la guerre est saisissante, souvent brutale. Les deux tomes sont pleins de magnifiques morceaux de bravoure, comme la panique dans le métro lors de l'évasion des prisonniers extra-terrestres. Il y a aussi une étonnante description, dans le tome 2, des affrontements entre partisans de la poursuite de la lutte et ceux de la capitulation, écho de juin 1940. Ils culminent dans une scène de conflit armé, sur une base militaire française entre ceux qui veulent rejoindre les États-Unis toujours en guerre et les capitulards.

En tout cas, l'auteur a du souffle et l'apocalypse du tome 2, lorsque les extra-terrestres utilisent leur nouvelle arme, n'a rien à envier à celle du récent film « 2012 ».


L'article seul

Exposé DNSSEC à JRES

Première rédaction de cet article le 4 décembre 2009


Le 4 décembre, à Nantes, j'ai eu le plaisir de faire un exposé lors des JRES sur le sujet « Sécurité du DNS et DNSSEC ».

Voici les documents produits à cette occasion :

L'article est sous GFDL (JRES n'ajoute pas de contraintes). Pour les transparents, leur licence est dans l'avant-dernier (transparents issus d'un projet collectif et ayant eu une longue histoire).

PS : l'exemple NSEC est faux (merci à Rani Zaidi) car ftp.nic.example n'est pas entre ns2 et www.


L'article seul

Tout le monde parle de Google DNS...

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


Alors, je vais en faire autant. Après Google Mail, Google Docs, Google Talk, Google Wave, Google DNS est la dernière vedette de la blogosphère, en attendant Google Power (pour distribuer l'électricité) et Google Airlines (gratuit, évidemment, pour battre les compagnies low cost).

Google DNS est un résolveur DNS ouvert, accessible à tous gratuitement. On peut l'utiliser à la place des résolveurs fournis par le service informatique du réseau local, ou par le FAI. Les instructions pour cela sont disponibles chez Google (en gros, sur Unix, il suffit d'éditer son /etc/resolv.conf).

L'adresse à indiquer, 8.8.8.8, sera certainement dans très peu de temps une des plus connues de l'Internet. C'était une idée marketing géniale que d'utiliser une adresse simple à mémoriser (avec son alternative, 8.8.4.4, et ses équivalents IPv6, moins sexys, 2001:4860:4860::8888 et 2001:4860:4860::8844) même s'il n'est pas sûr que faire de l'anycast sur cette plage normalement allouée à Level 3 soit parfaitement conforme aux règles de l'ARIN. Mais ne chipotons pas.

Quel intérêt y a t-il à utiliser un résolveur DNS distinct du résolveur habituel qu'on trouve sur n'importe quel réseau ? La seule raison valable, à mon avis, est le cas où ledit résolveur soit inexistant ou très lent (cela arrive avec certains FAI).

Mais Google met en avant d'autres raisons. En résumant : vitesse, sécurité et honnêteté. Commençons par la fin : contrairement à ses trois concurrents plus anciens (dont le plus connu, en raison de leur marketing agressif, est OpenDNS), les résolveurs de Google ne sont en effet pas des menteurs. Remarquons qu'on est tombés très bas : ne pas mentir devient si rare que c'est désormais cité comme argument commercial.


% dig @8.8.8.8 MX doesnotexist.fr
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3712

On obtient bien le NXDOMAIN (No Such Domain), le DNS fonctionne normalement.

Et la vitesse ? A priori, l'essentiel du temps de réponse étant dû à la latence jusqu'au résolveur, Google DNS a peu de chances d'être plus rapide. À l'heure actuelle, Google DNS n'a apparemment pas d'instance en France et le serveur semble à Francfort. Mais mesurons, ne devinons pas. En utilisant qtest, voyons, pour une machine française, trois résolveurs de son réseau local, les deux résolveurs d'OpenDNS et les deux de Google DNS :

% qtest -n3 "A a.gtld-servers.net"  127.0.0.1 192.134.7.248 192.134.4.162 208.67.222.222 208.67.220.220 8.8.8.8 8.8.4.4
0 127.0.0.1/127.0.0.1
0 192.134.4.162/192.134.4.162
0 192.134.7.248/192.134.7.248

Les résolveurs locaux gagnent nettement, comme prévu. Et si on compare les trois services de résolveur extérieurs :

% qtest -n3 "A a.gtld-servers.net"  208.67.222.222 208.67.220.220 8.8.8.8 8.8.4.4 156.154.70.1 156.154.71.1
11 8.8.4.4/8.8.4.4
11 8.8.8.8/8.8.8.8
17 208.67.220.220/208.67.220.220

Google l'emporte sur OpenDNS, non seulement en honnêteté mais aussi en vitesse. Il n'y a donc vraiment aucune raison pratique d'utiliser OpenDNS. (Il y a d'autres mesures sérieuses, avec le même résultat, par exemple Google DNS vs OpenDNS: Google Rocks for International Users ou Divers Resolver DNS Services. Un autre outil de mesure, certes écrit par Google mais dont le source est disponible, si vous n'avez pas confiance, est l'excellent Namebench. Voyez aussi Domain Name Speed Benchmark (ce dernier étant spécifique à Windows).

Et la sécurité ? Google promet que ses résolveurs mettent en œuvre toutes les bonnes pratiques actuelles, ce qui est la moindre des choses. La seule stratégie qui aurait été différenciatrice aurait été de faire la validation DNSSEC mais Google DNS ne le fait pas. Par rapport aux résolveurs locaux utilisant les logiciels libres actuels, à jour, comme Unbound ou BIND, Google DNS n'a qu'un avantage, l'utilisation de la variation de la casse, un hack amusant mais marginal.

Parlant de sécurité, notons un petit problème : il n'y a aucune authentification entre le client sur son poste de travail et Google DNS. Rien ne garantit qu'on parle bien aux machines de Google. D'habitude, cette sécurisation du dernier kilomètre n'était pas un problème car le résolveur DNS était proche : sur le même réseau local ou en tout cas sur le même FAI. Avec Google DNS, cela cesse d'être vrai et on pourrait imaginer de nombreux détournements possibles, par attaque sur le système de routage. Ces attaques pourraient être faites par un intermédiaire, ou bien par un FAI malhonnête, peu soucieux de voir ses clients partir chez Google. Pour s'en protéger, il existe plusieurs solutions techniques mais aucune ne semble réaliste. Les seules solutions DNS (j'exclus IPsec et compagnie) possibles sont TSIG (RFC 2845), qui repose sur un secret partagé, et est donc inutilisable pour un service public comme Google DNS, et SIG(0) (RFC 2931), que personne n'a jamais déployé). Dans les deux cas, je ne crois pas qu'aucun stub resolver existant (par exemple la GNU libc) ne le gère, ce qui les rend complètement irréalistes et explique pourquoi Google n'offre pas ce service de sécurité.

Bref, il n'y a de raisons d'utiliser un service de résolveurs externe que si le « sien » est dramatiquement défaillant. Mais, dans ce cas, quelles sont les conséquences ? D'abord, il y a un problème spécifique à Google : l'existence d'une offre très vaste couvrant à peu près tout les services Internet. Si malhonnête que soit OpenDNS, quoi qu'ils fassent des données recueillies sur les utilisateurs, le fait qu'ils ne gèrent qu'un unique service limite les corréalations qu'ils peuvent établir et donc le mal qu'ils peuvent faire.

Au contraire, Google, ayant une offre complète, peut établir des relations, mettre en connexion des données, et représente donc un danger potentiel plus important. Externaliser son courrier à Gmail (ou son DNS à Google DNS), est une chose. Externaliser tous ses services en est une autre. Cela revient à avoir la même entreprise qui serait à la fois votre banque, votre médecin, votre épicier et votre garagiste...

Comment Google peut-il exploiter Google DNS, service gratuit ? Ici, je spécule, je n'ai pas d'informations précises. Google peut gagner de l'argent :

  • en exploitant l'information recueillie pour améliorer le moteur de recherche,
  • en vendant cette information (les noms les plus populaires, par exemple, une information qui intéressera les domainers, surtout si la réponse est NXDOMAIN, indiquant que le domaine est libre),
  • en hébergeant, dans le futur (ce service n'existe pas aujourd'hui), moyennant finances, des serveurs faisant autorité, qui profiteront de la proximité du résolveur pour de meilleures performances. Google, futur hébergeur de TLD ?
  • Reconstituer la totalité d'un TLD, même lorsque celui-ci ne publie pas cette information, en comptant les noms dans les requêtes et les réponses obtenues.
  • Ou, tout simplement, s'assurer que l'Internet fonctionne bien, pour que les clients puissent aller voir les autres services de Google (chez certains FAI, les résolveurs DNS marchent mal, ce qui gêne sans doute Google dans son cœur de métier).

L'article seul

L'OARC, un exemple d'ISAC

Première rédaction de cet article le 3 décembre 2009


Si vous aimez les acronymes de quatre lettres, en voici un dont je viens d'apprendre l'existence alors qu'il n'est même pas dans Wikipédia : ISAC pour Information Sharing and Analysis Center. L'OARC est un exemple d'ISAC, pour le DNS.

Ce terme générique d'ISAC recouvre toutes les organisations qui font du partage de données et d'expériences, en général dans les secteurs d'activité considérés comme critiques (devant fonctionner sans panne). Quelques exemples :

Donc, l'OARC (DNS Operations Analysis and Research Center) est une ISAC. Dire que j'ai été élu au CA sans savoir cela.

Par contre, je sais ce que fais l'OARC : recevoir des informations de ses membres et leur rendre accessible ces informations. En pratique, le gros du travail aujourd'hui est de gérer les fichiers pcap envoyés par des opérateurs de serveurs de noms et de les analyser. Cela peut mener à la publication de rapports comme celui sur les conséquences de l'augmentation de taille de la racine. Il y a aussi de très intéressantes réunions (la prochaine est à Prague en mai 2010) et des outils très pratiques.


L'article seul

Le rejet des règles de sécurité peut être raisonnable

Première rédaction de cet article le 2 décembre 2009


Si les utilisateurs s'obstinent à violer les règles de sécurité que les spécialistes de sécurité leur imposent, est-ce parce qu'ils sont bêtes et obstinés ? Ou bien parce qu'il font un calcul plus raisonnable qu'on ne pourrait le penser ? Un économiste tente de répondre à la question.

Cormac Herley, dans son article « So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users » étudie le comportement des utilisateurs, lors de questions de sécurité informatique, à la lumière de calculs économiques rationnels. Excellent article, très provoquant. Sa thèse est que l'insistance des responsables de sécurité informatique, ou des informaticiens, à exiger des utilisateurs qu'ils appliquent des règles de sécurité contraignantes est non seulement sans espoir (ce que tout informaticien a déjà pu constater) mais également inappropriée. Les mesures de sécurité coûtent cher et il n'y a quasiment jamais d'analyse coût/bénéfice de celles-ci. On demande aux utilisateurs de passer du temps, donc de l'argent, pour résoudre des problèmes qui ne se posent finalement que rarement.

Un des meilleurs exemples de Cormac Herley concerne les certificats X.509. Lorsqu'une alerte de sécurité survient, il s'agit dans la quasi-totalité des cas d'une fausse alerte (certificat signé par une CA qui n'est pas dans le magasin, magasin qui est rempli assez arbitrairement, ou bien certificat expiré). Les vraies attaques sont très rares. Une analyse coût/bénéfice rationnelle comparerait le produit de cette probabilité d'attaque par le coût d'une attaque réussie, avec le coût des mesures de sécurité (ne pas pouvoir accomplir la tâche souhaitée). Et cette analyse dirait probablement que l'utilisateur qui s'obstine à passer outre l'avertissement et le parcours du combattant qu'impose Firefox 3 pour ignorer l'alarme, cet utilisateur est raisonnable.

Même chose avec l'analyse des URL dans le navigateur pour tenter de détecter une tentative de hameçonnage. Même si cette analyse ne prend que dix secondes par utilisateur, multipliée par le nombre d'utilisateurs et leur salaire horaire, cette vérification coûterait plus cher que le hameçonnage (l'article comprend un calcul détaillé, dans le cas des États-Unis). C'est bien la raison pour laquelle toutes les études sur le hameçonnage montrent qu'il n'y a pas d'utilisation de noms de domaines « confondables » (contrairement à ce qu'on lit souvent pour s'opposer aux noms de domaine en Unicode).

Je ne dis pas que je suis d'accord avec l'auteur en tout. Il oublie de prendre en compte les effets rebonds (certaines attaques sont très rares mais, si on baisse la garde en pensant que les précautions coûtent trop cher, le nombre d'attaques va augmenter). Et les utilisateurs ne sont pas forcément rationnels car ils sous-estiment (souvent) ou sur-estiment (plus rarement) certains risques techniques. Mais Cormac Herley a le mérite de poser enfin le problème : dans certains cas (mots de passe par exemple), on n'a presque pas de données sur les attaques réussies par suite d'une trop faible sécurité. Alors, faut-il continuer à prôner aveuglément des mesures de sécurité, sans aucune mesure de leur rentabilité ?


L'article seul

Fin du groupe de travail LTRU

Première rédaction de cet article le 30 novembre 2009


Le groupe de travail LTRU (Language Tag Registry Update) de l'IETF vient d'être dissous, après un long travail, finalement couronné de succès.

À l'IETF, les groupes de travail ne sont pas éternels (à quelques exceptions près). Ils sont créés pour une tâche spécifique, décrite dans leur charte, et sont dissous dès qu'elle est accomplie, pour éviter la création de bureaucraties qui s'auto-entretiennent. C'est ce qui vient d'arriver au groupe de travail LTRU.

LTRU était chargé de mettre à jour le vieux RFC 3066 sur les étiquettes de langue, ces courts identificateurs qui permettent d'indiquer la langue d'un document ou la langue souhaitée par un utilisateur (par exemple br pour le breton ou mn-Latn pour le mongol en alphabet latin). Cela a été fait en deux temps, avec la création du RFC 4646 en septembre 2006 (ce RFC introduisait la notion de sous-étiquette, à partir de laquelle on pouvait génerer les étiquettes de son choix), puis avec celle du RFC 5646 en septembre 2009 (qui intégrait les nouveautés de ISO 639-3). Les discussions ont été longues et souvent acharnées mais le résultat est là.

Une particularité curieuse de LTRU : il fut un des rares groupes de travail de l'IETF à ne jamais avoir de rencontre physique. Ses membres n'ont interagi que par le biais de la liste de diffusion.

Aujourd'hui, il reste de ce groupe la liste (toujours ouverte), le site Web et, bien sûr, les RFC produits...


L'article seul

RFC 5536: Netnews Article Format

Date de publication du RFC : Novembre 2009
Auteur(s) du RFC : K. Murchison (Carnegie Mellon University), C. Lindsey (University of Manchester), D. Kohn (FlyDash)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF usefor
Première rédaction de cet article le 29 novembre 2009


Malgré la concurrence de la messagerie instantanée, du courrier, du Web avec la syndication, Usenet / Netnews, un des plus anciens outils numériques de communication et de distribution d'information continue à vivre. Plus ancien que l'Internet sur beaucoup de sites (Usenet était souvent distribué via UUCP), ce dinosaure continue à faire la joie et le désespoir de millions d'utilisateurs. Mais ses normes avaient un peu vieilli et pas subi de mise à jour depuis longtemps. C'est heureusement ce qui vient de leur arriver, dans une série de RFC dont les premiers publiés sont le RFC 5537 et notre RFC 5536, qui normalise le format des messages. Ces documents ont pris plus de huit ans à être élaborés et approuvés.

Notre RFC 5536 est le successeur du célèbre RFC 1036, publié en décembre 1987, et qui spécifiait avant lui le format des messages (comme ce que fait le RFC 5322 pour le courrier). Depuis des années, les mises en œuvres existantes de Usenet utilisaient un sur-ensemble du RFC 1036, sur-ensemble qui vient d'être normalisé. (Avant cela, ces améliorations étaient contenues dans un document informel, « Son of RFC 1036 », qui a finalement été publié en RFC 1849.)

Les news comprennent plusieurs parties : le protocole de transport des messages, aujourd'hui essentiellement NNTP (RFC 3977), le format des messages (notre RFC 5536) et des conventions plus ou moins formelles entre les sites qui s'envoient des messages NetNews, ces sites formant le réseau Usenet (ou des réseaux privés).

Que contient concrètement notre RFC ? La section résume les concepts de base. « NetNews » est composé d'un ensemble de protocoles pour stocker, transmettre et lire des articles, organisés en groupes (newsgroups). Ces articles sont typiquement distribués au sein d'Usenet par un algorithme d'inondation. Pour retrouver facilement un article, et déterminer s'il est déjà présent localement, le serveur Usenet utilise un Message ID (section 3.1.3) qui est présent dans chaque article, et est unique. Le format NetNews est très proche de celui du courrier, tel que décrit dans les RFC 5322 et RFC 2045. La définition de la syntaxe d'un article (section 1.4) emprunte également beaucoup au RFC 5322 (voir annexe C, qui développe les différences entre les deux formats ; notre RFC 5536 a une syntaxe plus stricte).

La section 2 décrit en détail ce format, en partant du RFC 5322, mais en ajoutant des restrictions (section 2.2). L'internationalisation, comme pour le courrier, est assurée par MIME (section 2.3) et notamment les RFC 2049 et RFC 2231 (voir aussi la section 4).

Une fois les principes de base du format posés dans la section 2, la section suivante décrit chaque en-tête possible. Certains sont obligatoires dans tout article (section 3.1) comme Date: (section 3.1.1) ou From: (3.1.2). Est également obligatoire Message-ID: (section 3.1.3) qui est un identifiant unique de l'article, sur lequel les serveurs se basent pour mettre en œuvre l'algorithme d'inondation. Les identificateurs d'articles sont transmis à tous les serveurs voisins, ceux-ci pouvant alors dire s'ils acceptent ou refusent (car ils ont déjà un article de même Message-ID:). (Le Message-ID: sert également aux recherches d'un article, par exemple, via GoogleGroups.)

Dans les en-têtes obligatoires, on trouve également Newsgroups: (section 3.1.4) qui donne la liste des groupes dans lequel l'article a été envoyé et Path: (3.1.5), qui est la séquence des serveurs par lesquels est passé l'article, séparés par des !. Cet en-tête vise à empêcher les boucles dans l'algorithme d'inondation : même si la détection d'un Message-ID: connu ne marche pas, le fait que le serveur apercevra son nom dans le path: lui indiquera qu'il doit rejeter l'article.

L'ancienneté des NetNews fait que beaucoup de points de la norme s'expliquent par des raisons historiques. Ainsi, le fait de mettre le nom de l'expéditeur au début du Path: et la ressemblance d'un Path: avec une adresse UUCP avec route explicite ne sont pas un hasard. Dans les réseaux UUCP, le Path: pouvait être utilisé comme adresse de courrier, pour écrire à l'expéditeur (cet usage s'est perdu et notre RFC recommande de mettre not-for-mail comme adresse d'expéditeur).

Bien sûr, il y a aussi des en-têtes facultatifs, décrits dans la section 3.2 : c'est le cas par exemple de Archive: (section 3.2.2) qui indique si l'expéditeur veut que son message puisse être archivé (Google permet de chercher dans tous les articles échangés sur Usenet depuis 1981).

Expires: (section 3.2.5) sert à indiquer au bout de combien de temps l'article peut être supprimé d'un serveur qui veut faire de la place (en l'absence de cet en-tête, le serveur décide seul de la date d'expiration).

Et il y a bien d'autres en-têtes possibles dans cette section 3.2.

Quelle est la sécurité offerte par Usenet ? Nulle, rappelle la section 5. Les articles ne sont pas confidentiels et leur intégrité n'est pas garantie.

La liste complète des changements depuis le RFC 1036 apparait en annexe B. MIME est désormais formellement reconnu (la plupart des logiciels le géraient depuis longtemps mais il n'existait pas à l'époque du RFC 1036). Certains en-têtes largement acceptés par les logiciels deviennent officiels, comme Archive:. Autrement, les changements sont surtout du toilettage de syntaxe.

Voici, tel qu'il passe sur le réseau (affiché dans un logiciel de lecture, cela peut évidemment être très différent) un article à ce format :


Path: news.free.fr!xref-2.proxad.net!spooler1c-1.proxad.net!cleanfeed2-a.proxad.net!nnrp3-2.free.fr!not-for-mail
From: Stephane Acounis <panews@free.fr>
Subject: =?iso-8859-1?b?wA==?= donner: Sun(s) SS20 sur Nantes
Date: Mon, 09 Jun 2008 19:24:17 +0200
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-Id: <pan.2008.06.09.17.24.16.590396@free.fr>
Newsgroups: fr.comp.ordinosaures
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

Bonsoir,

J'ai deux stations Sun SS20, une bi-pro (SM75), l'autre mono-pro (SM75),
à donner sur Nantes (ou Nançay mercredi/jeudi ou Brest vendredi).
256Mo de mémoire vive, disque 9Go, carte vidéo.
Je doit avoir des claviers, des câbles divers, des cartes SBus en plus.

...


Notez l'en-tête Subject: encodé selon le RFC 2047.

NetNews est mis en œuvre dans de nombreux logiciels aujourd'hui, souvent dans les logiciels de courrier, vu la ressemblance des formats. C'est ainsi que le célèbre MUA Thunderbird est également un bon lecteur de News.


Téléchargez le RFC 5536


L'article seul

RFC 5537: Netnews Architecture and Protocols

Date de publication du RFC : Novembre 2009
Auteur(s) du RFC : R. Allbery (Stanford)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF usefor
Première rédaction de cet article le 29 novembre 2009


L'antique RFC 1036 qui, pendant les vingt dernières années, était la seule norme gouvernant le système de news, vient d'être remplacé par une série de RFC dont celui qui fait l'objet de cet article, le RFC 5537 qui décrit l'architecture générale des news.

Les news (ou Netnews, dit le RFC) sont un extraordinaire système de distribution de messages, organisés en groupes de discussion (newsgroups). Chacun de ces groupes peut être un vecteur d'annonces ou bien un forum de discussion, où la vigueur de ces discussions sont une caractéristique fréquente des news. Les news existaient avant que l'Internet ne se répande et, jusqu'à très récemment, était souvent distribuées avec des protocoles non-TCP/IP tel qu'UUCP. Mille fois, la fin des news a été annoncée, au profit de gadgets récents accessibles via le Web et à chaque fois, elles ont continué à inonder les serveurs et à passionner des dizaines de milliers de participants. À l'époque où n'importe quel système de communication via le Web fait immédaitement l'objet de l'attention des médias et des experts, les news reste un outil « invisible » (en tout cas invisible aux chefs, aux experts, aux ministres et aux journalistes), ce qui fait une bonne partie de leur charme.

Maintenant, place à la technique. Comment les news fonctionnent-elles (section 1 de notre RFC) ? Les serveurs de news s'échangent des articles, dans un format normalisé. Les articles sont regroupés en groupes comme fr.reseaux.internet.hebergement ou soc.culture.belgium. Les groupes qui partagent un préfixe commun comme fr forment une hiérarchie. Chaque serveur transmet ses articles à ses voisins qui, à leur tour, le transmettent à leurs voisins, un protocole dit d'inondation (il existe d'autres protocoles fondés sur le bavardage de proche en proche dans l'Internet). Un ensemble de serveurs ainsi reliés est un réseau et le principal se nomme Usenet (il existe aussi des réseaux privés, bien plus petits). Lorsque les gens disent qu'ils lisent les news ils font en général allusion à celles d'Usenet.

Les deux principaux RFC de la nouvelle série, celle qui remplace le RFC 1036, sont le RFC 5536, qui normalise le format des messages, un format très inspiré de celui du courrier électronique, et notre RFC 5537 qui décrit le cadre général. L'annexe A est consacrée aux changements depuis le RFC 1036. Le développement de cette nouvelle série de RFC a finalement pris près de dix ans. (Une documentation du premier effort se trouve dans le RFC 1849, « Son of RFC 1036 ».)

Parmi les serveurs de news, la section 1.2 fait la distinction entre :

  • injecting agent le premier serveur qui reçoit un article, article à qui il manquera peut-être quelques caractéristiques pour être tout à fait conforme à la norme,
  • relaying agent un serveur qui recevra et transmettra un article, typiquement sans le modifier,
  • serving agent, un serveur qui permettra la lecture par les clients finaux,
  • user agent, le logiciel qui tourne sur le bureau de l'utilisateur final, lui-même séparé en posting agent qui permet d'écrire et reading agent qui permet de lire,
  • et les passerelles, qui connectent le monde des news à d'autres systèmes, comme le courrier électronique ou le Web

mais, en pratique, beaucoup de logiciels assurent plusieurs fonctions à la fois. Par exemple, INN est injecting agent, relaying agent et serving agent.

Les devoirs des différents logiciels sont résumés dans la section 3. Il y a des grands principes (section 3.1), comme le Principe de Robustesse « Soyez restrictif dans ce que vous envoyez et ouvert pour ce que vous recevez » ou bien comme le principe d'Hippocrate, « Avant tout, ne pas nuire », c'est-à-dire que, en cas de doute, le logiciel doit s'abstenir d'intervenir. D'autant plus que le RFC rappelle que tous les lecteurs doivent voir le même article, ce qui interdit les modifications qui ne soient pas purement techniques.

Et il y a des règles plus pratiques. Par exemple, la section 3.2 est consacrée au champ Path: des en-têtes. Il sert à indiquer le chemin parcouru par le message entre les relaying agent et donc à éviter les boucles. Tout serveur doit donc indiquer son identité dans ce champ (section 3.1.5 du RFC 5536, l'identité est en général le nom de domaine du serveur). Les sections 3.2.1 et 3.2.2 détaillent le processus de formation du champ Path:, bien plus riche que dans le RFC 1036. Un Path: peut être aussi complexe que :

Path: foo.isp.example!.SEEN.isp.example!!foo-news
            !.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example
            !!old.site.example!barbaz!!baz.isp.example
            !.POSTED.dialup123.baz.isp.example!not-for-mail

qui utilise la plupart des possibilités comme celle de noter que la machine 2001:DB::8:800:200C:417A n'avait peut-être pas le droit de se prétendre bar.isp.example.

Tout aussi important que Path: qui permet d'éviter les boucles et de détecter les problèmes, par exemple les injections de spam, est l'en-tête Message-ID: (section 3.1.3 du RFC 5536) qui sert à assurer l'unicité des articles et à garantir que l'algorithme d'inondation se termine : un serveur refuse les articles qu'il a déjà. Pour s'en souvenir, il doit donc stocker les Message-ID: dans une base de données, souvent nommée history (section 3.3).

La section 3.4 se penche ensuite sur le cas des posting agents, le logiciel avec lequel l'utilisateur va interagir pour écrire sur les news. Parmi leurs nombreuses tâches figure celles liées aux réponses à des messages existants (sections 3.4.3 et 3.4.4). Le logiciel doit notamment construire un champ References: qui citera le Message-ID: du message auquel on répond, permettant ainsi au lecteur de news de reconstituer les fils de discussion (même s'il y aura toujours des ignorants pour voler les fils, comme avec le courrier). Voici la partie de l'en-tête qui montre une réponse au message <l_CdnfgkWe7PWyLUnZ2dnUVZ8viWnZ2d@giganews.com> :

Newsgroups: fr.comp.reseaux.ethernet
References: <l_CdnfgkWe7PWyLUnZ2dnUVZ8viWnZ2d@giganews.com>
Subject: =?iso-8859-1?Q?Re:_Debogage_d'une_panne_r=E9seau?=
Message-ID: <49bfceec$0$2734$ba4acef3@news.orange.fr>

Les news ne sont pas seulement une technique mais avant tout un réseau social (même si le mot n'était pas encore à la mode lors de leur création). Certains groupes sont donc modérés et il faut donc aussi spécifier les règles techniques que doivent observer les modérateurs (section 3.9).

Il n'y a pas que les news dans la vie et certains groupes peuvent intéresser des gens qui ne veulent ou ne peuvent pas accéder aux news. Le rôle des passerelles est donc de convertir les articles depuis, ou vers le monde des news. Par exemple, une passerelle peut traduire les news d'un groupe en HTML et les mettre sur une page Web (voyez par exemple l'archive de comp.os.research). Mais les passerelles les plus répandues sont celles entre les news et le courrier électronique, permettant aux utilisateurs du courrier d'écrire sur les news ou bien de recevoir des news par courrier. Historiquement, les passerelles ont souvent été responsables de problèmes sur les news, par exemple de boucles sans fin (article transmis du réseau A au réseau B puis retransmis vers A et ainsi de suite éternellement) et la section 3.10 normalise donc ce qu'elles doivent faire et ne pas faire. Les passerelles doivent notamment conserver le Message-ID:, principale protection contre les boucles, puisque permettant de voir qu'un message est déjà passé. La section 3.10.4 donne un exemple complet pour le cas d'une passerelle bidirectionnelle avec le courrier.

Aujourd'hui, la plupart des news sont transportées par le protocole NNTP, dont le RFC 3977 date d'un peu plus de deux ans. Mais, historiquement, UUCP (RFC 976) avait été très utilisé. La section 2 du RFC détaille les obligations de ces protocoles de transport, notamment le fait de pouvoir faire passer des caractères codés sur 8 bits (permettant ainsi des encodages comme Latin-1). Cette obligation, nécessaire à l'internationalisation a fait l'objet de longues luttes, depuis l'époque où les logiciels devaient encoder les messages écrits en français avec le Quoted-Printable. L'obligation s'applique aussi aux en-têtes des messages et un logiciel de news a donc davantage d'obligations ici qu'un logiciel de messagerie.

Une des particularités des news est que les messages de contrôle (comme ceux demandant la création ou la suppression d'un groupe) sont des messages comme les autres, distribués par le même mécanisme d'inondation. La section 5 normalise ces messages. Le principe de base est que le message de contrôle se reconnait par la présence d'un champ Control: (section 3.2.3 du RFC 5536). Dans l'ancien RFC 1036, les messages de contrôle pouvaient aussi se reconnaitre par un sujet spécial, commençant par cmsg mais cet usage est désormais officiellement abandonné.

Il n'y a aucune sécurité dans les news en général. Certains réseaux peuvent ajouter leurs propres mécanismes mais Usenet, par exemple, n'a pas de mécanisme général. Les messages de contrôle peuvent donc facilement être imités, même s'il existe des méthodes non officielles pour les authentifier (section 5.1). Usenet étant un réseau très animé et très peu policé, cette absence de sécurité a donc entrainé souvent des surprises. Le RFC rappelle donc l'importance de tenter de s'assurer de l'authenticité d'un message de contrôle (les méthodes pour cela ne sont pas normalisées mais, par exemple, INN peut vérifier les signatures PGP).

Les messages de contrôle permettent, par exemple, d'annuler un message, de stopper sa diffusion (section 5.3). Comme on s'en doute, ce sont parmi les messages les plus souvent usurpés. Le RFC 1036 demandait, dans l'espoir de renforcer la sécurité, que l'expéditeur (tel qu'indiqué par le champ From:) soit le même dans le message de contrôle et dans le message initial. Comme il est trivial d'usurper cette identité, cela ne faisait que diminuer la traçabilité, en décourageant les « annulateurs » de s'identifier. Cette règle est donc supprimée par notre RFC.

Les messages de contrôle liés à la gestion des groupes sont décrits dans la section 5.2. Par exemple, newgroup (section 5.2.1) permet de créer un nouveau groupe. Il ressemble à :

From: "example.* Administrator" <admin@noc.example>
Newsgroups: example.admin.info
Control: newgroup example.admin.info moderated
...

Parlant de sécurité, la section 6 lui est entièrement consacrée. Elle résume dès le début la situation : NetNews avait été conçu pour la diffusion large de l'information, et la sécurité en est presque totalement absente. Des grosses erreurs de mise en œuvre avaient en outre aggravé les choses comme le fait que certains logiciels appliquaient (il y a longtemps) les messages de contrôle... en les passant, verbatim, au shell !

Avant de participer aux news il faut donc bien être conscient ce ces problèmes : vulnérabilité aux dénis de service (section 6.2), non-authentification de l'expéditeur (attention donc si un message semble particulièrement outrancier, son vrai expéditeur n'est peut-être pas celui affiché dans le champ From:) et diffusion très large, parfois au delà de ce qui était prévu (section 6.3).

Les articles de news étaient traditionnellement marqués, dans le système MIME comme message/news. Ce type n'a jamais été un grand succès et notre RFC 5537 le remplace par trois nouveaux types, décrits en section 4, application/news-transmission pour un articles en route vers un injecting agent ou bien un modérateur et deux types pour les messages de contrôle, application/news-groupinfo et application/news-checkgroups.

L'annexe A résume les changements depuis le RFC 1036. Parmi eux :

  • Un format beaucoup plus riche du champ Path:, permettant de mettre davantage d'informations comme la notification de suspicions sur l'origine d'un message,
  • Les nouveaux types MIME de la section 4,
  • Les nouvelles règles pour le format des messages de contrôle, notamment la suppression de la règle du sujet commençant par cmsg,
  • La suppression de la règle de pseudo-authentification des messages d'annulation (qui obligeait à ce que le champ From: du message et de l'annulation correspondent),
  • Et de nombreuses précisions ou des normalisations de pratiques que tout le monde faisait mais qui n'étaient pas dans le précédent RFC.

Il existe aujourd'hui de nombreuses mises en œuvre des news en logiciel libre. Par example, parmi les logiciels client (lecture et écriture), xrn ou Thunderbird (ce dernier ne sert donc pas qu'au courrier). Parmi les serveurs, INN. Personnellement, je regrette que mon lecteur de courrier habituel, mutt, n'aie pas de fonction de lecture des news, même si plusieurs modifications non officielles ont déjà été proposées.

En 2001, l'achat par Google de la société DejaNews a mis à la disposition du géant de la recherche sur Internet une archive de tous les messages Usenet depuis 1981. Cette archive est désormais cherchable par date sur Google Groups. Si vous voulez chercher mon premier article envoyé sur les news... (Avec une double signature, une erreur de débutant.) Ou bien une discussion en 1993 sur le DNS...


Téléchargez le RFC 5537


L'article seul

Combien y a t-il vraiment de serveurs DNS racine ?

Première rédaction de cet article le 27 novembre 2009
Dernière mise à jour le 13 janvier 2010


La question resurgit régulièrement dans les discussions sur la gouvernance de l'Internet : combien le DNS a t-il de serveurs racine ?

Comme souvent avec les chiffres, tout dépend de ce qu'on mesure. La marionette du gouvernement états-unien se contredit même dans sa propre propagande. En 2007, l'ICANN criait bien fort qu'il n'y en avait pas que treize serveurs racine, pour se moquer des critiques de son concurrent, l'UIT. En 2009, dans les publications officielles de la même organisation, ils sont redevenus treize.

En fait, les deux textes ont raison, car ils ne mesurent pas la même chose. Ce qui est drôle est que le texte de 2007 est très agressif, très arrogant, laissant entendre que les gens qui parlent des « treize serveurs » sont des ignorants, alors que la même organisation reprend ce compte deux ans après.

Donc, si on veut les chiffres authentiques, il faut passer un peu de temps et mieux comprendre ce qu'il y a derrière les chiffres. On peut trouver tous les détails sur le site (non officiel) de certains des opérateurs des serveurs racine. Le résultat :

  • Il y a onze organisations qui gèrent un serveur racine (VeriSign, ISI, Cogent, université du Maryland, NASA, ISC, armée US, Autonomica, RIPE-NCC, ICANN et WIDE). Seulement deux sont européennes et une japonaise, toutes les autres sont états-uniennes. Changer cette liste est à peu près impossible pour des raisons politiciennes. Il n'y a aucun processus pour recruter un gérant de serveur racine et aucun pour en licencier un, quelles que soient les choses étranges qu'il fasse. En l'absence d'autorité (au sens moral et politique du terme) qui puisse dire qu'on va remplacer telle organisation, qui ne rend pas un service génial, par telle autre (les bons ne manquent pas), la liste n'a jamais connu une seule modification depuis quinze ans, cas unique de stabilité dans l'Internet. Le statu quo semble la seule solution.
  • Il y a treize noms dans la racine (treize enregistrements NS pour « Name Server »), de A.root-servers.net à M.root-servers.net. Avec dig, la commande dig NS . vous les affichera. Déduire de ce nombre une insuffisance de la résistance de la racine aux pannes (« Il n'y a que treize pauvres machines (et là on imagine un vieux serveur Dell sur son rack) ») serait donc erroné, ces treize serveurs ne sont pas treize machines. À noter que le nombre de treize vient de vieilles considérations sur l'ancienne taille des paquets DNS, limitée à 512 octets autrefois. La limite a été étendue il y a dix ans et a été effectivement dépassée lors de l'introduction des adresses IPv6 dans la racine en 2008 mais personne n'ose prendre la responsabilité de remettre en cause ce nombre magique de treize.
  • Il y a vingt et une adresses IP de serveurs de noms de la racine (certains n'ont pas encore une adresse IPv6).
  • Grâce à l'anycast, il y a cent quatre vingt neuf sites physiques différents où se trouve un serveur racine, comme celui de Prague, annoncé dans le communiqué de l'ICANN d'octobre 2009. Un bon nombre de ces sites sont purement locaux, leurs annonces BGP ne sont pas propagées en dehors d'un cercle limité et ces sites ne sont donc pas accessibles de l'extérieur (par exemple, ils sont souvent limités aux opérateurs connectés à un même point d'échange). Ce nombre varie souvent et dépend uniquement des décisions de chaque organisation gérant un serveur. Certaines, les plus dynamiques comme l'ISC, ouvrent des sites à un rythme soutenu.
  • Il y a un nombre inconnu de machines qui assurent ce service, certainement nettement plus de deux cents, la plupart des sites hébergeant plus qu'une machine, derrière un répartiteur de charge.

Si on va analyser la résistance de la racine aux pannes, le chiffre à prendre en considération dépend de la panne envisagée. Si c'est la panne d'un composant électronique dans un ordinateur, c'est bien le nombre de machines physiques qui est le paramètre important. Si la panne est un incendie ou un tremblement de terre, c'est plutôt le nombre de sites qui compte car la panne affectera tous les serveurs situés sur le site. Enfin, si la panne est de nature organisationnelle (cas de certains serveurs racines où l'organisation qui les héberge ne fait guère d'efforts et ne déploie guère de moyens, voire connait des conflits internes), c'est bien le chiffre de onze, le nombre d'organisations, qu'il faut prendre en compte pour évaluer la fiabilité de la racine.

Autres lectures sur ce sujet : un article technique très détaillé sur « pourquoi 13 et pas 14 » et une discussion sur certains points historiques.


L'article seul

Le musée d'histoire naturelle de Rouen n'a pas subi le sort imaginé par le romancier

Première rédaction de cet article le 27 novembre 2009


En 1996, Philippe Delerm publiait un court roman pour jeunes, « Sortilège au muséum ». Le cadre était le musée d'Histoire Naturelle de Rouen. Dans le roman, le musée va être fermé et certaines des collections vénérables déplacées vers un musée plus moderne, au grand déplaisir du jeune héros... et de certains fantômes.

C'est un très joli livre, hymne aux vieux musées poussiéreux de province et aux trésors improbables qu'ils renferment. Au moment où il a été écrit, le musée était un archétype de la muséologie du 19ème siècle, avec ses calmars dans le formol, ses animaux empaillés, ses têtes de « cannibales » prélevées par l'armée coloniale française (non exposées au public) et son parquet qui craque. Et il était effectivement question de le rénover de fond en comble.

Mais l'histoire a suivi un autre cours : le musée a simplement été nettoyé, dépoussiéré et mis aux normes de sécurité modernes. Le musée a rouvert en 2007. En 2009, il est quasiment dans l'état où il était avant sa longue fermeture.

Contrairement à la grande galerie de l'évolution à Paris, qui, après une incroyablement longue fermeture, a été refaite complètement et n'a plus rien à voir avec l'ancienne muséologie, le musée d'histoire naturelle de Rouen reste un « musée de musée ».


L'article seul

RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security

Date de publication du RFC : Février 2002
Auteur(s) du RFC : P. Hoffman (Internet Mail Consortium)
Chemin des normes
Première rédaction de cet article le 26 novembre 2009


Le courrier électronique, on le sait, n'offre guère de sécurité, que cela soit contre la lecture illégitime des messages ou bien contre l'injection de faux messages. Vue la complexité de son architecture (cf. RFC 5598), fruit d'une histoire longue et agitée, il ne faut pas espérer trouver la solution parfaite à tous les problèmes de sécurité du courrier. Aussi, ce RFC 3207 se contente d'apporter juste une brique à l'édifice, l'utilisation de TLS pour protéger le canal de communication entre deux MTA.

La communication normale entre deux de ces serveurs de messagerie se fait, avec le protocole SMTP, en clair. Aucune protection contre l'écoute ou la modification de données (section 1). Il n'y a pas non plus de moyen d'être sûr de l'authenticité du serveur en face. TLS, normalisé aujourd'hui dans le RFC 5246, fournit ces services de confidentialité (via le chiffrement) et d'authentification (via les certificats). Il faut noter que TLS ne sécurise ici que le canal entre deux serveurs, pas le message qui est transporté. Un message passe typiquement par plusieurs serveurs et toutes les communications ne seront pas forcément protégées par TLS. Même si elles le sont, si un des serveurs intermédiaires est malhonnête, TLS ne protégera pas (voir la section 6 du RFC qui détaille ce point de manière très complète). Au contraire, les solutions de sécurité de bout en bout comme PGP protégeront le message (mais sont peut-être plus difficiles à déployer).

Donc, le principe de ce RFC est de faire tourner SMTP au dessus de TLS. Cela se fait par le biais d'une nouvelle extension SMTP, STARTTLS, décrite en section 2 (contrairement à HTTP, il n'y a pas de port spécial où on utiliserait toujours TLS).

Cette extension est composée d'une option qu'annonce le serveur distant, STARTTLS :

220 mail.generic-nic.net ESMTP Postfix (Debian/GNU)
EHLO chezmoi.example.net
250-mail.generic-nic.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
...

et d'une nouvelle commande, également nommée STARTTLS, décrite en section 4 :

STARTTLS
220 2.0.0 Ready to start TLS
...

À cette commande, le serveur distant peut parfois répondre 454 (TLS not available due to temporary reason) auquel cas l'initiateur de la connexion devra décider s'il continue sans TLS (et est donc vulnérable à une attaque par repli, où un attaquant actif essaie de faire croire que la sécurisation n'est pas possible, voir la section 6 du RFC) ou de renoncer. Voir par exemple l'option smtp_tls_security_level = encrypt" de Postfix. Le RFC suggère (section 6) d'enregistrer le fait qu'un pair donné utilise TLS et de refuser les connexions ultérieures si TLS a été abandonné mais je ne connais aucune mise en œuvre de SMTP sur TLS qui fasse cela.

Pour que le courrier puisse continuer à fonctionner dans l'Internet, le RFC impose qu'un serveur annoncé publiquement (par exemple, placé en partie droite d'un enregistrement MX) accepte les connexions sans TLS. En revanche, l'option TLS est particulièrement intéressante (section 4.3) si l'utilisateur humain est authentifié et donc si on utilise le port de soumission (RFC 4409).

Si la commande STARTTLS est un succès (code 220), la négociation TLS habituelle commence. Les deux parties examinent ensuite ses résultats (par exemple l'algorithme de cryptographie négocié, ou bien le certificat du pair distant) et décident de continuer ou pas (section 4.1).

Parlant du certificat, faut-il vérifier celui du voisin ? En pratique, quasiment personne ne le fait, en raison du prix des certificats et de la difficulté à les obtenir et les gérer. De nos jours, SMTP sur TLS procure donc la confidentialité par rapport à des écoutants passifs mais aucune authentification. À la rigueur, on peut toujours regarder les en-têtes du message pour avoir quelques informations supplémentaires :


Received: from mail.bortzmeyer.org (unknown [IPv6:2001:4b98:41::d946:bee8:232])
        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
        (Client CN "mail.bortzmeyer.org", Issuer "ca.bortzmeyer.org" (not verified))
        by mx1.nic.fr (Postfix) with ESMTP id 964A71714088
        for <echo@nic.fr>; Thu, 26 Nov 2009 12:08:08 +0100 (CET)

Si le MTA vérifie l'authenticité de son partenaire, le RFC lui laisse le choix des détails, recommandant seulement d'accepter un serveur situé dans le même domaine que celui qu'on cherche à contacter.

Une fois TLS négocié avec auccès, les machines doivent ignorer tout ce qui a été tapé avant et reprendre la négociation SMTP (EHLO et la suite), puisque l'information obtenue sans TLS n'est pas fiable (section 4.2).

Ce RFC est une mise à jour de la première norme, le RFC 2487, en bien plus détaillé, notamment sur les attaques possibles (une annexe résume les changements).

La plupart des MTA aujourd'hui ont la capacité de faire du TLS, comme décrit pour Postfix dans mon article. Parmi les auto-répondeurs de test, certains acceptent TLS.


Téléchargez le RFC 3207


L'article seul

Une approche d'économiste sur le prix des routes BGP

Première rédaction de cet article le 25 novembre 2009


D'innombrables électrons ont déjà été agités pour discuter de l'architecture actuelle du routage sur l'Internet et des conséquences du multi-homing. La plupart de ces discussions portaient plutôt sur l'aspect technique. Voici un article de mai 2009 qui discute de l'aspect économique.

L'article « Internet Multi-Homing Problems: Explanations from Economics », de Richard Clayton (université de Cambridge) prend la question du multi-homing (qu'il appelle le « problème » du multi-homing, ce qui montre qu'il avait déjà une idée derrière la tête) en évaluant le coût, pour l'infrastructure globale de l'Internet, d'une annonce BGP supplémentaire, due au fait qu'un réseau devient multi-homé. L'article expose d'abord en détail et de maniètre très claire et très correcte le fonctionnement du routage (il cite des documents utiles comme le RFC 4116 ou le RFC 3582). Puis il passe aux applications numériques.

L'auteur (je résume son calcul) arrive à un coût total de l'infrastructure de routage de 23 milliards de dollars US (en additionnant le coût de tous les routeurs de tous les opérateurs). En divisant par le nombre de préfixes annoncés en BGP (près de 300 000), il arrive à 77 000 $ par préfixe. Ce coût est porté par tous les opérateurs de l'Internet et pas par le réseau multi-homé. Une décision locale, par les administrateurs du réseau multi-homé aura donc eu des conséquences globales. L'auteur ne fait donc pas preuve d'originalité en citant pour la millionième fois l'article de Hardin sur la tragédie des biens communs (article presque toujours cité à tort).

En économiste traditionnel, l'auteur demande donc la mise à l'étude d'un mécanisme de paiement permettant de récupérer cet argent auprès du réseau multi-homé. Il ne mentionne guère une autre approche, qui serait de modifier l'architecture de l'Internet (par exemple par une séparation de l'identificateur et du localisateur) pour rendre le multi-homing moins coûteux (seul SHIM6 (RFC 5533) est sérieusement cité, HIP (RFC 7401) est éliminé sans explication).

Une autre idée originale est de demander que l'IETF aie une section Economic Considerations obligatoire dans ses RFC comme c'est déjà le cas pour la sécurité, avec les obligations du RFC 3552. Mais l'IETF, bien qu'ayant souvent discuté de cette approche, a toujours refusé de prendre en compte les questions économiques. Deux raisons à cela : l'IETF n'a pas de compétence particulière dans ce domaine et les questions économiques sont très différentes des questions techniques. On ne peut pas changer la vitesse de la lumière alors que les « lois » économiques sont le résultat de décisions politiques, qui peuvent changer.


L'article seul

RFC 4310: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 25 novembre 2009


Le protocole EPP d'avitaillement d'un registre (par exemple un registre de noms de domaine), normalisé dans le RFC 5730, manipule des objets qui sont des instances d'une classe (nommée mapping). Par exemple, il existe une classe (un mapping) pour les noms de domaine, décrite dans le RFC 5731. Notre RFC 4310 (remplacé depuis par le RFC 5910) décrit, lui, une extension EPP à ce mapping permettant de spécifier les données nécessaires à DNSSEC, notamment la clé publique d'une zone signée.

DNSSEC, normalisé dans le RFC 4033, utilise la même délégation que le DNS. La zone parente d'une zone signée délègue en indiquant la clé publique de sa zone fille. Plus exactement, la zone parente publie un condensat cryptographique de la clé publique de la zone fille, l'enregistrement DS (pour Delegation Signer), normalisé dans la section 5 du RFC 4034 (voir aussi le rappel en section 2.1 de notre RFC 4310).

Lorsqu'un bureau d'enregistrement crée un nom de domaine signé, ou bien informe le registre qu'un domaine est désormais signé, comment indique t-il ce DS ? Il y a plusieurs façons, et notre RFC propose d'utiliser EPP.

L'extension nécessaire est résumée en section 2. Elle fonctionne en ajoutant des éléments à la classe Domaine du RFC 5731. Un élément obligatoire est le condensat cryptographique de la clé (alors qu'il n'est pas forcément unique : cette erreur a été corrigée dans le RFC 5910). Mais le client EPP peut aussi fournir la clé elle-même (le RFC 6781 explique pourquoi le condensat, le futur DS, est obligatoire alors que la clé est facultative). Le RFC prévoit également que le registre de la zone parente peut également récupérer la clé dans le DNS (enregistrement DNSKEY) pour tester si le condensat reçu est correct (et il est donc recommandé que ladite DNSKEY soit publiée avant de prévenir le parent par EPP). La clé transmise au registre doit être une clé de confiance, c'est-à-dire avoir le bit SEP à 1 (cf. RFC 3757). En terminologie moderne, cette clé doit être une KSK (Key Signing Key).

Les commandes EPP pour gérer cette information font l'objet de la section 3. Ainsi, les réponses à <info> doivent désormais contenir un élément <secDNS:infData>, qui contient lui-même des éléments comme <secDNS:dsData> qui a son tour contient les champs qu'on trouve dans un enregistrement DS comme <secDNS:keyTag> (l'identificateur de la clé), <secDNS:alg> (l'algorithme utilisé), etc. L'espace de noms urn:ietf:params:xml:ns:secDNS-1.0 (ici avec le préfixe secDNS) est enregistré dans le registre IANA (voir section 6). (C'est désormais secDNS-1.1, depuis le RFC 5910.) Voici un exemple de réponse à <info> sur le domaine example.com :


<resData>
...
<domain:name>example.com</domain:name>
...
<extension>
  <secDNS:infData
   xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
   xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
    <secDNS:dsData>
      <secDNS:keyTag>12345</secDNS:keyTag>
      <secDNS:alg>3</secDNS:alg>
      <secDNS:digestType>1</secDNS:digestType>
      <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
    </secDNS:dsData>
  </secDNS:infData>
</extension>

Le condensat est de type SHA1 (<digestType>1</digestType>), la clé elle-même étant DSA/SHA1 (<alg>3</alg>).

L'extension DNSEC permet évidemment de créer un domaine signé, avec <create> (section 3.2.1) :


<domain:create>
  <domain:name>example.com</domain:name>
  ...
  <extension>
  <secDNS:create xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
    xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
  <secDNS:dsData>
    <secDNS:keyTag>12345</secDNS:keyTag>
    <secDNS:alg>3</secDNS:alg>
    <secDNS:digestType>1</secDNS:digestType>
    <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
    <!-- <secDNS:keyData>, la clé elle-même, est *facultatif* -->
  </secDNS:dsData>
</secDNS:create>
 ...

Une fois le domaine ainsi créé, le registre publiera typiquement un enregistrement DS comme :

example.com.  IN DS 12345 3 1 49FD46E6C4B45C55D4AC

Bien sûr, on peut aussi ajouter DNSSEC à un domaine existant, ou bien changer une clé existante. Cela se fait avec <update> :


    <domain:update>
        <domain:name>example.com</domain:name>
    ...
    <extension>
      <secDNS:update
       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
        <secDNS:add>
          <secDNS:dsData>
            <secDNS:keyTag>12346</secDNS:keyTag>
            <secDNS:alg>3</secDNS:alg>
            <secDNS:digestType>1</secDNS:digestType>
            <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
            <!-- <secDNS:keyData>, la clé elle-même, est *facultatif* -->
          </secDNS:dsData>
        </secDNS:add>
      </secDNS:update>
     ...

Et, en utilisant <secDNS:rem> au lieu de <secDNS:add>, on peut retirer une délégation sécurisée (« dé-signer » le domaine).

Comme la grande majorité des extensions et mappings d'EPP, celle-ci est spécifiée en utilisant la syntaxe formelle des W3C schemas, ici en section 4.


Téléchargez le RFC 4310


L'article seul

Des numéros d'AS attribués deux fois à des organismes différents

Première rédaction de cet article le 24 novembre 2009
Dernière mise à jour le 21 décembre 2009


Il existe un certain nombre de ressources virtuelles sur l'Internet qui doivent être uniques. Les noms de domaine, par exemple. Pour cela, toute une infrastructure est mise en place, en partant de l'IANA, pour s'assurer de cette unicité. Mais cette infrastructure peut cafouiller, comme en août dernier où des numéros d'AS ont été attribués deux fois...

Le numéro d'AS est utilisé dans des protocoles comme BGP. Il identifie de manière (normalement) unique un système autonome qui est une collection de réseaux gérés par la même entité (typiquement, un opérateur réseau). C'est ainsi que PCH, par exemple, a le numéro 42. On peut trouver des informations liées à un numéro d'AS avec whois, par exemple, pour un AS de mon employeur :

% whois -h whois.ripe.net AS2486
...
aut-num:        AS2486
as-name:        NIC-FR-DNS-TH2
descr:          AFNIC
remarks:        Peering:   peering@nic.fr
remarks:        NOC:       noc@nic.fr
...

Normalement, pour que BGP fonctionne, un numéro d'AS doit être unique au niveau mondial. L'IANA alloue des plages de numéros contigus à des RIR qui les affecte ensuite à leurs membres et aux clients de ceux-ci. L'AS 2486, cité plus haut, a ainsi été délégué par le RIPE-NCC à l'AFNIC.

Mais cette unicité suppose un minimum d'attention de la part des RIR et il vient d'y avoir un gros cafouillage. Toute une plage (de l'AS 1708 au 1726), avait été transférée du RIPE-NCC à l'ARIN sans faire attention aux faits qu'ils étaient déjà alloués (voir https://www.iana.org/assignments/as-numbers/). En août 2009, l'ARIN a commencé à les affecter et des collisions se sont déjà produites. Ansi, l'AS 1712 « appartient » désormais à la fois à Télécom Paris Tech et à un opérateur texan :


% whois -h whois.ripe.net AS1712

aut-num:        AS1712
as-name:        FR-RENATER-ENST
descr:          Ecole Nationale Superieure des Telecommunications,
descr:          Paris, France.
descr:          FR

% whois -h whois.arin.net AS1712

OrgName:    Twilight Communications
City:       Wallis
StateProv:  TX
Country:    US

Et le 1715 est à la fois à REMIP et chez un new-yorkais qui fait des placements dans les paradis fiscaux :

% whois -h whois.ripe.net AS1715

aut-num:        AS1715
as-name:        FR-REMIP2000
descr:          REMIP 2000 Autonomous System
descr:          Metropolitan Network
descr:          Toulouse City France
descr:          FR

%  whois -h whois.arin.net AS1715

OrgName:    Harrier Hawk Management LLC 
City:       New York
StateProv:  NY
Country:    US

Une telle erreur est grave dans son principe et indique un sérieux cafouillage du système des RIR. Quelles sont ses conséquences pratiques ? Les deux AS jumeaux ne peuvent pas se voir l'un l'autre, car les annonces BGP entrantes de l'« autre » sont refusées, BGP interprétant la présence de son propre AS dans le chemin comme le signe d'une boucle. Par contre, les autres AS peuvent voir les deux annonces, qui portent sur des préfixes d'adresses IP différents. Voici un préfixe de Twilight et un de Télécom Paris Tech / ENST, depuis un site tiers (rappel : les chemins d'AS se lisent de droite à gauche, comme les mangas, l'AS d'origine est donc le plus à droite) :

% bgproute 74.118.148.1   
AS path: 3277 3267 174 701 1712
Route: 74.118.148.0/22

% bgproute 137.194.2.1 
AS path: 293 20965 2200 2422 1712
Route: 137.194.0.0/16

La solution adoptée (et annoncée officiellement le 26 novembre) a été d'annuler les allocations faites par ARIN, les plus récentes. Au 21 décembre, cela n'était réalisé que pour 5 AS sur 19 (ce qui n'est pas étonnant, les clients d'ARIN qui ont reçu ces numéros ne sont évidemment pas enthousiastes à l'idée de renuméroter).

Pour les prochaines fois, les RIR se sont engagés à faire ce que n'a pas fait ARIN : tester, avant d'affecter un numéro d'AS, s'il est dans les bases des autres RIR, et s'il est utilisé dans la table de routage BGP globale (s'il est annoncé, ce qui n'est pas le cas de tous les AS).

Merci à Jean-Louis Rougier, Éric Elena et Pierre Beyssac pour le diagnostic et l'analyse. Un article ultérieur de Renesys montre qu'il existe d'autres problèmes de conflit de numéro d'AS, en général bien moins graves et plutôt dûs à des problèmes internes aux entreprises, liés aux divers rachats et fusions..


L'article seul

Le koala n'est pas vraiment karmique pour moi

Première rédaction de cet article le 24 novembre 2009


Je viens de passer un portable Ubuntu dans la dernière version de ce système d'exploitation et j'ai bien galéré autour de gdm.

Ubuntu a de jolis noms pour ses versions. Je viens de passer du Bouquetin Intrépide au Koala Karmique (en sautant l'étape intermédiaire du Jackalope Enjoué, ce qui ajoutait un élément de risque). En gros, ça s'est bien passé, sauf que gdm (Gnome Display Manager) ne se lançait plus normalement. Lancé à la main par sudo gdm, tout allait bien. Lancé par le système lui-même au démarrage, ou bien par la commande officielle sudo service gdm start, X se lance mais gdm plante presque aussitôt et me laisse avec un écran X tout noir (l'écran reste vraiment noir, sans clignoter).

Des commandes comme aptitude dist-upgrade (pour être sûr que tout soit à jour) ou aptitude install ubuntu-desktop (pour être sûr qu'il ne manque rien) n'aident pas (merci à gabe, à ce sujet).

Après pas mal de temps passé, la solution est de retourner à l'ancien gdm, comme expliqué en http://richardsantoro.wordpress.com/2009/11/02/ubuntu-9-10-karmic-koala-reinstaller-lancien-gdm/ ou en http://www.ubuntugeek.com/how-to-downgrade-gnome-display-manager-2-28-to-2-20-in-ubuntu-9-10-karmic.html. Cela nécessite un peu de sed (s#X11R6/##) mais ça marche. On peut trouver des détails dans la documentation d'Ubuntu en français (merci à Antonio Kin-Foo pour son aide).

Bref, Ubuntu a parfois des bogues qui le rendent difficile pour les utilisateurs normaux.


L'article seul

RFC 5694: Peer-to-peer (P2P) Architectures

Date de publication du RFC : Novembre 2009
Auteur(s) du RFC : G. Camarillo
Pour information
Première rédaction de cet article le 24 novembre 2009


Il existe un très grand nombre de systèmes pair-à-pair et leur succès est un témoignage de la capacité de l'Internet à accepter des applications complètement imprévues à l'origine. Cette variété est telle qu'il est difficile de s'y retrouver, par exemple pour d'éventuels travaux de normalisation sur les protocoles pair-à-pair. D'où ce document de l'IAB, qui définit ce qu'est un système pair-à-pair, et propose une taxonomie de ceux-ci. Ce RFC propose également des méthodes pour analyser si un système pair-à-pair est adapté à un problème donné.

Pourtant, on ne manque pas de textes sur les systèmes pair-à-pair. Il y a eu de très nombreuses publications scientifiques, plusieurs conférences uniquement consacrées à ce sujet, et un groupe de travail de l'IRTF lui est entièrement voué. Et, bien sûr, il existe de nombreuses applications pair-à-pair, certaines avec un code source disponible, et parmi lesquelles se trouvent des applications parmi les plus populaires sur l'Internet.

Mais il n'existe pas encore de compréhension commune de ce qu'est le pair-à-pair et, pire, beaucoup de gens, de bonne ou de mauvaise foi, assimilent « pair-à-pair » aux seules activités illégales de transfert de fichiers (section 1 du RFC).

Le but de de document est donc d'aider à la construction de cette compréhension commune et de montrer que le pair-à-pair est largement utilisé pour des activités tout à fait légitimes.

La section 2 du RFC s'attaque à la définition du pair-à-pair. Il existe plusieurs définitions, qui ne sont pas forcément équivalentes, d'autant plus que le marketing s'en mêle et que « pair-à-pair » est souvent un terme vendeur. En outre, la section 2 prévient aussi que certains systèmes souvent qualifiés de « pair-à-pair » ne correspondront que partiellement à cette définition et ne pourront donc pas être considérés comme complètement « pair-à-pair ». Ce n'est pas forcément un défaut : le but est de bâtir le meilleur système possible, pas de coller à la définition du « pair-à-pair ». Bien des systèmes réussis sont « mixtes », mélangeant « pair-à-pair » et « centralisé ».

La définition de ce RFC 5694 est donc : « Est pair-à-pair un système où les éléments qui le composent partagent leurs ressources pour fournir le service pour lequel le système est prévu. Chaque élément du système fournit des services et en reçoit. » En théorie, cette définition impose que tous les éléments partagent leurs ressources mais, en pratique, il existe des systèmes où certains éléments sont des clients purs, ne fournissant aucune ressource. Le RFC considère qu'un système où les clients seraient nettement plus nombreux que les pairs ne serait pas réellement pair-à-pair. Par contre, le RFC note explicitement que le fait que certaines parties du système soient centralisées ne l'empêche pas d'être pair-à-pair. L'exemple cité est celui d'un système où il y aurait un serveur central pour enregistrer les nouveaux pairs. Un tel système serait pair-à-pair, selon la définition proposée.

On peut ensuite faire varier cette définition à l'infini, en ajoutant que les pairs doivent participer à des transactions qui ne leur bénéficient pas directement, ou que les pairs doivent pouvoir communiquer sans passage par un intermédiaire, ou que le contrôle doit être entièrement distribué (sans aucun serveur central, contrairement à ce qu'accepte la définition du RFC 5694).

Il est d'autant plus difficile de classer les systèmes pair-à-pair que beaucoup sont composites, faits de plusieurs services, pas forcément pair-à-pairs. Ainsi, si j'utilise un moteur de recherche BitTorrent accessible par le Web, comme btjunkie, pour récupérer ensuite un fichier avec le protocole BitTorrent, suis-je en pair-à-pair ou pas, le Web étant client/serveur ?

Notre définition étant posée, le reste de la section 2 va l'appliquer à divers systèmes existants, pour voir s'ils peuvent être considérés pair-à-pair ou pas.

La section 2.1 commence ces applications avec le DNS. Les résolveurs DNS étant des clients purs, qui ne fournissent aucun service, le DNS ne peut pas être considéré comme pair-à-pair selon la définition de notre RFC.

Et SIP (RFC 3261) ? La section 2.2 en rappelle les principes, notamment le fait que les user agents sont à la fois client et serveurs. Mais un user agent ne participe qu'aux transactions qui ont un intérêt pour lui (parce qu'il appelle ou bien qu'il est appelé) et le SIP traditionnel ne peut pas être considéré comme pair-à-pair. En revanche, P2PSIP, décrit en section 2.3, est différent : les user agents ne s'enregistrent plus auprès d'un serveur mais entre eux et la fonction de rendez-vous nécessite donc la participation d'autres pairs, qui n'y tirent pas de bénéfice personnel. P2PSIP est donc bien pair-à-pair.

L'un des protocoles pair-à-pair les plus connus est BitTorrent. La section 2.4 examine son cas. Comme un pair BitTorrent, non seulement récupère des fichiers pour son usage personnel, mais en outre en envoie à d'autres, sans que cela ne présente d'interêt pour eux, BitTorrent est bien pair-à-pair. Toutefois, le monde réel est toujours plus compliqué que cela et le RFC note que, si la majorité de l'essaim (l'ensemble des pairs), est composée de pairs ayant récupéré tous leurs fichiers et ne faisant plus que les distribuer (des seeders dans la terminologie BitTorrent), alors, l'essaim ne fonctionne plus vraiment en pair-à-pair.

Après ces études de cas, le RFC se penche, dans sa section 3, sur les fonctions qu'il faut assurer pour qu'un système pair-à-pair fonctionne. Au minimum, et quel que soit le service fourni par ce système, il faut assurer :

  • Le recrutement, c'est-à-dire le mécanisme d'authentification et d'autorisation auxquels sont soumis les nouveaux pairs,
  • La découverte des pairs : le nouveau nœud du réseau doit trouver un ou plusieurs pairs pour commencer la communication.

Dans certains systèmes pair-à-pairs (par exemple eDonkey), ces fonctions sont centralisées. Un serveur de recrutement (dit parfois bootstrap server) est contacté par les nouveaux venus, et il peut, après les avoir autorisés, les mettre en contact avec les autres pairs. Ce serveur est évidemment un point vulnérable du réseau mais notre RFC 5694 ne considère pas que son existence empêche le système d'être authentiquement pair-à-pair. En effet, les fonctions considérées comme significatives sont celles qui ont un rapport direct avec le service fourni.

À noter que ces fonctions peuvent avoir été programmées une fois pour toutes dans un ensemble logiciel qui sert de base pour la construction d'un système pair-à-pair (cf. section 5.4). C'est le cas par exemple de JXTA.

Celles-ci dépendent du service et ne sont donc pas présentes systématiquement. On trouve parmi elles :

  • L'indexation des données présentes dans le système.
  • Le stockage des données présentes dans le système.
  • Les calculs que doit faire le système.
  • L'acheminement de messages d'un pair à l'autre, acheminement qui peut impliquer plus de deux pairs.

Il reste à classer les différents systèmes pair-à-pair. La section de taxonomie est la numéro 4. Le problème n'est pas simple puisqu'il existe déjà plusieurs classifications incompatibles des systèmes pair-à-pair. Pire, le vocabulaire n'est même pas identique entre les auteurs (par exemple pour des termes comme « première génération » ou « deuxième génération »). Notre RFC propose de partir de la fonction d'indexation. Un index peut être centralisé, local ou distribué (cf. RFC 4981). Dans le premier cas, une seule machine garde trace de toutes les données (Napster fonctionnait ainsi). Dans le second, chaque machine se souvient des données qui l'intéressent (les premières versions de Gnutella fonctionnaient ainsi). Avec un index distribué, les références aux données se trouvent sur plusieurs machines. Les DHT sont un bon exemple d'un tel système.

On peut aussi classer les index entre ceux avec ou sans sémantique. Les premiers contiennent des informations sur les relations entre les données et les métadonnées mais pas les seconds. Les index avec sémantique permettent donc des recherches plus riches mais ne trouvent pas forcément toutes les données présentes.

D'autres auteurs ont classé les systèmes pair-à-pair entre systèmes hybrides (pas complètement pair-à-pair, par exemple parce qu'ils ont un index centralisé) et purs. Les systèmes purement pair-à-pair peuvent continuer à fonctionner même quand n'importe laquelle des machines qui les composent est en panne ou arrêtée.

Une autre classification est selon la structure. Les systèmes non structurés sont ceux où un nouveau pair peut se connecter à n'importe quel pair existant. Les systèmes structurés imposent au pair arrivant de ne se connecter qu'à certains pairs bien définis, en fonction de leur identité (c'est par exemple le cas des DHT, où les pairs sont en général organisés en un anneau virtuel dans l'ordre des identificateurs). Mais, là encore, la distinction n'est pas absolue et on trouve, par exemple, des systèmes non structurés où certains pairs ont des rôles particuliers.

Une autre classification qui a eu un relatif succès médiatique est par « génération ». Certains auteurs ont classé les systèmes à index centralisé dans une « première génération du pair-à-pair », ceux à index local dans la seconde génération et ceux utilisant une DHT dans la troisième. Cette classification a plusieurs problèmes, l'un des principaux étant qu'elle laisse entendre que chaque génération est supérieure à la précédente.

Aucune de ces classifications ne prend en compte les fonctions de recrutement et de découverte : un système peut donc être pair-à-pair même si un des ces fonctions, ou les deux, est effectuée par un mécanisme centralisé.

Si on développe des systèmes pair-à-pair, c'est parce qu'ils ont une utilité concrète. La section 5 décrit les principaux domaines d'application des systèmes pair-à-pair. Le plus connu est évidemment la distribution de contenu, qui fait l'objet de la section 5.1. Parfois, ce contenu est composé de fichiers illégalement distribués, par exemple parce que ledit contenu n'est pas encore monté dans le domaine public dans tous les pays. Mais le pair-à-pair va bien au delà des utilisations illégales. La distribution de contenu sur Internet se fait par de nombreux moyens, HTTP, RFC 7230 et FTP, RFC 959 étant les plus traditionnels, et personne ne prétend que HTTP est néfaste parce que du contenu illégal est parfois distribué par HTTP.

Parmi les exemples importants de distribution de contenu légal par le pair-à-pair, il y a les systèmes d'exploitation dont les images ISO sont distribués en BitTorrent (comme Debian ou NetBSD), soulageant ainsi les serveurs de l'organisation, qui n'a pas en général de grands moyens financiers pour leur fournir une capacité réseau suffisante. Il y a aussi les mises à jour de logiciel commerciaux comme World of Warcraft et bien d'autres.

Le gros avantage du pair-à-pair, pour ce genre d'applications, est le passage à l'échelle. Lorsqu'une nouvelle version de NetBSD est publiée, tout le monde la veut en même temps. Un serveur FTP ou HTTP central, même avec l'aide de dix ou vingt miroirs, s'écroulerait sous la charge, tout en restant très sous-utilisé le reste du temps. Au contraire, un protocole comme BitTorrent marche d'autant mieux qu'il y a beaucoup de téléchargeurs (les leechers dans la terminologie BitTorrent). L'effet est équivalent à celui de milliers de miroirs, sans que l'utilisateur n'aie à les choisir explicitement.

Cette question de la sélection du pair d'où on télécharge le fichier est centrale pour l'efficacité d'un système pair-à-pair. L'un des problèmes que pose cette sélection est que les intérêts des différentes parties peuvent être contradictoires. Les utilisateurs veulent le pair le plus rapide, les gérants du système de distribution du contenu voudraient que les pairs possédant les parties les plus rares soient sélectionnés en premier (pour augmenter la fiabilité globale de la distribution), les FAI voudraient que les pairs situés sur leur propre réseau soient privilégiés. Il n'est pas étonnant que la sélection du pair aie été tant discuté au IETF workshop on P2P Infrastructure de 2008 (dont un compte-rendu figure dans le RFC 5594). Le groupe de travail Alto de l'IETF est chargé de travailler sur ce point.

La section 5.1 se termine sur un exemple original, Zebranet, un système de collecte de données sur les zèbres en liberté. Chaque animal porte un collier qui collecte des informations et les transmet aux stations qui se déplacent dans la savane. Mais il arrive souvent qu'un zèbre ne passe jamais près d'une station ! Zebranet permet alors la transmission de données de collier à collier. Chaque zèbre rassemble ainsi les données de plusieurs autres animaux, et le passage d'un seul zèbre près de la station permet de récolter toutes ces données d'un coup. Le RFC note toutefois que Zebranet n'est pas vraiment pair-à-pair puisque le collier ne fait que donner et la station que recevoir.

Une autre utilisation courante du pair-à-pair est le calcul distribué (section 5.2). Une tâche de calcul y est divisée en plusieurs sous-tâches, chacune confiée à une machine différente. Il est général bien moins coûteux d'avoir beaucoup de machines bon marché et relativement lentes plutôt qu'un seul supercalculateur. Contrairement à une grappe, les pairs sont typiquement très éloignés les uns des autres. Il existe aujourd'hui bien des systèmes de calcul distribué (comme Boinc) mais la plupart ne peuvent pas être considérés comme pair-à-pair et seraient mieux qualifiées de « maître-esclave ». En effet, en général, il existe un nœud central, qui décide des calculs à effectuer et les différentes machines lui obéissent, sans tirer elle-mêmes profit du calcul fait (un exemple typique est SETI@home). Tous les systèmes compris sous l'appelation marketing de grille sont dans ce cas.

C'est également la même chose pour l'une des plus grosses applications du calcul distribué, les botnets. Même lorsqu'ils reposent sur une technique pair-à-pair comme Storm, qui dépend d'une DHT, le zombie ne tire pas de profit des actions du botnet, que ce soit l'envoi de spam ou bien la dDoS. Il ne fait qu'obéir aveuglément au C&C (Command and Control Center, la ou les machines qui dirigent le botnet.

La troisième grande catégorie, les applications de collaration, fait l'objet de la section 5.3. Les plus connues de ces applications sont celles de voix sur IP et de messagerie instantanée. Si la conversation elle-même se fait entre deux machines, le rendez-vous initial peut être réalisé en pair-à-pair, comme ce que permet P2PSIP (cf. section 2.3).

Bien, il y a donc de nombreuses applications qui utilisent le pair-à-pair. Mais est-ce à juste titre ? Dans quels domaines le pair-à-pair est-il fort et dans quels domaines vaut-il mieux s'en méfier ? C'est l'objet de la section 6 qui donne des critères d'évaluation des avantages et inconvénients du pair-à-pair. Notre RFC note qu'il n'existe pas de règle simple, la réponse à la question « Vaut-il mieux utiliser le pair-à-pair ? » dépend de beaucoup de choses. Parmi les points importants, le RFC note que les systèmes pair-à-pair sont particulièrement adaptés aux cas où il n'existe pas d'infrastructure existante et où il serait difficile de l'installer, ce qui est le cas des réseaux ad hoc.

Autre point fort du pair-à-pair, le passage à l'échelle. Avec lui, augmenter les ressources du système se fait simplement en ajoutant de nouveaux pairs. Si l'application envisagée doit pouvoir grossir jusqu'à la taille de l'Internet, le pair-à-pair est souvent une option à regarder sérieusement. (En fait, tout n'est pas toujours si simple et la fin d'OpenDHT a montré que le pair-à-pair ne se fait pas forcément tout seul.)

Si on est désireux d'avoir une application fiable (cf. RFC 4981), les systèmes pair-à-pair sont également intéressants. Si chaque pair individuel est en général considéré comme peu fiable, le système complet est conçu pour fonctionner alors même que les pairs individuels arrivent ou repartent du groupe en permanence. Il peut donc être très robuste.

Et les performances ? Il est difficile de dire si le pair-à-pair est plus rapide ou pas, cela dépend de nombreuses choses. Des « pique-assiettes » (free riders), qui profitent du système mais ne lui fournissent rien, peuvent sérieusement dégrader ces performances. D'où la recherche permanente de bons mécanismes d'incitation pour que les pairs ne se conduisent pas en parasites.

Un système pair-à-pair réel doit parfois choisir entre toutes ces caractéristiques. Le RFC cite l'exemple d'une base de données pair-à-pair : si toutes les données sont dupliquées sur tous les pairs, elle serait très robuste face aux pannes et très rapide en lecture. Mais l'arrivée d'un nouveau pair serait très lente parce qu'il devrait commencer par tout recopier. Et les écritures prendraient un temps fou.

Et les questions de sécurité ? Lorsque des tas de machines, parfois placées sous des administrations différentes, travaillent ensemble, ces problèmes de sécurité prennent une autre ampleur. La section 7 leur est consacrée. D'abord, toutes les machines du système sont-elles de confiance ? Certains systèmes pair-à-pair n'enrôlent pas n'importe qui mais uniquement des machines appartenant à la même entité. Dans ces conditions, le problème est plus facile à résoudre. Par contre, avec un système pair-à-pair ouvert à tout l'Internet, que n'importe quelle machine peut joindre quand elle veut, le problème devient un défi...

Dans tous les cas, la liste des problèmes de sécurité potentiels posés par les systèmes pair-à-pair est longue. Par exemple :

  • Pour les systèmes qui ont un composant centralisé, une DoS réussie contre ce composant stoppe tout service,
  • Pour les (nombreux) systèmes pair-à-pair où les messages ne sont pas transmis directement mais routés d'un pair à un autre jusqu'à la destination finale (cas de DHT comme Chord par exemple), les pairs intermédiaires ont des capacités de nuisance très importantes. Une attaque Sybil peut aboutir à ce qu'une grande partie des intermédiaires ne soient pas dignes de confiance,
  • Si le protocole utilisé ne chiffre pas les messages, ceux-ci peuvent être écoutés par les routeurs IP mais aussi par les pairs intermédiaires (si on chiffre, il faut quand même laisser ceux-ci déchiffrer ce qui concerne le routage),
  • Pour les systèmes pair-à-pair qui permettent le stockage des données, comme les DHT, un attaquant peut essayer d'épuiser les ressources. Un quota peut donc être nécessaire (ou une politique de nettoyage, comme le faisait OpenDHT),
  • Si l'attaquant ne réussit pas à faire enrôler des machines à lui pour s'insérer dans le système, il peut, dans certains cas, subvertir le routage pour arriver à recevoir quand même les messages (attaque Eclipse, voir « Eclipse Attacks on Overlay Networks: Threats and Defenses).

Téléchargez le RFC 5694


L'article seul

RIM cache ses brevets à l'IETF

Première rédaction de cet article le 23 novembre 2009


Les brevets logiciels, légaux dans certains pays, sont une source d'ennuis sans fin pour les organisations de normalisation. En effet, l'intérêt évident du détenteur du brevet est d'obtenir que des normes fassent référence audit brevet, obligeant ainsi tous ceux qui déploient cette norme à lui acheter une licence. L'intérêt des utilisateurs étant au contraire que la norme ne soit pas plombée par des brevets, les SDO déploient diverses mesures pour limiter les dégâts. Pour les titulaires de brevet, la tentation est donc forte de tricher comme vient de le faire RIM auprès de l'IETF.

Les politiques des SDO sur les brevets varient beaucoup. Certaines, comme OASIS, laissent même chaque groupe de travail décider de sa politique. Les attitudes possibles vont du refus absolu de normaliser une technique encombrée par des brevets à leur acceptation moyennant publication. L'inconvénient de la position dure est que, appliquée strictement, il ne resterait plus rien de normalisable. La quantité de brevets futiles est telle que toute technique un peu sophistiquée est forcément couverte par des milliers de brevets, tous plus ridicules les uns que les autres, mais qui sont quand même acceptés par les offices de brevets, à la fois par incompétence et aussi parce que ces organismes n'ont aucun intérêt à limiter le nombre de brevets, bien au contraire.

L'IETF a donc une politique de brevets fondée sur la divulgation (disclosure). Cette politique, originellement spécifiée dans le RFC 2026, est aujourd'hui exposée en détail dans le RFC 8179 mais, en deux mots, elle consiste à accepter les technologies plombées par un brevet, tout en imposant à tout participant à l'IETF de divulguer les brevets dont il a connaissance, concernant tout sujet sur lequel se penche le ou les groupes de travail auxquels il participe. Ces divulgations sont ensuite publiées sur le site Web de l'IETF.

Le but de cette politique est d'éviter les brevets sous-marins. Il s'agit de brevets qu'une entreprise détient mais dont elle n'informe pas la SDO, dans l'espoir que celle-ci normalisera une technique brevetée... découvrant ensuite, mais trop tard, que tous les utilisateurs devront payer une licence.

Cette politique est présentée à chaque inscription dans une liste de diffusion de l'IETF et répétée systématiquement lors des réunions physiques, sous le nom de Note Well. On peut donc difficilement l'ignorer.

Néanmoins, une telle tricherie vient d'être découverte à l'IETF. RIM, entreprise connue pour son gadget pour cadres sup', le Blackberry, avait déposé une demande de brevet, tout en travaillant à l'IETF à normaliser une technologie qui en dépendait. Et cela sans divulgation, en violation directe de la Note Well.

Pris la main dans le sac, les employés de RIM ont essayé de prétendre que le réglement intérieur de leur entreprise ne leur avait pas permis de communiquer sur ces demandes de brevet. Défense tout à fait inappropriée puisque les règles de l'IETF sont claires et que la participation à cette organisation est volontaire. Si on ne peut pas en respecter les règles, on ne doit pas participer. Le président de l'IETF, Russ Housley et l'avocat, Jorge Contreras, l'ont rappelé nettement.

Mais il est vrai que le capitalisme n'est pas la démocratie. Dans l'entreprise, il n'existe pas de liberté d'expression, un employé ne peut raconter quelque chose à l'extérieur qu'après avoir eu l'aval de trois juristes et cinq vice-présidents. Cela a mené à des situations cocasses comme les messages rigoureusement identiques envoyés par tous les employés de RIM à l'IETF. Tristes manifestations d'unanimisme brejnevien.

Notez que, deux ans plus tard, Huawei a fait la même chose que RIM dans le processus qui a mené au RFC 6468. Cette seconde violation grossière des règles a mené à la publication de deux RFC, le RFC 6701, qui décrit les sanctions possibles contre les tricheurs, et le RFC 6702, qui rappelle comment encourager le respect des règles.

Ce n'est pas la première fois qu'il y a une collision entre les règles de l'IETF et les principes de la communication corporate. Par exemple, l'IETF avait déjà dû refuser les ridicules ajouts juridiques aux courriers que certaines entreprises mettent systématiquement. Comme, selon le mot de John Levine, les juristes recommanderont toujours n'importe quoi, quel que soit son coût, pour se prémunir contre n'importe quel risque, de tels ajouts sont aujourd'hui fréquents. Il a donc fallu que l'IETF développe une politique de refus de ces textes.


L'article seul

RFC 5730: Extensible Provisioning Protocol (EPP)

Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 23 novembre 2009


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

Notre RFC remplace le second RFC sur EPP, le RFC 4930, mais les changements sont mineurs (cf. annexe C, le principal étant que le RFC rend plus clair le fait que la liste des codes de retour est limitative : un registre ne peut pas créer les siens, ce qui est une des plus grosses limitations de EPP). EPP est désormais une norme complète (Full Standard).

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

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


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

Les espaces de noms utilisés, comme urn:ietf:params:xml:ns:epp-1.0 sont enregistrés dans le registre IANA (cf. section 6). Le <clTRID> est un identifiant de transaction (celui-ci est choisi par le client) et il facilite la traçabilité des opérations EPP. L'exécution de ces éléments doit être atomique (section 2 du RFC).

Chaque commande EPP entraîne une réponse (section 2.6) qui inclus notamment un code numérique à quatre chiffres (section 3) résumant si la commande a été un succès ou un échec (reprenant le schéma expliqué dans la section 4.2.1 du RFC 5321). Le premier chiffre indique le succès (1) ou l'échec (2) et le second la catégorie (syntaxe, sécurité, etc). Par exemple 1000 est un succès complet, 1001 un succès mais où l'action n'a pas encore été complètement effectuée (par exemple parce qu'une validation asynchrone est nécessaire), 2003, une erreur syntaxique due à l'absence d'un paramètre obligatoire, 2104 une erreur liée à la facturation (crédit expiré, par exemple), 2302, l'objet qu'on essaie de créer existe déjà, etc.

EPP est donc typiquement un protocole synchrone. Toutefois, il dispose également d'un mécanisme de notification asynchrone. La commande EPP <poll> (section 2.9.2.3) permet d'accéder à des messages qui avaient été mis en attente pour un client, et lui donnaient l'état des traitements asynchrones.

Le RFC 5730 spécifie une dizaine de commandes EPP comme <check>, qui permet de s'assurer qu'un objet peut être créé, <info>, qui permet d'accéder aux informations disponibles à propos d'un objet existant (comme whois sauf que whois est typiquement public et EPP typiquement réservé aux bureaux d'enregistrement), <create> pour créer de nouveaux objets (par exemple réserver un nom de domaine), etc.

Comme tout objet géré par EPP a un « sponsoring client », l'entité qui le gère (dans le cas d'un registre de noms de domaine, il s'agit typiquement du bureau d'enregistrement), EPP fournit une commande pour changer ce client, <transfer> (section 2.9.3.4). Des options de cette commande permettent d'initier le transfert, d'annuler une demande en cours, de l'approuver explicitement (pour le client sortant), etc.

La syntaxe formelle des éléments XML possibles est décrite dans la section 4, en utilisant le langage W3C schema.

Le transport de ces éléments XML sur le réseau peut se faire avec différents protocoles, s'ils respectent les caractéristiques listées en section 2.1. Par exemple, le RFC 5734 normalise EPP reposant directement sur TCP.

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

Dans tous les cas, chaque objet manipulé avec EPP reçoit un identificateur unique (par exemple SB68-EXAMPLEREP), dont les caractéristiques sont normalisées dans la section 2.8. Les dépôts possibles sont enregistrés dans un registre IANA.

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

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

Il existe plusieurs mises en œuvres d'EPP en logiciel libre par exemple le serveur EPP OpenReg de l'ISC, le logiciel Fred du registre de .cz ou bien le client EPP Net::DRI de Patrick Mevzek. Si vous voulez expérimenter avec EPP, vous devez installer votre propre serveur, il n'existe pas de serveur public pour tester.


Téléchargez le RFC 5730


L'article seul

Avoir sa base de données hébergée sur l'Internet : rdbhost

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


Si on veut avoir sa base de données hébergée quelque part sur l'Internet et accessible depuis des applications qui peuvent tourner à divers endroits, on a bien sûr plusieurs solutions. Je présente ici un hébergement chez rdbhost.

Si on est administrateur système de profession, ou simplement si on a besoin d'applications très spécifiques, qu'on a peu de chances de trouver dans une offre standard, la meilleure solution est sans doute de louer une machine dédiée, par exemple chez Slicehost. Mais si on est un programmeur ordinaire, qui n'a ni le temps, ni l'envie de faire de l'administration système, un service hébergé peut être intéressant. Le public typique visé par rdbhost est le client de Google App Engine qui veut une autre base de données que celle fournie par Google.

Que fournit rdbhost ? Un service gratuit (pour les usages raisonnables) de base de données, vous donnant accès à une base SQL (en l'occurrence, PostgreSQL). L'interface avec la base n'utilise pas le protocole réseau habituel de PostgreSQL, mais un protocole spécifique à rdbhost, au dessus de HTTP (et qui a donc de fortes chances de passer les pare-feux). Pour les programmeurs Python, rdbhost fournit une bibliothèque conforme au standard « Python DB » (PEP 249).

Voici donc un exemple en Python :

from rdbhdb import rdbhdb
import sys

role = 'r0000000837'
authcode = 'trop secret'
conn = rdbhdb.connect (role, authcode)
conn.https = True
cur = conn.cursor()
cur.execute("INSERT INTO Test (data) VALUES ('%s')" % sys.argv[1])
cur.execute("SELECT * FROM Test")
for tuple in cur.fetchall():
    print tuple
conn.close()

On note le conn.https = True. Par défaut, la connexion n'est pas chiffrée et le mot de passe circule donc en clair. Un exemple de script plus riche est celui de chargement de la base de StackOverflow.

Pour créer les tables et les modifier, on peut utiliser des requêtes SQL DDL comme CREATE TABLE mais aussi une interface Web pratique, fournie par rdbhost.

Le service est gratuit, mais il vient avec un certain nombre de limites, comme un maximum de cent tuples en réponse à un SELECT. Si on veut stocker de grosses quantités de données, récupérer davantage de tuples, etc, il faut s'abonner au service payant. Et, naturellement, comme avec toute base de données hébergée, on n'a pas de garantie sur la confidentialité des données ou sur leur pérennité.

Il est donc indispensable de pouvoir sauvegarder ses données. Pour cela, rdbhost fournit un service de récupération du contenu de ses bases.

Le service est encore assez récent et on peut donc donner son avis sur Uservoice.

Il existe un certain nombre de services ayant des caractéristiques similaires (merci à Fil et à David Larlet pour leurs informations) :

  • SimpleDB d'Amazon ne fournit pas d'interface SQL, et la documentation se moque du monde en prétendant qu'avec des bases de données relationnelles, on ne peut pas ajouter de colonnes a posteriori.
  • RDS, d'Amazon, est par contre une vraie base relationnelle (mise en œuvre avec MySQL). Contrairement à rdbhost, on peut apparemment utiliser n'importe quel client MySQL, le protocole d'accès est celui du SGBD. RDS est payant, même pour les petites bases.
  • FathomDB utilise aussi MySQL. Il n'y a guère de détails sur le site Web et le service est actuellement en beta et je n'ai pas d'invitation.

Connaissez-vous d'autres services équivalents ?


L'article seul

Quelques pensées sur la faille de renégociation de TLS

Première rédaction de cet article le 18 novembre 2009
Dernière mise à jour le 25 novembre 2009


Beaucoup d'électrons ont déjà été secoués pour communiquer des informations sur la faille de sécurité de renégociation de TLS. Je ne vais pas martyriser davantage ces pauvres leptons, uniquement faire partager quelques réflexions que m'a inspiré cette faille.

J'ai d'autant moins l'intention d'expliquer en détail la faille que je ne suis pas un expert TLS. D'accord, j'ai lu la norme, le RFC 5246, mais cela ne suffit pas. Et, de toute façon, les articles de Marsh Ray, le découvreur (« Renegotiating TLS » ou d'Eric Rescorla, le gourou TLS de l'IETF (« Understanding the TLS renegotiation attack ») sont très clairs.

Non, je voudrais plutôt gloser sur quelques points liés à cette faille. D'abord, il faut se rappeler qu'il s'agit d'une faille du protocole, pas d'une mise en œuvre particulière. Les protocoles, comme les programmes, ont des bogues. L'utilisation (parfois) de méthodes formelles pour les spécifier n'a pas diminué le nombre de bogues. (Après tout, les programmes sont tous écrits dans un langage formel et ont quand même plein de bogues.) Néanmoins, certains choix d'implémentation peuvent aggraver la faille. Ainsi, OpenSSL, par défaut, permet la renégociation, même si l'application qui utilise cette bibliothèque n'a rien demandé. GnuTLS, au contraire, ne la permet que si l'application l'a explicitement demandée, ce qui rend ses utilisateurs moins vulnérables.

Ensuite, pourquoi y a t-il des failles dans le protocole TLS ? Une des raisons est sa complexité, le pire ennemi de la sécurité. La norme (RFC 5246) fait plus de cent pages et offre plein d'options et de choix, dont cette fameuse renégociation. Simplifier la norme, retirer des options non indispensables comme la renégociation, aurait probablement diminué le nombre de failles dans TLS.

Évidemment, dans le monde réel, les choses ne sont jamais aussi simples. Un protocole offrant moins de possibilités aurait peut-être eu moins de succès. Par exemple, avec HTTPS, si on n'a pas de possibilité de renégociation, la seule façon d'authentifier un client avec un certificat est d'exiger systématiquement le certificat au début de la session TLS. Il ne serait plus possible d'attendre la requête du client, puis de renégocier si cette requête s'avère nécessiter une authentification. Avoir deux serveurs, www.example.org et auth.example.org est bien sûr possible, mais pas forcément pratique (rendre public un document signifierait un changement d'URL, ce qui est presque toujours une mauvaise idée.

En relisant la liste des failles de sécurité qui ont affecté TLS et son prédécesseur SSL, on voit que la faille de renégociation n'est pas la première à reposer sur un problème de liaison (binding) entre deux élements du protocole. Les oublis de liaison sont une des erreurs les plus fréquentes dans les protocoles de sécurité. Supposons un protocole au dessus de TCP qui authentifie, mettons par cryptographie, au début de la connexion. On se croit en sécurité par la suite ? Erreur. Si les paquets TCP suivant l'authentification ne sont pas liés à la session qui a été authentifiée (par exemple par une MAC), l'attaquant pourra attendre l'authentification, puis injecter des paquets TCP mensongers qui seront acceptés. De même, dans la faille de renégociation, il n'y avait pas de liaison entre l'« ancienne » session (avant la renégociation) et la « nouvelle », ce qui permettait l'injection de trafic.

Ce qui nous amène aux solutions. Le correctif apporté par OpenSSL supprime simplement la renégociation (ce qui va dans la sens de mes remarques sur le danger des protocoles trop riches en fonctions). Mais cela va empêcher certaines applications de fonctionner. C'est donc un contournement, avec effets de bord désagréables, pas une vraie solution.

Une solution à plus long terme a été élaborée à l'IETF dans le groupe de travail TLS. Elle est décrite dans le RFC 5746. Son principe est de créer une liaison entre l'« ancienne » session et la nouvelle, par le biais d'une nouvelle extension TLS, nommée renegotiation_info. Le problème est que les clients TLS ne peuvent pas l'utiliser contre les anciens serveurs (qui ne connaissent pas cette extension) et que le déploiement risque donc d'être laborieux. Pendant un certain temps, les clients TLS auront donc le choix entre exiger cette extension (au risque de ne pas pouvoir se connecter) ou bien accepter le risque de tomber sur un serveur vulnérable à la faille de renégociation. (Il existe un projet concurrent, draft-mrex-tls-secure-renegotiation, qui inclus une bonne description de la faille.)

Et pour finir sur une note pratique, un bon moyen (merci à Kim-Minh Kaplan) pour tester si un serveur permet la renégociation (et est donc peut-être vulnérable) :

% openssl s_client -connect www.example.org:443     
CONNECTED(00000003)
...
R        <--- Tapez cette unique lettre pour commencer la renégociation
RENEGOTIATING
depth=2 /C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailAddress=ips@mail.ips.es
verify error:num=19:self signed certificate in certificate chain
verify return:0

Ici, le serveur était vulnérable, il a accepté la renégociation. Sinon, il aurait juste affiché :

RENEGOTIATING
 
[Puis plus rien]

L'article seul

Combiner DNSSEC avec les mises à jour dynamiques

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


Un certain nombre de zones DNS sont mises à jour par le protocole Dynamic Update du RFC 2136. Peut-on encore signer les données ainsi avitaillées, pour DNSSEC ? Même avec NSEC3 ? Même avec l'opt-out ? La réponse est oui.

Le fonctionnement le plus courant de DNSSEC est de signer la zone d'un coup, avec un outil comme dnssec-signzone de BIND ou comme ldns-signzone de ldns. Mais un tel mode n'est pas compatible avec les mises à jour dynamiques (dynamic updates) du RFC 2136).

Une solution est mise en œuvre par BIND, sous le nom de online key (cf. RFC 3007). Si le serveur a accès à la clé privée, il peut signer les nouveaux enregistrements qui arrivent. Les exemples suivants ont été testés avec la version beta de BIND 9.7. Ils marcheraient sans doute avec des versions antérieures mais la 9.7 apporte suffisamment de choses du point de vue de DNSSEC pour que cela vaille la peine.

Voici la configuration de BIND :

zone "example" {
        type master;
        allow-update {
              localhost; // Cette ACL est définie par défaut dans BIND
        };
        file "example.db.signed";
};

On est parti d'une zone ordinaire, qu'on a signé avec une clé de type NSEC3RSASHA1 (NSEC3 est normalisé dans le RFC 5155 et rend le recalcul des signatures plus délicat). La suite de l'évolution de la zone se fera uniquement par mise à jour dynamique.

Un exemple de script de mise à jour est :


#!/bin/sh

NUM=$(date +%s)
PID=$$

nsupdate -d <<EOF
  server ::1 8053
  zone example
  update add created-dyn-$NUM-$PID.example 3600 NS ns1.nic.example
  send
EOF

Il contacte le serveur local (adresse ::1), sur le port 8053 et lui demande d'ajouter un enregistrement pour le nom created-dyn-$NUM-$PID.example (qui n'existait pas avant). Ce genre d'ajout est typique de l'activité d'un TLD (une zone DNS ordinaire utiliserait plutôt des enregistrements de type A ou AAAA).

La mise à jour se passe bien :

% ./dynupdate      
Sending update to ::1#8053
...
;; UPDATE SECTION:
created-dyn-1258541343-2833.example.    3600    IN      NS      ns1.nic.example.
...
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:   1926
;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0

Et le serveur de noms note :

18-Nov-2009 11:27:47.327 client ::1#46234: updating zone 'fr/IN': adding an RR at 'created-dyn-1258541343-2833.example' NS
18-Nov-2009 11:27:47.708 zone fr/IN: sending notifies (serial 2222229958)

Et on peut vérifier que le serveur connait bien le nouvel enregistrement :

% dig +dnssec -p 8053 @::1 ANY  created-dyn-1258541343-2833.example.
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1019
...
;; AUTHORITY SECTION:
created-dyn-1258541343-2833.example.    3600    IN      NS      ns1.nic.example.
DE3SCFLTLOBRFQAAO85TGISFO23QDLO5.example. 5400 IN NSEC3 1 1 10 F00DCAFE FU8ND8DK3QVMR9JNDR9LIM31K0RPAS43 NS SOA TXT RRSIG DNSKEY NSEC3PARAM
...

Comme les enregistrements de délégation, les NS, ne font pas autorité, la réponse ne figure pas dans la section Réponse mais dans la section Autorité. Les enregistrements NSEC3 sont inclus dans la réponse mais ils ne sont pas modifiés par les ajouts dynamiques puisqu'on est en opt-out, on ne modifie pas les chaînes NSEC3 pour des enregistrements ne faisant pas autorité. (BIND découvre tout seul que la zone avait été signée avec opt-out, en regardant le champ Flags de l'enregistrement NSEC3 précédent, cf. section 3.1.2 du RFC 5155. L'enregistrement NSEC3PARAM ne peut pas être utilisé, car son champ opt-out est toujours à zéro, cf. section 4.1.2 du RFC 5155, cet enregistrement ne servant qu'à informer les serveurs secondaires.)

Passons maintenant à l'enregistrement d'un domaine signé, ayant un enregistrement DS, qui fera donc autorité. On modifie le script :


#!/bin/sh

NUM=$(date +%s)
PID=$$

nsupdate -d <<EOF
  server ::1 8053
  zone fr
  update add created-dyn-$NUM-$PID.example 3600 NS ns1.nic.example
  update add created-dyn-$NUM-$PID.example 3600 DS 24045 7 1 c5746...
  send
EOF

Et, cette fois, le nombre d'enregistrements NSEC3 dans la zone change, BIND en a ajouté automatiquement un.

Toutes ces signatures nécessitent évidemment que BIND aie accès à la clé privée (c'est-à-dire le fichier Kexample.+007+39888.private où 39888 est l'identicateur de la clé). BIND la cherche dans le répertoire indiqué par l'option directory. (BIND peut aussi utiliser PKCS #11 pour parler à un équipement qui garde la clé.)

Si jamais on a « retiré le tapis » de sous les pieds du serveur de noms, par exemple en déplaçant les clés (les fichiers Kexample...), logiquement, BIND n'arrive plus à signer :

18-Nov-2009 11:05:03.162 client ::1#32072: updating zone 'example/IN': found no private keys, unable to generate any signatures
18-Nov-2009 11:05:03.162 client ::1#32072: updating zone 'example/IN': RRSIG/NSEC/NSEC3 update failed: not found

et il renvoie donc SERVFAIL au client.

Enfin, on peut noter que, bien que le RFC 3007 le permettre, il n'est pas actuellement possible de calculer la signature dans le client avant de l'envoyer au serveur :

18-Nov-2009 12:29:36.777 client ::1#36479: updating zone 'example/IN': update failed: \
    explicit RRSIG updates are currently not supported in secure zones \
    except at the apex (REFUSED) 

Un bon article sur le même sujet, allant jusqu'à la création d'un service de DNS dynamique, est « How-To: Create your own 'DynDNS' Service ».


L'article seul

Faudra t-il désormais noter l'adresse IP et le port ?

Première rédaction de cet article le 12 novembre 2009


Les serveurs réseau qui tournent aujourd'hui enregistrent leur activité dans un journal où ils notent, en général, l'adresse IP de leur client. Vue l'évolution de l'Internet va t-il falloir également enregistrer le port dudit client ?

N'importe quel serveur réseau aujourd'hui, qu'il fasse du HTTP, du SMTP ou bien d'autres protocoles reposant sur TCP, note chaque connexion dans son journal. Par exemple, pour Apache, les entrées dans le journal ressemblent à :

192.0.2.235 - - [12/Nov/2009:15:38:31 +0100] "GET /feed.atom HTTP/1.0" 304 - "-" "Liferea/1.4.23 (Linux; fr_FR.UTF-8; http://liferea.sf.net/)" www.bortzmeyer.org
2001:db8:2f58:ce40:216:3eff:feb0:452f - - [12/Nov/2009:15:38:36 +0100] "GET /xml-to-csv.html HTTP/1.1" 200 18011 "http://www.google.fr/search?q=transformer+fichier+xml+en+csv" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1)" www.bortzmeyer.org

192.0.2.235 et 2001:db8:2f58:ce40:216:3eff:feb0:452f sont les adresses IP de deux clients. On enregistre l'adresse IP car elle permet, normalement, d'identifier de manière unique une machine. C'est en tout cas l'architecture originale de l'Internet.

Cette idée qu'une adresse IP est unique est largement répandue, y compris chez les non-techniciens. Par exemple, Cédric Manara attire mon attention sur un arrêt d'un tribunal, le 7 octobre 2009 à Paris, qui dit « les numéros IP étant attribués par l'IANA (Internet Assigned Numbers Agency [sic]), deux ordinateurs ne peuvent pas avoir la même adresse IP ».

L'affirmation n'est pas 100 % fausse mais elle est très simpliste et ne correspond plus à la réalité de l'Internet d'aujourd'hui.

D'abord, il faudrait préciser « deux ordinateurs ne peuvent pas avoir la même adresse IP en même temps » car les adresses IP sont couramment réaffectées. C'est probablement ce que fait Verizon (gérant de l'adresse citée dans le jugement).

Ensuite, l'IANA n'a pas de force de police et ne peut donc pas empêcher des gens de prendre sauvagement des adresses IP. À une époque, un opérateur européen s'était ainsi arrogé un préfixe IP qui fut finalement officiellement alloué à un opérateur kenyan. Avec l'épuisement des adresses IPv4, ce genre de squattage sera de plus en plus fréquent.

Un problème analogue est que l'architecture de l'Internet ne permet pas de s'assurer facilement de l'authenticité d'une adresse IP, vieux problème de sécurité bien connu (voir le RFC 2827). Avec UDP, utiliser une fausse adresse est trivial. C'est toutefois plus compliqué en TCP, qui est utilisé pour le courrier, ce qui affaiblit l'argument de la défense qui laissait entendre que n'importe qui pouvait facilement usurper une adresse.

Tout ceci est bien connu. Mais il y a un autre problème, plus récent. Le principe d'un espace d'adressage unique, commun à tout l'Internet, ne correspond plus à la réalité d'aujourd'hui. Avec les adresses IP privées du RFC 1918, (ce qui n'est pas le cas de celle citée, attention), des milliers d'ordinateurs ont la même adresse et utilisent ensuite le NAT. En Europe ou aux États-Unis, le partage ne concerne en général qu'un foyer ou qu'une entreprise (et donc tous les ordinateurs partageant cette adresse sont sous la même responsabilité). Mais, avec l'épuisement rapide des adresses IPv4, cela va changer et des NAT au niveau d'un opérateur entier, déjà courants en Asie ou en Afrique, vont se répandre.

Ce partage intensif d'adresses IP est tellement répandu que l'IETF, à sa réunion d'Hiroshima, s'est penchée sérieusement sur une normalisation du fait que l'identificateur, aujourd'hui, n'est plus l'adresse seule mais le couple adresse+port (merci à Rémi Desprès pour la discussion sur ce sujet). Un des documents qui discutent la question est l'Internet-Draft draft-ford-shared-addressing-issues (devenu depuis RFC 6269). Mais il y en a d'autres comme draft-ietf-geopriv-held-identity-extensions qui note « However, widespread use of network address translation (NAT) means that some Devices cannot be uniquely identified by IP address alone. ».

Revenons à notre journal. Tout cela veut dire que cela sera de moins en moins utile d'enregistrer uniquement l'adresse IP. Il faudra bientôt enregistrer également le port source utilisé par le client, et, si on veut de la traçabilité, que le routeur NAT conserve trace des correspondances entre une adresse IP interne et le couple {adresse IP publique, port} qu'il avait attribué à cette adresse interne. (Cette recommandation est devenue RFC deux ans après, avec le RFC 6302.) Verra t-on Apache écrire :

192.0.2.235:13174 - - [12/Nov/2009:15:38:31 +0100] "GET /feed.atom HTTP/1.0" 304 - "-" "Liferea/1.4.23 (Linux; fr_FR.UTF-8; http://liferea.sf.net/)" www.bortzmeyer.org
[2001:db8:2f58:ce40:216:3eff:feb0:452f]:48221 - - [12/Nov/2009:15:38:36 +0100] "GET /xml-to-csv.html HTTP/1.1" 200 18011 "http://www.google.fr/search?q=transformer+fichier+xml+en+csv" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1)" www.bortzmeyer.org

où 13174 et 48221 sont les ports source ? Apache ne savait pas autrefois enregistrer le port mais c'est possible désormais (merci à Tony Finch) en mettant dans le format %{remote}p (%p étant le port local au serveur). Les applications Web, elles, peuvent utiliser la variable CGI REMOTE_PORT.

(Notez la syntaxe légèrement différente pour IPv6, décrite dans la section 3.2 du RFC 3986. Ceci dit, le partage d'adresses n'ayant pas de raison d'être avec IPv6, vue l'abondance d'adresses, le problème ne devrait pas exister.)


L'article seul

Vélos en libre service à Hiroshima

Première rédaction de cet article le 8 novembre 2009


Il existe désormais de nombreuses villes dans le monde avec un système de vélos en libre-service. Hiroshima est en train de beta-tester le sien, baptisé E-cycle. J'ai pu le tester à l'occasion de la réunion IETF dans cette ville.


L'article complet

Festival Dreamination à Hiroshima

Première rédaction de cet article le 8 novembre 2009


Quelques photos du festival Dreamination, festival de sculptures lumineuses, qui se tient en ce moment à Hiroshima.


L'article complet

Noms de domaines IDN dans la racine

Première rédaction de cet article le 6 novembre 2009


L'annonce par l'ICANN le 30 octobre de la proche possibilité de demander l'introduction d'IDN dans la racine du DNS a suscité beaucoup d'articles, la plupart d'un niveau de désinformation consternant. Ce n'est pas étonnant de la part de médias professionnels, dont les contributeurs ne connaissent jamais leur sujet et ne cherchent jamais, mais cela a aussi été le cas de la part de sites d'information d'habitude plus sérieux comme LinuxFr.

Certes, c'est l'ICANN qui a commencé. Leur communiqué officiel contient des affirmations comme quoi par exemple les IDN représenteraient « The biggest technical change to the Internet since it was created four decades ago ». Pour voir le caractère ridicule de cette phrase, il suffit de se rappeler que, quarante ans auparavant :

  • Le DNS n'existait pas,
  • BGP n'existait pas et l'Internet (enfin, son ancêtre) était un réseau mono-opérateur (alors que sa principale caractéristique d'aujourd'hui est de ne pas dépendre d'un opérateur particulier),
  • IPv4 n'existait même pas.

Alors, de dire que les IDN sont un changement plus important que le DNS (vers 1985), BGP (1989) ou IPv4 (1983), c'est franchement grotesque.

Autre affirmation trompeuse de l'ICANN, prétendre que cette organisation aurait fourni un travail quelconque dans le domaine des IDN. La réalité est que la norme technique (le RFC 3490, aujourd'hui le RFC 5891) a été fait par l'IETF, les logiciels (comme la GNU libidn) développés par diverses équipes et les premiers déploiements, réalisés par des registres de noms de domaines comme ceux de .cn ou .jp. Malgré ces énormités, la plupart des articles ont repris le communiqué de l'ICANN tel quel.

Très peu ont expliqué ce qu'il y avait de nouveau dans l'annonce ICANN, le fait que le domaine de tête puisse désormais être en IDN, alors que, jusqu'à présent, en raison du blocage de l'ICANN, il restait en caractères latins.

Et les articles publiés ont même souvent rajouté des erreurs au communiqué ICANN. Quelques exemples :


L'article seul

La grande panne DNS de Chine de mai 2009

Première rédaction de cet article le 6 novembre 2009


Le 19 mai 2009, la Chine a connu sa plus grande panne de l'Internet. Sur le moment, de nombreux articles ont été publiés, sans détails pratiques la plupart du temps, à part le fait qu'il s'agirait d'un problème lié au DNS. Le 5 novembre, à la réunion OARC à Pékin, Ziqian Lu, de China Telecom, a fait un remarquable exposé détaillant les causes de la panne.

C'est un bel exercice de transparence, avec plein de détails techniques. Je ne suis pas sûr que les opérateurs Internet français en fassent autant, si une telle panne frappait la France.

Donc, le 19 mai vers 21 h, heure locale, les téléphones se mettent à sonner : « l'Internet est en panne ». China Telecom, mais également d'autres FAI, constate à la fois que les utilisateurs se plaignent mais que le trafic a chuté considérablement. Les « tuyaux » ne sont donc pas surchargés, bien au contraire. En outre, le service n'est pas complètement interrompu : parfois, cela marche encore un peu. En raison de la baisse du trafic, on soupçonne un problème dans le routage. Il faut un certain temps pour que quelqu'un remarque ces lignes dans le journal des serveurs de noms récursifs du FAI :

19-May-2009 22:21:13.186 client: warning: client 218.77.186.180#51939: recursive-clients soft limit exceeded, aborting oldest query
19-May-2009 22:21:13.213 client: warning: client 59.50.182.161#1151: recursive-clients soft limit exceeded, aborting oldest query

Et la vérité se fait jour : le problème est dans le service DNS récursif. La majorité des requêtes DNS échouent. Quelques unes passent, ce qui explique que l'Internet ne semble pas complètement en panne à certains utilisateurs. Comme presque toutes les activités Internet dépendent du DNS, le trafic réseau chute.

Pour résumer la panne, il y avait bien une attaque DoS mais, comme au billard, l'attaque n'a pas frappé directement les serveurs DNS. L'attaque a touché un service très populaire, Baofeng, qui distribue de la vidéo et de la musique. Les attaquants frappent un serveur de jeux en ligne et l'arrêtent. Rien d'extraordinaire, ce genre de choses arrive tous les jours sur l'Internet. Sauf que l'attaque stoppe également certains des serveurs du domaine baofeng.com, qui partagent la même infrastructure. Et que les logiciels clients de Baofeng, devant la panne, réagissent en faisant encore plus de requêtes DNS, qui restent sans réponse. Le logiciel résolveur utilisé par tous les FAI chinois, BIND, a une limite sur le nombre de requêtes DNS récursives en attente, 1000 par défaut. En temps normal, c'est largement suffisant mais, ici elle était vite remplie par les innombrables requêtes en attente des serveurs de baofeng.com.

Si vous gérez un récurseur BIND, vous pouvez voir l'état des requêtes en cours avec rndc :

% rndc status
...
recursive clients: 13/1900/2000

Le dernier chiffre est la limite dure au nombre de requêtes en attente (il se règle avec l'option recursive-clients dans named.conf). L'avant-dernier est la limite « douce » à partir de laquelle BIND commencera à laisser tomber des requêtes, provoquant le message ci-dessus. Le premier chiffre est le nombre de requêtes actuellement en attente.

En raison du nombre de clients attendant baofeng.com, cette limite a été vite dépassée, supprimant toute résolution DNS, même pour les domaines n'ayant rien à voir avec Baofeng. Pour votre récurseur, faites le calcul : prenez la différence entre la limite douce et le nombre de clients en temps normal (ici, c'est 1900 - 13, mettons 1900) et divisez là par le taux de requêtes : cela vous donnera une idée du nombre de secondes que vous pourrez tenir en cas de panne. Ici, si le taux de requêtes est de 100 par seconde (ce qui est une valeur pour un petit FAI), vous avez droit à seulement dix-neuf secondes de marge en cas de panne d'un gros domaine très populaire... La plupart des récurseurs ont probablement une valeur de recursive-clients trop basse.

Conclusion : si quelqu'un réussit à planter tous les serveurs DNS de google.com ou ebay.com, il peut théoriquement planter tout le DNS et donc tout l'Internet.

Dans le cas chinois, tous les résolveurs étaient des BIND (comme c'est probablement le cas dans la plupart des pays). Il n'a pas été possible de tester avec d'autres résolveurs comme Unbound mais rien n'indique qu'ils auraient fait mieux. Le choix des développeurs de BIND était d'avoir un tableau de taille limitée pour les requêtes en attente. Si ce tableau était par contre dynamique, le récurseur aurait, à la place, avalé toute la mémoire du serveur.

Quelques-uns des articles les moins mal informés qui ont été publiés sur cette panne :

Merci à Ziqian Lu pour ses explications détaillées.


L'article seul

Le hameçonnage n'a pas de rapport avec les IDN

Première rédaction de cet article le 3 novembre 2009


L'annonce par l'ICANN, le 30 octobre, de la possibilité d'avoir bientôt des IDN dans la racine, c'est-à-dire des domaines de tête en Unicode, a suscité la marée attendue de réactions provinciales et étroites de tous ceux qui regrettent qu'on ne puisse pas forcer ces insupportables chinois ou russes à utiliser la même écriture que nous. Un record dans ce domaine a été établi par l'ultra-nostalgique « ICANN Approves Domain Names We Can't Type ». Un des arguments avancés, très classique mais complètement faux, serait que les IDN favorisent le hameçonnage. Qu'en est-il ?

L'argument est que IDN permet des noms de domaine homographes, c'est-à-dire qui s'écrivent de manière visuellement identique (ou très proche). On risque alors de ne pas pouvoir distinguer PAYPAL.com et PΑYPAL.com (dans le second, il y a un alpha grec).

Les homographes existent bien, et ils n'ont pas attendu les IDN. Par exemple, google.com et goog1e.com sont quasi-homographes (regardez bien). Unicode multiplie leur nombre car les écritures humaines n'ont pas été conçues par des technocrates rationnels mais sont issues d'une longue évolution distribuée sur toute la planète. Unicode est donc complexe, car le monde est complexe.

Mais le problème n'est pas dans l'existence d'homographes. Il est dans le fait que ce problème n'a rien à voir avec le hameçonnage. Je reçois beaucoup de rapports de hameçonnage au bureau et aucun ne dépend jamais d'homographes. La plupart du temps, le hameçonneur ne fait aucun effort pour que l'URL soit vraisemblable : il utilise un nom comme durand.monfai.net, voire une adresse IP. Et pour cause, très peu d'utilisateurs vérifient la barre d'adresse de leur navigateur, ne serait-ce que parce qu'ils ne comprennent pas ce qu'elle contient et qu'ils n'ont eu aucune formation sur les noms de domaines. Le hameçonneur, escroc rationnel, ne se fatigue donc pas.

Parfois, il faut quand même un petit effort. On voit des noms comme secure-societegenerale.com pour tromper sur societegenerale.com. À part les spécialistes du DNS, qui comprennent sa nature arborescente et le rôle de chaque label du nom, qui verra que secure-societegenerale.com n'a aucun rapport avec societegenerale.com ?

Si vous ne faites pas confiance à mon vécu, regardez les nombreux articles de psychologie qui ont été consacrés au hameçonnage. Comme cette activité coûte cher aux banques, de nombreuses études scientifiques ont été faites pour mieux comprendre ce phénomène et pourquoi les utilisateurs se font avoir. Toutes concluent que le nom de domaine ne joue aucun rôle (et que donc l'argument d'homographie contre les IDN est du FUD). Voici une petite bibliographie (avec mes remerciements à Mike Beltzner de Mozilla) :

On peut aussi citer, sur une problématique proche, « So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users » de Cormac Herley, dont la section 4 parle de l'analyse d'URL. Et le rapport 2010 de l'Anti-Phishing Working Group dont la page 16 parle des IDN.

Mais, si toutes les études scientifiques montrent qu'il n'y a pas de connexion entre IDN et hameçonnage, pourquoi trouve t-on tant d'articles faisant ce lien ? La principale raison est l'ignorance : les journalistes ne connaissent pas leur sujet, ne cherchent pas (pas le temps) et se recopient donc les uns les autres, sans questionner l'« information » originale. Ce phénomène n'est d'ailleurs pas réservé aux journalistes professionnels et s'étend aux blogueurs, aux twitteurs, etc.

Mais il y a une autre raison : beaucoup, parmi les « élites mondialisées », qui parlent anglais, regrettent, plus ou moins explicitement, qu'il ne soit pas possible de faire rentrer toutes les langues humaines dans le lit de Procuste d'une seule langue. Les vagues accusations d'hameçonnage contre les IDN, jamais étayées, ne sont donc que l'expression en douceur de leur refus de l'internationalisation.


L'article seul

OpenDNSSEC, ou comment faciliter l'utilisation de DNSSEC

Première rédaction de cet article le 31 octobre 2009


Le fait que le DNS soit très vulnérable aux attaques d'empoisonnement (comme l'attaque Kaminsky) est désormais bien connu. On sait aussi que la seule solution à moyen terme est DNSSEC (mais des solutions à court terme, plus faciles à déployer, existent). Seulement, DNSSEC est un protocole complexe et les erreurs se paient cher, par une impossibilité d'accèder aux informations DNS. Il y a donc en ce moment plusieurs efforts visant à rendre DNSSEC plus digeste, comme par exemple OpenDNSSEC.

En quoi DNSSEC, tel que normalisé dans le RFC 4034 et suivants est-il complexe ? Certes, le protocole n'est pas pour ceux qui ont du jus de navet dans les veines (le RFC 5155 étant certainement le pire). Mais, après tout, cela ne concerne que les implémenteurs, les auteurs de logiciels comme BIND ou nsd. Les simples administrateurs système peuvent-ils, eux, ignorer la complexité de DNSSEC ? Pas complètement : en effet, une bonne part de la complexité réside dans les procédures qu'il faut suivre pour configurer correctement sa zone et surtout pour qu'elle le reste. En effet, le DNS classique était une statue de chat : une fois une zone configurée (et testée avec des outils comme Zonecheck), elle restait configurée. DNSSEC est un chat vivant : il faut aspirer ses poils, le nourrir et changer sa litière. (J'ai oublié qui m'a enseigné cette parabole la première fois. S'il se reconnait...) Quelles sont les tâches récurrentes avec DNSSEC ? Essentiellement la gestion des clés cryptographiques. Il est recommandé de changer ces clés régulièrement (la discussion exacte du pourquoi de cette recommandation a déjà fait bouger beaucoup d'électrons, je ne la reprends pas ici). Ce changement est très délicat car, à tout moment, la zone doit être validable. Or, la propagation des informations dans le DNS n'est pas instantanée. Par exemple, en raison des caches chez les résolveurs, notamment des FAI, une signature faite il y a des heures peut être encore disponible... et la clé qui a servi à cette signature doit l'être également. Changer une clé DNSSEC est une opération qui nécessite, soit des procédures manuelles très rigoureuses et parfaitement suivies, soit une automatisation par un logiciel. Et c'est le rôle d'OpenDNSSEC.

Il existe diverses solutions d'automatisation des procédures de changement de clés de DNSSEC. La plupart sont embryonnaires, les problèmes concrets de déploiement de DNSSEC sont assez récents (le RFC 6781 en donne une idée). Il y a des solutions sous forme d'un boîtier fermé (comme Secure64) ou bien en logiciel libre comme OpenDNSSEC. Ce dernier est encore en version béta et je préviens donc tout de suite il faut être prêt à bricoler un peu.

J'ai rédigé cet article en travaillant sur une machine Debian. OpenDNSSEC nécessite plusieurs programmes tiers et voici une liste non-exhaustive de ce qu'il faudra installer :

% sudo aptitude install libxml2-dev rubygems libopenssl-ruby \
          libsqlite3-dev libldns-dev libdns-ruby

Ensuite, il faut choisir le mécanisme de stockage des clés. La méthode la plus sûre est d'utiliser un HSM (Hardware Security Module), un boîtier qui génère les clés, les stocke, et fait les signatures cryptographiques. Certains HSM (à partir de la certification FIPS 140-3) sont en outre résistants aux attaques physiques : si vous essayez de les ouvrir, la clé privée est détruite. Vos clés sont ainsi parfaitement en sécurité.

Il existe une API standard pour accéder à ces HSM, PKCS #11 et la plupart des logiciels DNSSEC (comme, par exemple, le signeur de BIND) la gèrent. En pratique, toutefois, il semble que cela ne soit pas toujours aussi simple et on peut trouver facilement sur le Web beaucoup de récits désabusés...

En outre, ces HSM sont des engins relativements chers (apparemment à partir de 1 000 € en France) et difficiles à obtenir. Faites l'expérience avec des vendeurs nationaux de HSM comme Thales ou Bull en France : les commerciaux ne vous rappellent pas. Pour commencer, on va donc utiliser un stockage logiciel des clés, dans le système appelé SoftHSM (oui, c'est un oxymore), dû aux même auteurs que OpenDNSSEC. SoftHSM permet de stocker les clés en local, dans une base SQLite (qu'il faudra évidemment protéger avec soin, le matériel ne le faisant pas pour vous).

Bref, on installe SoftHSM, on n'oublie pas, comme la documentation l'indique, le ldconfig pour que les nouvelles bibliothèques soient trouvées, on initialise notre « HSM » :

% softhsm --init-token --slot 0 --label "OpenDNSSEC"

On devra alors, comme avec un vrai HSM, indiquer un « PIN », un mot de passe.

Le HSM étant prêt, on peut compiler et installer OpenDNSSEC. On édite son /etc/opendnssec/conf.xml pour indiquer le PIN :


         <Repository name="softHSM">
                <Module>/usr/local/lib/libsofthsm.so</Module>
                <TokenLabel>OpenDNSSEC</TokenLabel>
                <PIN>cestressecret</PIN>
         </Repository>

OpenDNSSEC est alors prêt à utiliser ce « HSM ». Il connait le nom de la bibliothèque à charger pour lui parler (/usr/local/lib/libsofthsm.so) et le PIN. Testons qu'il apparait bien dans la liste des HSM :

% sudo hsmutil list                  
hsm_session_init(): Incorrect PIN for repository softHSM

OK, faute de frappe en tapant le PIN, on recommence :

% sudo hsmutil list                 
Listing keys in all repositories.
0 key found.

Repository            ID                                Type      
----------            --                                ----      

C'est parfait. (Dans les versions d'OpenDNSSEC ultérieures, toutes les commandes sont préfixées de ods- donc on aurait écrit sudo ods-hsmutil list.) Il n'y a pas de clé mais, à ce stade, c'est normal (OpenDNSSEC les créera tout seul).

Maintenant, on configure OpenDNSSEC : quelles zones doit-il gérer, avec quels paramètres, etc. Les fichiers de configuration livrés contiennent déjà des paramètres par défaut (par exemple, clé RSA de 2048 bits pour la KSK, la Key Signing Key, périodes avant le renouvellement des clés, en suivant la syntaxe décrite en http://trac.opendnssec.org/wiki/Signer/Using/Configuration, etc). Je ne touche pas tout de suite à /etc/opendnssec/kasp.xml, qui contient les politiques de définition de ces paramètres et j'édite /etc/opendnssec/zonelist.xml qui contient la liste de mes zones :


   <Zone name="bortzmeyer.fr">
        <Policy>default</Policy>
        ...
        <Adapters>
               <Input>
                    <File>/var/opendnssec/unsigned/bortzmeyer.fr</File>
               </Input>
               <Output>
                    <File>/var/opendnssec/signed/bortzmeyer.fr</File>
               </Output>
...

Cette zone sera signée avec les paramètres par défaut (définis dans kasp.xml) et je dois mettre le fichier de zone non signé dans /var/opendnssec/unsigned/bortzmeyer.fr. (Attention pour ceux qui ont déjà utilisé le signeur dnssec-signzone de BIND : ici, on ne doit pas inclure les DNSKEY, OpenDNSSEC fait cela tout seul.)

Je compile les politiques (sudo ksmutil setup la première fois, sudo ksmutil update all ensuite ; comme indiqué plus haut, c'est ods-ksmutil dans les OpenDNSSEC récents). Je démarre alors les démons OpenDNSSEC :

% sudo ./ods-signerd
% sudo ./ods-enforcerd

Le premier est le signeur. Écrit avec la bibliothèque ldns, il réalise les opérations de signature (avec un vrai HSM, elles seraient largement déléguées au matériel). Le second démon, le policeur, fait respecter les politiques de remplacement des clés qu'on a définies.

Normalement, le policeur doit alors noter qu'il n'a pas de clés, et les générer. Vérifions :

% sudo hsmutil  list                
Listing keys in all repositories.
4 keys found.

Repository            ID                                Type      
----------            --                                ----      
softHSM               cc59d2b16e421c57eec35ed4ceae0099  RSA/1024  
softHSM               e17b1d0465e6976536119c872a353911  RSA/1024  
softHSM               fa8cdfc8da319311283b66fe55839212  RSA/2048  
softHSM               60b57dff6604cc35ec6fdd8aef7710a2  RSA/2048  

C'est parfait, on a deux ZSK (1024 bits par défaut) et deux KSK (2048 bits par défaut), une active et une prête à assurer le remplacement futur. On la publie en avance, pour être sûr qu'elle soit disponible dans les caches DNS.

De la même façon, la zone a dû être signée et le résultat mis en /var/opendnssec/signed/bortzmeyer.fr. Sinon, il faut regarder le journal pour savoir ce qui s'est passé. On peut aussi forcer OpenDNSSEC à signer tout de suite avec ods-signer sign bortzmeyer.fr. Par défaut, OpenDNSSEC ne fait pas le travail si la zone n'a pas changé pour on peut le convaincre de signer quand même avec ods-signer clear bortzmeyer.fr qui précède le ods-signer sign bortzmeyer.fr.

OpenDNSSEC permet de gérer plusieurs zones DNS donc si je veux voir uniquement les clés d'une zone, je me sers de --zone :

% sudo ksmutil key list  --zone bortzmeyer.fr  
SQLite database set to: /var/opendnssec/kasp.db
Keys:
Zone:                           Keytype:      State:    Date of next transition:
bortzmeyer.fr                   KSK           active    2010-10-27 13:14:39       
bortzmeyer.fr                   KSK           ready     next rollover             
bortzmeyer.fr                   ZSK           active    2009-11-26 13:14:39       
bortzmeyer.fr                   ZSK           ready     next rollover     

Je vois ainsi les clés, et le moment où elles seront remplacées (par la clé qui est dans l'état ready). --verbose affiche également le key tag (annexe B du RFC 4034), également mis par le signeur dans le fichier de zones et qu'affiche aussi dig avec l'option +multi, ce qui est pratique pour déboguer les zones une fois chargées :

% sudo ksmutil key list  --zone bortzmeyer.fr --verbose
SQLite database set to: /var/opendnssec/kasp.db
Keys:
Zone:                           Keytype:      State:   ... Keytag:
bortzmeyer.fr                   KSK           active   ... 24045
bortzmeyer.fr                   KSK           ready    ... 36168
...
% dig @192.0.2.1 +dnssec +multi DNSKEY bortzmeyer.fr
bortzmeyer.fr.          3600 IN DNSKEY 257 3 7 (
                                ...
                                ) ; key id = 24045

24045 étant le key tag de la KSK active.

OpenDNSSEC ne permet pas de mettre à jour automatiquement la clé dans la zone parente (en partie parce qu'il existe plusieurs protocoles différents pour cela, comme celui du RFC 4310). Mais il aide, en indiquant ce qu'il faut transmettre au parent, un enregistrement DS :

% sudo ksmutil key export --ds
SQLite database set to: /var/opendnssec/kasp.db

;active KSK DS record (SHA1):
bortzmeyer.fr.  3600    IN      DS      24045 7 1 c57467e055adde7fcad11...

;active KSK DS record (SHA256):
bortzmeyer.fr.  3600    IN      DS      24045 7 2 2d47e39d7f04237292760...

Seule la KSK actuellement active, la 24045, est ainsi « exportée » (avec deux algorithmes de hachage possibles).

OpenDNSSEC n'a pas de problèmes avec les petites zones. Si on essaie de signer des zones de plus d'un million d'enregistrements, il vaut mieux supprimé l'auditeur, encore trop bogué. L'auditeur a pour but de vérifier l'intégrité du fichier signé et sa conformité aux politiques décrites dans kasp.xml. S'il échoue, la zone signée n'est donc pas publiée. Comme il échoue souvent, je l'ai pour l'instant débrayé : suppression de <Auditor> dans conf.xml, de <Audit> dans kasp.xml et ods-ksmutil update pour prévenir les démons qui sont en cours d'exécution. Les signatures se dérouleront alors normalement.

Prochaines étapes, chers lecteurs :

  • Voir si on peut utiliser OpenDNSSEC avec les mises à jour DNS dynamiques (il semble que non),
  • Tester avec un vrai HSM,
  • Faire marcher l'auditeur.

L'article seul

Le prix Nobel d'Économie pour étudier les biens communs

Première rédaction de cet article le 30 octobre 2009


Effet amusant de la crise financière, le prix Nobel d'Économie, auparavant attribué uniquement aux économistes les plus ultra-capitalistes, partisans d'un marché à outrance, a retourné sa veste. Désormais, finies les modélisations mathématiques irréalistes, ayant pour seul but de justifier les réductions de salaire ou d'avantages sociaux. Maintenant, priorité aux économistes qui étudient le monde réel.

En 2009, le prix Nobel d'Économie est revenu à Elinor Ostrom et Oliver Williamson. La première est surtout connue pour son étude du fonctionnement des biens communs.

Dans un article du 12 octobre, Hervé Le Crosnier se félicite de cette décision du comité Nobel et estime que l'un des mérites d'Ostrom est d'avoir tordu le cou à la théorie simpliste de la tragédie des biens communs.

Cette théorie, formalisée dans un article célèbre de Garrett Hardin en 1968 part du cas d'un pré communal où chaque berger peut faire paître ses moutons. Rapidement, selon Hardin, le pré, qui n'est à personne puisqu'il est à tout le monde, est complètement dévasté et plus rien n'y pousse. L'article (court, seulement six pages, et où l'auteur nous inflige ses opinions sur à peu près tous les sujets, de la surpopulation à la publicité en passant par une réflexion quasi-eugéniste) ne détaille pas longuement ce cas. Mais l'exemple de la « tragédie des biens communs » est en général cité à l'appui de la propagande pro-privatisation : la solution est tout simplement de donner le pré à un ou plusieurs hommes riches qui vont s'en occuper... et taxer les bergers.

Je vous laisse lire l'excellent article d'Hervé Le Crosnier pour une explication de l'argument d'Ostrom contre cette théorie. Mais il y a un point qui me tient à cœur dans le problème de la tragédie des biens communs qui est rarement mentionné : c'est que le problème est artificiellement déséquilibré. Dans la description classique du problème, le pré est public mais les moutons sont privés. Donc, les dépenses (d'entretien et de régénération du pré) sont partagées entre tous alors que les bénéfices reviennent à 100 % au berger. Pas besoin d'être prix Nobel d'Économie pour voir que, dans ce cas, l'intérêt rationnel de chaque berger est d'épuiser le pré le plus vite possible. En effet, s'il y a N bergers et qu'ils sont en même temps, en tant que membres de la communauté, responsables équitablement du pré, les dépenses D provoquées par le surpâturage seront de D/N par berger, alors que le bénéfice dû à ce surpâturage, même s'il est très inférieur à D, est entièrement pour le berger. Le choix rationnel individuel est vite fait et, comme souvent, il mène à la ruine de tous. On voit ce genre de phénomènes tous les jours ; par exemple, dans le transport routier, le patron d'une entreprise de transport ne paie qu'une partie de l'usure de la route due à ses camions, via ses impôts, alors qu'il garde tous les bénéfices : les moyens de transport collectifs comme le train ne peuvent donc pas lutter.

Comme tous les articles célèbres, « Tragedy of the commons » est souvent cité et jamais lu. Car ces deux points sont centraux dans l'article d'Hardin (avec la pollution à la place du transport routier), beaucoup plus riche et nuancé que l'ultra-résumé qu'on cite tout le temps.

Et pas besoin d'avoir un doctorat en mathématiques pour se dire que le problème peut être résolu d'un côté (privatiser la terre commune) ou de l'autre (remettre en cause la propriété privée des moutons) : c'est la contradiction entre les deux modes de propriété - dépenses publiques et bénéfices privés - qui est la source du problème. (Là, par contre, Hardin s'est arrêté avant ce point.)

L'argument d'Ostrom est différent (mais pas incompatible) en insistant sur le fait que les biens communs ne sont pas seulement une ressource passive qu'on exploite mais aussi un espace politique, régulé par la communauté. Ce point a été traité, par exemple, par Eva Hemmungs Wirten dans ses études sur les glaneuses. Pour éviter qu'une glaneuse individuelle ne ramasse tout, un certain nombre de règles ont été élaborées par les glaneuses, ainsi qu'une méta-règle, glaner uniquement en plein jour, pour garantir la transparence du processus.


L'article seul

NKM fait l'éloge des crapauds fous

Première rédaction de cet article le 30 octobre 2009
Dernière mise à jour le 1 novembre 2009


Cela fait longtemps que je n'avais pas lu le livre d'une politique en activité. Vous savez, ces livres écrits par des nègres qui s'intitulent « Ma vision », « Mon ambition pour la France » voire « Désir d'avenir ». Je viens d'acheter, le jour de sa parution en fanfare, « Tu viens ? », de Nathalie Kosciusko-Morizet.

Hélas, pas de surprises. Pour 12 € 90, le contenu est très limité en quantité (175 pages), et surtout en idées. Bon, je veux bien passer sur le nombre de pages, après tout l'auteure est une cumularde (maire et ministre en même temps et je ne mentionne pas ses activités familiales, car si elle était un homme, personne ne le ferait) et manquait donc de temps.

Mais le manque d'idées est plus sérieux. Si Nathalie Kosciusko-Morizet n'arrête pas de déplorer le manque d'élan de la politique, l'absence de grands rêves, et le caractère bien terre-à-terre de nos ambitions, elle ne propose rien. Aucun grand projet exaltant ne semble suggéré. Elle appelle à écouter les « prophètes » et les « crapauds fous » (ceux qui ne se dirigent pas aveuglément vers la même mare que tous les autres) mais elle-même prend bien soin de ne pas se placer dans cette catégorie. Elle a quelques idées (sur l'écologie, le rôle de l'argent, la consommation, d'ailleurs, on se dit de temps en temps en lisant le livre qu'il faudrait qu'une âme charitable la prévienne qu'elle est dans un gouvernement de droite, elle semble l'oublier souvent). Mais pas de propositions.

Sur la forme, je trouve le ton et les références à Thoreau ou Saint Augustin assez pédantes mais, bon, chacun écrit comme il veut.

La campagne médiatique organisée par les communiquants fait référence à ce livre comme le « premier livre politique 2.0 », car on peut envoyer des commentaires via un site Web. J'ai essayé mais c'est davantage « Web 1.0.1 » que « Web 2.0 ». Les commentaires sont limités à mille caractères, modérés a priori, et la liste des menaces légales à lire avant d'écrire a de quoi sérieusement décourager le crapaud pas trop fou. C'est néanmoins sur le site officiel que j'ai trouvé la meilleure analyse du livre, « Non, je ne viens pas ». Sylvius Aeneas s'y moque à juste titre d'une « ministre de l'Internet » qui n'a rien à dire sur Hadopi. Le gouvernement dont elle fait partie multiplie les mesures liberticides contre Internet pendant Nathalie Kosciusko-Morizet relit Saint-Augustin. (Depuis que cet article a été écrit, Nathalie Kosciusko-Morizet a explicitement pris position en faveur de la loi répressive Loppsi.)

J'ai personnellement tenté deux contributions, en essayant de suivre lesdites règles. Une a été affichée, l'autre (qui me semblait bien plus modérée, et purement factuelle) rejetée, sans explications : « Nous sommes au regret de vous dire que votre contribution, parce qu'elle contrevient à la charte de notre site ou bien qu'elle ne répond pas à l'une des six questions posées, ne sera pas publiée sur le site www.tuviens.fr. [...] Merci de ne pas répondre à cet email, votre réponse ne sera pas traitée. »

Sur la politique de Nathalie Kosciusko-Morizet, j'approuve complètement l'article de bluetouff, « À quoi sert Nathalie Kosciusko-Morizet ? » (vous vous doutez de la réponse...)


L'article seul

RFC 5702: Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC

Date de publication du RFC : Octobre 2009
Auteur(s) du RFC : J. Jansen (NLnet Labs)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsext
Première rédaction de cet article le 28 octobre 2009
Dernière mise à jour le 28 juin 2010


La cryptanalyse progresse sans cesse et, comme aiment le répéter les experts, « Les attaques ne deviennent jamais pires, elles ne font que s'améliorer ». Les menaces contre la fonction de hachage SHA-1 devenant de plus en plus précises, cet algorithme est petit à petit remplacé par la famille SHA-2. Ce RFC 5702 spécifie ce futur remplacement pour le protocole DNSSEC.

Normalisé dans le RFC 4033 et suivants, DNSSEC, qui vise à garantir l'authenticité des ressources DNS par le biais d'une signature numérique, n'est pas lié à un algorithme particulier. Aussi bien l'algorithme asymétrique utilisé pour les signatures que celui de hachage qui sert à créer un condensat des données à signer ne sont pas fixés en dur dans le protocole. SHA-1 avait été spécifié dans le RFC 3110. Un registre IANA des algorithmes possibles existe et notre RFC 5702 marque l'entrée de la famille SHA-2 dans ce registre.

Il n'est pas évident de savoir si SHA-1 est vraiment vulnérable dès aujourd'hui. Plusieurs attaques ont été publiées dans la littérature ouverte (et il y en a donc sans doute bien d'autres, gardées secrètes) mais elles ne semblent pas facilement exploitables, surtout dans le cas de l'utilisation particulière qu'en fait DNSSEC. Néanmoins, le remplacement de SHA-1 était une nécessité, compte-tenu du fait que les attaques ne peuvent que s'améliorer (voir la section 8 pour un exposé plus détaillé), et parce qu'un tel remplacement prend du temps (par exemple, l'élaboration de ce RFC a été très longue).

Le remplaçant, SHA-2, décrit dans la norme FIPS 180-3 de 2008, n'est pas vraiment un algorithme unique mais une famille d'algorithmes. DNSSEC n'en retient que deux, SHA-256 (code 8) et SHA-512 (code 10). Voir la section 1 du RFC pour ces rappels.

SHA-2 est utilisable dans les enregistrements de type DNSKEY (clés cryptographiques distribuées par le domaine) et RRSIG (signature cryptographiques). Le RFC 4034 décrit tous ces types d'enregistrement.

La section 2 décrit les enregistrements DNSKEY. Comme la clé publique ne dépend pas de l'algorithme de hachage utilisé ultérieurement, on pourrait penser qu'ils ne sont pas modifiés. Mais il est important d'indiquer au résolveur cet algorithme de hachage car tous les résolveurs ne connaissent pas SHA-2 du jour au lendemain. Il faut donc qu'ils sachent tout de suite, en examinant la clé, s'ils pourront valider la zone ou pas. (Sinon, ils considéreront la zone comme étant non signée.) Les DNSKEY avec RSA + SHA-256 sont donc stockés avec le même format qu'avant, mais avec le numéro d'algorithme 8. Les DNSKEY avec RSA + SHA-512 auront, eux, le numéro d'algorithme 10.

Les signatures (enregistrements RRSIG) sont, elles, plus largement modifiées. La section 3 décrit ces modifications. Elle indique la représentation à suivre pour les RRSIG, suivant le standard PKCS #1 (RFC 3447).

Les signatures faites avec RSA + SHA-256 seront stockées avec le numéro d'algorithme 8 et leur codage aura un préfixe spécifique, pour les distinguer des signatures faites avec d'autres fonctions (section 3.1). Idem pour celles faites avec RSA + SHA-512 (section 3.2).

Et les problèmes pratiques du déploiement ? Pas de panique, ils sont dans la section 4. La taille des clés elle-mêmes n'est pas couverte (section 4.1) mais déferrée aux recommendations du NIST. La taille des signatures dépend de celle de la clé, pas de l'algorithme de hachage et ne changera donc pas (section 4.2).

Quels logiciels peuvent aujourd'hui utiliser ces algorithmes ? Pour BIND, ce sera à partir de la version 9.7 (actuellement en béta publique, mais sans SHA-2). Pour ldns, c'est déjà disponible dans la version actuelle, la 1.6.1 (mais tous les paquetages binaires de ldns n'ont pas forcément été compilés avec l'option --enable-sha2). La section 5 donne quelques détails pour les programmeurs, notamment sur la raison pour laquelle il n'y a plus de version spécifique à NSEC3 (section 5.2 et RFC 5155).

Voici un exemple d'utilisation du programme ldns-keygen (livré avec ldns) pour générer des clés utilisant SHA-256 pour la zone vachement-secure.example :

% ldns-keygen -a RSASHA256 vachement-secure.example
Kvachement-secure.example.+008+23094

% cat Kvachement-secure.example.+008+23094.key 
vachement-secure.example.       3600    IN      DNSKEY  256 3 8 \
      AwEAAc87fkhQ3RehZ9AWUtataphm6Ku+DLKgtUPp/Zi0mwhtDN36oWBhzUt5a82Zeat4zsbC6WjIDWWqOx33cWh3ISMKDK0cOu1kMRCZTXS98WoSA0TgfMBdGdaK/Z+yLX+COq8HL72gBDG/RuDqIOwdtCBhbDluIwafzPAw3l2rIEiR \
      ;{id = 23094 (zsk), size = 1024b}

Et lorsqu'on la signe :

% ldns-signzone  vachement-secure.example.zone Kvachement-secure.example.+008+23094

% cat vachement-secure.example.zone.signed
...
.       3600    IN      SOA     localhost. root.localhost. 1 604800 86400 2419200 604800
.       3600    IN      RRSIG   SOA 8 0 3600 \
                    20091125150944 20091028150944 23094 . nvIldICQaBpHR/Fn264gL
7bl5RCzzM6h3S5o6k/yq9cFRhYpOO4FQGfozP2q8A7whoHfymCg1D6harOt7b0ffO+TA1iBddpF1DJLQ/DKPhfS2REqXbXjpveU3uQNK
g0jOdj7G6hrSQl9wXg3Co5yL84jG33oSlDWQM9QhKUyAUk= \
                    ;{id = 23094}

Comme il y a déjà eu des attaques de cryptanalyse contre SHA-1 publiées, la section 8, qui synthétise les questions de sécurité, recommande donc d'utiliser SHA-2 pour les futurs déploiement de DNSSEC.

Enfin, la section 8.2 explique pourquoi SHA-2 n'est pas vulnérable aux attaques par repli : si une zone a deux clés, utilisant SHA-1 et SHA-2, un méchant ne peut pas forcer l'utilisation de l'algorithme le plus faible car les enregistrements DNSSEC doivent être signés avec toutes les clés présentes.

Si on veut voir des signatures en vrai, la racine, et des TLD comme .pm sont signés (au 28 juin 2010) avec SHA-256, tandis que .cat est signé avec SHA-512. Sinon, on peut trouver des exemples de DNSKEY et de RRSIG utilisant SHA-2 dans la section 6 du RFC, ou bien les générer soi-même comme dans l'exemple ci-dessus.


Téléchargez le RFC 5702


L'article seul

RFC 5693: Application-Layer Traffic Optimization (ALTO) Problem Statement

Date de publication du RFC : Octobre 2009
Auteur(s) du RFC : J. Seedorf (NEC), E. Burger (Neustar)
Pour information
Réalisé dans le cadre du groupe de travail IETF alto
Première rédaction de cet article le 28 octobre 2009


Le groupe de travail Alto de l'IETF est chargé de développer un protocole permettant aux participants d'un réseau pair-à-pair de trouver le pair le plus « proche », pour améliorer la communication ultérieure et consommer moins de ressources réseau. Ce premier RFC officiel du groupe décrit le problème à résoudre.

Le fond du problème est que les pairs ne connaissent pas la topologie du réseau. Disposant de trop peu d'informations, ils risquent de choisir, parmi les pairs potentiels, un pair situé très loin d'eux, ce qui se traduira par une capacité réseau inférieure, et une utilisation exagérée des lignes à longue distance, alors que des réseaux à courte distance, moins chargés, étaient disponibles. Le but d'Alto est donc de donner aux pairs le moyen de faire des choix meilleurs que le simple hasard.

Le problème n'est d'ailleurs pas limité aux applications pair-à-pair. Comme le rappelle la section 1, les applications client/serveur traditionnelles ont également parfois à choisir entre plusieurs sources, pour une même ressource (« vais-je télécharger mon image ISO de NetBSD depuis ftp.nl.netbsd.org ou bien ftp.de.netbsd.org ? »). L'Internet est actuellement exploitée de manière très peu « développement durable ». Les applications gourmandes comme le chargement de vidéos ou l'échange de fichiers multimédia consomment beaucoup de capacité du réseau, sans faire d'effort pour minimiser cette consommation.

Comme dans l'exemple de la distribution de NetBSD ci-dessus, la ressource convoitée est aujourd'hui souvent disponible depuis plusieurs sources, chacune ayant une réplique de la ressource (section 1.1). Mais les applications ne disposent pas d'éléments suffisants pour choisir la réplique la plus proche. Des heuristiques comme le pays (dans l'exemple de NetBSD ci-dessus) sont très insuffisantes car la connectivité n'épouse pas les frontières nationales. Les mesures comme celle du RTT (mises en œuvre par un logiciel comme netselect) ne donnent pas d'informations sur la capacité du réseau (cf. RFC 5136), ni sur le coût des différentes lignes (par exemple entre transit et peering). Voici un exemple avec netselect, où il affiche le serveur ayant le plus faible RTT (l'algorithme exact de netselect est plus riche, voir la documentation) :

% netselect  ftp.be.netbsd.org ftp.nl.netbsd.org  ftp.de.netbsd.org ftp.es.netbsd.org  
   25 ftp.be.netbsd.org

et, en plus détaillé :

% netselect -vv ftp.be.netbsd.org ftp.nl.netbsd.org  ftp.de.netbsd.org ftp.es.netbsd.org
Running netselect to choose 1 out of 5 addresses.       
....................................
ftp.be.netbsd.org                       11 ms  11 hops  100% ok (10/10) [   23]
192.87.102.43                         9999 ms  30 hops    0% ok
192.87.102.42                         9999 ms  30 hops    0% ok
ftp.de.netbsd.org                       24 ms  10 hops  100% ok (10/10) [   48]
ftp.es.netbsd.org                       17 ms  10 hops  100% ok (10/10) [   34]
   23 ftp.be.netbsd.org

Face à ce problème, plusieurs groupes ont expérimenté des solutions visant à donner davantage d'information aux applications (cf. par exemple le RFC 5632, et le RFC 6029 pour une étude détaillée des propositions techniques existantes). Si cela viole un peu le modèle en couches (pour lequel l'application devrait être totalement ignorante du réseau sous-jacent), cela permet en général une nette augmentation des performances et une diminution de la consommation de ressources.

L'état de l'art est résumé dans la section 1.2 du RFC. Outre le RFC 5632, on peut consulter les références données dans le RFC comme « P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers ». Ces solutions ont en commun de fournir un mécanisme de découverte de la source d'information et, une fois qu'on a trouvé celle-ci, un mécanisme d'interrogation de la source, pour récupérer les informations qui permettront de prendre une bonne décision.

La section 2 définit les (nombreux) termes utilisés par Alto. Le schéma des protocoles est particulièrement recommandé, il illustre notamment le fait qu'Alto n'est concerné que par la récupération de l'information depuis les serveurs Alto, pas par la manière dont cette information a été récoltée par les serveurs.

Enfin, le problème qu'Alto veut résoudre est défini rigoureusement dans la section 3. Dans un environnement où on veut une ressource (un fichier MP3, par exemple), pas une machine spécifique, il s'agit de trouver la meilleure machine pour la communication, parmi un ensemble de machines qui hébergent la même ressource. « Meilleure » peut signifier plusieurs choses, débit, coût ou même d'autres critères comme la volonté de ne pas concentrer tous les « clients » sur un seul « serveur ». En tout cas, « meilleur » doit être simplement « meilleur qu'en tirant au hasard », ce choix aléatoire étant la référence de base.

Dans quels cas un protocole de type Alto serait-il utile ? La section 4 donne des exemples de scénarios. Par exemple, le partage de fichiers (section 4.1) est une application courante et très gourmande, les fichiers en question étant souvent du gros multimédia. Si je veux télécharger un film, la quantité de données à faire passer par le réseau justifie certainement de passer quelques secondes à choisir la ou les meilleures machines d'où le charger.

Même chose lorsqu'il faut choisir, dans un protocole client/serveur traditionnel comme HTTP (section 4.2), le meilleur « miroir » d'un site donné (comme dans l'exemple de NetBSD plus haut).

Il existe encore plusieurs exemples comme l'utilisation d'Alto pour aider à construire une DHT (section 4.5).

Alto soulève plein de questions (comme l'avait montré la réunion animée à Dublin). La section 5 tente d'y répondre. D'abord, quelle information doit être distribuée par Alto (section 5.1) ? Pour éviter de surcharger le protocole, il faut développer des critères permettant de dire ce qu'on distribue et ce qu'on ne distribue pas. On ne distribue certainement pas avec Alto de l'information très temporaire comme la congestion. Alto devrait servir à transporter de l'information relativement stable et, surtout, que l'application ne peut pas obtenir facilement elle-même. La mesure du RTT, par exemple, n'a pas besoin d'Alto. Mais séparer les liens Internet chers de ceux bon marché ne peut jamais être découvert par l'application et doit donc être fourni par Alto. Même chose pour toutes les notions « comptables » comme le quota restant, dans le cas d'une connexion Internet facturée à l'usage (notez que la plupart des offres Internet sur mobile sont dans ce cas, même si la publicité mensongère des opérateurs les nomme « Internet illimité ».

Et qui va rassembler l'information que les serveurs Alto distribueront (section 5.2) ? A priori, on pourrait imaginer que cela soit fait par les opérateurs (qui connaissent leur réseau), des tiers qui bénéficient de certaines informations fournies par les opérateurs (un bon exemple est Akamai) ou bien, en style davantage « 2.0 », des communautés d'utilisateurs travaillant de manière décentralisée.

Le service Alto pourra donc être présenté de manière différente (section 5.3). Il pourrait être un service centralisé ou bien être lui-même pair-à-pair. Il faudra donc prévoir un mécanisme de découverte, pour savoir où s'adresser.

Évidemment, les applications utilisée peuvent manipuler des données privées. Si j'utilise une application pair-à-pair pour récupérer des films pornos, je n'ai pas forcément envie que mon FAI soit au courant, même si c'est une activité parfaitement légale. La section 5.4 explore donc la question de la protection de la vie privée. Le serveur Alto souhaiterait avoir le plus d'informations possibles pour prendre la meilleure décision, mais l'utilisateur doit avoir un moyen de ne pas trop en dire. Un problème analogue est celui de la protection des données confidentielles de l'opérateur réseau. Celui-ci ne souhaite pas forcément que ses clients soient au courant de la topologie du réseau (section 5.5).

Enfin, le problème de la coexistence avec les caches fait l'objet de la section 5.6.

Alto pose aussi des questions liées à la sécurité (section 6). Si les problèmes de mise en œuvre du contrôle des contenus sont explicitement exclus, d'autres questions restent posées. Par exemple, comme le serveur Alto peut influencer le processus de choix d'un pair (c'est son but), Alto introduit une tierce partie dans le dialogue pair-à-pair et donc un composant de plus pour l'analyse de la securité.

Ainsi, si le serveur Alto est géré par le FAI, certains utilisateurs peuvent ne pas avoir envie de l'utiliser car ils craignent (à juste titre quand on voit le comportement de certains FAI) que le FAI ne se serve d'Alto pour imposer les quatre volontés de Warner ou de Disney, ou bien pour espionner l'activité de certains utilisateurs, ou encore pour appliquer des politiques de sélection qui sont dans l'intérêt du FAI mais pas dans celui des utilisateurs (faire passer par des routes lentes mais moins chères, par exemple).

Toutefois, il n'est pas envisagé de rendre Alto obligatoire. Si certains serveurs Alto n'agissent plus dans l'intérêt des utilisateurs, le plus simple sera de ne pas les utiliser.


Téléchargez le RFC 5693


L'article seul

RFC 5668: Four-octet AS Specific BGP Extended Community

Date de publication du RFC : Octobre 2009
Auteur(s) du RFC : Y. Rekhter (Juniper Networks), S. Sangli (Cisco Systems), D. Tappan
Chemin des normes
Première rédaction de cet article le 28 octobre 2009


Depuis le RFC 1997 en août 1996, les annonces BGP effectuées par un routeur sont fréquemment marquées par une communauté, un nombre qui identifie des caractéristiques particulières d'une route, comme, par exemple, le fait qu'elle ne doive pas être réexportée vers d'autres AS. Ces communautés étaient traditionnellement encodées sous la forme { numéro d'AS : valeur de la communauté } en profitant du fait que les communautés du RFC 1997 faisaient quatre octets (deux pour l'AS et deux pour la valeur spécifique à l'AS). Avec l'arrivée des AS sur quatre octets, il fallait un nouveau type de communauté.

Le RFC 1997 recommandait ce type d'encodage, qu'on retrouve dans la documentation des politiques de routage de nombreux AS. Par exemple, whois -h whois.ripe.net AS3356 nous montre :

remarks:        --------------------------------------------------------
remarks:        prefix type communities
remarks:        --------------------------------------------------------
remarks:        3356:123  - Customer route
remarks:        3356:666  - Peer route
remarks:        --------------------------------------------------------
remarks:        error type communities
remarks:        --------------------------------------------------------
remarks:        3356:911  - "internal use" communities received from peer
remarks:        --------------------------------------------------------
remarks:        city communities (some cities not listed as they home off
remarks:        one of the below)
remarks:        --------------------------------------------------------
remarks:        3356:2001 - CHI1 - Chicago
remarks:        3356:2002 - SDG1 - San Diego
remarks:        3356:2003 - LAX1 - Los Angeles
remarks:        3356:2004 - DEN1 - Denver
...

où on voit une communauté encodée sous forme de numéro d'AS (3356), d'un deux-points et d'une valeur.

Mais, depuis le RFC 4893, en mai 2007, les numéros d'AS peuvent faire quatre octets et, à partir du 1er janvier 2010, ce sera même la taille par défaut, distribuée par les RIR. L'ancien encodage ne convenait pas.

Notre RFC 5668 propose donc un nouveau mécanisme. Il s'appuie sur les « communautés étendues » du RFC 4360, qui normalisait un type de communauté n'ayant plus la limitation des quatre octets et où les deux premiers octets indiquaient le type de communauté.

Notre RFC 5668 déclare donc un nouveau type de communauté étendue, pour les AS à quatre octets. Sa structure est détaillé dans la section 2. Le premier octet du champ Type du RFC 4360 vaut 0x02 pour les communautés transitives et 0x42 pour les autres (le tout est enregistré dans le registre IANA). Le champ Valeur de la communauté étendue, pour qui le RFC 4360 réserve six octets est séparé en deux, la partie Global Administrator, qui stocke l'AS sur quatre octets, et la partie Local Administrator, qui stocke une valeur spécifique à l'AS, sur les deux octets restants.

Petit piège mentionné en section 3, bien que ces communautés étendues pour AS 4-octets permettent de représenter les anciens AS 2-octets (en ajoutant des zéros devant), cela ne doit pas être fait, pour éviter qu'une communauté puisse être codée de deux façons différentes (ce qui compliquerait les comparaisons).

Il n'y a pas de nouvelle représentation texte standard de ces communautés, on reprend l'existante, comme dans l'exemple de l'AS 3356 plus haut.


Téléchargez le RFC 5668


L'article seul

RFC 5692: Transmission of IP over Ethernet over IEEE 802.16 networks

Date de publication du RFC : Octobre 2009
Auteur(s) du RFC : H. Jeon (ETRI), M. Riegel (NSN), S. Jeong (ETRI)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF 16ng
Première rédaction de cet article le 28 octobre 2009


Le système de transmission radio par micro-ondes Wimax, normalisé par l'IEEE sous le numéro de 802.16, offre une interface Ethernet aux protocoles de couche réseau comme IP. À première vue, on pourrait penser qu'il n'y a donc rien de spécial à faire pour faire fonctionner IP sur Wimax. En fait, ce système offre suffisamment de particularités par rapport à l'Ethernet filaire pour que ce RFC soit nécessaire, pour normaliser les points de détails où il faut s'écarter de l'usage classique d'Ethernet.

Parmi les points importants de Wimax, système conçu pour fonctionner à grande distance, contrairement au Wifi :

  • Il n'est pas pair-à-pair. Les machines connectées (nommées SS pour Subscriber Station) ne peuvent pas se parler directement, elles doivent passer par la station de base (BS pour Base Station).
  • Wimax est orienté connexion et non pas datagramme : la machine ne peut pas transmettre avant une négociation avec la station de base, qui lui alloue un canal et des ressourecs.
  • Il n'y a pas de vraie diffusion : une machine qui veut parler à toutes les autres doit transmettre à la station de base, qui diffusera.
  • Comme souvent avec les transmissions radio, les machines qui l'utilisent peuvent avoir des ressources limitées, notamment en électricité, et il faut éviter de les activer pour un oui ou pour un non.
  • Wimax offre, entre autres, une interface (un convergence layer, dans la terminologie IEEE) Ethernet. Mais Ethernet avait été prévu pour un bus, un média partagé, alors que Wimax est point-à-multipoint.

La norme IEEE 802.16 est très riche et complexe et beaucoup d'options qu'elle présente peuvent avoir une influence sur IP.

Le défi de ce RFC 5692 (section 1) est donc de profiter de l'interface Ethernet de Wimax, tout en l'optimisant pour l'usage d'IPv4 et IPv6, sans abandonner les principes de base de l'IP sur Ethernet. Le cahier des charges détaillé avait fait l'objet du RFC 5154.

La section 4 décrit le modèle d'IEEE 802.16. Chaque connexion entre la SS (la machine qui se connecte) et la BS (la station de base) reçoit un identificateur sur 16 bits, le CID (Connection Identifier). Il peut y avoir plusieurs connexions entre une BS et une SS. L'acheminement des paquets se fait avec le CID, pas avec l'adresse MAC de l'interface Ethernet.

La section 4.2 couvre les subtilités de l'adressage 802.16. Chaque SS a une adresse MAC sur 48 bits, comme avec Ethernet. Mais la commutation des paquets par la BS se fait uniquement sur la base des CID, les identificateurs des connexions SS<->BS. L'adresse MAC sources des paquets sur un lien radio n'est donc pas forcément celle d'une des deux stations, puisque la BS peut relayer des messages, jouant le rôle d'un pont.

Contrairement au vrai Ethernet, il n'y a pas de diffusion (globale ou restreinte) avec Wimax. La BS peut diffuser à toutes les SS mais si une SS veut en faire autant, elle doit transmettre à la BS, qui reflétera le paquet vers toutes les stations (section 4.3 et annexe A).

Les concepteurs de 802.16, conscients de l'importance d'Ethernet dans le monde des réseaux, avaient prévu dans la norme un mécanisme (et même deux) pour la transmission de paquets au format Ethernet. Comme l'explique la section 4.4, le premier de ces mécanismes, Packet Convergence Sublayer permet d'affecter différents protocoles au dessus d'Ethernet à des connexions différentes (et donc d'avoir des QoS différentes).

Ethernet n'est pas seulement un format de paquets, c'est aussi un modèle de réseau où toute station d'un même Ethernet peut parler directement à n'importe quelle autre. Ce n'est pas le cas, on l'a vu, pour 802.16, et il a donc fallu introduire un pont, rôle joué par la station de base, la BS (section 5). Ce mécanisme n'est pas très différent de celui de l'Ethernet filaire commuté (section 5.1). Comme un commutateur, la BS transmet aveuglément les paquets d'une station d'abonné, une SS, à une autre.

Il reste à réaliser la diffusion (broadcast). Comme indiqué plus haut, et précisé en section 5.2, la BS réalise une diffusion en dupliquant les paquets, un exemplaire par SS destinataire.

Bien, maintenant que le modèle de la liaison et celui de l'émulation Ethernet sont clairs, comment faire passer IP là-dessus ? C'est le rôle des techniques exposées en section 6. Les sections 6.1 et 6.2 font un rappel de la méthode habituelle de transmission d'IP sur Ethernet. Décrite dans les RFC 894 pour IPv4 et RFC 2464 pour IPv6, cette méthode décrit l'encapsulation d'IP dans Ethernet, et la résolution d'adresses IP en adresses MAC par les protocoles ARP (RFC 826, pour IPv4) et NDP (RFC 4861, pour IPv6). IP sur Wimax continue dans la même veine et utilise les mêmes techniques.

C'est ici que se nichent les subtiles différences entre IP sur Ethernet et IP sur 802.16. Par exemple, la section 6.2.2.1 recommande des valeurs particulières pour certaines variables comme l'écart maximum entre deux annonces par un routeur. Comme les machines connectées en Wimax peuvent dépendre d'une batterie, qu'il faut économiser, les valeurs recommandées sont plus importantes que pour un réseau où la majorité des machines est connectée au secteur.

La section 7 détaille ces améliorations qui doivent être apportées à « IP sur Wimax ». Par exemple, la mise en œuvre de la diffusion restreinte Ethernet par les BS consiste à répéter la trame sur tous les liens virtuels, réveillant ainsi même les machines qui n'étaient pas membres du groupe multicast considéré. La section 7.1.1 demande donc que l'information sur qui est membre ou pas soit traitée par la BS, de façon à ce qu'elle sache sur quels liens transmettre la trame. Pour cela, la BS doit donc écouter le trafic lié à la diffusion restreinte, comme expliqué dans le RFC 4541.

Et la diffusion générale (broadcast) ? Elle est encore plus gourmande en électricité. La section 7.1.2 demande donc que la station de base procède intelligement et ne transmette pas les trames de diffusion des protocoles comme ARP, DHCP ou IGMP, qu'elle doit plutôt intercepter et traiter elle-même. La section 7.2 explique comment assurer ce traitement pour DHCP et la 7.3 pour ARP. Dans ce dernier cas, la BS, connaissant toutes les stations des clients et donc leurs adresses MAC, doit assurer un rôle de relais ARP. À noter que l'équivalent d'ARP pour IPv6, NDP, ne fonctionne pas de la même manière (les trames sont transmises en diffusion restreinte) et peut donc être traitée par le mécanisme général de la diffusion restreinte.

La section 10 clôt le RFC avec les questions de sécurité. Comme IP sur Wimax est très proche de IP sur Ethernet, les problèmes de sécurité liés à Ethernet sont souvent les mêmes, et les solutions aussi. Ainsi, les paquets NDP (Neighbor Discovery Protocol) peuvent être mensongers et les techniques de sécurité comme SEND peuvent être utilisées.

Deux annexes reviennent sur des choix qui ont été faits lors de l'adaptation d'IP à 802.16. L'annexe A discute la possibilité d'utiliser des CID (Connection Identifier) pour la diffusion restreinte, mais la rejette car la diffusion restreinte de 802.16 ne fonctionne que dans un seul sens, de la BS vers les SS. De plus, elle nécessite un traitement par toutes les machines à qui la BS a envoyé la trame, les forçant ainsi à se réveiller et à consommer du courant.

L'annexe B discute pour sa part les avantages et les inconvénients d'un pont centralisé entre les SS, par rapport à un ensemble de ponts connectés entre eux.


Téléchargez le RFC 5692


L'article seul

Qu'est-ce que Google Wave ?

Première rédaction de cet article le 26 octobre 2009
Dernière mise à jour le 25 août 2010


Tout le monde a parlé de Google Wave au moment de sa sortie, alors, pourquoi pas moi ? je vais expliquer ce que j'y ai compris, en commençant par des choses qui peuvent intéresser tous les utilisateurs de l'Internet, puis en passant à une analyse un peu plus technique.


L'article complet

RFC 5644: IP Performance Metrics (IPPM) for spatial and multicast

Date de publication du RFC : Octobre 2009
Auteur(s) du RFC : E. Stephan (France Telecom R&D), L. Liang (University of Surrey), A. Morton (AT&T Labs)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 24 octobre 2009


Deux jeux de métriques (grandeur à mesurer, définies de façon formelle) sont normalisés dans ce RFC, l'un pour des mesures « spatiales », l'autre pour la diffusion de groupe.

Dans le cadre du RFC 2330, il existe plusieurs métriques pour mesurer des « performances » d'un réseau de bout en bout. On peut ainsi mesurer le temps de trajet (RFC 7679), le taux de perte (RFC 7680), les changements d'ordre des paquets (RFC 4737), etc. Notre RFC 5644 étend ces métriques :

  • aux cas où on ne mesure pas seulement de bout en bout mais également aux routeurs intermédiaires,
  • aux cas où il y a plusieurs destinations pour un paquet (multicast).

Ici, je parlerais surtout des premières, les métriques dites « spatiales » (voir les sections 7 et 8 pour les autres).

Comme les précédentes, ces nouvelles métriques sont enregistrées dans le registre créé par le RFC 4148. Les définitions nécessaires figurent dans la section 2. Ainsi, métrique multipartite (multiparty metric) est définie (section 2.4) comme le cas où il existe plusieurs points de mesure, une métrique spatiale (spatial metric) est (section 2.5) celle où certains des points de mesure ne sont ni la source, ni une destination du paquet (mais des routeurs situés sur le trajet). Et la métrique de groupe est (section 2.6) celle où il existe plusieurs destinations.

La section 2.7 introduit la notion de points intéressés (points of interest). Ce sont les machines où se fait la mesure. Pour les métriques spatiales, c'est un sous-ensemble des routeurs du chemin suivi par le paquet. Pour les métriques de groupe, ce sont les machines de destination.

Autre terme important, celui de vecteur (vector), défini en section 2.9. C'est simplement une liste de valeurs obtenues en différents points. Par exemple, si on mesure le temps que met un paquet multicast pour aller de la source à N destinations, le résultat de la mesure est un vecteur dont chaque composante est le temps qu'a pris le trajet de la source à un des récepteurs.

Une fois qu'on a les vecteurs, les matrices ne sont pas loin (section 2.10). Une matrice est simplement une liste de vecteurs. Dans le contexte de notre RFC, la matrice a une dimension d'espace (mesures effectuées à différents points, comme dans le vecteur cité en exemple ci-dessus) et une dimension de temps (mesures répétées dans le temps). Si on met le temps horizontalement et l'espace verticalement, une colonne est un vecteur (mesures à différents points, d'un même paquet) et une ligne est un échantillon (mesures de paquets successifs au même point).

Les métriques elles-mêmes sont introduites dans la section 3, en reprenant les concepts des RFC 2330, RFC 2679, RFC 2680, RFC 3393 et RFC 3432. Petit rappel : Type-P indique le type du paquet (TCP ou UDP, taille du paquet, etc) car les performances peuvent en dépendre. Par exemple, Type-P-Spatial-One-way-Delay-Vector reprend la métrique Type-P-One-way-Delay du RFC 2679 et l'étend en vecteur. Elle désigne donc le temps de trajet mesuré à différents points successifs du chemin (différents routeurs).

Pourquoi avoir créé ces nouvelles métriques ? La section 4 reprend les motivations du travail du groupe ippm. Pour les métriques spatiales (section 4.1), il y avait le souhait de comprendre la contribution de chaque étape du chemin au temps total (ce que fait l'ingénieur réseaux lorsqu'il regarde ce qu'affichent traceroute ou mtr avant de dire « Ça coince à tel endroit »).

Venons-en maintenant aux définitions formelles. La section 5 le fait pour les métriques spatiales. Il faut avoir bien lu avant les définitions pour les métriques de bout en bout, les métriques spatiales étant simplement une généralisation. Type-P-Spatial-One-way-Delay-Vector est définie en section 5.1 et, comme indiquée plus haut, c'est simplement l'ensemble des délais d'acheminement d'un paquet, mesuré à plusieurs points du trajet. Je ne recopie pas ici la définition détaillée et très précise du RFC mais je dis juste un mot sur la discussion en section 5.1.5. Cette métrique peut rencontrer des cas pathologiques par exemple si le temps au point N+1 est supérieur au temps au point N. Cela peut être dû à plusieurs choses comme une désynchronisation des horloges (section 3.7.1 du RFC 2679) ou bien un changement dans le routage. Entre le moment où on a déterminé l'ordre des points de mesure (par exemple en faisant un traceroute) et le moment de la mesure, le routage a pu changer et le routeur N+1 passer avant le N.

De même qu'on peut définir Type-P-Spatial-One-way-Delay-Vector en « vectorisant » Type-P-One-way-Delay, la section 5.2 crée Type-P-Spatial-Packet-loss-Vector en vectorisant Type-P-Packet-loss, le taux de perte de paquets du RFC 2680. Et la section 5.3 crée Type-P-Spatial-One-way-ipdv-vector à partir de l'IPDV (Inter-Packet Delay Variation) du RFC 5481.

Les mesures « spatiales » posent des problèmes de méthodologie particuliers qui font l'objet de la section 5.4. Ainsi, la perte d'un paquet est définie par le RFC 2680 comme la non-arrivée de ce paquet au bout d'un temps fini. Si deux points de mesure n'utilisent pas la même valeur pour ce temps, un paquet peut être considéré comme perdu à un point de mesure... mais pas à un point situé en aval, qui utilise un délai maximum plus élevé (section 5.4.1). Il est donc important que tous les points de mesure utilisent des valeurs cohérentes.

Les vecteurs de notre RFC 5644 sont ordonnés : chaque point mesure a une place, qui est l'ordre dans lequel ils voient passer le paquet. Toutes les métriques spatiales dépendent donc de cet ordre. Or, celui-ci n'est pas constant sur l'Internet. Par exemple, une instabilité temporaire du routage peut entraîner une micro-boucle où le paquet passe plusieurs fois par le même routeur et est donc observé plusieurs fois (section 5.4.2). Les points de mesure doivent donc pouvoir détecter de pareils cas, pour les éliminer des statistiques. (La section 10.2.1 mentionne aussi l'importance d'indiquer le chemin suivi par le paquet dans les publications.)

Un vecteur désigne des mesures qui varient dans l'espace, une mesure par point d'observation. Les mesures varient aussi dans le temps, ce qui mène aux métriques de la section 6. Type-P-Segment-One-way-Delay-Stream (section 6.1) est ainsi l'observation dans le temps du délai d'acheminement entre deux routeurs.

Les vecteurs étant évidemment plus gros que les scalaires, les métriques de notre RFC posent des problèmes techniques liés à l'espace de stockage nécessaire et à la capacité du réseau pour les transporter. La section 9 discute de ces détails pratiques. Par exemple, la section 9.3 expose deux méthodes de réduction des matrices avant de les envoyer, réduction sur le temps (agréger les mesures faites à des moments différents) ou bien sur l'espace (agréger les mesures de tous les routeurs). Comme seule la première méthode de réduction peut être effectuée localement, sur chaque point de mesure, c'est elle qui permet de minimiser le trafic réseau lié à ces mesures.


Téléchargez le RFC 5644


L'article seul

L'Internet IPv6 coupé en deux

Première rédaction de cet article le 23 octobre 2009


Depuis au moins le 12 octobre, l'Internet IPv6 est coupé en deux et les paquets ne passent plus entre les deux moitiés.

À ma connaissance, le problème a été signalé pour la première fois à NANOG. Depuis certains sites IPv6, on peut joindre www.cogentco.com (ici depuis Renater) :

% traceroute6 www.cogentco.com 
traceroute to cogentco.com (2001:550:1::cc01) from 2001:660:3003:8::4:69, 30 hops max, 16 byte packets
...
13  2001:550:1::1 (2001:550:1::1)  101.526 ms  92.821 ms *
14  cogentco.com (2001:550:1::cc01)  92.261 ms  92.558 ms  92.294 ms

et pas depuis d'autres (ici Hexago mais c'est pareil depuis Hurricane Electric) :

% traceroute6 www.cogentco.com
traceroute to cogentco.com (2001:550:1::cc01) from 2001:5c0:1000:b::219, 30 hops                          max, 24 byte packets
 1  2001:5c0:1000:b::218 (2001:5c0:1000:b::218)  31.998 ms  27.998 ms  31.998 ms
 2  ix-5-0-1.6bb1.MTT-Montreal.ipv6.as6453.net (2001:5a0:300::5)  31.998 ms !N                           31.998 ms !N  31.998 ms !N

Que s'est-il passé ? Un problème non-technique, qui arrive parfois dans le monde IPv4 (mais qui est en général réglé rapidement car la perte de connectivité est trop grave) et qui fait ici ses débuts dans le monde IPv6 : le depeering, en l'occurrence celui de Hurricane Electric par Cogent.

Pour que l'Internet fonctionne, il faut que des opérateurs réseau concurrents échangent du trafic. Ils peuvent le faire sur la base d'une relation client/fournisseur, où le client paie le fournisseur (on dit qu'il « achète du transit ») ou bien sur la base d'une égalité approximative entre les deux opérateurs (on dit qu'ils « peerent »). Évidemment, les gros n'aiment pas peerer avec les petits et saisissent toute occasion de « dépeerer », les forçant à passer par les liens de transit, plus coûteux. Dans le monde IPv4, ce genre de bras de fer peut se traduire par des coûts plus élevés mais ne met pas en péril la connectivité, sauf cas extrêmes, car les opérateurs ont en général plusieurs solutions de rechange pour acheminer les paquets.

Mais la connectivité IPv6 est bien plus pauvre, avec moins de redondance. En outre, comme IPv6 n'est encore largement utilisé que pour des essais, les coupures suscitent nettement moins d'intérêt de peuvent durer bien plus longtemps.

Voici le point de vue de Hurricane Electric. Je ne peux pas pointer vers celui de Cogent, cette entreprise n'informe jamais les utilisateurs. Mais voici un bon article de synthèse de l'affaire, avec la photo du gâteau que Hurricane Electric a réalisé...


L'article seul

RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors

Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : M. StJohns
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsext
Première rédaction de cet article le 23 octobre 2009
Dernière mise à jour le 2 juillet 2015


La plaie de DNSSEC, comme celle de tous les systèmes de cryptographie, est la gestion des clés. Avec DNSSEC, la clé de signature des autres clés, la KSK (Key Signing Key) est censée être remplacée (rolled over) régulièrement. Si un résolveur a une KSK dans sa configuration, cela oblige l'administrateur du résolveur à effectuer le remplacement à la main, ce qui peut être contraignant. Notre RFC 5011 propose une autre solution : le domaine signe la nouvelle KSK avec l'ancienne et le résolveur accepte alors automatiquement cette nouvelle clé.

Le résolveur peut ainsi construire une chaîne de confiance menant de la première clé pour laquelle il a été configuré, jusqu'à la clé actuelle. Cela implique que ledit résolveur ait un espace où écrire les clés successives qu'il a authentifié et décidé de garder.

La méthode de notre RFC présente des risques (cf. section 8.3) mais pas plus que la situation actuelle où les clés sont entièrement gérées à la main.

Ce RFC 5011 fournit donc un moyen de ne configurer la clé d'un domaine qu'une seule fois (cette configuration initiale reste manuelle), même si elle est remplacée par la suite. Le principe est simple (et le RFC est donc très court). La section 2 le décrit : quand une clé est configurée pour une zone du DNS (cette clé est dite un « trust anchor ») et qu'une nouvelle KSK apparait dans la zone, signée par l'ancienne, le résolveur accepte cette nouvelle KSK comme trust anchor et l'enregistre dans sa configuration. Une machine à états complète figure en section 4.

Le principal piège avec cette méthode est que, si une clé privée est volée, l'attaquant pourra continuer à générer une chaîne de confiance : le retrait de la clé compromise par le gérant de la zone ne suffira pas à annuler son usage. Il faut donc un mécanisme de révocation (section 2.1). Lorsqu'une KSK est publiée, signée mais que le nouveau bit REVOKE est mis, alors le résolveur doit retirer cette clé de sa configuration.

Un autre risque est que la clé privée soit volée sans que le gérant de la zone ne s'en rende compte immédiatement. Pour éviter que l'attaquant ne fasse accepter une nouvelle clé, le résolveur est supposé attendre lorsqu'une clé apparait (section 2.2). La durée d'attente est typiquement de 30 jours (section 2.4.1).

Le résolveur qui met en œuvre ce RFC 5011 doit périodiquement vérifier que la clé est toujours en service. La section 2.3 expose les règles à suivre pour cette vérification (il faut demander souvent pour détecter les nouvelles clés, sans attendre l'expiration du TTL mais pas trop pour ne pas surcharger les serveurs).

On l'a vu, ce RFC crée un nouveau booléen dans les enregistrement DNSKEY, pour indiquer la révocation. Le format est donc légèrement modifié, comme spécifié en section 3. C'est le bit n° 8 du champ DNSKEY Flags (voir section 2.1.1 du RFC 4034) qui servira à cet effet.

Si toutes les clés d'une zone sont révoquées, la zone devient non-validable (section 5), ce qui signifie qu'elle sera traitée comme si elle n'était pas signée du tout (insecure en terminologie DNSSEC).

Le bon fonctionnement de l'algorithme nécessite que la zone signée procède au remplacement des clés d'une manière particulière, décrite en section 6. Ainsi, le remplacement (rollover) va nécessiter la révocation de l'ancienne clé.

Le logiciel BIND a introduit le système de ce RFC dans sa version 9.7. (Voir le fichier README.rfc5011 dans le code source.) Cela se configure avec la directive managed-keys, qui ressemble beaucoup à trusted-keys (sauf l'ajout d'un mécanisme pour trouver la première clé, ici avec le paramètre initial-key), par exemple ainsi :

managed-keys {
    "example.com."     initial-key             257 3 5 
                                "AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ
                                1wcTkypSExLCBPMS0wWkrA1n7t5hcM86VD94L8oEd9jn
                                HdjxreguOZYEBWkckajU0tBWwEPMoEwepknpB14la1wy
                                3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6FdFL9wyC
                                flV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3Aa
                                pH2GXCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNS
                                M4q3zGhuly4NrF/t9s9jakbWzd4PM1Q551XIEphRGyqc
                                bA2JTU3/mcUVKfgrH7nxaPz5DoUB7TKYyQgsTlc=";
                                // key id = 8779
};

Une fois que BIND démarre, il crée un journal pour une zone bidon, managed-keys.bind et commence le processus décrit dans le RFC :

23-Oct-2009 10:55:10.152 zone managed-keys.bind/IN/_meta: loaded serial 0
23-Oct-2009 10:55:10.169 zone managed-keys.bind/IN/_meta: Initializing automatic trust anchor management for zone 'example.com'; \
   DNSKEY ID 49678 is now trusted, waiving the normal 30-day waiting period.

On voit que example.com a déjà une nouvelle clé, 49678, signée avec l'ancienne (celle que j'ai configurée dans manage-keys) et que BIND commence la période d'attente. Voici, avec une zone différente, le contenu de managed-keys.bind au moment où une deuxième clé vient d'être publiée :

$ORIGIN .
$TTL 0	; 0 seconds
@			IN SOA	. . (
				2          ; serial
				0          ; refresh (0 seconds)
				0          ; retry (0 seconds)
				0          ; expire (0 seconds)
				0          ; minimum (0 seconds)
				)
			KEYDATA	20150703040258 20150702160258 19700101000000 257 3 8 (
				AwEAAaP3gGQ4db0tAiDEky0dcUNGeI1aTDYP5NFxzhbd
				pD60ZhKLVV4KyxPmoSNUpq5Fv5M0iBwK1Tyswsyq/9sM
				SoZ8zx8aT3ho1YnPsSqQeJfjTT1WsX6YZ5Kw6B2QkjRN
				a6OMGZ96Kn8AI/slqsw+z8hY49Sn3baeo9iJxHPzloNc
				2dQkW4aLqzNEYxnuoJsthCfGrPSAXlUjY9m3YKIaEWR5
				WFYQk770fT+gGWLk/54Vp0sG+Lw75JZnwhDhixPFaToT
				DNqbHQmkEylq1XJLO15uZ/+RZNRfTXZKO4fVR0tMEbMA
				ITqRmyP8xLXY4RXbS4J32gnenQbzABX8sQmwO7s=
				) ; KSK; alg = RSASHA256; key id = 55954
			KEYDATA	20150703040258 20150702160258 19700101000000 257 3 8 (
				AwEAAchb6LrHCdz9Yo55u1id/b+X1FqVDF66xNrhbgnV
				+vtpiq7pDsT8KgzSijNuGs4GLGsMhVE/9H0wOtmVRUQq
				Q50PHZsiqg8gqB6i5zLortjpaCLZS7Oke1xP+6LzVRgT
				4c8NXlRBg3m/gDjzijBD0BMACjVGZNv0gReAg2OCr9dB
				rweE6DnM6twG7D2NyuGjpWzKeJfNd3Hek39V9NGHuABG
				kmYG16XCao37IWcP/s/57HuBom5U3SNfuzfVDppokatu
				L6dXp9ktuuVXsESc/rUERU/GPleuNfRuPHFr3URmrRud
				4DYbRWNVIsxqkSLrCldDjP1Hicf3S8NgVHJTSRE=
				) ; KSK; alg = RSASHA256; key id = 24439

Pour Unbound, la configuration de ce RFC se fait en préfixant les directives par auto-. Ainsi, au lieu d'avoir une clé statique et qui ne bougera pas :

trust-anchor-file: "root.key"

On aura une clé modifiable :

auto-trust-anchor-file: "autokey/root.key"

Il faut bien sûr veiller à ce que le répertoire (ici autokey/) soit accessible à Unbound en écriture. Voici un fichier pour les mêmes clés que l'exemple BIND plus haut :

; autotrust trust anchor file
;;id: . 1
;;last_queried: 1435856265 ;;Thu Jul  2 16:57:45 2015
;;last_success: 1435856265 ;;Thu Jul  2 16:57:45 2015
;;next_probe_time: 1435899044 ;;Fri Jul  3 04:50:44 2015
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.	86400	IN	DNSKEY	257 3 8 AwEAAaP3gGQ4db0tAiDEky0dcUNGeI1aTDYP5NFxzhbdpD60ZhKLVV4KyxPmoSNUpq5Fv5M0iBwK1Tyswsyq/9sMSoZ8zx8aT3ho1YnPsSqQeJfjTT1WsX6YZ5Kw6B2QkjRNa6OMGZ96Kn8AI/slqsw+z8hY49Sn3baeo9iJxHPzloNc2dQkW4aLqzNEYxnuoJsthCfGrPSAXlUjY9m3YKIaEWR5WFYQk770fT+gGWLk/54Vp0sG+Lw75JZnwhDhixPFaToTDNqbHQmkEylq1XJLO15uZ/+RZNRfTXZKO4fVR0tMEbMAITqRmyP8xLXY4RXbS4J32gnenQbzABX8sQmwO7s= ;{id = 55954 (ksk), size = 2048b} ;;state=1 [ ADDPEND ] ;;count=2 ;;lastchange=1435813814 ;;Thu Jul  2 05:10:14 2015
.	85667	IN	DNSKEY	257 3 8 AwEAAchb6LrHCdz9Yo55u1id/b+X1FqVDF66xNrhbgnV+vtpiq7pDsT8KgzSijNuGs4GLGsMhVE/9H0wOtmVRUQqQ50PHZsiqg8gqB6i5zLortjpaCLZS7Oke1xP+6LzVRgT4c8NXlRBg3m/gDjzijBD0BMACjVGZNv0gReAg2OCr9dBrweE6DnM6twG7D2NyuGjpWzKeJfNd3Hek39V9NGHuABGkmYG16XCao37IWcP/s/57HuBom5U3SNfuzfVDppokatuL6dXp9ktuuVXsESc/rUERU/GPleuNfRuPHFr3URmrRud4DYbRWNVIsxqkSLrCldDjP1Hicf3S8NgVHJTSRE= ;{id = 24439 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1434990786 ;;Mon Jun 22 16:33:06 2015

Notez qu'Unbound, lui, écrit l'état des clés, VALID pour celle en cours d'utilisation et ADDPEND (Add, Pending) pour celle qui la remplacera.

Un très bon article de test de notre RFC, avec OpenDNSSEC, BIND et Unbound, par Jan-Piet Mens.


Téléchargez le RFC 5011


L'article seul

RFC 5734: Extensible Provisioning Protocol (EPP) Transport over TCP

Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 22 octobre 2009
Dernière mise à jour le 30 octobre 2009


Ce court RFC spécifie comment utiliser le protocole d'avitaillement EPP au dessus d'une simple connexion TCP.

EPP, décrit dans le RFC 5730 est à sa base uniquement un format XML pour les requêtes d'avitaillement (création, mise à jour et destruction d'objets) et leurs réponses. Ces éléments XML peuvent être transmis de différence façon (au dessus de HTTP, de BEEP, par courrier électronique, etc), et notre RFC normalise la plus commune aujourd'hui, une simple connexion TCP. Il remplace le RFC 4934, avec uniquement des modifications de détail, portant notamment sur l'utilisation de TLS (section 9).

Le RFC est court car il n'y a pas grand'chose à dire, juste l'utilisation des primitives de TCP (ouverture et fermeture de connexion, section 2 du RFC), l'ordre des messages (section 3), le port utilisé (700, 3121 ayant été abandonné, section 7) et le fait que chaque élément EPP soit précédé d'un entier qui indique sa taille (section 4). Sans cet entier (qui joue le même rôle que l'en-tête Content-Length de HTTP), il faudrait, avec la plupart des implémentations, lire les données octet par octet (sans compter que la plupart des analyseurs XML ne savent pas analyser de manière incrémentale, il leur faut tout l'élément). En outre, sa présence permet de s'assurer que toutes les données ont été reçues (voir l'excellent article The ultimate SO_LINGER page, or: why is my tcp not reliable).

L'entier en question est fixé à 32 bits. Si on programme un client EPP en Python, l'utilisation brutale du module struct ne suffit pas forcément. En effet :

struct.pack("I", length)

force un entier (int) mais pas forcément un entier de 32 bits. Pour forcer la taille, il faut utiliser également, comme précisé dans la documentation, les opérateurs < et >, qui servent aussi à forcer la boutianité (merci à Kim-Minh Kaplan pour son aide sur ce point). Voici une démonstration (un "l" standard fait 4 octets alors que le type long de C peut faire 4 ou 8 octets) :

# Machine 32 bits :

Python 2.4.4 (#2, Apr  5 2007, 20:11:18) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
4
>>> print struct.calcsize(">l")
4
# Machine 64 bits :

Python 2.4.5 (#2, Mar 11 2008, 23:38:15) 
[GCC 4.2.3 (Debian 4.2.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
8
>>> print struct.calcsize(">l")
4

Si on a quand même un doute, on peut tester la taille obtenue mais ce code est probablement inutile (merci à David Douard pour son aide ici) :


# Get the size of C integers. We need 32 bits unsigned.
format_32 = ">I"
if struct.calcsize(format_32) < 4:
    format_32 = ">L"              
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
elif struct.calcsize(format_32) > 4:
    format_32 = ">H"                
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
else:
    pass
...
def int_from_net(data):
    return struct.unpack(format_32, data)[0]

def int_to_net(value):
    return struct.pack(format_32, value)

L'algorithme complet d'envoi est :

epp_as_string = ElementTree.tostring(epp, encoding="UTF-8")
# +4 for the length field itself (section 4 mandates that)
# +2 for the CRLF at the end
length = int_to_net(len(epp_as_string) + 4 + 2)
self._socket.send(length)
self._socket.send(epp_as_string + "\r\n")

et la lecture :

data = self._socket.recv(4) # RFC 5734, section 4, the length 
                            # field is 4 bytes long
length = int_from_net(data) 
data = self._socket.recv(length-4)
epp = ElementTree.fromstring(data)
if epp.tag != "{%s}epp" % EPP.NS:
     raise EPP_Exception("Not an EPP instance: %s" % epp.tag)
xml = epp[0]

Le code Python complet (qui ne met en œuvre qu'une petite partie de EPP, le but était juste de tester ce RFC 5734), utilisant la bibliothèque ElementTree, est disponible en ligne. Le code ci-dessus comporte une grosse faiblesse (mais classique) : rien ne garantit que recv(n) retournera autant d'octets que réclamé. Il en renverra au plus n mais peut-être moins. Pour de la programmation sérieuse, il faut donc le réécrire avec une fonction du genre :

   def safe_recv(s, n):
       data = ''
       while (n > 0):
           tmp = s.recv(n)
           data += tmp
           n -= len(tmp)
       return data

(Merci à Kim-Minh Kaplan pour son aide sur ce point.)

Pour Perl, ce code ressemblerait (merci à Vincent Levigneron), pour envoyer un élément EPP stocké dans la variable $out, à :

print pack('N', length($out) + 4).$out;

et pour lire un élément EPP :

my $length = unpack "N", $buf;
...
$rc = read STDIN, $buf, $length;

Puisque le format N désigne un entier non signé gros boutien (cf. http://perldoc.perl.org/functions/pack.html).

À noter que cette lecture du champ longueur présente un risque de sécurité : si le serveur malloque aveuglément la taille indiquée dans ce champ, comme il fait quatre octets, le serveur naïf risque de consommer quatre giga-octets de mémoire.

La section 8, consacrée à la sécurité, et surtout la nouvelle section 9, consacrée à TLS, détaillent le processus d'authentification du client et du serveur. L'utilisation de TLS (RFC 5246) est obligatoire, ne serait-ce que pour protéger les mots de passe qui circulent en clair dans les éléments EPP. TLS permet également au client d'authentifier le serveur et au serveur d'authentifier le client, par la présentation de certificats X.509. Leur présentation et leur usage sont désormais obligatoires dans EPP. Notons que, comme toujours avec X.509, la difficulté est de déterminer ce qu'on vérifie. La section 9 détaille le cas où on vérifie un nom et celui où on vérifie une adresse IP. Il serait intéressant de savoir quels registres et quels bureaux d'enregistrement effectuent réellement ces validations...

La liste des changements par rapport au RFC 4934 se trouve dans l'annexe A. Le principal changement consiste en une meilleure spécification des règles de vérification du certificat X.509 lorsque TLS est utilisé (cf. la nouvelle section 9).


Téléchargez le RFC 5734


L'article seul

Regarder les films débiles de YouTube avec uniquement du logiciel libre

Première rédaction de cet article le 21 octobre 2009
Dernière mise à jour le 4 novembre 2010


Aujourd'hui, l'Internet sert presque uniquement à regarder les vidéos publiées sur YouTube. Mais le mode de publication par défaut est sous forme d'animation Flash, une technologie fermée, contrôlée par un seul acteur, Adobe. Peut-on voir les mêmes films débiles que tout le monde avec uniquement du logiciel libre ?

Si on utilise une machine qui ne fait tourner que du logiciel libre, dans mon cas une Debian, version « lenny » qui n'a que la section « main », celle qui ne contient que du logiciel libre, et donc pas celui de la section « non-free », que voit-on sur YouTube ? « Hello, you either have JavaScript turned off or an old version of Adobe's Flash Player. Get the latest Flash player. » Eh oui, YouTube impose l'utilisation de la technologie fermée et privatrice Flash.

Peut-on utiliser un autre logiciel pour voir ses animations ? Gnash, équivalent d'Adobe Flash en logiciel libre n'a jamais vraiment atteint un niveau suffisant pour être utilisé couramment.

Mais il existe une autre solution. La page renvoyée par YouTube contient le nom du film (au format FLV). On peut donc récupérer celui-ci avec un logiciel comme wget ou curl. Il y a toutefois plus pratique, utiliser l'excellent logiciel youtube-dl qui automatise tout cela. Il analyse le source HTML de la page pour vous et récupère le film. Une fois celui-ci stocké sur votre disque, vous pourrez le regarder à loisir avec des logiciels comme mplayer ou vlc (FLV est lisible par beaucoup de logiciel libres, il n'y a même pas besoin de codecs non-libres).

Voici un exemple d'utilisation :

% youtube-dl -t 'http://www.youtube.com/watch?v=ro6sTexFQbU' 
[youtube] Setting language
[youtube] ro6sTexFQbU: Downloading video info webpage
[youtube] ro6sTexFQbU: Extracting video information
[download] Destination: A_la_belle_viiiie-ro6sTexFQbU.flv
[download] 100.0% of 6.24M at   65.24k/s ETA 00:00 
% mplayer A_la_belle_viiiie-ro6sTexFQbU.flv
...

Les apostrophes autour de l'URL sont là parce que le point d'interrogation est un caractère spécial pour le shell. L'option -t est là pour que le fichier prenne comme nom le titre du film (autrement, le fichier a un nom inhumain, l'identifiant YouTube du film.)

youtube-dl fonctionne par scraping de la page Web. Une telle technique est très fragile : il suffit que YouTube change son format et tout est à recommencer. En pratique, lorsque cela arrive, une nouvelle version de youtube-dl sort en général rapidement.

Enfin, pour venir, quelques bons films choisis tout à fait subjectivement et arbitrairement sur YouTube :

Je trouve personnellement que youtube-dl manque de quelques options pratiques comme la possibilité de lancer un programme de visualisation une fois le chargement terminé. Le petit script shell suivant répond à ce problème. On l'utilise ainsi :

% yt 'http://www.youtube.com/watch?v=7sjlX8ueFfU'
[youtube] Setting language
[youtube] 7sjlX8ueFfU: Downloading video info webpage
[youtube] 7sjlX8ueFfU: Extracting video information
[download] Destination: UN_VILLAGE_FRANCAIS_SAISON_2-7sjlX8ueFfU.flv
[download] 100.0% of 1.19M at  284.76k/s ETA 00:00 
MPlayer 1.0rc2-4.3.2-DFSG-free (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) Dual  CPU  E2140  @ 1.60GHz (Family: 6, Model: 15, Stepping: 13)
...
Playing UN_VILLAGE_FRANCAIS_SAISON_2-7sjlX8ueFfU.flv.

et on a à la fois le film enregistré en un endroit précis et sa visualisation tout de suite. Le script est simplement :

#!/bin/sh

if [ -z "$1" ]; then
    echo "Usage: $0 YouTube-URL" >&2
    exit 1
fi

url=$1
LOGFILE=youtube-dl-$$.log

set -e
cd ~/tmp
youtube-dl -t $url | tee $LOGFILE
file=$(awk '/Destination:/ {print $3}' < $LOGFILE)
if [ -z $file ]; then
    echo "$url: invalid YouTube URL" >&2
    exit 1
fi
mplayer $file
rm -f $LOGFILE

Comme youtube-dl n'a apparemment pas d'option pour indiquer simplement le nom du fichier enregistré sur la sortie standard (les options -g et -e n'affichent pas exactement ce nom, et elles inhibent le téléchargement), il faut utiliser awk pour analyser le résultat de youtube-dl.

Bien sûr, comme le fait de pouvoir regarder YouTube fait partie des droits de l'homme fondamentaux, plein de gens ont développé d'autres mécanismes pour le faire avec du logiciel libre. Ainsi, Yannick Roehlly, me signale get-flash-videos, quasiment l'équivalent de youtube-dl mais écrit en Perl (et qui gère d'autres services que YouTube). Christophe Narbonne me recommande YouTube Perfect, un script Greasemonkey pour voir YouTube. Marc Hertzog suggère un truc pour obtenir de YouTube un fichier MP4. Et Yannick Palanque préfère utiliser cclive (il existe aussi un clive).

Et pour Dailymotion ? Pas de problème, youtube-dl le gère depuis peu mais, apparemment, clive et cclive le font aussi. Notez que Dailymotion, contrairement à son concurrent, a en test une distribution de vidéos ne dépendant pas de logiciel non-libre : http://openvideo.dailymotion.com/. (Voir le communiqué de la FSF, « Dailymotion's support for Ogg is a big deal ».) Pour le service Vimeo, en revanche, il y a http://gist.github.com/146789 (suggestion de Marc Hertzog).


L'article seul

Je ne veux pas de liens vers mon site Web !

Première rédaction de cet article le 18 octobre 2009


Aujourd'hui, la plupart des gérants de sites Web veulent attirer du trafic par n'importe quel moyen. Ils paient très chers des rebouteux (pardon, des consultants) en SEO qui leur promettent une « optimisation du référencement ». Ils ne se demandant pas si leur site est intéressant ou utile, uniquement comment avoir davantage de visiteurs. Donc, logiquement, ils devraient chercher à tout prix à avoir des liens entrants, des liens hypertexte qui pointent vers leur site ? Eh bien non, beaucoup de gros sites Web interdisent explicitement qu'on mette des liens vers eux...

Thierry Stœhr, auteur de l'excellent blog Formats Ouverts, a commencé une liste de tels sites (elle est actualisée régulièrement sur identi.ca, sous l'étiquette #pdlsa, « Pas De Lien Sans Autorisation »). La liste est étonnament longue, et regroupe des sites Web d'origines très variées, grosses entreprises capitalistes, syndicats, ONG, services publics, etc.

Qu'est-ce qui leur a pris ? Pourquoi ces webmestres ne veulent-ils pas de liens entrants, alors que, par exemple, le nombre de ces liens est un des principaux critères utilisés par Google pour déterminer la popularité d'un site ? Ils sont devenus fous ?

Difficile d'obtenir des gérants de ces sites la moindre explication. Il semble que la motivation la plus fréquente (mais on ne la met jamais par écrit, par peur du ridicule) soit juridique. Le raisonnement est le suivant : comme, de nos jours, on peut être trainé en justice pour absolument n'importe quoi, surtout si ça a un rapport avec l'Internet, la possibilité d'une procédure judiciaire pour un lien entrant n'est pas nulle. Un groupe néo-nazi fait un lien vers vous et paf, vous pouvez être accusé de complicité. Bien sûr, c'est absurde, bien sûr, il n'y a pratiquement aucune chance d'être condamné mais, pour pas mal d'organisations, qui pilotent leur site Web l'œil fixé sur le trouillomètre, il vaut mieux surréagir et stériliser le Web, plutôt que de courir le moindre risque.

Si, en outre, vous demandez un avis juridique à des professionnels, vous êtes pratiquement sûrs d'obtenir une réponse du type « Il y a un risque, il vaut mieux interdire » (car, en effet, toute activité présente un risque). Le risque de procès est tel désormais que l'avis du juriste passera toujours devant celui du responsable de la communication, qui voudrait bien avoir davantage de liens. La mention « Pas De Lien Sans Autorisation » reflète donc, pour un site Web, l'importance relative donnée aux critères juridiques par rapport au but normal d'un site Web : être lu et connu.

Si vous travaillez dans un organisme qui met de telles mentions anti-Web sur son site, vous pouvez toujours essayer l'argumentaire « Votre site Web demande une autorisation pour faire un lien vers lui : les 10 questions à vous poser » ou bien le texte de synthèse « Texte destiné aux Services juridique, marketing, commercial (ou autres) et la Direction de votre site Web ». Il n'est pas sûr que cela marche, car l'argument « C'est pour des raisons juridiques » (jamais explicitées) est en général définitif et indiscutable.

Inutile de dire que les liens entrants vers ce site http://www.bortzmeyer.org/ sont les bienvenus et que je donne d'avance mon autorisation enthousiaste !

Quelques articles sur la campagne qui a suivi l'étude de Thierry Stœhr :


L'article seul

District 9

Première rédaction de cet article le 18 octobre 2009


Bon, comme tout les lecteurs de ce blog, je suis allé voir ce film. Je n'ai pas été déçu par les qualités cinématographiques (très bon film, très « coup de poing », fait avec un budget raisonnable pour un film de SF moderne), j'ai apprécié un film en anglais où tout le monde a un accent inhabituel mais...

J'ai été un peu gêné par le rôle des noirs : tous les rôles importants (que ce soient des bons ou des méchants) sont tenus par des blancs (ou des aliens). Par contre, les excités anti-aliens qui répondent au micro-trottoir sont tous noirs, ainsi que les pogromistes ou les gangsters nigérians (noirs et nigérians, ils sont bien plus aliens que les aliens).

Ce film est censé, en tout cas c'est ce que dit tout le monde, dénoncer le racisme. Comme il est fait par un sud-africain, on pense forcément à l'apartheid. Mais, dans le film, j'ai eu plutôt l'impression que l'auteur essayait de faire oublier l'apartheid au profit d'un discours comme quoi tous les humains sont des racistes.

En tout cas, le film est plus conçu pour nous émouvoir sur le sort des aliens (surtout le mignon enfant) que sur celui des humains qui peuplent, encore aujourd'hui, les bidonvilles de Johannesburg.

Finalement, la meilleure critique, dans ce film, est celle des médias : tout est vu à travers des reportages à la télévision et le héros, lorsqu'il s'aventure dans le bidonville des aliens, est bien plus attentif à la caméra qui le filme en permanence, qu'aux aliens auxquels il s'adresse.

Voir, sur le même sujet, l'article de Thomas Quinot, plutôt critique du film et celui de Goon, très favorable.


L'article seul

Un domaine de tête entier, le suédois, disparait temporairement

Première rédaction de cet article le 14 octobre 2009


Lundi 12 octobre, vers 20h00 UTC, le domaine de tête .se a chargé la zone DNS de numéro de série 2009101210 qui comprenait une énorme erreur. Pendant une heure, plus aucun nom de domaine se terminant par .se ne fonctionnait.

Très vite, Twitter a vu des tweets sur le sujet, puis des rapports et des discussions ont commencé sur les listes de diffusion d'opérateurs comme Nanog.

La cause immédiate était le manque d'un point dans le fichier de zone, les enregistrement NS de la zone avaient tous un .se en trop à la fin, par exemple h.ns.se.se. En effet, dans le format standard des fichiers de zone DNS, tel qu'il est défini en section 5 du RFC 1035, un nom qui ne se termine pas par un point est complété par la nom de la zone, ici .se. Pendant la panne, on a donc pu voir :

% dig +cd NS se.
...
;; ANSWER SECTION:
se.                     172540  IN      NS      h.ns.se.se.
se.                     172540  IN      NS      g.ns.se.se.
...

Vous avez remarqué ? (Moi, je ne l'avais pas vu.) Un .se de trop à la fin, les noms des serveurs de noms étaient donc tous considérés comme inexistants. .se avait donc disparu de l'Internet, plus de Web, plus de courrier, plus de XMPP, etc. Comme quasiment toutes les interactions sur l'Internet commencent par une requête DNS, plus rien ne marchait.

Selon la façon dont les résolveurs remplaçaient la délégation venue de la racine (qui était correcte) par celle faisant autorité (car publiée par le domaine .se lui-même), ils arrivaient encore à résoudre les noms en .se ou pas (BIND se débrouillait mieux qu'Unbound, l'inverse aurait été vrai si l'erreur avait été à la racine).

Le problème ne concernait pas que les enregistrement NS du TLD mais aussi ceux de toutes les zones déléguées :

ballou.se.              42617   NS      ns1.ballou.se.se.
                        42617   NS      ns2.ballou.se.se.
                        45098   NS      ns3.aname.se.se.

Vers 21h00 UTC, .se a chargé la zone 2009101211 qui corrigeait l'erreur... et en introduisait d'autres, notamment des signatures DNSSEC invalides pour le SOA. (Ce problème a été reconnu par le registre.)

Tout a finalement été réparé mais la mauvaise information pouvait encore se trouver dans des caches. Pendant un certain temps, les sites en .se restaient injoignables, sauf à obtenir de votre FAI qu'il redémarre son résolveur (comme conseillé par le registre, command rndc flush pour BIND). Pendant quelle durée exactement ? Le TTL est de deux jours, donc j'avais pensé que ce serait la durée de la panne (et c'est aussi ce qu'annonce le registre) mais Jay Daley me fait remarquer à juste titre que, les noms n'existant pas, c'est le cache négatif (RFC 2308) qui compte et que celui-ci est de seulement deux heures pour .se.

Cette panne est une des plus graves qui aient jamais affecté un domaine de tête sérieux. Aurait-elle pu être évitée ? Il est évident qu'il faut faire tourner des tests de validité avant de publier la zone. Mais aucun test ne détecte tous les problèmes possibles. Par exemple, un outil de vérification livré avec BIND aurait pu détecter le problème :

% named-checkzone example example.zone
zone example/IN: NS 'ns1.nic.example.example' has no address records (A or AAAA)

Mais named-checkzone a aussi des limites. Il ne positionne pas le code de retour dans le cas ci-dessus, par exemple (et, non, -n fail ne change rien). Et il ne marche pas si la zone est mise à jour par dynamic update (RFC 2136).

Quelques leçons à en tirer :

  • Les problèmes surviennent, donc une détection et correction rapide est primordiale,
  • DNSSEC, pour lequel le registre suédois était pionnier, n'a pas aidé. Si les données sont fausses, DNSSEC ne va pas les corriger. Garbage In, Garbage Out.

Quelques articles sur le sujet :

Je dois aussi des remerciements à Jay Daley, David Blacka, Gilles Massen, Jakob Schlyter, Jelte Jansen et Olaf Kolkman pour leurs analyses et le partage d'information.


L'article seul

RFC 5733: Extensible Provisioning Protocol (EPP) Contact Mapping

Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 14 octobre 2009


Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux contacts, c'est-à-dire aux personnes physiques ou morales responsables d'un objet de la base et qui peuvent être contactées à son sujet. (L'objet étant typiquement un nom de domaine ou bien un préfixe IP.)

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 5730, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type, la classe (EPP dit le mapping) pour les contacts. Il remplace le RFC 4933, avec très peu de changement, et marque l'arrivée de cette norme au statut de « norme complète », la dernière étape du chemin des normes de l'IETF.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

Un contact est donc composé d'un identificateur (type clIDType du RFC 5730). Cet identificateur (on l'appelait traditionnellement le handle) est, par exemple, SB68-GANDI (section 2.1).

Les contacts ont également un statut (section 2.2) qui est toujours mis par le client EPP, typiquement le bureau d'enregistrement. Ce mapping ne permet pas aux contacts d'être maîtres de leur propre information et de la changer directement (ce qui est cohérent avec l'approche d'EPP où un intermédiaire, le bureau d'enregistrement, a l'exclusivité des changements).

Les contacts ont aussi évidemment des moyens d'être contactés, via numéro de téléphone, adresse postale, etc. Par exemple, l'adresse de courrier du contact est spécifiée en section 2.6. La syntaxe formelle est celle du RFC 5322, par exemple joe.o'reilly+verisign@example.com. (Mais le schéma XML a une syntaxe plus bien laxiste, presque tout est accepté.)

Les contacts pouvant être des personnes physiques, pour protéger leur vie privée, la section 2.9 du RFC décrit aussi un format pour spécifier si ces informations doivent être publiées ou pas. Insuffisant pour tous les cas, ce format est en général remplacé, chez les registres européens, par un mapping spécifique (par exemple, EPP parameters for .pl ccTLD pour les polonais qui utilisent un élément <individual> pour indiquer si le contact est une personne physique, et a donc droit à la protection des lois européennes sur les données personnelles).

La section 3 normalise ensuite l'usage des commandes standards d'EPP (comme <create>) pour les objets de notre classe « contact ». À titre d'exemple, voici la réponse d'un serveur EPP à une requête <epp:info> (section 3.1.2) pour le contact SB68-GANDI :


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:infData
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>SB68-GANDI</contact:id>
        <contact:roid>SH8013-REP</contact:roid>
        <contact:status s="clientDeleteProhibited"/>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Exemple SA</contact:org>
          <contact:addr>
            <contact:street>123 rue de l'Exemple</contact:street>
            <contact:city>Trifouillis-les-Oies</contact:city>
            <contact:cc>FR</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+33.7035555555</contact:voice>
        <contact:fax>+33.7035555556</contact:fax>
        <contact:email>jdoe@example.com</contact:email>
        <contact:crDate>1997-04-03T22:00:00.0Z</contact:crDate>
        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
        <contact:disclose flag="0">
          <contact:voice/>
          <contact:email/>
        </contact:disclose>
      </contact:infData>
    </resData>
  </response>
</epp>

L'espace de noms XML pour les contacts est urn:ietf:params:xml:ns:contact-1.0.

Comme rappelé par la section 5, EPP utilise XML dont le modèle de caractères est Unicode depuis le début. Logiquement, on devrait donc pouvoir enregistrer des noms et prénoms comportant des accents (comme « Stéphane ») mais je ne suis pas sûr que cela marche avec tous les registres : c'est une chose de transporter la chaîne de caractères Unicode jusqu'au registre et une autre de la stocker dans la base et de la ressortir proprement.

La classe « Contact » permet de représenter certains éléments (comme l'adresse postale) sous deux formes, une en Unicode complet (en indiquant type="loc" et l'autre sous une version restreinte à l'ASCII (en indiquant type="int", notez que ces labels doivent être lus à l'envers, la forme restreinte en labelisée int pour « internationale » et la forme complète loc pour « locale » alors que le contraire aurait été plus logique.)

Ce RFC remplace son prédécesseur, le RFC 4933 mais ce ne sont que des modifications légères, détaillées dans l'annexe A.


Téléchargez le RFC 5733


L'article seul

RFC 5732: Extensible Provisioning Protocol (EPP) Host Mapping

Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 13 octobre 2009


La représentation des serveurs de noms (host, dans ce contexte) dans un registre de noms de domaine a toujours été une source de confusion et de désaccords. Le protocole EPP d'avitaillement (provisioning) d'un registre a tranché arbitrairement et décidé que la bonne méthode était d'avoir des objets « serveur de noms » (host) explicitement mis dans le registre. C'est ce que normalise notre RFC, successeur du RFC 4932, qui lui-même succédait au RFC 3732.

Un registre de noms de domaine stocke en effet au moins deux classes d'objets : les domaines, bien sûr, et les contacts, les entités (personnes physiques ou organisations) qui gèrent les domaines. Mais cela laisse ouverte la question des serveurs de noms. Pour pouvoir déléguer un domaine, le registre a besoin de ces serveurs, qui se retrouveront en partie droite des enregistrements de type NS, comme ici, dans le registre de .org :

example.org.      IN     NS    ns1.example.org.
                  IN     NS    galadriel.lothlorien.net. 

Comme souvent lors de l'élaboration d'un schéma de données, on peut se poser la question : objet ou attribut ? Les serveurs de noms doivent-ils être des objets « de première classe », gérés en tant que tels, accessibles via whois ou bien doivent-ils être de simples attributs des objets de la classe domaine ?

Les deux approches sont possibles. .com utilise la première. Un serveur de noms est un objet de première classe, vous pouvez le voir avec whois :

% whois ns.kimsufi.com 
...
   Server Name: NS.KIMSUFI.COM
   IP Address: 213.186.33.199
   Registrar: OVH

D'autres registres ont choisi de faire des serveurs de noms de simples attributs. Quelle approche fallait-il retenir pour le protocole d'avitaillement EPP, normalisé dans le RFC 5730 ? Celui-ci sépare le protocole proprement dit de la définition des classes d'objets (classes nommées, dans EPP, mappings. Il existe une classe (un mapping) pour les domaines (RFC 5731), une pour les contacts (RFC 5733) et notre RFC 5732 pour les serveurs de noms. Toutes sont optionnelles. Un registre n'est pas obligé de mettre en œuvre tous ces mappings et peut donc, s'il ne gère pas les objets hosts, ignorer le RFC 5732.

Si un registre choisit, par contre, de gérer des objets « serveur de noms » comme dans ce RFC, la section 1 décrit les relations entre ces objets et les domaines. Ainsi, tout serveur de noms est subordonné à un domaine (le parent) : ns1.example.org est subordonné à example.org et la relation doit être conservée par EPP (par exemple, l'objet host ne peut être créé que par le client EPP qui gère l'objet domaine parent). À noter que le parent peut être externe au registre (par exemple galadriel.lothlorien.net pour le registre de .org).

La section 2 de ce RFC énumère ensuite les attributs de l'objet « serveur de noms ». Le serveur a un nom (par exemple ns2.example.net), conforme aux règles syntaxiques du RFC 1123. Comme tous les objets manipulés avec EPP, il a un identificateur unique spécifique à EPP, le client identifier (voir le RFC 5730). Il a aussi un état (status), qui peut être une combinaison par exemple ok combiné avec linked (qui indique qu'il est utilisé dans au moins un domaine).

Il a enfin une adresse IP facultative. Le RFC recommande de ne la stocker que si elle est nécessaire pour publier la colle, les enregistrements qui permettent de trouver l'adresse IP d'un serveur de noms qui sert la zone dont il fait lui-même partie par exemple dans :

example.org.      IN     NS    ns1.example.org.
                  IN     NS    galadriel.lothlorien.net.

Ici, ns1.example.org est dans la zone qu'il sert (example.org), il faut donc transmettre au registre son adresse IP, pour qu'il puisse publier la colle :

ns1.example.org.          IN   AAAA    2001:db8:314::1:53

alors que cela n'est pas nécessaire pour galadriel.lothlorien.net. Les RFC 2874 et RFC 3596 contiennent des détails sur cette question. La section 3.2.1 de notre RFC, sur la commande <create> revient également sur ce point en insistant que cette commande n'impose pas de transmettre des adresses IP, bien au contraire.

Le cœur d'EPP est décrit dans le RFC 5730, qui inclus une description des commandes possibles (comme <create> ou <delete>). Toutes ne s'appliquent pas à tous les objets et chaque norme d'un mapping doit donc décrire quelles commandes ont un sens pour lui. C'est ici l'objet de la section 3. Par exemple (section 3.1.3), le passage d'un registrar à un autre (transfer) n'a pas de sens pour un objet « serveur de noms » et n'est donc pas défini. L'espace de noms XML du host mapping, de notre classe « serveur de noms » est urn:ietf:params:xml:ns:host-1.0 (voir section 6).

Les commandes <check> et <info> ont leur sens habituel (section 3.1), celui de récupérer des informations sur un objet, ici en donnant son nom. Voici l'exemple donné par le RFC pour la réponse à une commande <info> pour le serveur ns1.example.com :


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <host:infData
       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
        <host:name>ns1.example.com</host:name>
        <host:roid>NS1_EXAMPLE1-REP</host:roid>
        <host:status s="linked"/>
        <host:status s="clientUpdateProhibited"/>
        <host:addr ip="v4">192.0.2.2</host:addr>
        <host:addr ip="v4">192.0.2.29</host:addr>
        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
        <host:clID>ClientY</host:clID>
        <host:crID>ClientX</host:crID>
        <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
        <host:upID>ClientX</host:upID>
        <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
        <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
      </host:infData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

Les informations spécifiques à notre classe sont dans l'espace de noms urn:ietf:params:xml:ns:host-1.0 dont le préfixe est ici host.

La syntaxe formelle complète de cette classe figure dans la section 4, sous la forme d'un schéma W3C.

L'annexe A rassemble les changements depuis le RFC 4932. Les changements, à part la mise à jour des RFC cités en référence, consistent surtout en une nouvelle licence pour le schéma XML et une précision sur le code de retour 2201 (permission refusée).


Téléchargez le RFC 5732


L'article seul

Michael Crichton essaie de calmer nos peurs

Première rédaction de cet article le 11 octobre 2009
Dernière mise à jour le 12 octobre 2009


Finalement, ce n'est pas avant la mort de l'auteur que j'ai lu State of Fear de Michael Crichton. Je n'avais rien perdu en fait. Outre la forme, dont je parle plus tard, l'auteur utilise des méthodes rhétoriques peu honorables pour nier le changement climatique.

Tout au long du roman, tous les personnages sérieux ou attachants expliquent longuement que le changement climatique n'est qu'une vue de l'esprit (et, pour faire bonne mesure, qu'il aurait fallu continuer à utiliser le DDT et les CFC). Puis, dans une annexe au roman, Crichton explique que ce n'est qu'un roman, donne quelques détails sur ses opinions personnelles et explique que tout ça est bien compliqué et qu'il faut écouter les deux parties (y compris, donc, les négationnistes).

En effet, un roman n'est qu'un roman. Je ne vais pas fonder mon opinion sur l'Opus Dei, ou mon analyse de la cryptographie, sur les livres de Dan Brown. Mais tous les auteurs de romans ne sont pas, comme Dan Brown, uniquement occupés à essayer de distraire leurs lecteurs. Certains sont des militants, qui se servent du roman pour faire passer des opinions. Victor Hugo n'a pas écrit les Misérables uniquement pour passionner les lecteurs mais aussi pour dénoncer la situation des femmes, des bagnards ou des pauvres. Hugo a passé vingt ans en exil pour ses idées. Crichton n'avait pas envie de s'éloigner des MacDo et de l'air conditionné sans lesquels (comme l'explique sérieusement un personnage du livre), on ne peut pas vivre. Il prétend donc ne pas faire un livre militant et donner la parole à tous les points de vue, au travers des divers personnages. Bref, il veut le beurre et l'argent du beurre.

Mais il n'y a pas d'égalité dans le traitement des deux camps dans le roman. Les personnages importants et sérieux sont tous négationnistes. Tous ceux qui considèrent le réchauffement planétaire comme une menace sérieuse, sans exception, sont au contraire de ridicules exemplaires de la « gauche Hollywood », des avocats véreux ou des politiciens malhonnêtes.

Même si l'auteur tentait de tenir une égale balance entre les deux camps (ce qui est très loin d'être le cas), cela serait injuste. Bien sûr, certaines organisations environnementalistes sont devenues de grosses bureaucraties, dépensant des millions en frais d'avocat, et gérées comme des entreprises, avec des directeurs payés au succès. Mais cela ne change rien à l'énorme inégalité de moyens entre les environnementalistes et les grandes entreprises qui promeuvent les OGM, la production de dioxyde de carbone ou le nucléaire. Ce sont les secondes qui ont les budgets de propagande (pardon, on doit dire « communication », aujourd'hui) les plus élevés, et même chose pour les cabinets d'avocats qu'elles peuvent déployer. Prétendre tirer un trait d'égalité entre les unes et les autres est intellectuellement malhonnête, comme lorsque Crichton présente les grandes entreprises comme de malheureuses victimes innocentes de méchants environnementalistes fanatiques.

Enfin, sa rage anti-écologiste a au moins un avantage pour le lecteur : lui donner un roman écrit après le 11 septembre où les terroristes ne sont pas musulmans...

Crichton a bien d'autres malhonnêtetés à sa disposition. Par exemple, l'un des personnages essaie à plusieurs reprises de faire pleurer le lecteur sur les malheurs du Tiers-Monde en expliquant que les écologistes sont les ennemis du progrès et veulent donc maintenir les pauvres dans leur misère. Mais ces diatribes prétendument pro-Tiers-Monde seraient plus convaincantes si le livre comptait un seul personnage issu du monde non industrialisé. À part un groupe de cannibales sortis tout droit d'un film de série B des années 1930, il n'y a, bons ou méchants, que des ressortissants des pays riches, dans ce livre qui veut avoir une perspective mondiale...

Peut-être est-ce dû au bâclage général du roman ? L'auteur semble ne pas avoir pris de notes sur son travail, des personnages changent de rôle en cours de route, comme la juriste écologiste qui est présentée comme s'interrogeant sincèrement sur la réalité du changement global, avant d'être présentée comme une policière infiltrée (ce qui explique ses exploits commando lorsqu'elle est capturée par les cannibales), piste qui sera finalement abandonnée en rase campagne... Les invraisemblances ne font pas non plus peur à l'auteur comme le milliardaire âgé qui tient seul dans la jungle pendant une semaine, à surveiller le camp des terroristes.

Même sans vérifier les références données, la partie scientifique du roman comporte aussi des énormités. Par exemple, un personnage critique des prévisions des climatologues leur reprochent des erreurs dans les prévisions numériques et compare l'écart entre la prévision et le résultat à ce qu'on obtiendrai dans d'autres domaines, comme le temps de voyage d'un avion. C'est une méthode absurde : le degré de précision obtenu dans une prédiction dépend énormément du domaine considéré. En physique atomique, on n'est pas satisfait à moins de douze chiffres significatifs alors que bien d'autres domaines des sciences dures (comme l'astrophysique) sont très contents quand l'erreur n'est que d'un facteur deux.

Comme dans son roman suivant, Next, Crichton semble avoir perdu tout talent et tout sérieux d'écrivain. Le conseil le plus charitable qu'on puisse donner est de laisser tomber ses romans tardifs, écrits lorsqu'il luttait contre le cancer, et de relire Jurassic Park et surtout Eaters of the Dead, son chef d'œuvre.

Ou bien, si on veut s'instruire, on peut s'amuser à analyser les erreurs techniques du roman, en s'aidant d'un bon article comme « Crichton's Thriller State of Fear: Separating Fact from Fiction ». En français, on peut aussi lire « Commentaire de lecture : Etat d'Urgence » ou, sur la question du DDT, « Revanche du DDT ».


L'article seul

Exposé DNSmezzo à RIPE 59 (Lisbonne)

Première rédaction de cet article le 8 octobre 2009


Le 8 octobre, à Lisbonne, j'ai eu le plaisir de faire un exposé lors de RIPE 59, l'une des réunions RIPE, réunions rassemblant les acteurs de l'Internet européen (comme vous pouvez le voir, l'Europe du RIPE s'étend assez loin...) L'exposé portait sur DNSmezzo, la partie passive de DNSwitness, le logiciel de mesures des données DNS que j'ai développé à l'AFNIC. Cet exposé a été fait au sein du groupe de travail DNS.

Voici les documents produits à cette occasion :


L'article seul

Interface de configuration du futur BIND 10

Première rédaction de cet article le 8 octobre 2009


Le développement de la prochaine version du serveur DNS BIND continue à suivre son petit bonhomme de chemin. Cette semaine, la discussion portait surtout sur l'interface de configuration, posant quelques problèmes intéressants, notamment pour les cas où BIND sert un très grand nombre de zones.

BIND est utilisé dans des cas très variés. Du serveur de noms de la racine, avec très peu de données mais énormément de trafic et un rôle critique, au serveur d'un fournisseur de services Internet, qui héberge 100 000 zones pour ses clients, en passant par le petit résolveur du petit réseau local de la petite entreprise. Il est difficile de concevoir une interface qui convient à tous les cas. Aujourd'hui, BIND version 9 se configure essentiellement via le fichier named.conf où on indique à la fois des informations de contrôle (comme recursion no; ou listen-on { 127.0.0.1; };) et des données comme la liste des zones servies. Dans la plupart des cas, ces données sont de taille raisonnable mais, pour un gros hébergeur DNS, il peut y avoir des centaines de milliers de zones servies (soit comme serveur maître, soit comme esclave), et la lecture du fichier de configuration, au démarrage comme au rechargement, prend un temps fou :

zone "example.net" IN {
	type master;
	file "pri/example.net.zone";
};
zone "example.org" IN {
	type master;
	file "pri/example.org.zone";
};
zone "example.com" IN {
	type master;
	file "pri/example.com.zone";
};
...

La configuration via un fichier, traditionnelle sur Unix, surtout pour un démon, a d'autres défauts. Tout changement doit se faire par la modification d'un fichier, puis un rechargement (opération, on l'a vu, parfois assez lente et pendant laquelle le serveur ne répond pas, ou plus lentement). Cela n'est pas pratique par rapport à une configuration interactive, comme celle des routeurs Cisco utilisant IOS.

La proposition des développeurs de BIND 10 était donc de remplacer le traditionnel named.conf par une telle interface interactive. L'administrateur système aurait alors tapé des requêtes de configuration, que BIND aurait sauvegardé sous un format non texte, par exemple une base de données SQLite.

Ce projet, présenté dans des réunions physiques en marge de la réunion RIPE à Lisbonne, a suscité, c'est le moins qu'on puisse dire, des réserves. Outre le fait qu'un tel projet heurtait des habitudes ancestrales, outre le fait qu'il mettait BIND à part de tous les autres démons Unix, ce mécanisme avait d'autres inconvénients comme de rendre impossible l'échange de fichiers de configuration (par exemple pour signaler une bogue ou un problème sur une liste de diffusion). Et les gérants de grands parcs de serveurs BIND craignaient la perspective de ne plus pouvoir générer un fichier de configuration avant de le pousser sur toutes les machines.

Des tas d'approches alternatives ont été discutées : par exemple s'inspirer de JunOS plutôt que de IOS, pour une interface interactive (avec navigation hiérarchique) ou bien permettre une exportation de la base de données sous forme texte pour les sauvegardes ou l'échange d'informations.

Mais l'idée qui est revenue le plus souvent était de regarder ce que font les autres démons Unix qui gèrent des milliers de domaines. En général, ils gardent le principe du fichier de configuration pour le contrôle et y renoncent pour les données.

Ainsi, Apache a plusieurs méthodes pour configurer divers domaines. La méthode de base est de les mettre dans les fichiers de configuration :


NameVirtualHost 198.51.100.44
<VirtualHost 198.51.100.44>
ServerName www.customer-1.com
DocumentRoot /www/hosts/www.customer-1.com/docs
</VirtualHost>

<VirtualHost 198.51.100.44>
ServerName www.customer-2.com
DocumentRoot /www/hosts/www.customer-2.com/docs
</VirtualHost>

# ...

<VirtualHost 198.51.100.44>
ServerName www.customer-N.com
DocumentRoot /www/hosts/www.customer-N.com/docs
</VirtualHost> 

Mais il en existe d'autres, très bien décrites dans la documentation. Avec le module Apache mod_vhost_alias, on utilise le système de fichiers comme base de données : la présence d'un répertoire indique la gestion d'un domaine de même nom, sans avoir besoin d'éditer un fichier ou de recharger Apache :

VirtualDocumentRoot /www/hosts/%0/docs

# Et il n'y a plus qu'à créer /www/hosts/www.customer-1.com,
# /www/hosts/www.customer-1.com, etc

Pour le serveur de courrier Postfix, il existe également plusieurs méthodes, décrites dans la documentation. Toutes reposent sur l'usage des maps, des tables qui associent une clé (typiquement une adresse de courrier) à une valeur, par exemple :

virtual_alias_domains = example.com ...
virtual_alias_maps = hash:/etc/postfix/virtual
...
# /etc/postfix/virtual
postmaster@example.com postmaster
info@example.com       joe
sales@example.com      jane

Ces tables peuvent être des fichiers texte, ou bien distribuées par des SGBD, LDAP, etc.

Bref, il en existe des méthodes pour configurer un serveur Internet.


L'article seul

Signature DNSSEC de la racine du DNS en 2010

Première rédaction de cet article le 7 octobre 2009
Dernière mise à jour le 16 décembre 2009


À la réunion RIPE du 6 octobre, l'ICANN et Verisign ont conjointement annoncé la signature DNSSEC de la racine du DNS pour le 1er juillet 2010. (Le processus pratique a commencé en janvier 2010.)

Cette annonce spectaculaire, quoique attendue, comportait notamment un calendrier pour la signature :

  • signature (non publiée) le 1er décembre 2009,
  • publication des signatures (mais pas de la clé) : de janvier-juin 2010, et de manière différenciée selon les serveurs racine,
  • publication officielle de la clé (et donc vrai lancement, puisque cela permettra aux résolveurs de valider) : 1er juillet 2010,
  • ajout des délégations vers les TLD (enregistrements DS) : non spécifié et c'est là le point le plus noir. Comme (malgré ce qu'écrivent les journalistes au sujet d'une soi-disant indépendance que l'ICANN aurait récemment gagné) tout changement dans la racine du DNS, même purement technique, doit être approuvé par écrit et à l'avance par le gouvernement états-unien, ce point va sérieusement handicaper le déploiement de DNSSEC. Les TLD déjà signés comme .se ou .org ne sont donc pas près de pouvoir être validés.

L'annonce a été faite à deux voix (Joe Abley pour l'ICANN et Matt Larson pour Verisign) car, si la grande majorité des acteurs de l'Internet voulaient confier la responsabilité de la signature à l'ICANN, Washington a finalement préféré renouveler sa confiance à une société privée à but lucratif, Verisign. L'ICANN gérera donc la clé de signature de clé (KSK pour Key Signing Key) et Verisign la clé de signature de zone (ZSK pour Zone Signing Key).

Le délai entre la signature et la publication officielle de la clé, via un canal sécurisé à déterminer, s'explique par le fait que, tant qu'on ne publie pas la clé officiellement (on peut toujours la prendre dans le DNS avec dig DNSKEY .), les gens sérieux ne valident pas les signatures et, donc, rien ne peut aller vraiment mal. Quand on publie la clé, les gens s'en servent et, là, ça peut portentiellemnt aller mal. Il est donc prudent de prévoir une marge. Avant que la clé soit publiée officiellement, on peux toujours arrêter de signer (.gov l'avait fait pendant leurs essais). Après, ce n'est plus possible, les résolveurs validateurs casseraient.

Quelques décisions techniques ont également été annoncées hier :

  • KSK RSA de 2048 bits,
  • changée tous les 2-5 ans (avec cérémonie solenelle de génération de la nouvelle clé),
  • condensats de la famille SHA2 (SHA-256).

Les transparents de l'annonce sont en ligne. Un site officiel d'informations sur le processus a été créé en http://www.root-dnssec.org/.

La signature de la racine soulève quelques problèmes techniques spécifiques liés à l'augmentation de taille des réponses, problèmes discutés en Preparing K-root for a Signed Root Zone.


L'article seul

Le projet Net4D d'utilisation des classes DNS

Première rédaction de cet article le 6 octobre 2009


Le projet Net4D vise à utiliser un champ peu connu du DNS, la classe, pour permettre de créer autant d'« espaces de noms » distincts que de classes, afin de démocratiser la gestion des noms de domaine, actuellement verrouillée par le gouvernement états-unien. Ce n'est pas forcément une bonne idée que de « casser » les projets rigolos et originaux mais, comme les promoteurs de Net4D ont manifestement l'oreille des médias, je vais y aller quand même.

D'abord, désolé, mais je ne peux pas m'empêcher d'un petit retour technique. Le DNS distribue des enregistrements, dont la clé est un nom de domaine. Chaque enregistrement a un type (par exemple AAAA pour les adresses IP, MX pour les relais de courrier, etc). Il a aussi une valeur, qui dépend du type (par exemple, la valeur d'un enregistrement de type LOC est une latitude et une longitude). Il a aussi une durée de vie et, surtout, ce qui nous intéresse ici, une classe. Le champ class était quasiment oublié car il a toujours la même valeur, IN (pour Internet). Mais il est toujours là et figure également dans la question que pose un client DNS (champ QCLASS pour Query Class). Tout ceci est précisé dans le RFC 1034, notamment sections 3.6 et 3.7.1.

À la fin de cet article, je donne quelques exemples techniques. Mais, avant cela, revenons à la proposition de Net4D. Aujourd'hui, seules trois classes sont enregistrées à l'IANA :

Registry:
Decimal
Hexadecimal    Name                            Reference
-------------  ------------------------------  ---------
0              Reserved                        [RFC5395]
1              Internet (IN)                   [RFC1035]
2              Unassigned
3              Chaos (CH)                      [Moon1981]
4              Hesiod (HS)                     [Dyer1987]
5-253          Unassigned
254            QCLASS NONE                     [RFC2136]
255            QCLASS * (ANY)                  [RFC1035]
256-65279      Unassigned
65280-65534    Reserved for Private Use        [RFC5395]
65535          Reserved                        [RFC5395]

J'ai déjà parlé de la classe IN pour Internet, numéro 1. Chaos (classe numéro 3) était un protocole réseau qui n'a guère eu de succès mais qui utilisait le DNS. Et Hesiod (numéro 4) était un mécanisme de distribution d'information sur les utilisateurs via le DNS (je l'avais déployé au CNAM mais, aujourd'hui, tout le monde utilise LDAP ou le vieux NIS).

Aujourd'hui, un nom comme www.carlabrunisarkozy.org est donc quasiment toujours de la classe IN. C'est tellement le cas qu'on ne pense plus en général à l'indiquer. Il n'existe pas de mécanisme standard dans les URL (comme http://www.carlabrunisarkozy.org/) pour indiquer une classe, des fonctions pour les programmeurs comme getaddrinfo() n'ont pas de paramètre pour la classe, etc.

L'idée de base de Net4D est d'allouer un certain nombre de classes, actuellement libres, et d'y créer des racines du DNS, avec des noms qui auraient une signification différente. Par exemple, supposons qu'on alloue la classe numéro 2 sous le nom UN, on pourrait, dans la configuration des serveurs de noms, créer un www.carlabrunisarkozy.org qui n'aurait rien à voir avec celui cité précédemment et qui pourrait avoir un enregistrement de type adresse qui pointe vers un tout autre service. (La procédure d'allocation de nouvelles classes, relativement souple, figure dans la section 3.2 du RFC 6195.)

La motivation est politique : il s'agit, comme l'indique le titre du publi-reportage du Monde, d'avoir plein de nouvelles ICANN, pour que d'autres puissent jouer aux jeux politiciens qui occupent les fréquentes réunions de cette organisation. Un autre .com pourrait donc voir le jour, où sex.com pourrait être vendu à un autre, un autre .fr serait alloué à une autre organisation que l'AFNIC, etc. C'est pour cela que l'UIT, qui souffre d'être tenue à l'écart de la gouvernance d'Internet par le gouvernement états-unien, finance Net4D.

Maintenant, quels sont les problèmes de cette approche ? Il y en a trois, un technique, un politique et un de méthode.

Le problème technique est le suivant : bien sûr, les classes fonctionnent, le logiciel est déjà là et tout est déjà normalisé. Mais, sur l'Internet, il y a ce qui marche en théorie et ce qui marche en pratique : l'Internet est hélas très ossifié aujourd'hui. Des tas de programmes mal écrits avec les pieds sont fermement installés et ne laissent pas passer des choses parfaitement légales. D'innombrables boitiers intermédiaires sont sur le chemin des paquets et filtrent ce qu'ils ne comprennent pas. Comme l'ont fort bien expliqué Avri Doria et Karl Auerbach lors des discussions sur la liste governance@lists.cpsr.org, le manque flagrant de robustesse de beaucoup de composants de l'Internet, leur incapacité à gérer des situations légales mais inattendues, ne laisse pas beaucoup d'espoir (voir le message d'Auerbach et celui de Doria ; notez qu'aucun des deux n'est un défenseur de l'ICANN, bien au contraire). Entre deux logiciels sérieux situés sur deux machines du même réseau, les classes vont marcher. Sur l'Internet en général, c'est bien plus difficile (il suffit de voir le temps qu'il a fallu pour que des types légaux comme SRV, passent à peu près partout).

Ce problème technique est d'autant plus sérieux que les promoteurs de Net4D traitent avec une désinvolture inquiétante les points sur lesquels il faudra déployer du code nouveau (comme un remplaçant de getaddrinfo()).

Bref, déployer les classes serait sans doute quasiment autant de travail que de déployer un système de nommage et de résolution complètement nouveau (DNS 2.0 ?).

Le problème politique est qu'utiliser un truc technique astucieux (comme les classes) pour résoudre un problème politique (la mainmise du gouvernement états-unien et des titulaires de propriété intellectuelle sur l'ICANN) est en général une mauvaise idée. Le problème de fond est politique, et aucune astuce technique ne permettra de le contourner. Évidemment, il est plus facile de rêver à se créer son monde idéal, plutôt qu'à s'attacher à changer celui qui existe...

Enfin, il y a un problème de méthode. L'UIT, on l'a vu, finance, avec l'argent public, la technique des classes. Ce n'est pas très compliqué que de configurer un serveur comme NSD pour charger une racine composée de plusieurs classes (par exemple la numéro 65280, prévue pour les essais), tester la délégation, les logiciels clients DNS courants, une version modifiée de getaddrinfo(), un site Web accessible via une classe autre que IN, etc. Ce serait un bon exercice dans un cours sur les réseaux à l'Université. Une entreprise sérieuse pourrait réaliser une telle étude en un temps, et pour une somme très raisonnable. Mais rien ne semble avoir été fait en ce sens (en tout cas rien n'a été publié). Tout le temps et l'argent ont été dépensés en relations publiques, dont l'article du Monde, qui ne donne la parole qu'à un seul point de vue, est un bon exemple. Cela n'augure pas bien du sérieux de la démarche.

Terminons avec un peu de technique. Une des rares utilisations aujourd'hui des classes autres que IN est pour détecter la version d'un serveur de noms (il existe désormais une autre méthode, dans le RFC 5001, mais elle est encore peu utilisée). Cela se fait en interrogeant le serveur pour le type TXT, la classe CH, et le nom version.bind :

% dig +short @f.root-servers.net CH TXT version.bind.
"9.5.1-P3"

Le domaine de tête .bind n'existe pas dans la classe IN.

Enfin, pour ceux qui s'intéressent aux bits sur le câble, pour décoder les paquets DNS, la classe figure dans la question, juste après le nom et le type. En C, le décodage ressemble donc à :

struct dns_packet {
...
    uint16_t    qtype, qclass;
...           
/* sectionptr indicates the next byte in the packet */
decoded->qtype = ntohs(*((uint16_t *) sectionptr));
sectionptr += 2; /* Two bytes for the type */
CHECK_SECTIONPTR(2); /* Two bytes for the class */
decoded->qclass = ntohs(*((uint16_t *) sectionptr));

L'article seul

Un « Internet-Draft » résumant ce que peut faire un FAI contre les zombies

Première rédaction de cet article le 5 octobre 2009


Une des plus grosses menaces sur la sécurité de l'Internet réside dans les zombies, ces machines Windows contaminées par du logiciel malveillant et qui obéissent désormais à un maître qui leur ordonne, selon sa volonté, de lancer une dDoS, d'envoyer du spam, etc.

Il n'existe pas de solution miracle contre les zombies. C'est comme cela que je lis l'Internet-Draft, draft-oreirdan-mody-bot-remediation, intitulé « Remediation of bots in ISP networks » mais qui, malgré son nom, propose peu de remèdes. (Bot est l'abrévation de robot et désigne un zombie.)

Cet Internet-Draft, qui est devenu un RFC de « bonnes pratiques » quelques années plus tard (RFC 6561), est écrit par des employés de Comcast et résume l'état actuel de l'art, vu du point de vue du FAI. Celui-ci, étant donné sa position, est bien placé pour identifier les machines de ses clients qui sont devenues des zombies. Mais que peut-il faire ?

Le document explique bien le problème, ainsi que la manière de détecter les zombies (par l'analyse passive du trafic, ou bien par les plaintes, même si peu de FAI les traitent ; le document évoque aussi la possibilité de recherches actives, comme le permet un outil comme nmap, bien que de telles recherches ne soient pas forcément légales). Il insiste sur la nécessité de détecter vite, si nécessaire au détriment de la justesse des résultats (tirer d'abord, réflechir ensuite...)

Parmi les techniques disponibles, le document cite Netflow (RFC 3954) ou bien les méthodes à base de DNS, très à la mode en ce moment, notamment grâce au travail des chercheurs de Georgia Tech (voir par exemple David Dagon, Wenke Lee, « Global Internet Monitoring Using Passive DNS », Cybersecurity Applications & Technology Conference for Homeland Security, 2009). Mais combien de FAI, qui n'arrivent déjà pas à fournir un service correct à leurs utilisateurs, ont les moyens, la compétence et le temps de mener ce genre d'études ?

Le document rend aussi un hommage obligatoire à la nécessite de préserver la vie privée des utilisateurs, sans trop s'attarder sur comment concilier surveillance rapprochée et respect de la vie privée.

La partie la plus intéressante du document concerne la notification des utilisateurs. Comment les prévenir que leur machine, infectée, est devenue un zombie ? Et le faire de façon à ce qu'ils comprennent et agissent ? Le problème est d'autant plus complexe que les méchants peuvent essayer d'envoyer de faux messages pour brouiller les pistes (du genre « Nous avons reçu notification d'une alerte de sécurité sur votre compte, connectez-vous à http://igotyou.biz/phishing.asp pour indiquer vos coordonnées »...)

Toutes les techniques de communication possibles avec les utilisateurs sont soigneusement passées en revue, mais aucune ne semble parfaite. Les appels téléphoniques coûtent cher (le courrier papier encore plus), les messages peuvent être ignorés, couper l'accès pour que l'utilisateur appele est violent, quoique efficace, etc. Cette discussion des difficultés à attirer l'attention de ses propres clients sur un problème sérieux est la plus concrète et certainement la plus intéressante du document. Le RFC 6108, publié plus tard, présente une solution possible.

La seule section qui aie un rapport direct avec le titre, sur les remèdes est, par contre, très courte, peut-être à juste titre, étant donné la difficulté à traiter les zombies : « Réinstallez votre système d'exploitation » est un remède assez radical et donc peu susceptible d'être suivi...

À noter qu'une autre faiblesse de ce document est que, pour éviter de déchainer les avocats de Microsoft, le fait que la quasi-totalité des zombies soient des machines Windows est tout simplement absent...


L'article seul

Une organisation hacker en France ?

Première rédaction de cet article le 4 octobre 2009


Un « Manifeste pour la création d'une organisation hacker » circule en ce moment (le site original - craqué ? - ne semble plus accessible mais on peut trouver des copies ici ou bien ). Comme son nom l'indique, il plaide pour la mise sur pied d'une organisation qui regrouperait les hackers, en citant des exemples comme le fameux Chaos Computer Club allemand.

Pour les lecteurs de ce blog qui ne seraient pas familiers avec le terme, il faut préciser que le Manifeste fait évidemment référence au sens premier du mot hacker : un passionné qui veut savoir comment ça marche, regarde à l'intérieur et ne se contente pas du mode d'emploi et des livres « Pour les nuls ». Ce genre de personnes est bien antérieure à l'invention de l'informatique (Galilée était un hacker). Ce n'est que bien après que des journalistes ignorants ont commencé à utiliser ce terme comme synonyme de délinquant informatique.

Seulement, c'est aussi sur ce point que le Manifeste a un gros manque : il transforme une méthode (être un hacker) en une idéologie (la liberté et la résistance aux oppresseurs). Il y a des gentils et des méchants chez les hackers, des gens qui utilisent leurs compétences pour aider l'humanité à progresser et des gens qui les utilisent pour se faire un maximum de fric et de gloire en écrasant les autres. Hacker n'est pas une opinion politique et ne peut pas servir à fonder une organisation politique ; c'est un état d'esprit, une technique de pensée, une compétence, c'est tout. Il y a des hackers dans les organisations liberticides, où leurs compétences servent à aider Big Brother. (Au passage, le Manifeste cite à ce sujet, Jean-Bernard Condat mais en lui prêtant des pouvoirs qu'il n'a probablement jamais eu : c'était davantage un habitué des médias, plutôt qu'un super-méchant au service des forces du mal.)

Objection, dirons certains, le Manifeste parle de « vrais » hackers, ceux qui partagent la connaissance et la diffusent à tous, ce qui est incompatible avec un travail pour la DST ou la NSA. Certes, mais, alors, pourquoi ce terme de hacker ? On pourrait aussi bien dire « partisan de la liberté de l'information et de la connaissance » et revenir à des classifications politiques traditionnelles... (Cela serait évidemment moins chic que de citer Hakim Bey... Allez, moi aussi, je vais faire du littéraire, « Le guerrier de la lumière partage avec les autres sa connaissance du chemin. Celui qui aide est toujours aidé ; et il a besoin d'enseigner ce qu'il a appris. » - Paulo Coelho, « Manuel du guerrier de la lumière »)

Cette distinction entre bons et méchants est essentielle, bien plus que celle entre les gens compétents et les autres (cf. la grotesque citation dans le Manifeste « Mon crime est de vous surpasser »). C'est la différence entre le voleur individuel, capitaliste parfait, pour qui seul compte le profit, et celui qui viole les lois dans l'intérêt général, pas pour son profit personnel. Si le partisan de l'Ordre les mettra tous les deux dans le même sac des « actions illégales », le Guerrier de la Lumière :-) fera la différence. Le Manifeste cite la loi Godfrain comme loi répressive, l'assimilant à des lois purement répressives comme Hadopi, alors que, s'il est vrai qu'elle interdit qu'on pénètre dans le système informatique d'une multinationale pour découvrir ses méfaits, elle empêche aussi le petit con qui se prend pour un hacker de jouer avec les machines de citoyens moins compétents que lui, mais qui ont tout autant droit à la tranquillité.

Le Manifeste contient aussi une erreur fréquente mais que je ne peux pas laisser passer : une peinture d'un « monde anglo-saxon » mythique où régnerait une liberté d'expression totale et sans limites (le Manifeste cite explicitement le droit à nier la Shoah). Il y a deux erreurs énormes ici : l'une est de voir le « monde anglo-saxon » comme un bloc homogène de défense de la liberté d'expression totale (alors que des pays comme l'Australie et la Grande-Bretagne sont très en pointe, parmi les démocraties, dans la censure d'Internet). L'autre est de croire sur parole à la légende comme quoi, aux États-Unis, la liberté d'expression serait totale. Essayez de porter un T-shirt « J'aime Fidel Castro » à Miami ou un badge « L'avortement est une liberté fondamentale pour les femmes » en Alabama et vous mesurerez physiquement les limites de la liberté d'expression...

Pour conclure positivement, j'encourage les hackers attachés à des valeurs comme la liberté d'expression, le droit à la connaissance, et la transparence, à rejoindre les organisations qui, aujourd'hui, et depuis des années, se battent pour ces causes :


L'article seul

Le modem US Robotics Courier

Première rédaction de cet article le 1 octobre 2009


Je viens de ressortir du placard un vieux modem analogique, un US Robotics Courier V.34. Ce n'est pas que j'en avais besoin, mais, à une époque, je travaillai souvent avec de tels engins, donc c'était l'occasion de voir s'il marchait toujours, et de prendre quelques photos.

Le Courier était (enfin, est, car il est toujours en vente même si, en France, les modems analogiques ne sont plus guère utilisés) la Rolls-Royce des modems. Doté d'une alimentation électrique sérieuse (alors que la plupart des modems avaient une alimentation de train électrique et supportaient mal les réseaux électriques de mauvaise qualité, par exemple en Afrique), d'un processeur DSP hors du commun, le Courier arrivait en général à accrocher avec le modem d'en face, même sur les plus mauvaise lignes téléphoniques. Il était en outre très fiable. J'ai vu il y a six mois des Courier toujours en service à Nouakchott, malgré la poussière et le sable qui s'infiltraient partout.

(À noter que le Sportster, du même constructeur, n'avait pas du tout les mêmes caractéristiques.)

Voici un Courier, vu de devant. Il est connecté à un ordinateur (diodes TR - Terminal Ready et RS - Request To Send). courier-front-offline.jpg

Une fois en ligne, il allume en outre les diodes CD - Carrier Detect (porteuse détectée), HS - High Speed (ce qui veut simplement dire > 2 400 b/s...) et ARQ (la correction d'erreurs V.42). courier-close-front-online.jpg.

À noter que la seconde photo a été prise lors d'une connexion via le réseau téléphonique de Free, le modem étant branché sur le port téléphonique de la Freebox. Bien que les CGV disent « Du fait de la technologie utilisée, ce Service ne permet pas de garantir le raccordement d'équipements DATA (télécopieurs, modems, minitel, équipements de télésurveillance...) ainsi que l'accessibilité des services afférents », le modem accroche quand même avec certains services RTC.

On peut trouver d'autres photos sur Wikimedia Commons.

Pour me connecter au modem depuis une machine Debian, j'utilise un convertisseur USB<->RS-232 puisque peu de PC de nos jours ont encore des ports série. Le logiciel est minicom et voici le contenu du fichier de configuration /etc/minicom/minirc.modem :

pu port             /dev/ttyUSB0
pu rtscts           Yes

Le résultat, lorsqu'on envoie les commandes Hayes et que le modem se connecte :

AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0                     
OK                                                   
ATDT 0x xx xx xx xx
CONNECT 28800/ARQ/V34/LAPM/V42BIS


### Access restricted to authorized users ###

foobar login: 

Merci à Pascal Courtois et Marc Baudoin pour le coup de main.


L'article seul

RFC 5657: Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard

Date de publication du RFC : Septembre 2009
Auteur(s) du RFC : L. Dusseault (Messaging Architects), R. Sparks (Tekelec)
Première rédaction de cet article le 1 octobre 2009


Dans son processus de normalisation, l'IETF a toujours accordé une grande importance au caractère réaliste et pratique de ses normes. Contrairement à d'autres SDO, qui n'hésitent pas à publier comme norme des pavés incompréhensible et inimplémentables, l'IETF veille à ce que l'avancement d'une norme sur le chemin des normes s'accompagne d'une vérification que cette norme peut être mise en œuvre et que les différents programmeurs ont bien compris la même chose. Cette vérification se traduit par des rapports analysant l'état actuel des implémentations d'une norme et le but de ce RFC est de guider les auteurs de ces rapports.

Le processus du chemin des normes est décrit dans le RFC 2026 (cf. section 1 de notre RFC 5657). Il comprenait trois étapes, proposition de norme (Proposed Standard), projet de norme (Draft Standard) et enfin norme tout court (Standard). Leur nombre a toutefois été réduit à deux par le RFC 6410. Lors du passage de la première à la deuxième étape, pour devenir projet de norme, un RFC doit (section 4.1.2 du RFC 2026) avoir été mis en œuvre au moins deux fois, par des équipes indépendantes, et ces deux mises en œuvre doivent interopérer (pouvoir travailler ensemble).

Le dossier présenté à l'IESG pour l'avancement d'une norme au statut de projet de norme doit comprendre un rapport (même section 4.1.2 du RFC 2026) décrivant les tests effectués entre ces mises en œuvre, leurs résultats, etc. Historiquement, ces rapports, dont la forme n'était spécifiée nulle part, ont été de qualité très variable ; certains étaient très courts, se contentant de dire « On a testé et ça marche ». D'autres détaillaient à l'extrême un aspect particulier des tests mais oubliaient les résultats. Le but de ce RFC 5657 est de limiter cette variation. Il met donc à jour légèrement le RFC 2026. Lui-même a été amendé par le RFC 6410, qui a rendu ce rapport facultatif.

L'espoir est que ce RFC contribuera également à clarifier les tâches à accomplir pour faire avancer une norme : aujourd'hui, peu de gens s'y retrouvent et bien des normes stables et très utilisées sont restées au début du chemin des normes car personne n'avait eu le courage de lancer le processus d'avancement.

La section 2 définit donc ce que doit contenir le rapport d'interopérabilité. Sur certains points, il est moins strict que le RFC 2026. Par exemple, il n'est plus obligatoire de nommer les implémentations testées (cela défrisait certains vendeurs). Si seulement une partie des implémentations existantes est testée, le rapport doit dire comment la sélection s'est faite.

Le RFC 2026 parlait d'implémentations « indépendantes » sans définir ce que voulait dire ce terme. Notre RFC 5657 précise que cela veut dire qu'elles ont été écrites par des personnes différentes, dans des organisations différentes et qu'elles n'aient pas de code en commun (il est fréquent que plusieurs logiciels dérivent de la même souche et n'aient donc guère de mérite à interopérer correctement).

La section 3 décrit le format du rapport d'interopérabilité. C'est le même que celui des RFC. La section indique aussi les parties obligatoires et leur contenu. Un résumé doit préciser les points importants. La méthodologie de test doit être décrite. Les éventuelles exceptions (points de la norme sur lesquels l'interopérabilité échoue) doivent être précisement listées.

Un point délicat des rapports d'interopérabilité est la question des fonctions qu'on teste. Faut-il tout tester dans le moindre détail ou bien a t-on le droit d'omettre des fonctions qui sont dans la norme ? La section 4 analyse la question. En gros, si on teste seulement des grandes fonctions, on ne pousse pas les implémentations dans leurs limites mais si on teste tous les détails et leurs combinaisons, la matrice des tests explose, notamment pour les protocoles ayant beaucoup d'options. Il faut donc trouver un niveau intermédiaire raisonnable. Le RFC cite en exemple le rapport sur RTP qui liste les fonctions testées sous forme de services importants, et non pas sous la forme, trop détaillée, de chaque bit possible de l'en-tête.

Le pragmatisme reste nécessaire. La section 5 explique comment gérer des cas particuliers. Par exemple, si le protocole est déjà largement déployé, on peut (section 5.1) privilégier l'analyse de son fonctionnement réel plutôt que des tests en laboratoire. Une étude ou un questionnaire sont donc sans doute la meilleure méthode. Par contre, si le protocole n'a pas encore connu de déploiement significatif (section 5.2), les tests sont la meilleure approche. Le RFC insiste quand même sur le fait qu'il faut essayer d'anticiper les problèmes opérationnels comme la congestion ou la gestion.

Un autre cas particulier est celui des RFC qui normalisent des formats et pas des protocoles, traité dans la section 5.3. Par exemple, le RFC 5234 normalise les grammaires ABNF et le RFC 4287 le format de syndication Atom. L'interopérabilité, dans ce cas, se juge notamment à la capacité des différentes implémentations à considérer comme corrects les mêmes fichiers (et même chose pour les incorrects). ABNF a ainsi fait l'objet d'un rapport de mise en œuvre.

Parmi les autres cas couverts par notre RFC, celui des protocoles pour lesquels il existe une suite de tests comme WebDAV, avec Litmus. Cette suite ne permet pas forcément de tester l'interopérabilité (section 5.5) car elle ne teste pas des vraies mises en œuvre les unes contre les autres. Avec Litmus, par exemple, le client WebDAV est un client artificiel, qui n'est pas forcément représentatif des vrais clients.

Tous les rapports de mise en œuvre existants sont disponibles en ligne. La section 6 de notre RFC 5657 cite quelques exemples particulièrement instructifs comme le rapport sur PPP-LCP pour sa concision ou celui sur OSPF (publié également dans le RFC 2329), jugé trop long mais quand même de qualité. Celui sur le « pipelining » SMTP est jugé très court, à la limite de la taille minimale.


Téléchargez le RFC 5657


L'article seul

Nominum, une entreprise à éviter de loin

Première rédaction de cet article le 23 septembre 2009
Dernière mise à jour le 4 octobre 2009


La société Nominum, qui vend des logiciels DNS, s'était déjà fait connaître par des discours marketing douteux sur ses concurrents, notamment ceux utilisant du logiciel libre. Elle franchit un nouveau pas, avec l'interview / publireportage de son marketroïde Jon Shalowitz en Why open-source DNS is 'internet's dirty little secret' .

Aujourd'hui que Microsoft proteste de son amitié pour le monde du logiciel libre, et qu'Apple la ferme prudemment, Nominum prend le relais de SCO en assumant le rôle du méchant, qui crache son venin sur le principe même du logiciel libre, comparé au malware.

Bien sûr, comme tant de commerciaux, Jon Shalowitz est un ignorant complet et n'a même pas pensé que tout le monde testerait immédiatement les serveurs de Nominum pour voir quels logiciels ils utilisent :

% dig +short NS nominum.com
ns1.nominum.com.
ns2.nominum.net.
ns3.nominum.com.

% dig +short @ns1.nominum.com CH TXT version.bind.
"Nominum ANS 3.0.1.0"
% fpdns ns1.nominum.com
fingerprint (ns1.nominum.com, 64.89.228.10): Nominum ANS

% dig +short @ns2.nominum.net CH TXT version.bind.
"9.3.5-P2"
% fpdns ns2.nominum.net
fingerprint (ns2.nominum.net, 81.200.68.218): ISC BIND 9.2.3rc1 -- 9.4.0a0

Eh oui, un des serveurs DNS de Nominum utilise BIND, archétype du serveur DNS en logiciel libre. (Les deux autres utilisent ANS, Authoritative Name Server, l'un des principaux produits de Nominum.)

Depuis que cette information a été publiée, le serveur a changé. Difficile de dire s'il a vraiment été remplacé ou bien si un technicien de Nominum a utilisé la directive version du bloc options pour changer le nom sous lequel BIND s'annonce...

Autre cas où Nominum dépend de logiciel libre, son site Web :

% telnet www.nominum.com http
Trying 67.192.49.178...
Connected to www.nominum.com.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.nominum.com

HTTP/1.1 200 OK
Date: Wed, 23 Sep 2009 10:20:28 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/4.3.9
...

Pour une société qui prétend que son logiciel est sécurisé, utilisable industriellement, etc, cela fait drôle d'utiliser PHP, dont on n'avait jamais entendu dire qu'il était spécialement durci... (En outre, si le numéro de version est correct, la version de PHP date de 2004, ce qui montre un certain sens du conservatisme.)

On pourrait continuer à l'infini à se moquer de Nominum et de la nullité de ses équipes commerciales, dont l'aggresivité essaie de masquer la perte de part de marché actuelle. Mais il est probable que le discours de Nominum ne vise pas à convaincre les lecteurs de ce blog, ni les habitués du logiciel libre, ni même d'ailleurs aucun technicien connaissant ne serait-ce qu'un tout petit peu le DNS. Leur propagande est conçue pour une population de PHB, qui ignorent tout du logiciel libre, qui les inquiète. Ceux-ci sont rassurés que quelqu'un ose tenir un discours de guerre froide, avec la reprise d'arguments moyen-âgeux, comme le fait que la non-distribution du code source permettrait à Nominum de mettre en œuvre des protections originales contre les vulnérabilités du DNS.

Tiens, à propos de cet argument (Nominum cite la faille Kaminsky, en oubliant qu'elle les avait obligé, eux aussi, à mettre à jour en urgence leur logiciel), est-il vrai ? Beaucoup pensent que Nominum ne fait que bluffer, qu'il n'existe aucune protection particulière contre l'empoisonnement de cache dans CNS (Caching Name Server, l'autre produit de Nominum). Mais il y en a bien une (merci à Paul Vixie pour son rappel à ce sujet), CNS essaie de se connecter en TCP s'il reçoit des réponses dont le Query ID ne correspond pas (ce qui peut indiquer une tentative d'empoisonnement). Cela n'a évidemment rien de « secret » contrairement à ce que raconte le menteur en chef de Nominum, puisque n'importe quel gérant de zone peut voir (par exemple avec tcpdump) les machines CNS essayer en TCP, simplement en tentant d'empoisonner sa propre zone.

Les serveurs de Nominum, à part qu'ils sont privateurs, sont-ils meilleurs ou au moins comparables aux serveurs en logiciel libre comme Unbound, NSD ou PowerDNS ? Impossible de le dire : lorsqu'il y a des tests comparatifs de logiciels DNS, Nominum refuse systématiquement de prêter une copie d'ANS ou de CNS pour les essais. Ou alors, ils imposent des contraintes comme l'impossibilité de rendre compte publiquement des résultats sans leur autorisation expresse. Donc, on ne peut rien dire, Nominum n'a pas assez confiance dans ses logiciels pour les comparer aux autres.

Devant la pluie de critiques qui s'est abattue sur Nominum à cette occasion, un chef plus haut placé a fini par comprendre l'erreur commise et a opéré un tournant à 180° dans un article sur CircleID où il abandonne toutes les attaques contre le logiciel libre. Voilà des gens qui n'ont pas de fierté : on attaque méchamment puis, lorsque les victimes font trop de bruit, on s'enfuie en prétendant n'avoir jamais voulu cela.

Mais il y a bien plus grave que ces attaques anti-pingouins. Nominum, on l'a vu, ne cherche pas à convaincre les porteurs de T-shirts IETF. Nominum vise les messieurs sérieux, ceux qui sont haut placés dans les entreprises ou les gouvernements. Et, à ceux-ci, Nominum ne se présente pas simplement comme un fournisseur de logiciels DNS, mais comme une entreprise de filtrage et de censure: « Since the first step of any Internet request is a DNS look-up, the name service is a natural position to deploy technology asserting manageable controls over the complexities and threats of today's Internet. ».

Pas étonnant, donc, que Nominum cherche en ce moment à convaincre le gouvernement français de l'intérêt de ses produits, au moment où l'une des pistes suivies pour la loi LOPPSI est l'installation obligatoire de serveurs DNS censeurs chez les FAI.


L'article seul

Que se passe-t-il vraiment quand vous consultez un site Web avec votre navigateur ?

Première rédaction de cet article le 21 septembre 2009


Sur l'excellent site de Q&A Super User, une question « What exactly happens when you browse a website in your browser? » a suscité une excellente réponse de Ilari Kajaste. Comme elle est à la fois correcte et drôle, cela valait la peine de la traduire en français. Traduction et adaptation par Ève Demazière.

Navigateur : Bon, j'ai un utilisateur qui me demande cette adresse : www.telerama.fr. Comme il n'y a pas de barre oblique, ni rien d'autre, j'imagine qu'il s'agit de la page d'accueil. Pas de protocole ni de port ? Ce doit être du HTTP et le port 80... Mais commençons par le commencement. Hello, DNS ! Réveille-toi ! Où se cache ce www.telerama.fr ?

DNS : Attends... Je demande aux serveurs du fournisseur d'accès. Bon, il semble que ce soit le 212.95.67.146.

Navigateur : Merci. Internet Protocol, c'est à toi ! Appelle le 212.95.67.146, s'il te plaît. Envoie-leur cet en-tête HTTP. On demande la structure basique et la page d'accueil... Mais c'est vrai, tu t'en fiches !

TCP/IP : Comment ça, « c'est à moi » ? Comme si je ne bossais pas déjà comme un malade pour le DNS !... Pas moyen d'être un peu reconnu, par ici...

Navigateur : ...

TCP/IP : ça va, ça va, je me connecte... Je vais demander au routeur de le transmettre. Vous savez, ça n'est pas si simple que ça, je vais devoir diviser votre demande en plusieurs morceaux pour qu'elle aille jusqu'au bout, et rassembler les milliers d'infos que je reçois en retour... Ah oui, vous vous en fichez...

[Entretemps, au quartier général de Télérama, un message finit par arriver à la porte du serveur Web.]

Le serveur Web de Télérama : Tchôôô ! Un client ! Il veut des infos ! La page d'accueil ! On peut ?

Logiciel de gestion du contenu : Oui, c'est bon. La page d'accueil, c'est ça ?

Le serveur de la base de données de Télérama : Ouïe, du travail pour moi ! Vous voulez quoi, comme contenu ?

Logiciel de gestion du contenu : euh... désolé, la base de données ! En fait, j'ai déjà une copie de la page d'accueil, dans mon cache, pas besoin de rassembler les infos. Mais récupère donc l'identité de cet utilisateur et garde-le en réserve, comme ça on saura à qui on parle, plus tard. Je renvoie un cookie à l'utilisateur !

Le serveur de la base de données de Télérama : OK !

[Revenons à l'ordinateur de l'utilisateur...]

TCP/IP : Oooookay, voilà la réponse. Oulà, j'ai comme l'impression que c'en est une grosse...

Navigateur : Waouh, il y a toutes sortes de Javascript... Et des images, et des formulaires... Bon, ça va prendre un peu de temps, pour l'affichage. Je m'y mets. Hé, IP, il faut que tu ailles m'en chercher un peu plus. Il y a des feuilles de style chez statique.telerama.fr. Passe par le HTTP et demande /css/styles_2009.css. Et regarde aussi les scripts dans /scripts/, dans /uz/ et dans /scriptaculous_beta/, j'en trouve 60 pour le moment. Il y a même un iframe qui va chez pubm.lemonde.fr.

TCP/IP : je vois le genre... Donne-moi l'adresse du serveur et le reste. Les infos sur les fichiers, mets-les toi-même dans la demande HTTP, je ne veux pas avoir à m'en occuper.

DNS : c'est bon, je cherche le serveur statique.telerama.fr... Ouah, facile, en fait il s'appelle statique-telerama.sdv.fr et son numéro IP est le 212.95.67.146.

Navigateur : ouais, ouais... Attends ! ça va prendre quelques nanosecondes, j'essaie de comprendre tous ces scripts...

TCP/IP : tiens, voilà la CSS que tu demandais. Ah... et encore des scripts qui viennent juste d'arriver.

Navigateur : hey, il y a une publicité en Flash, aussi !

TCP/IP : oh mec, ça a l'air super marrant...

Navigateur : il y a plein d'images, aussi. Et cette CSS est un peu bizarre... Alors, si ce bout va ici, avec cette ligne tout en haut... Et ça, où est-ce que je le mets, il n'y a plus de place... Bon, il faut que je déplace tout pour que ça tienne... Ah, mais l'autre CSS remplace cette règle... Bon, ça ne va pas être facile à afficher, c'est sûr !

TCP/IP : hé, arrête de me distraire, j'ai encore plein de choses à faire, de mon côté !

Navigateur : hé, l'utilisateur, voici une petite barre de progression pour toi, pendant que tu attends. Désolé, mais ça va prendre quelques secondes, il doit y avoir 245 éléments différents à télécharger, et j'en ai 16, pour le moment !

[Une ou deux secondes plus tard...]

TCP/IP : Bon, je crois que j'ai tout. Désolé si je t'ai aboyé dessus tout à l'heure... Tu t'en sors ? C'est un sacré boulot, pour toi...

Navigateur : Ouf, c'est sûr... Tous ces sites Web, de nos jours, ne nous rendent pas la tâche facile. Bon, je m'en sortirai, après tout c'est à ça que je sers...

TCP/IP : c'est difficile pour nous tous, en ce moment... Eh, arrête de faire des demandes DNS pendant ce temps !

Navigateur : Ouh ouh, l'utilisateur ! Ton site Web est prêt, tu peux lire tes infos !


L'article seul

Mes débuts avec Twitter

Première rédaction de cet article le 21 septembre 2009
Dernière mise à jour le 23 septembre 2009


Bon, on ne peut pas dire que je sois un pionnier : j'ai ouvert un compte Twitter (http://twitter.com/bortzmeyer) pour la première fois il y a quelques jours seulement, alors que toute la planète utilise ce service depuis longtemps et qu'il a largement été commenté dans les médias. Je peux maintenant informer la planète entière de ce que j'ai mangé à midi ou bien demander des conseils littéraires. Et j'apprends à grand pas les règles et les usages, le rôle du @ et celui du #.

Néanmoins, je peux toujours dire qu'arriver tard a quelques avantages, notamment la grande disponibilité d'outils divers, déjà développés. Par exemple, j'aime beaucoup http://foller.me/ qui affiche plein de statistiques inutiles sur un abonné Twitter (voir les miennes).

J'ai beaucoup hésité avant de sauter le pas mais, en matière d'outils de communication, la règle est simple : la valeur d'un outil provient du nombre de gens qui y sont connectés (loi de Metcalfe). Un outil de communication génial mais que personne n'utilise n'a guère d'intérêt. Or, je constate que des tas de gens très bien utilisent Twitter et que beaucoup d'informations utiles y circulent (pour les informations inutiles, voir un bon résumé dans l'excellent « Le top 10 des relous sur twitter ».)

Twitter est aussi utilisé désormais par des entreprises « sérieuses » pour diffuser de l'information urgente (c'est le cas de la RATP). Des discussions vives ont déjà eu lieu sur des forums comme Nanog au sujet de l'intérêt de communiquer sur Twitter. Pour un acteur de l'Internet, l'un des intérêts est que l'infrastructure de Twitter ne tombera peut-être pas en panne au même moment que celle dont on veut annoncer la défaillance. En revanche, un des problèmes est que les modes passent vite : si une entreprise investit dans la communication via Twitter, elle est raisonnablement sûre de devoir investir dans un gadget plus récent dans un an ou deux, accumulant petit à petit les canaux de communication, ce qui risque de brouiller celle-ci.

Twitter a quelques particularités qui sont rarement évoquées :

  • C'est un service centralisé, où tout passe par un acteur unique. Techniquement, Twitter est un grand recul par rapport à XMPP.
  • Il n'est pas seulement centralisé techniquement mais aussi organisationnellement : une seule société contrôle tout et, comme avec la plupart des services « 2.0 », vos données ne vous appartiennent plus (quel utilisateur de Twitter a lu les règles d'utilisation ?).
  • Twitter est accessible par de très nombreux moyens techniques. J'ai lu des gens qui refusaient d'utiliser Twitter avec des arguments du genre « Pas question de passer par un navigateur Web pour suivre les nouvelles » mais cet argument ne tient pas, le navigateur n'est qu'une des innombrables options possibles.

Pour cette dernière raison, des discussions sur « Le meilleur outil de veille, RSS ou Twitter » sont un peu à côté de la plaque, puisqu'on peut suivre Twitter en RSS... (Et probablement l'inverse.)

Twitter étant un grand succès, il n'est pas étonnant que les identificateurs Twitter deviennent désormais aussi convoités que dans d'autres domaines. Ainsi, la SNCF a déjà vu son nom lui échapper (c'est une violation directe des règles d'utilisation mais cela se fait quand même.)

Personnellement, pour tout ce qui ressemble de près ou de loin à la messagerie instantanée, ce qui est le cas de Twitter, j'utilise l'excellent logiciel Pidgin. Il a deux greffons pour faire du Twitter, pidgin-twitter et microblog-purple, qui est celui que j'utilise. On en trouve une bonne documentation en How to Add Twitter in Pidgin (Windows/Linux).

Son installation, sur une machine Debian, consiste simplement en :

wget http://microblog-purple.googlecode.com/files/mbpurple-0.2.3.tar.gz
tar ...
sudo aptitude install libpurple-dev pidgin-dev
make
sudo make install

Et le résultat ressemble à : twitter-pidgin.png

S'il y a tant de clients Twitter différents, c'est en bonne partie parce que Twitter dispose d'une API très simple. Elle permet le développement de plein de gadgets rigolos comme par exemple l'envoi des messages de commits de Subversion (pour lequel il existe même plusieurs méthodes).

Pour le programmeur Python qui veut utiliser cette API, le plus simple est d'installer le paquetage python-twitter. On peut ensuite faire des choses comme :


>>> import twitter
>>> api = twitter.Api(username='MONNOM', password='MONMOTDEPASSE') 
>>> status = api.PostUpdate(u"Envoyé grâce à l'API de Twitter et python-twitter")

(La lettre u devant la chaîne de caractères est pour bien expliquer qu'on veut de l'Unicode, la chaîne comptant des caractères composés.) On peut ensuite lire cette passionnante information.

Un exemple plus sophistiqué est celui que j'utilise pour prévenir, sur Twitter, des nouveautés de mon blog. Le programme Python est très simple, il extrait automatiquement le titre à partir du source XML et essaie juste de faire tenir le titre et l'URL dans la limite de Twitter, les fameux 140 caractères :

max_twitter = 140
...
rest = max_twitter - len(url) + 1
if len(title) > rest:
    shorttitle = title[:rest-3] + "..."
else:
    shorttitle = title
message = u"%s %s" % (shorttitle, url)

Il existe bien d'autres outils pour faire du Twitter depuis la ligne de commande, par exemple, toujours en Python, Twyt.

Bien sûr, Twitter n'est pas le seul outil centralisé de microblogging et on me recommande souvent Identi.ca, qui travaille uniquement avec du logiciel libre et s'engage à ne pas abuser des données personnelles. J'ai aussi un compte sur identi.ca mais, pour l'instant, je n'ai pas l'impression qu'il y aie autant de monde que sur Twitter. Et je n'ai pas encore testé l'API. (Il en existe une version compatible avec Twitter.)


L'article seul

Accéder aux ports série d'une Sparc

Première rédaction de cet article le 20 septembre 2009
Dernière mise à jour le 2 avril 2011


Je sais, il n'y a plus grand'monde qui a des Sparc ou des UltraSparc en production mais c'était de bonnes machines et j'ai passé tellement de temps à essayer d'accéder à la console d'une Sparc par son port série qu'il me semble que ce serait dommage de ne pas rédiger cet article. Qui sait, je pourrais avoir demain besoin de cette petite documentation...

Pourquoi a t-on besoin du port série ? Parce que la Sparc n'a pas forcément une carte graphique et, même si elle en a, on n'a pas toujours le clavier et l'écran spéciaux qu'elle réclame. Si on a acheté sa Sparc sur eBay ou bien lors d'un vide-grenier, par exemple pour jouer avec Debian ou NetBSD sur une machine originale, on n'a souvent pas tout le matériel. En raison de cette utilisation « Unix libre », courante sur les vieilles Sparc, les meilleures documentations se trouvent en relation avec ces Unix (par exemple, la FAQ de NetBSD ou celle spécifique aux UltraSparc). Mais je n'ai jamais trouvé de documentation qui mentionne tous les points exposés ici. Si vous venez donc de toucher une vieille Sparc et que vous voulez y installer un Unix libre, voici quelques trucs utiles au démarrage.

Le principe de base est simple : la Sparc, dans sa configuration de sortie d'usine, démarre sur son clavier et son écran (spécifiques de Sun). Si elle ne trouve pas de clavier (et pas d'écran), elle bascule sur son premier port série, nommé A. Si on veut utiliser le second port série, nommé B, il faudra la configurer explicitement. Donc, même si on n'a pas de clavier Sun, le port série devrait être utilisé automatiquement. Néanmoins, il y a parfois des imprévus et, d'une manière générale, la solution la plus simple est d'essayer de mettre la main sur un clavier Sun.

Lorsque la machine démarre, si on veut prendre la main pour, par exemple, changer les options de démarrage, avec le clavier Sun, on doit taper STOP-A (les deux touches en même temps). Si on n'a pas de clavier Sun et qu'on passe par le port série, cela dépend du logiciel utilisé. Avec Minicom, c'est Ctrl-A F (qui envoie un BREAK) Avec cu, c'est ~#.

Note sur Minicom en passant : voici un fichier de configuration (/etc/minicom/minirc.$NOM_CONFIG) qui permet de se connecter au port série d'une Sparc, depuis un PC Linux moderne, qui n'a donc pas de port série et utilise un câble USB<->série (le câble série étant un « zéro modem »). Une fois le module noyau usbserial chargé, on se connecte donc à /dev/ttyUSB0 (ce serait plutôt /dev/ttyS0 pour un vieux PC, équipé d'un port série) :

# Connection to the serial port, for managing a machine such as a Sparc
pu port             /dev/ttyUSB0
pu baudrate         9600
pu bits             8
pu parity           N
pu stopbits         1
pu minit            
pu mreset           
pu mhangup          
pu rtscts           No 

Fin de la digression minicom, retournons à la Sparc. Si on utilise un clavier Sun et que le clavier est un Azerty, il faut faire un STOP-Q et non pas STOP-A. Ce n'est qu'après que la Sparc reconnait son clavier correctement. Les autres commandes sont donc à taper normalement.

Cela, c'est pour la configuration d'usine. Mais, si on a récupéré une Sparc d'occasion, une autre configuration, en général inconnue, a parfois été stockée dans la NVRAM. Cette configuration peut, par exemple, débrayer la sélection du port série et on est alors bien démuni si on n'a pas le clavier et l'écran Sun. Remettre à zéro la NVRAM nécessite, avec un clavier Sun, un STOP-N (les deux touches en même temps) au démarrage (presser bien avant d'allumer, et bien attendre longtemps). Si on n'a même pas de clavier Sun, même emprunté pour cinq minutes, je ne sais hélas pas quoi faire.

L'UltraSparc 10 a deux ports série, un DB25 femelle (le port A) et un DB9 mâle (le port B). Que faire si le premier, le seul choisi automatiquement avec la configuration d'usine, ne marche pas, ce qui m'est arrivé sur une Sparc récupérée ? Le mieux est d'emprunter un clavier Sun (l'écran n'est pas nécessaire) et de taper en aveugle les commandes qui forcent l'usage du port B :

setenv output-device ttyb
setenv input-device ttyb
reset

On peut aussi utiliser le clavier Sun en entrée et la console série seulement en sortie mais l'installeur de Debian n'aime pas (« Inconsistent console »).

Sur la photo ci-dessous, on voit un câble série branché dans le port B : sparc-ultra10-back-small.jpg et sur celle-ci, les deux ports sont libres. A est le 25-broches à gauche, B est étiqueté par son nom : sparc-ultra10-ports-small.jpg


L'article seul

Fiche de lecture : Dictionnaire amoureux des langues

Auteur(s) du livre : Claude Hagège
Éditeur : Plon / Odile Jacob
978-2-259-20409-5
Publié en 2009
Première rédaction de cet article le 20 septembre 2009


Comme son titre l'indique, ce livre est pour l'amoureux des langues, celui qui est prêt à se pencher sur la néologie en islandais (article « Islandais ») ou sur les risques pesant sur le qawasqar (article « Danger (langues en) »). Si, au contraire, vous voulez annuler Babel et pensez qu'il vaudrait mieux que tout le monde ne parle qu'une seule langue, il vaudrait mieux trouver une autre lecture.

Claude Hagège est connu pour ses travaux de linguiste que, dans ce livre, il essaie de faire partager à tous. La forme est celle d'un dictionnaire mais, en fait, chaque article est plutôt encyclopédique, détaillant un des points qui touchent particulièrement l'auteur.

Ainsi, l'article « Témoignages » explique qu'en français, les conditions dans lesquelles on a appris une information (« Jean n'est pas allé travailler aujourd'hui ») doivent être exprimées en plus (« Irène m'a dit que Jean n'était pas allé travailler aujurd'hui ») alors qu'en turc, il y a deux verbes différents selon qu'on sait l'information de première main, ou bien indirectement. (Et le tuyuca a cinq niveaux différents, selon qu'on est témoin immédiat, ou plus ou moins éloigné de la source originale.) Ainsi, on ne peut pas être ambigu en turc lorsqu'on rapporte une information : la grammaire oblige à dire si on était vraiment là pour la constater.

« Composés et dérivés » explique, lui, comment former des nouvaux mots, selon les langues, certaines, comme le chinois, privilégiant la composition (faire un mot avec deux), d'autres, comme les langues sémites, la dérivation (ajouter des affixes à un radical).

Autre article passionnant, « Hybridation » explique les mécanismes par lesquelles les langues se mélangent. L'emprunt massif de vocabulaire est l'exemple le plus connu mais il y a aussi des mélanges bien plus intimes comme dans le cas du maltais où l'hybridation avec l'italien et l'anglais rend parfois difficile de détecter le fond arabe. (Il y a aussi un article « Emprunt », sur le même sujet.)

L'article « Traduire » est évidemment un des plus longs car cette activité a une longue histoire d'auto-introspection. Comment traduire le chinois « une moustache en huit » sans savoir que l'expression fait allusion à la forme du caractère représentant ce chiffre en chinois ? Et si un français parlait de « moustache à la gauloise », le traducteur en chinois aurait sans doute besoin de se renseigner sur l'histoire de France...

Mon principal regret est que beaucoup d'articles passionnants (comme « Difficiles (langues) ») soient assez gâchés par l'anglophobie militante de l'auteur qui passe beaucoup trop de temps à cracher son venin contre le rôle excessif de la langue d'Obama et de Ballmer, en dérapant souvent sérieusement.

Le livre est très technique, et nécessite, si on n'a pas de connaissances préalables en linguistique, une attention soutenue. Mais l'auteur a fait de gros efforts pour tout expliquer et rendre ces concepts accessibles et il y est bien arrivé.


L'article seul

OpenDNS, surtout pas

Première rédaction de cet article le 17 septembre 2009
Dernière mise à jour le 11 mai 2015


Quand survient un problème avec les résolveurs DNS d'un FAI, la réponse courante dans les forums bas de gamme est « il faut utiliser les résolveurs d'OpenDNS ».

Un exemple courant de problème est lorsque le FAI déploie des DNS menteurs pour diriger ses utilisateurs vers des sites Web de publicité. Par exemple, lorsque SFR a rétabli ses DNS menteurs en août 2009, des tas de blogueurs ont conseillé sur leur site d'utiliser OpenDNS. Même chose lorsqu'une faille de sécurité touchant au DNS est publiée (par exemple lors de l'attaque contre Eircom).

Dans le premier cas, l'idée est mauvaise : les résolveurs d'OpenDNS sont également des menteurs. Si OpenDNS a supprimé les mensonges en cas de noms non existants, ils continuent à changer les réponses « pour des raisons de sécurité ».

Donc, utiliser OpenDNS pour échapper aux résolveurs menteurs de son FAI, c'est comme plonger dans le lac lorsqu'il pleut, pour éviter d'être mouillé. Le seul avantage, c'est qu'on est mouillé volontairement... (Je plaisante mais j'ai vu l'argument « Oui, mais OpenDNS, on n'est pas obligé de l'utiliser ». Justement, puisqu'on n'est pas obligé, ne l'utilisons pas.)

À noter que ces mécanismes de mensonge sur les réponses DNS sont également débrayables si on se crée un compte (gratuit) chez OpenDNS avant d'indiquer ses adresses IP et de décocher la case qui va bien.

La publicité d'OpenDNS repose sur plusieurs arguments, la plupart fallacieux. Un des plus courants est la vitesse. Cet argument est très souvent répété sur les forums, par des gens qui n'ont jamais mesuré eux-mêmes, et n'est pas très différent de tous les arguments marketing « X est plus rapide que Y », argument qui ne s'impose que par la répétition. Si tout le monde le dit, c'est que ça doit être vrai, non ? Eh bien non, si on mesure soi-même au lieu de répéter ce que disent les moutons, on s'aperçoit qu'OpenDNS est toujours plus lent que les serveurs DNS de votre réseau local ou de votre FAI. Comme le note seizurebattlerobot lors d'une discussion sur Slashdot, c'est logique, « Despite their claims to the contrary, OpenDNS's servers are likely farther away from you than your local ISP's. ».

D'autre part, OpenDNS affirme protéger l'utilisateur de la pornographie et du malware en mentant sur les réponses DNS, même lorsque le nom de domaine existe. (Ce qui entraîne de sérieux risques de surblocage.)

Enfin, il y a ce qu'OpenDNS ne dit pas : puisque l'usage de leurs résolveurs est gratuit, quel est leur modèle d'affaires ? Simplement vendre l'information qu'ils ont récolté sur vous. Comme le note encore seizurebattlerobot sur Slashdot, en juillet 2009 : « They also keep permanent logs of all queries, which could be subpoenaed by a government entity. Their joke of a privacy policy allows them to sell your logs to "Affiliated Businesses", which pretty much means anybody. Not that it really matters - they could amend their privacy policy tomorrow morning and be selling your info by the afternoon. ». Un résolveur DNS reçoit énormément d'informations sur ce que font ses clients (et je sais de quoi je parle, grâce à des systèmes comme DNSmezzo).

Donc, pour l'utilisateur typique, il n'existe aucune raison valable d'utiliser OpenDNS. Y a t-il des cas où on n'a pas le choix ? Sur certains réseaux (par exemple chez beaucoup de FAI africains, sur un hotspot mal géré, dans beaucoup d'hôtels), les serveurs DNS sont souvent en panne ou très lents. Si on est coincé sur un tel réseau, on a bien besoin de résolveurs DNS quand même. Autrefois, tous les résolveurs DNS étaient ouverts à tous et il suffisait d'en prendre un au hasard. Aujourd'hui, pour diverses raisons (voir par exemple le RFC 5358), de tels serveurs récursifs ouverts sont de plus en plus rares et ceux qui restent ne sont pas forcément dignes de confiance. Une des solutions est de les utiliser quand même, et d'être prêt à changer lorsqu'ils tombent en panne ou bien se sécurisent.

Une autre solution est d'avoir un résolveur DNS local sur sa machine ou son réseau. Cela peut sembler une solution très geek mais c'est plus simple que ça n'en a l'air. Sur Debian ou Ubuntu, un simple aptitude install unbound et le résolveur Unbound est prêt à l'emploi (il faut modifier /etc/resolv.conf pour indiquer comme serveur de noms 127.0.0.1, la machine locale, ou bien changer les réglages DHCP si c'est possible). Unbound est probablement plus sûr que BIND car moins chargé en fonctions. Mais, bien sûr, on peut utiliser BIND aussi. Pour les amateurs de MS-Windows, Gils Gayraud me recommande TreeWalk.

Certaines personnes peuvent s'inquiéter à cette idée d'un résolveur sur chaque machine (ou en tout cas sur chaque petit réseau), en raison de la charge supplémentaire que cela imposera aux serveurs de la racine ainsi qu'à ceux des domaines de tête. Sans le partage des informations dans les grands caches des résolveurs DNS des FAI, les serveurs de la racine tiendront-ils le coup ? C'est en raison de cette question que je ne conseille pas d'installer son résolveur à soi sans une bonne raison. Dans le futur, il est possible qu'on n'ait plus le choix, si on veut un service DNS correct. Et, à ce moment, on verra bien. Lors de réunions d'experts comme à l'OARC, les opérateurs des serveurs racine ont toujours déclaré qu'ils n'étaient pas inquiets sur ce point.

Reste le cas des documentations dont l'auteur ne sait pas sur quel réseau tournera la machine et où il préfère indiquer les serveurs d'OpenDNS pour permettre un copier-coller des instructions (voir par exemple http://wiki.openmoko.org/wiki/Android_usage). Une meilleure solution serait de recommander d'utiliser DHCP, pour récupérer les serveurs du réseau local.

La dernière solution est d'utiliser un concurrent d'OpenDNS. La plupart utilisent les mêmes méthodes et ont des résolveurs tout aussi menteurs. C'est le cas de Comodo, de Scrubit ou de Neustar/Advantage. À défaut de tout, les utiliser permet d'éviter la constitution d'un monopole d'OpenDNS. Mais il existe aujourd'hui un service de résolveur ouvert honnête, c'est Google DNS et c'est donc une possibilité intéressante. Pour une liste plus complète (trop complète, on y trouve de tout mais, heureusement, avec tous les détails pratiques), voir l'excellent resolv.conf de Chris Hills.

Je laisse la conclusion à, à nouveau, seizurebattlerobot : « I think many people read the "Open" part of the OpenDNS name and turn their brains off. »


L'article seul

RFC 3971: SEcure Neighbor Discovery (SEND)

Date de publication du RFC : Mars 2005
Auteur(s) du RFC : J. Arkko, J. Kempf, B. Zill, P. Nikander
Chemin des normes
Première rédaction de cet article le 15 septembre 2009


Pour trouver l'adresse MAC d'un voisin, une machine IPv6 utilise le protocole NDP (Neighbor Discovery Protocol), normalisé dans le RFC 4861. Ce protocole ressemble beaucoup au traditionnel ARP (RFC 826) d'IPv4 et il partage notamment sa principale vulnérabilité : une machine peut tout à fait se faire passer pour une autre et recevoir ainsi les paquets qui ne lui sont pas destinés. En outre, NDP dispose d'autres fonctions qu'ARP, comme la découverte des routeurs, fonctions qui sont tout aussi critiques et tout aussi vulnérables. Au début d'IPv6, l'enthousiasme pour IPsec était sans limite et il était donc censé résoudre ce problème, comme beaucoup d'autres. En réalité, IPsec a été peu implémenté et encore moins déployé et il a donc fallu trouver une autre solution, SEND (SEcure Neighbor Discovery) qui fait l'objet de ce RFC.

Les détails sur les vulnérabilités de NDP figurent dans le RFC 3756. Ils sont aussi résumés dans la section 11.1 du RFC 4861 et rappelés dans la section 1 de notre RFC 3971. Exemple ironique, à chaque réunion physique de l'IETF, certains portables sont configurés pour créer des réseaux ad hoc et envoient des annonces RA (Router Advertisement) concurrents de ceux du routeur légitime. La seule solution est de donner au micro les adresses MAC des routeurs « pirates » pour les filtrer.

Cette section 1 explique aussi, en plus des problèmes généraux d'IPsec, pourquoi il ne peut pas être utilisé pour sécuriser un protocole de découverte des voisins et du réseau, en raison des limites du bootstrap (on a besoin du réseau pour IKE mais on a besoin d'IPsec pour initialiser le réseau..).

Sur un réseau local qui n'offre pas de sécurité physique (Ethernet sans 802.1x ou bien WiFi), NDP est très vulnérable et c'est la raison d'être de SEND.

Résumé brièvement, SEND consiste à utiliser des adresses CGA (adresses auto-signées) sur les machines non-routeuses et des signatures cryptographiques avec certificat pour authentifier les annonces des routeurs.

La section 3 résume les fonctions de NDP :

  • Découverte automatique des routeurs (une autre solution étant d'utiliser DHCP),
  • Auto-configuration, sans état, des adresses IP des machines (RFC 4862),
  • Détection des conflits d'adresses (lorsque deux machines ont reçues la même adresse IP),
  • Résolution d'adresses IP en adresses MAC (section 7.2 du RFC 4861).

Toutes ces fonctions sont mises en œuvre par des messages portés sur ICMP (RFC 4443) qui contiennent des données et des options encodées en TLV. (Voir la liste dans le registre IANA.)

Comment fonctionne SEND ? C'est l'objet du reste du RFC, à commencer par la section 4 qui décrit le fonctionnement général. SEND comprend :

  • Un système de certificats, permettant de valider les annonces d'un routeur, en suivant un chemin de certificats signés (l'annonce du routeur n'a pas besoin d'inclure tous les certificats du chemin, des nouveaux messages NDP permettent au récepteur de demander les certificats qui lui manquent).
  • Des adresses cryptographiques, les CGA du RFC 3972, permettent de s'assurer que la machine qui répond aux requêtes Neighbor Discovery est bien la « propriétaire » de l'adresse. (Donc, contrairement aux annonces des routeurs, SEND n'utilise pas de certificat pour authentifier les simples machines. Cette possibilité est uniquement mentionnée pour un usage possible dans le futur.)
  • Une nouvelle option NDP, RSA signature, permet de vérifier l'intégrité du message. La clé publique utilisée pour la signature est récupérée, soit par les certificats, si l'émetteur est un routeur, soit, pour le cas de CGA par une autre option qui permet d'inclure cette clé dans les messages. À noter que RSA est le seul algorithme normalisé, pour garantir l'interopérabilité (puisque SEND tourne dans des environnements où il ne serait pas réaliste de se lancer dans des négociations entre émetteur et récepteur). S'il fallait changer d'algorithme, par exemple suite aux progrès de la cryptanalyse, il faudrait alors développer une nouvelle version de SEND (ce qui est précisement en cours).
  • Et enfin un mécanisme de nonce contre les attaques par rejeu.

Le détail de ces nouvelles options et de leur format figure en section 5. Par exemple, l'option CGA (section 5.1) permet au répondeur qui utilise des adresses IP CGA d'inclure la clé publique utilisée dans la réponse. La section 5.1.1 détaille comment l'émetteur doit remplir cette option et la 5.1.2 comment le récepteur peut l'utiliser pour vérifier que le détenteur de la clé est bien celui de l'adresse

La section 5.2, elle, normalise l'option CGA signature, où le message SEND contient une signature au format PKCS#1. Là encore, la section décrit en détail ce que doit faire l'émetteur pour remplir cette option et le récepteur pour la vérifier. Toute aussi indispensable, la section 5.2.3 traite de la configuration de l'option par l'administrateur système et note qu'une mise en œuvre de SEND doit pouvoir être configurée pour vérifier cette signature par différents moyens, comme une trust anchor, une clé publique de départ, à laquelle on fait confiance et qui peut à son tour signer d'autres clés.

Un enjeu de sécurité important de SEND est la protection contre le rejeu. Pour cela, les options Timestamp et Nonce, décrites en section 5.3 sont indispensables. Timestamp indique le temps de l'émetteur et permet, si les horloges de l'émetteur et du récepteur sont raisonnablement synchronisées (la section 5.3.4.2 précise les tolérances admises), d'empêcher qu'un méchant n'enregistre une réponse tout à fait légitime et ne la réutilise plus tard, alors qu'elle n'est plus valable. Nonce, elle, stocke un nombre aléatoire (de taille variable, au moins 48 bits) envoyé par le solliciteur et retourné par le répondant. Ainsi, on peut être sûr que le paquet SEND est bien une réponse à une question qu'on avait posé. Les règles de génération imposent l'usage de ces deux options (et les récepteurs doivent considérer les messages SEND sans une de ces options comme étant non-SEND donc non sûrs).

La section 6 entreprend de résoudre le difficile problème de la validation des certificats des routeurs. La méthode normale, si on n'a pas déjà l'information dans son magasin de certificats, est d'aller la chercher sur l'Internet. Mais, ici, comme il s'agit de découvrir le routeur, cette solution n'est pas possible puisque, justement, on n'a pas encore de routeur pour aller sur l'Internet. Comment SEND traite t-il ce problème ?

Le modèle général est celui de X.509, comme l'utilisent, par exemple, les navigateurs Web. Chaque machine doit avoir un magasin de certificats (qui ne sont pas forcément les mêmes que ceux utilisés, après la configuration d'IP, pour des activités comme le Web) et se sert de ce ou ces certificats comme trust anchors, comme points de départ de la validation (sections 6.1 et 6.5). La machine terminale n'a pas de certificats à elle (à part avec CGA, elle ne s'authentifie pas, seul le routeur le fait). Le routeur, lui, reçoit son certificat et sa clé privée. Le certificat l'autorise non seulement à agir comme routeur mais également à annoncer certains préfixes IP et pas les autres.

Qui attribue ces certificats ? La section 6.2 mentionne une autorité de certification mondiale unique pour les routeurs... qui n'existe pas (et n'est sans doute pas près d'exister). Elle pourrait émaner de l'IANA ou bien d'un consortium formé par les RIR.

Une autre solution mentionnée par le RFC (nommée dans le RFC le « modèle décentralisé », un terme incorrect), et la seule possible aujourd'hui, est celle d'un nuage de diverses autorités de certification, chacune reconnue par certains sites mais pas par d'autres. Cela rend très difficile la mobilité (un portable en visite sur un autre site n'a aucun moyen de valider les annonces SEND du routeur local).

Le format des certificats, lui, est expliqué en section 6.3. C'est du X.509 v3, avec le profil des RFC 3779 et RFC 5280, RFC qui permet de décrire dans le certificat les ressources Internet qu'on peut annoncer (les adresses IP, par exemple, section 4.2.1.6 du RFC 5280).

Enfin, pour permettre la réception de certificats non contenus dans le magasin, mais nécessaires pour boucler la chaîne de validation, la section 6.4 prévoit des types de messages ICMP Certificat Path Solicitation et Certification Path Advertisement. Avec elles, on peut construire des messages pour demander ou obtenir des certificats.

L'usage des adresses IP par SEND fait l'objet de la section 7. Une machine SEND est censée n'utiliser que CGA (section 7.1) et donc pas les adresses IP temporaires du RFC 4941. Sécurité ou vie privée, il faut choisir ! Pour travailler avec d'autres adresses, rien n'est encore trop précisé, à part l'API du RFC 5014. Autre exemple (section 7.4), SEND ne fournit aucun moyen d'authentifier les messages NDP pour les adresses IPv6 statiques, ou bien les adresses autoconfigurées à partir de l'adresse MAC.

SEND est aujourd'hui très peu déployé. Comme tous les protocoles récents (il date quand même de plus de quatre ans), il fait face à des problèmes de transition avec l'ancienne méthode (qui est de ne pas sécuriser du tout). La section 8 expose ces problèmes. Comme, en pratique, une machine SEND va certainement rencontrer des réseaux non-SEND, le RFC demande que les messages non sécurisés soient également acceptés. La machine SEND qui reçoit deux sortes de messages doit évidemment donner la priorité à ceux qui sont sécurisés. Le RFC recommande également une option de configuration « paranoïaque » où seuls les messages NDP sécurisés soient acceptés (à condition qu'elle ne soit pas active par défaut). Inversement, le RFC admet une option de ne pas envoyer de messages SEND (au cas où ils perturbent le réseau mais, si tout le monde suit la norme IPv6 correctement, cela ne devrait pas arriver, les options SEND des messages NDP devraient simplement être ignorées) mais cette option doit être activée explicitement.

La cohabitation de réseaux SEND (sécurisés) et non-SEND (non sécurisés) peut avoir pour conséquence la réception d'un message non sécurisé qui essaie de remplacer l'information issue d'un message sécurisé. Notre RFC 3971 impose que les caches (comme celui des voisins qui, sur Linux, peut être affiché avec ip -f inet6 neighbour show) doivent garder trace du caractère sûr ou non sûr de l'information et ne doivent pas remplacer une information sûre par une non sûre.

SEND est entièrement voué à la sécurité donc l'obligatoire section Sécurité pourrait être inutile mais, ici, la section 9.1 couvre un problème utile : les menaces que SEND ne résoud pas. Ainsi, SEND ne protège pas la confidentialité des échanges NDP. SEND ne rend pas complètement sûr un réseau physique non sûr (par exemple, une machine malveillante peut toujours envoyer des paquets avec une adresse MAC source mensongère).

À l'heure actuelle, un groupe de travail de l'IETF, csi, travaille à améliorer SEND. Par exemple, SEND est limité à SHA1 et RSA alors que le groupe de travail explore la meilleure façon d'utiliser de nouveaux algorithmes cryptographiques.

Quells mises en œuvres de SEND sont disponibles ? DoCoMo en avait une mais qui n'est plus maintenue. On trouve quelques bouts de code par ci par là, quelques projets pas finis, mais apparemment pas d'implémentation libre complète qui marche sur des systèmes comme Linux ou FreeBSD. Donc, je ne crois pas que je pourrai activer SEND sur ma Freebox. En revanche, Cisco a une mise en œuvre de SEND sur ses routeurs (mais pas, semble t-il, Juniper).

Pourquoi SEND n'est-il pratiquement pas déployé ? Il y a sans doute plusieurs raisons : le déploiement est difficile puisqu'il faut mettre la clé publique des routeurs dans chaque machine et la sécurité du protocole NDP n'est pas vraiment un problème aujourd'hui (à part sur le réseau de Defcon, les attaques réelles sont rares).


Téléchargez le RFC 3971


L'article seul

Acheter légalement de la musique sur Internet, est-ce possible ?

Première rédaction de cet article le 13 septembre 2009
Dernière mise à jour le 20 septembre 2009


Les défenseurs des lois liberticides comme Hadopi mettent souvent en avant l'argument comme quoi les amateurs de musique désireux d'acheter sur l'Internet peuvent simplement recourir au téléchargement légal, en achetant en ligne à un commerçant qui reversera une part à l'industrie du divertissement. Par exemple, l'Hadopi mentionne cette offre légale sur son site (en ne donnant pas un seul exemple). Je me suis toujours méfié de cet argument mais, après tout, peut-être faut-il essayer ?

Je ne connais rien à ces mythiques « plate-formes de téléchargement légal » qui sont régulièrement vantées comme la solution légale aux désirs des internautes musicophiles, sans jamais fournir de liste. J'ai donc commencé par me dresser une petite liste des critères qui sont importants pour moi :

Bien sûr, je souhaiterai aussi qu'on puisse acheter sans devoir s'inscrire (je n'ai pas besoin de remplir un questionnaire pour acheter dans un magasin physique !) et que cela ne soit pas trop cher (puisqu'il est moins coûteux de déplacer des bits que des atomes).

Je ne sais pas trop où chercher des vendeurs qui corrspondent à ces critères alors j'ai demandé des idées à un moteur de recherche. Il m'a trouvé Starzik qui, parait-il, colle à mon cahier des charges. Mais, apparemment, il est impossible de télécharger sans s'inscrire et Starzik ne semble pas vouloir de moi comme client, répondant systématiquement que « L'adresse email ne semble pas valide ». (D'autres personnes y arrivent donc cela semble indiquer que Starzik accepte arbitrairement certains clients et pas d'autres.) Le support de Starzik, prévenu, ne répond évidemment pas. Mais, en désactivant Javascript dans le navigateur, il est possible de passer outre : on le voit, acheter de la musique légalement nécessite d'être motivé ! En prime, les messages de Starzik sont systématiquement marqués comme spam par leur propre serveur de messagerie !

En tout cas, avec Starzik, j'ai enfin réussi par obtenir un fichier Ogg que je peux écouter avec mplayer. Avec le temps et les efforts que ça a pris, j'aurais certainement pu télécharger vingt morceaux illégalement...

Le même moteur de recherche suggère alors Amazon, une entreprise connue et sérieuse, dont je suis déjà client. Curieusement, Amazon recommande l'installation d'un logiciel privateur livré sans code source, Amazon MP3 Downloader. Certes, son utilisation ne semble pas obligatoire (« Si vous préférez ne pas installer l'application Amazon MP3 Downloader, vous pouvez quand même acheter des titres individuels. ») mais, en pratique, le lien qui suit cette affirmation ne fait rien et ramène toujours au texte de publicité en faveur de Amazon MP3 Downloader. C'est d'autant plus frappant que les bogues sont extrêmement rares sur le site Web d'Amazon, conçu avec un autre sérieux que les bricolages de tant de cyber-commerçants.

Lucas Nussbaum, qui a courageusement testé, me dit qu'il faut sans doute cocher la case « j'accepte les conditions d'utilisation de de MP3 Downloader » même si on ne veut pas l'utiliser. Très intuitif.

Enfin, au moins, le logiciel en question tourne sur Unix, ce qui est suffisamment rare pour être signalé. Mais, ne voulant pas l'installer, je suis également privé d'Amazon.

Depuis la première version de cet article, Amazon a changé la procédure et, désormais (novembre 2010), lorsque j'essaie d'acheter de la musique, j'ai : « We could not process your order. The sale of MP3 Downloads is currently available only to US customers located in the 48 contiguous states, Alaska, Hawaii, and the District of Columbia. ». Acheter légalement de la musique reste un parcours du combattant...

Bon, en lisant cet article, des gentils lecteurs m'ont fait d'autres recommandations.

Par exemple, Deezer, qui m'insulte en disant que ma version de Flash est trop ancienne. Sympa avec les clients, d'autant plus que je n'ai pas Flash du tout.

Il reste Spotify mais qui n'est pas encore complètement ouvert au public (il me demande un code d'invitation, que je n'ai pas). Apparemment, Spotify a été ouvert à un moment, puis refermé, mais un formulaire « sans invitation » reste ouvert. Il ne semble pas fonctionner, me ramenant à chaque fois au formulaire lorsque je clique « Create account and proceed ».

Bref, acheter légalement n'est pas de la tarte. Quelqu'un a t-il de meilleurs commerçants à me recommander ?

PS: le même gentil moteur de recherche m'a fait découvrir http://www.dilandau.com/ où on peut télécharger plein de MP3 sans payer, en très peu de temps, sans installer de logiciel sur sa machine, sans se faire insulter (« You must install Flash Player, you obsolete dinosaur! »). Sans doute pas légal mais il est frappant de constater que l'expérience utilisateur est bien meilleure avec un système illégal qu'avec un légal.

Merci à Pierre Beyssac et Kevin Hinault pour leurs suggestions. Un exemple d'article (médiocre) présentant les offres légales est « Quels sites conseiller aux ados pour écouter de la musique légalement sur Internet ? » : peu de recherches (Amazon et Starzik ne sont même pas mentionnés) et aucun effort pour indiquer les sites qui vendent du contenu DRMisé ou bien imposant un logiciel non-libre.


L'article seul

Mystère sur l'œil de Londres

Première rédaction de cet article le 12 septembre 2009


Aujourd'hui, les romans pour grands enfants et pour adolescents sont souvent d'une qualité telle que les adultes peuvent aussi les lire, sans trop avoir l'impression de régresser. Cela vaut donc la peine de passer faire un tour à des librairies spécialisées (comme le Divan Jeunesse à Paris) pour chercher ce genre de livres (si on a des enfants, c'est encore mieux, on peut partager les livres). Par exemple, The London Eye Mystery de Siobhan Dowd.

La traduction en français est très bonne mais sous un titre publicitaire, « L'étonnante disparition de mon cousin Salim », qui n'a rien à voir avec le titre original et sert seulement à faire penser au chef d'œuvre de Mark Haddon, « Le bizarre incident du chien pendant la nuit » dont le héros, comme celui du London Eye Mystery, est atteint du syndrome d'Asperger (mais c'est la seule ressemblance entre les deux livres).

Assez digressé, revenons au livre : un roman policier sans crime, mais avec un mystère, sans violence (alors que les livres visant un public adulte sont lancés dans une surenchère de meurtres atroces, de tortures décrites avec les détails, et de longues autopsies) autour d'un lieu unique, l'œil de Londres. Par des méthodes... non-standard... et de curieuses croyances (par exemple dans la combustion spontanée) , le héros, Ted, est-il vraiment le mieux placé pour retrouver Salim ? Avant de le savoir, on aura un peu visité Londres et surtout beaucoup voyagé dans un cerveau déroutant.


L'article seul

Un logiciel pour se créer sa page d'accueil, sans dépendre d'un service hébergé ?

Première rédaction de cet article le 12 septembre 2009
Dernière mise à jour le 18 octobre 2009


Je suis de plus en plus content des services hébergés comme iGoogle ou Netvibes qui vous permettent de créer une page d'accueil, de la modifier souvent, en y mettant plein de données dynamiques, via les gadgets, et du contenu régulièrement mis à jour via la syndication. Je configurerai bien désormais mon navigateur pour avoir comme page par défaut un service de ce genre. Mais ces services ne tournent pas avec du logiciel libre et, surtout, on est entièrement dépendant d'une entreprise extérieure, qui peut faire ce qu'elle veut avec les données ainsi récoltées. Pourquoi pas un logiciel libre qui me permette de mettre un Netvibes ou un iGoogle chez moi ?

Pour des services comme les moteurs de recherche, cela parait difficile, puisque mettre sur pied un tel service nécessite des moyens humains et financiers colossaux. Mais, pour un service comme iGoogle, presque rien n'est fourni par Google. Ce dernier se contente de publier le code Javascript qui permet de modifier la page (des bibliothèques comme Prototype ou jQuery rendent aujourd'hui bien plus facile l'écriture de tels programmes Javascript), et d'héberger les préférences de l'utilisateur, la liste de ses gadgets (j'aime beaucoup celui qui me permet de voir les vélos libres dans les stations Vélib), etc. Il semble que cela soit faisable avec relativement peu de moyens. Mon cahier des charges :

En logiciel libre, il n'y a apparemment que trois candidats :

  • Le plus perfectionné semble être dropthings mais, paradoxe, il ne tourne que sur MS-Windows.
  • Le second est liferay, tourne sur Unix mais il dépend de bien des usines à gaz comme Tomcat et je n'ai jamais réussi à l'installer.
  • Enfin, Posh de la société Portaneo (à ne pas confondre avec le shell du même nom). Écrit en PHP.

Posh correspond au cahier des charges. Cela aurait été bien de pouvoir le retenir. Malheureusement, il a deux points faibles. L'un est la sécurité, question traditionnellement ignorée des développeurs PHP. J'étais déjà assez inquiet à la pensée d'installer une grosse application PHP sur mes machines. Mais Posh demande en plus de débrayer les protections qui existent, par exemple en mettant la variable magic_quotes_gpc à OFF et la variable allow_url_fopen à ON (et pas question de passer outre, le script d'installation le vérifie).

Mais, surtout, Posh est encore trop bogué. L'Unicode est mal géré (bogue sur la syndication, notamment). Pas moyen de l'utiliser depuis Konqueror. La présentation est très contestable. Bref, c'est encore un outil expérimental.

Bref, si un lecteur de ce blog a une solution géniale, ça m'intéresse. Si un programmeur s'ennuie en ce moment, et cherche un bon sujet pour développer un logiciel libre, c'est également l'occasion.

J'avais posé la question sur Server Fault mais sans trop de résultats pour l'instant. Merci à Cyril Fait et Christian Fauré pour leurs suggestions.


L'article seul

Cafouillage entre .PR et le registre DLV de l'ISC

Première rédaction de cet article le 11 septembre 2009


DNSSEC, technologie chargée d'améliorer la sécurité du DNS, est une source de distractions sans fin pour l'administrateur système. Depuis que j'ai activé la validation DNSSEC sur le résolveur de ma machine au bureau, je vois des problèmes qui sont évidemment complètement invisibles si on ne vérifie pas les signatures DNSSEC. Ce fut le cas cette semaine avec la panne de .pr.

Comme toute technique cryptographique, DNSSEC (normalisé dans le RFC 4033 et suivants), produit des faux positifs, des cas où la vérification échoue, sans qu'il y aie eu de tentative de fraude, simplement parce que la cryptographie est compliquée et que les erreurs opérationnelles sont fréquentes. Avant d'améliorer la sécurité, la cryptographie sert donc souvent à casser des choses qui marchaient très bien avant qu'on ne l'utilise.

Le registre DNS de .pr a tenu à être un des premiers domaines de tête à signer avec DNSSEC. Mais leurs moyens humains ne semblent pas à la hauteur de leurs ambitions et il y a déjà eu plusieurs cafouillages, par exemple des signatures expirées ou, en dehors de DNSSEC, des attaques par injection SQL. Ce mois-ci, .pr a procédé à un changement de sa clé, certainement l'opération la plus dangereuse de DNSSEC. Cette opération a été assez mal faite, notamment parce que les administrateurs du domaine continuent à laisser l'ancienne clé sur leur site Web mais aussi parce qu'ils n'ont attendu que deux jours entre l'ajout de leur clé dans ITAR et le retrait de l'ancienne. Or, la racine du DNS n'étant pas signée, et le suivi à la main de toutes les clés de tous ceux qui signent n'étant pas réaliste, les très rares personnes qui, comme moi, utilisent un résolveur DNSSEC validant, se servent en général du registre DLV de l'ISC. DLV (DNSSEC Lookaside Validation), normalisé dans le RFC 5074, permet de ne gérer qu'une seule clé, celle du registre DLV, qui contient les autres clés. Heureusement que, grâce à l'ISC, ce registre DLV existe. Mais, problème, dlv.isc.org, ne se mettait apparemment à jour à partir d'ITAR que toutes les semaines. Résultat, l'ancienne clé de .pr a été retirée de la zone alors qu'elle était encore dans DLV (et, on l'a vu, sur le site Web du registre de .pr, donc le problème ne concerne pas que DLV).

Résultat, un beau SERVFAIL (Server Failure) à chaque tentative de résolution d'un nom en .pr. Gageons que cela n'encouragera pas les administrateurs de serveurs DNS récursifs à activer la validation DNSSEC.

L'incident a également réanimé tous ceux qui n'avaient pas apprécié le travail de l'ISC pour la mise en place du registre DLV. Pas mal de noms d'oiseaux ont été échangé sur des listes de diffusion comme celle du groupe de travail dnsop de l'IETF. Après tout, ce sont toujours ceux qui font le travail concret qui attirent les reproches...


L'article seul

RFC 5681: TCP Congestion Control

Date de publication du RFC : Septembre 2009
Auteur(s) du RFC : M. Allman, V. Paxton (ICSI), E. Blanton (Purdue University)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tcpm
Première rédaction de cet article le 11 septembre 2009


Successeur du souvent cité RFC 2581, ce RFC 5681 présente les algorithmes que doivent utiliser les mises en œuvres de TCP pour limiter les risques de congestion sur l'Internet. Comme TCP (RFC 793) est, de très loin, le principal protocole de transport de l'Internet, ces quatre algorithmes sont donc la principale ligne de défense contre la congestion.

Leurs noms en anglais sont tellement répandus qu'il n'est pas facile de concevoir une traduction. Essayons :

  • Démarrage en douceur (slow start),
  • Évitement de la congestion (congestion avoidance),
  • Retransmission rapide (fast retransmit),
  • Récupération rapide (fast recovery).

Mis au point à l'origine par Van Jacobson, ces algorithmes ont d'abord été normalisés dans le RFC 1122 (avant les RFC 2001, une lecture très recommandée, et RFC 2581). Des RFC comme le RFC 3390 ont également contribué. Richard Stevens décrit ces algorithmes dans son livre TCP/IP Illustrated (explications dans le premier volume et code source dans le deuxième). Ce livre est de très loin le meilleur pour quiconque veut apprendre le délicat fonctionnement de TCP.

Si TCP envoyait des données à la vitesse maximale que permet la carte réseau et la machine, l'Internet s'écroulerait rapidement. Le but de ces algorithmes est donc de freiner TCP et la section 3 note qu'une mise en œuvre de TCP est autorisée à être plus prudente que ces algorithmes (à envoyer moins de données) mais pas à être plus violente.

La section 3.1 décrit le Démarrage en douceur. Le principe est, au démarrage d'une connexion TCP, de ne pas envoyer trop de données sans avoir vu qu'elles pouvaient arriver au même rythme. L'envoyeur garde une variable, cwnd, la fenêtre de congestion, qui indique combien de données il peut envoyer sans recevoir d'accusé de réception (ACK). TCP commence avec une fenêtre assez petite (la section 3.1 donne la méthode de calcul, un exposé complet figure dans le RFC 3390) et l'ouvre au fur et à mesure de l'arrivée des accusés de réception (là encore, les valeurs précises figurent dans le RFC).

Si vous lisez le code source du noyau Linux 2.6, ces variables supplémentaires sont déclarées dans include/linux/tcp.h. Tous les noms de fichiers donnés plus loin concernent ce noyau.

Quant la fenêtre de congestion a été augmentée au delà d'un certain seuil, noté ssthresh, le second algorithme, l'Évitement de congestion prend le relais. Cet algorithme augmente différemment, de manière plus rapide, la fenêtre de congestion (quand tout va bien) et réagit à la congestion (détectée par l'expiration d'un délai de garde) en réduisant ssthresh, voire la fenêtre de congestion (ce qui peut la faire tomber en dessous de ssthresh, réactivant le démarrage en douceur). Ce second algorithme est décrit en détail dans la même section 3.1. Pour la mise en œuvre sur Linux, voir le très joli net/ipv4/tcp_cong.c.

Attention, comme l'ont montré plusieurs alertes de sécurité (la dernière datant de quelques jours après la publication du RFC), le fait de réagir aux messages de l'hôte distant présente toujours un risque, si celui-ci essaie de vous tromper. Diverses contre-mesures sont citées (cf. RFC 3465).

Les deux autres algorithmes, la Retransmission rapide et la Récupération rapide, sont décrits dans la section 3.2. Tous les deux reposent sur les accusés de réception dupliqués. Ceux-ci (définis formellement en section 2) sont des accusés de réception pour des données qui ont déjà fait l'objet d'un tel accusé. Notre RFC 5681 recommande que le TCP récepteur envoie un accusé de réception immédiatement lorsqu'il reçoit des données qui ne sont pas dans l'ordre des numéros de séquence (fonction __tcp_ack_snd_check dans net/ipv4/tcp_input.c). Cet accusé, considéré comme « dupliqué », permet à l'envoyeur de voir tout de suite que des données ont probablement été perdues (rappelez-vous que les accusés de réception, pour TCP, indiquent simplement le rang du dernier octet reçu avec succès, pas une plage ; les données hors-séquence ne suscitent normalement pas d'accusé de réception immédiat, TCP attend plutôt que les données manquantes arrivent).

La Retransmission rapide est utilisée lorsque TCP reçoit des accusés de réception dupliqués. Dans ce cas, TCP doit retransmettre tout de suite les données non encore acceptées par son pair, sans attendre que le délai de garde expire. La Récupération rapide consiste à ne pas utiliser le Démarrage en douceur lorsqu'on détecte des accusés de réception dupliqués. Elle a fait depuis l'objet de perfectionnements, décrits plus longuement dans le RFC 6582.

Après ces quatre algorithmes à utiliser, le RFC, dans sa section 4.1, couvre aussi le problème du redémarrage des sessions qui ont été longtemps inactives. Dans ce cas, TCP ne peut plus compter sur l'arrivée des accusés de réception pour calibrer le réseau (tous les ACK sont arrivés depuis longtemps) et son calcul de la fenêtre de congestion peut être désormais dépassé. Il risque donc d'envoyer un brusque flux de données. Le RFC recommande donc une variante du Démarrage en douceur, lorsque la session a été inactive pendant longtemps.

La section 4.2 revient sur le problème de l'envoi des accusés de réception. Le RFC 1122 (dans sa section 4.2.3.2) spécifie un algorithme pour cet envoi, dont le principe de base est d'attendre un peu avant d'envoyer l'ACK (dans l'espoir que d'autres données arriveront, permettant de se contenter d'un seul ACK), mais sans attendre trop pour éviter que l'émetteur ne s'impatiente et ne réemette. Notre RFC 5681 précise simplement les règles (ambigües) du RFC 1122.

En prime de la Retransmission rapide et du Redémarrage rapide, certains algorithmes ont été proposés et parfois déployés, pour récupérer des pertes de données. La section 4.3 les énumère, sans forcément prendre position sur leur opportunité. Certains, comme celui du RFC 3517, dépendent de l'option SACK (Selective Acknowledgment) du RFC 2018, d'autres, comme celui du RFC 3782 n'en dépendent pas.

Il est important de noter que le bon fonctionnement de l'Internet dépend de la mise en œuvre correcte de tous ces principes, par chaque implémentation de TCP. Deux machines « inciviles » qui désireraient envoyer le plus de données possiles, et tant pis pour la congestion, peuvent techniquement le faire (section 5, consacrée à la sécurité). C'est un des aspects les plus étonnants de l'Internet que peu de vendeurs aient eu l'idée de promouvoir un TCP « optimisé », c'est-à-dire égoïste. On trouve toutefois des cas limites comme Fast TCP.

Enfin, les changements par rapport au RFC 2581 sont présentés dans la section 7. Les principaux sont :

  • Une définition rigoureuse de la notion d'accusé de réception dupliqué (en section 2),
  • La recommandation d'utiliser le RFC 3465 pendant le Démarrage en douceur,
  • La recommandation d'utiliser le RFC 3042 pendant les Retransmission rapide et Récupération rapide.

(Je trouve personnellement que le RFC 2001 était le plus clair de tous et que la précision des mises à jour suivantes a plutôt brouillé les explications.)


Téléchargez le RFC 5681


L'article seul

RFC 5632: Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial

Date de publication du RFC : Septembre 2009
Auteur(s) du RFC : C. Griffiths, J. Livingood (Comcast), L. Popkin (Pando), R. Woundy (Comcast), Y. Yang (Yale)
Pour information
Première rédaction de cet article le 11 septembre 2009


Beaucoup de FAI se demandent comment limiter la charge qui provient de l'intense activité pair-à-pair de leurs clients. Les plus bas de front tentent l'interdiction (comme dans les conditions générales d'utilisation de SFR pour certaines de ses offres Internet mobile, où le pair-à-pair est explicitement interdit), d'autres cherchent des solutions techniques. L'une de ces solutions, P4P, qui permet au FAI d'informer les logiciels pair-à-pair de la topologie de son réseau, dans l'espoir qu'ils choisiront des pairs plus proches, est activement promue par certaines entreprises comme Pando. Comcast, un gros FAI, a testé P4P pour nous et en fait le compte-rendu dans ce RFC.

Ce gros FAI états-unien connecte essentiellement des particuliers, par le câble. Comcast est un des participants au groupe de travail qui élabore P4P. Le principe du système P4P (Proactive network Provider Participation for P2P) est de déployer des iTrackers qui sont des serveurs informant les clients pair-à-pair de la topologie du réseau, quels sont les liens recommandés, quelles adresses IP sont externes ou internes au dit réseau, etc (section 1 du RFC). Le logiciel peut alors choisir le pair le plus proche, économisant ainsi les ressources.

P4P a été discuté dans des forums comme le IETF workshop on P2P Infrastructure (raconté dans le RFC 5594) ou à la BoF Alto de l'IETF. Le test en vrai grandeur dont notre RFC 5632 rend compte a eu lieu en juillet 2008.

La section 2 du RFC résume le principe du test. Cinq essaims de machines, avec des iTrackers programmés différemment à chaque fois, participaient. Les statistiques étaient enregistrées par chaque client puis rassemblées. Témoignage de la puissance du pair-à-pair, le seeder (la machine qui avait le contenu original) n'a envoyé que dix copies alors qu'il y a eu un million de téléchargements.

Quels étaient les différents types de iTrackers utilisé ? Si, dans le premier essaim, les pairs étaient choisis au hasard, les autres utilisaient les politiques suivantes :

  • Grain fin (section 3.1). De loin le plus complexe à configurer, ce iTracker avait toute l'information sur le réseau de Comcast, incluant tous les liens avec l'extérieur. Non seulement l'élaboration et la mise à jour de sa configuration étaient très complexes (le fichier faisait plus de cent mille lignes) mais cet iTracker est très indiscret, permettant aux clients de récupérer une information que le FAI n'a pas forcément envie de livrer.
  • Gros grain (section 3.2). Présentant une vue moins précise du réseau (notamment de ses connexions externes), cet iTracker ne faisait plus que mille lignes et surtout (du point de vue de Comcast) était plus discret.
  • Pondéré génériquement (section 3.3). Identique au iTracker à gros grain, sauf que les poids attribués aux différents liens étaient définis par une autre équipe.

Qu'est-ce que ça a donné ? La section 4 résume les résultats (mais il faut aussi lire la section 5, qui détaille les pièges d'interprétation possibles) : chaque essaim de machines a réalisé environ 25 000 téléchargements par jour. Le plus gros essaim a atteint une taille de 11 700 machines. Les iTrackers à grain fin ou à gros grain ont vu leur débit de téléchargement (section 4.2) augmenter de 13 % (en moyenne) mais de 57 à 82 % pour les machines de Comcast, qui avaient le plus d'informations. Et la politique à gros grain s'est montrée plus efficace que celle à grain fin, contrairement à ce qu'on aurait pu attendre.

La section 4.2 donnait les résultats individuels, l'amélioration pour une machine qui télécharge. Mais pour le FAI, quel était le résultat ? La section 4.3 les résume : le trafic sortant de Comcast a diminué de 34 %, l'entrant vers Comcast de 80 %. À noter également qu'il y a d'avantage d'annulations (l'utilisateur s'impatiente et arrête le téléchargement) avec le premier essaim, celui qui n'utilisait pas P4P. Il est possible que les débits plus faibles entrainent davantage de découragement et donc d'annulation. En tout cas, le trafic à l'intérieur de Comcast augmente avec P4P : quand ça marche, les utilisateurs s'en servent plus.

La section 6 formule donc une conclusion relativement optimiste et recommande que l'IETF considère sérieusement P4P dans le cadre du groupe de travail Alto.


Téléchargez le RFC 5632


L'article seul

RFC 5646: Tags for Identifying Languages

Date de publication du RFC : Septembre 2009
Auteur(s) du RFC : A. Philipps (Lab126), M. Davis (Google)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 7 septembre 2009


Successeur du RFC 4646 (qui lui-même succédait au RFC 3066), notre RFC décrit les noms des langues (langues humaines, pas langages informatiques). Toute application qui a besoin d'indiquer une langue doit s'en servir.

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

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

Les noms des langues ont deux ou trois lettres et sont tirés de la norme ISO 639. Par exemple :

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

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

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

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

ISO 639-1 et 2 reflétaient plutôt les besoins des bibliothécaires, soucieux de simplifier la classification en évitant la multiplication des langues. ISO 639-3 adopte plutôt le point de vue des linguistes, qui tendent à voir bien plus de langues. Ce débat entre mergers (les bibliothécaires) et splitters (les linguistes) ne cessera pas de sitôt. L'intégration de ISO 639-3 fait que le registre des étiquettes de langues passe plutôt du côté des splitters.

Les étiquettes de langue sont donc composées de sous-étiquettes, et les diverses restrictions qui existent sur leur longueur et leur place font qu'il est possible d'analyser une étiquette, de déterminer où est la langue, où est le pays, etc, sans avoir d'accès au registre (section 2.2). Une étiquette peut être bien formée (obéir à la syntaxe) même si ses sous-étiquettes ne sont pas enregistrées (section 2.2.9 pour la définition de la conformance à cette norme, et la notion de « bien formée » et de « valide »). Le registre stocke des sous-étiquettes, pas des étiquettes entières, et ces sous-étiquettes peuvent être combinées librement, même si le résultat n'est pas forcément sensé. Par exemple, ar-Cyrl-AQ est à la fois bien formée - elle obéit à la grammaire, valide (toutes ses sous-étiquettes sont enregistrées) et néanmoins inutile car désignant l'arabe en écriture cyrillique tel que pratiqué en Antarctique.

Les différentes parties d'une étiquette sont décrites en section 2.2. Par exemple, l'écriture est complètement traitée en section 2.2.3 est dérive d'ISO 15924.

La section 2.2.6, sur les extensions (qu'il ne faut pas confondre avec les extlangs) n'est pas encore utilisée ; pour l'instant, aucune extension n'a été enregistrée.

Le format et la maintenance du registre sont décrits en section 3. Le registre est au format record-jar (section 3.1.1, ce format est décrit dans le livre The Art of Unix programming) et, par exemple, l'enregistrement du français est :

Type: language
Subtag: fr
Description: French
Added: 2005-10-16
Suppress-Script: Latn

et celui du cantonais est :

Type: language
Subtag: yue
Description: Yue Chinese
Added: 2009-07-29
Macrolanguage: zh

et cet enregistrement comporte la mention de la macrolangue (le chinois).

Désormais, le registre est en UTF-8 ce qui permet des choses comme :

Type: language
Subtag: pro
Description: Old Provençal (to 1500)
Description: Old Occitan (to 1500)
Added: 2005-10-16

L'ajout d'éléments au registre est possible, via une procédure décrite en sections 3.5 et 3.6. Si vous voulez enregistrer une sous-étiquette, la lecture recommandée est « How to register a new subtag ». La procédure inclus un examen par un Language Subtag Reviewer (section 3.2), actuellement Michael Everson. Je préviens tout de suite : comme indiqué en section 3.6, la probabilité qu'une demande refusée par l'ISO soit acceptée dans le registre IANA est très faible (malgré cela, des demandes sont régulièrement reçues pour des « langues » que seuls certains radicaux considèrent comme telles). Une liste complète des demandes d'enregistrement effectuées est archivée en https://www.iana.org/assignments/lang-subtags-templates. Un exemple réel est décrit dans « Enregistrement de l'alsacien dans le registre IETF/IANA ».

Lorsqu'on est occupé à étiqueter des textes, par exemple à mettre des attributs xml:lang dans un document XML, on se pose parfois des questions comme « Dois-je étiqueter ce texte comme fr ou bien fr-FR, lorsque les deux sont légaux ? » La réponse figure dans la section 4.1, qui est résumée dans « Tag wisely » (la réponse, ici, est « En général, fr tout court, sauf s'il est important de le distinguer des dialectes étrangers à la France »).

Les changements les plus importants par rapport au RFC 4646 (section 8) sont :

  • Intégration des normes ISO 639-3 et 5 (section 2.2.1) ce qui fait passer le nombre de langues de 500 à 7000.
  • L'arrivée de ISO 639-3 a apporté les extlangs (Extended Language Subtag, section 2.2.2) et 639-5 les collections, groupes de langues reliées entre elles.
  • Meilleure description du rôle de l'IANA, surtout pour l'archivage des requêtes.
  • Quelques changements pour les implémenteurs : grammaire différente mais meilleure (section 2.1) (notamment par une meilleure séparation des aspects syntaxiques et sémantiques) et registre désormais en UTF-8 et plus en ASCII.
  • Et plein de petits détails.

Le changement de grammaire ne change pas grand'chose aux étiquettes bien formées ou pas mais il facilitera la tâche des implémenteurs. Les étiquettes patrimoniales (grandfathered) sont ainsi séparées en deux catégories, selon qu'elles obéissent quand même à la syntaxe standard ou pas.

L'augmentation importante de la taille du registre fait que, encore plus qu'avant, la récupération automatique du registre nécessite donc de faire attention pour ne pas charger les serveurs de l'IANA (la méthode recommandée est le GET conditionnel de HTTP RFC 7232 (If-Modified-Since, section 3.3), par exemple, avec curl, curl --time-cond "20090702" https://www.iana.org/assignments/language-subtag-registry )

Les extlangs ont été une question particulièrement délicate. Parmi les macrolangues (une collection de langues qui, dans certaines cicronstances, peuvent être vues comme une langue unique), le piège spécifique à l'arabe et au chinois est que le mot « chinois » désigne à la fois une macrolangue et une langue particulière couverte par cette macrolangue (le mandarin). Pire, dans les deux cas (chinois et arabe), les communautés locales ont du mal à admettre le verdict des linguistes. Ceux-ci disent que l'« arabe » n'est pas une langue, et que le marocain et le syrien sont des langues distinctes. Les arabophones ne sont pas tous d'accord avec l'analyse scientifique.

Les autres macrolangues n'ont pas de « langue de référence » et elles sont typiquement pratiquées par des communautés ayant moins de poids que le gouvernement de Pékin.

L'IETF a tranché que, pour certaines langues, l'extlang serait PERMIS, la forme sans extlang RECOMMANDÉE (voir notamment la section 4.1.2 sur l'usage des extlangs). Les vainqueurs sont donc : 'ar' (Arabe), 'kok' (Konkanî), 'ms' (Malais), 'sw' (Swahili), 'uz' (Ouzbèke), et 'zh' (Chinois).

Donc :

  • pour le cantonais, zh-cmn permis, cmn recommandé,
  • idem pour l'arabe, ar-arz est permis pour l'égyptien, arz est recommandé,
  • pour le Cri, il n'a pas bénéficié de l'exception donc le Cri des Plaines est forcément crk, pas cr-crk.

Les transparents d'un exposé sur ces language tags sont disponibles. Ils ne parlent que de la version précédente, celle du RFC 4646. Le site Web officiel sur les étiquettes de langues est http://www.langtag.net/.

Un analyseur de language tags en logiciel libre existe, GaBuZoMeu et gère cette nouvelle norme. On peut trouver d'autres mises en œuvre en http://www.langtag.net/.


Téléchargez le RFC 5646


L'article seul

RFC 5645: Update to the Language Subtag Registry

Date de publication du RFC : Septembre 2009
Auteur(s) du RFC : D. Ewell
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 7 septembre 2009


Ce RFC, compagnon du RFC 5646, décrit le nouvel état du registre des langues de l'IANA. Comme son prédécesseur, le RFC 4645 avait servi à initialiser le registre des langues, notre RFC 5645 servira à la grande mise à jour qu'est l'intégration des normes ISO-639-3 et ISO 639-5. Le nombre de langues enregistrées passe de 500 à plus de 7 000.

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

Il sert juste à lister l'état du nouveau registre IANA avec des affectations comme ici pour le Nandi ou l'écriture du Bamum :

%% Description d'une langue, ici le Nandi (niq)
Type: language
Subtag: niq
Description: Nandi
Added: 2009-07-29
Macrolanguage: kln   
%%
%% Description d'une écriture, ici le Bamum
Type: script
Subtag: Bamu
Description: Bamum
Added: 2009-07-30
%%

Le registre va ensuite vivre sa vie et accepter de nouveaux enregistrements, suivant les procédures du RFC 5646. Une des façons de suivre ces futures évolution est de s'abonner au flux de syndication http://www.langtag.net/registries/lsr.atom.

Comment a été construit le nouveau registre ? La section 2 répond à cette question. Le point de départ était le registre existant, celui qui avait été créé par le RFC 4646. Les fichiers d'ISO 639-3 (disponibles chez SIL car l'ISO ne distribue quasiment jamais ses normes) et ISO 639-5 ont ensuite été intégrés, mais pas aveuglément :

  • Les langues qui n'avaient pas déjà de code dans le registre (comme l'ankave - code aak - ou le ghotuo - code aaa) ont été ajoutées. A contrario, celles qui avaient déjà un code ont été ignorées.
  • Les langues qui avaient une macrolangue (une nouveauté d'ISO 639-3, la macrolangue est une catégorie regroupant des langues qui sont parfois considérées comme distinctes et parfois comme une seule langue) ont été traitées comme les autres à l'exception de six langues pour lesquelles le groupe de travail LTRU de l'IETF a estimé qu'elles présentaient des caractéristiques particulières, notamment le fait que la macrolangue était souvent utilisée. Ces six exceptions sont l'arabe (ar), le konkani (kok), le malais (ms), le swahili (sw), l'ouzbèque (uz) et le chinois (zh). Pour les six exceptions, un extended language subtag a été créé dans le registre, pour indiquer la macrolangue et cela permettra d'écrire des étiquettes comme zh-yue (le cantonais, dont l'étiquette canonique est juste yue) pour le cas où l'ajout de la macrolangue semble important. Les autres langues ayant une macrolangue voient juste cette macrolangue ajoutée comme un champ de l'enregistrement.
  • Les descriptions présentes dans le registre ont parfois été complétées ou modifiées pour avoir une présentation cohérente. Cela aboutit parfois à élargir la portée d'un code. Ainsi, la collection afa « Autres langues afro-asiatiques » est devenue « Langues afro-asiatiques » ce qui est bien plus large.
  • Le RFC 5646 a inclus dans les codes de pays les éléments de ISO 3166 qui étaient marqués comme « exceptionellement réservés ». Cela a permis l'arrivée de EU, on peut donc désormais utiliser l'étiquette en-EU pour l'anglais parlé à Bruxelles. D'autres codes étaient déjà présents pour d'autres raisons comme l'amusant FX (France Métropolitaine).

Téléchargez le RFC 5645


L'article seul

Efficacité du stockage dans un VCS

Première rédaction de cet article le 4 septembre 2009


Un intéressant article d'Eric Sink, « Time and Space Tradeoffs in Version Control Storage », expose de manière très simple et très compréhensible (même par un programmeur peu expérimenté), les choix à faire lors de la conception du stockage des fichiers d'un VCS.

L'auteur décrit et met en œuvre successivement plusieurs systèmes pour stocker les différentes versions d'un fichier dans un VCS. La plus évidente est de garder chaque version complète : cela rend la récupération d'une version donnée très rapide, mais consomme beaucoup de disque. Plus sophistiqué, le stockage des différences uniquement (par exemple en suivant le RFC 3284). On occupe moins de place mais on est plus lent. Bref, il n'y a pas de méthode idéale, juste des compromis.

L'intérêt de l'article est de tester systématiquement chaque approche et les résultats ne sont pas forcément conformes à l'intuition. Par exemple, l'une des solutions qui prennent le moins de place est... de stocker chaque version complète mais en la comprimant. Plusieurs algorithmes très astucieux que teste l'auteur sont moins bons, à la fois en espace et en temps, que le bon vieux zlib. Cela illustre bien le fait, qu'en matière d'optimisation, il faut tester et ne pas se fier à des impressions.

(Par contre, l'auteur, après avoir très justement noté que la première qualité d'un VCS était de ne pas perdre les données qu'on lui a confié, oublie ce critère par la suite et ne prend pas en compte la fragilité de chacune des solutions testées. Par exemple, la chaîne des différences - on stocke la première version, puis la différence entre la version 1 et la 2, puis celle entre la 2 et la 3, etc - est très fragile car la perte d'une des différences fait perdre toutes les versions ultérieures.)


L'article seul

Fiche de lecture : Paris - quinze promenades sociologiques

Auteur(s) du livre : Michel Pinçon, Monique Pinçon-Charlot
Éditeur : Payot
978-2-228-90411-7
Publié en 2009
Première rédaction de cet article le 3 septembre 2009


Toujours soucieux d'explorer l'espace et de voir comment les sociétés l'occupent et le transforment, les auteurs des « Ghettos du Gotha » ont écrit un guide touristique original de Paris : quinze promenades sociologiques dans quinze quartiers différents.

Guide en main, on suit les auteurs, rue par rue, dans ces quinze quartiers, visitant à chaque fois, non seulement les bâtiments, mais surtout ce qu'ils nous disent du quartier, qui y habite, quelles évolutions il a connu.

Les Pinçon, ce qui n'étonnera pas les lecteurs de leurs précédents ouvrages, traitent en connaisseurs les quartiers des ultra-riches (la villa Montmorency dans le chapitre XI consacré aux « villas de Paris ») mais aussi les quartiers populaires comme la Goutte d'Or (chapitre XII).

Ils travaillent aussi sur des espaces négligés mais où beaucoup de parisiens (et de banlieusards) passent une bonne partie de leur journée : les transports en commun avec le chapitre VI sur la gare Saint-Lazare et le chapitre V sur un « quartier » un peu spécial, le métro. Dans ce dernier chapitre, la visite de la ligne 13 permet d'analyser les quartiers traversés et aussi ce quartier virtuel qu'est le métro, l'un des rares endroits où se croisent, au moins physiquement, toutes les classes sociales.

Même dans la capitale où tout changement s'opère sous l'œil de beaucoup d'autorités, les urbanistes ne peuvent pas changer la ville simplement en construisant : les quartiers échappent parfois à leur destin prévu comme le 13ème arrondissement dont une partie avait été semée de tours (à la grande époque du gaullisme immobilier) pour jeunes cadres dynamiques, tours dont les destinataires n'ont pas voulu (elles faisaient trop HLM) et qui ont finalement été recupérées par les immigrés du Sud-Est asiatique (chapitre IX, Chinatown).

Paris a été pendant longtemps une ville dangereuse pour les pouvoirs en place, pleine d'artisans et d'ouvriers prompts à la barricade. Aujourd'hui, beaucoup d'anciens quartiers populaires ont été « gentrifiés » et les chapitres VII (la reprise de la Bastille) et VIII (un nouveau quartier nocturne : la rue Oberkampf) étudient en détail ce phénomène en cours de réalisation.

Les conquêtes ne sont pas forcément éternelles. Si le monde du luxe a réussi à mettre la main sur Saint-Germain-des-Prés, chassant les fantômes de Sartre et Beauvoir (chapitre III), les Champs-Élysées, eux, semblent petit-à-petit être abandonnés par la bourgeoisie riche (chapitre IV).

Pour tous ceux qui sont rentrés de vacances et habitent à Paris ou dans les environs, voici donc quinze idées de promenades intelligentes pour le week-end, le guide à la main.

(Cette deuxième édition est la réédition et mise à jour d'un livre de 2001.)


L'article seul

RFC 3339: Date and Time on the Internet: Timestamps

Date de publication du RFC : Juillet 2002
Auteur(s) du RFC : Graham Klyne (Clearswift Corporation), Chris Newman (Sun Microsystems)
Chemin des normes
Première rédaction de cet article le 30 août 2009


Comment représente t-on une date sur l'Internet ? Il existe beaucoup de RFC qui ont besoin d'un format de date et, si certaine restent fidèles à des vieux formats, la plupart des RFC modernes se réfèrent à ce RFC 3339 qui définit un sous-ensemble d'ISO 8601 pour la représentation des dates.

Un des exemples les plus connus des vieux formats est le RFC 5322 qui garde, pour le courrier électronique, l'ancien format (initialement normalisé dans le RFC 724) difficile à analyser, et qui ressemble à Date: Thu, 27 Aug 2009 08:34:30 +0200. Ce format n'a été gardé que parce qu'on ne peut plus changer la norme du courrier sur un point aussi fondamental. Mais les RFC récents définissent un autre format, celui de notre RFC 3339. C'est, par exemple, le cas du RFC 4287 qui dit que les éléments XML d'un flux de syndication Atom doivent utiliser ce format, par exemple <published>2009-08-25T00:00:00Z</published>.

Pourquoi un RFC sur ce sujet et ne pas simplement se référer à la norme ISO 8601 ? Il y a plusieurs raisons. L'une est politique, c'est le fait que l'ISO ne distribue pas librement le texte de la plupart de ses normes (une version provisoire non redistribuable traine sur le serveur de l'ISO). L'autre est que ISO 8601, comme beaucoup de normes ISO, est mal spécifiée, très complexe et pleine de détails inutiles (cf. section 5.5). L'IETF a donc choisi la voix d'un sous-ensemble de ISO 8601, le format du RFC 3339.

La section 1 du RFC résume le problème général de la transmission et de l'affichage des dates. Beaucoup de programmes se sont cassés le nez sur ce sujet (je me souviens d'un logiciel commercial de gestion de tickets, très cher, qui envoyait des messages avec des dates invalides, ce qui décidait un autre logiciel commercial très cher, chargé de la lutte contre le spam, à les jeter).

Le RFC est bâti sur quelques principes, exposés dans cette section 1. On utilise évidemment le calendrier grégorien. Comme le but est de dater des événements Internet, on se limite aux dates de l'ère actuelle (i.e. après Jésus-Christ), on suppose que le décalage entre l'horloge locale et UTC est connu, etc.

Le problème de l'heure locale fait l'objet de la section 4. Les règles définissant l'heure légale étant très compliquées et changeantes (en raison de la stupide heure d'été), le choix est de s'appuyer sur UTC (section 4.1). Puisque le décalage entre l'heure locale et UTC est supposé connu, il est prévu de permettre d'indiquer ce décalage (section 4.2). Cela se fait toujours sous forme numérique, les noms alphabétiques des fuseaux horaires n'étant pas normalisés. Enfin, la section 4.4 réenfonce le clou au sujet des horloges qui ne connaissent que l'heure locale et pas son décalage avec UTC : de telles horloges sont inutilisables sur l'Internet puisqu'elles les indications temporelles transmises à partir d'elles sont fausses 23 fois sur 24 (dès qu'on n'est pas dans le même fuseau horaire).

Les historiens notent que c'était le cas des systèmes d'exploitation Microsoft pendant longtemps : l'horloge du PC ne stockait que l'heure locale, ce qui a créé d'innombrables problèmes lorsque Windows a dû se résigner à accepter les connexions avec l'Internet.

Voici pour le concept de temps. Et le format ? Quel est le cahier des charges précis ? La section 5 commence par énumérer les caractéristiques souhaitées. Les temps doivent pouvoir être comparées lexicographiquement (section 5.1), par exemple avec strcmp() en C ou sort avec le shell Unix. Contrairement à une idée répandue, ISO 8601 ne garantit pas cette possibilité (voir la section 5.1 pour une liste des règles à observer pour qu'une telle comparaison soit possible).

Autre critère important, le format doit être compréhensible par un humain (section 5.2). C'est une caractéristique fréquente des protocoles Internet ; les formats binaires sont relativement rares. Ceci dit, un format trop lisible peut mener à des erreurs. Par exemple, le format de date du RFC 5322 a mené certains programmeurs à croire qu'ils pouvaient traduire les noms de jour et de mois, puisque ceux-ci apparaissent sous une forme non-numérique (c'était l'erreur du logiciel commercial dont je parlais plus tôt ). Le format de notre RFC est donc compréhensible mais pas forcément familier à tout être humain et les logiciels doivent donc se préparer à l'afficher sous une forme plus conforme aux habitudes locales.

Autre erreur du format du RFC 5322, la redondance de l'information (section 5.4). Inclure le nom du jour est redondant (puisqu'on peut le calculer à partir de la date, l'annexe B donne un exemple de code) et augmente donc les risques d'erreur (que faire si ce jour n'est pas correct, qui croire ?).

Assez de préliminaires, quel format utiliser, maintenant ? La section 5.6 va le décrire rigoureusement, en utilisant le langage ABNF (RFC 5234). Il existe quelque options comme le fait que le temps peut être écrit en heure locale, si le décalage avec UTC est indiqué. La section 5.8 donne quelques exemples de temps corrects. Voici comment les produire avec GNU date (le fait de séparer la date et le temps par un espace et pas par la lettre T est une violation de la grammaire mais le RFC est ambigu sur ce point) :

% date --rfc-3339='ns'
2009-07-12 11:03:08.434344377+02:00

% date --rfc-3339='seconds'
2009-07-12 11:03:12+02:00

% date --rfc-3339='date'
2009-07-12

et voici un programme Python qui affiche la date actuelle en UTC (donc avec le Z à la fin, Z étant l'équivalent de +00:00) :

import time

# date+time but no fractional seconds
rfc_3339_nosecfrac = "%Y-%m-%dT%H:%M:%SZ"

# gmtime = UTC (old name)
print time.strftime(rfc_3339_nosecfrac, 
                    time.gmtime(time.time()))

Et, en C, voici un exemple possible :


#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

#define MAX_SIZE 256
#define RFC_3339_NOFRAC_UTC "%Y-%m-%dT%H:%M:%SZ"

int
main()
{
    char           *result = malloc(MAX_SIZE);
    struct timeval  tv;
    struct tm      *time;
    size_t          result_len;
    (void) gettimeofday(&tv, NULL);
    time = gmtime(&tv.tv_sec);
    result_len = strftime(result, MAX_SIZE, RFC_3339_NOFRAC_UTC, time);
    if (result_len != 0) {
        printf("%s\n", result);
        exit(0);
    } else {
        printf("Error in strftime\n");
        exit(1);
    }
}

Y a t-il des problèmes de sécurité cachés derrière l'affichage de la date ? Oui, la section 7 en cite un : la connaissance de l'heure locale d'un système peut permettre à un attaquant de déterminer les heures où le système est le plus suceptible d'être surveillé et le paranoïaque peut donc avoir intérêt à n'émettre que des temps en UTC...

Notre RFC compte plusieurs annexes intéressantes. Par exemple, l'annexe A est une rétro-ingénierie de la norme ISO 8601. Comme celle-ci ne spécifie pas formellement de grammaire pour le format des dates, ce sont les auteurs du RFC qui en ont établi une, à partir de la norme. Elle est bien plus riche (avec beaucoup plus d'options) que celle de la section 5.6. L'annexe D donne les détails sur la gestion des secondes intercalaires, qu'on peut trouver en ligne.


Téléchargez le RFC 3339


L'article seul

Repartir de zéro pour construire un meilleur Internet

Première rédaction de cet article le 29 août 2009


Un interview récent de John Doyle, «  When the Internet breaks, who ya gonna call? », montre que le mème « l'Internet est vraiment trop nul, il faut le refaire complètement en partant de zéro » se porte toujours aussi bien (voir aussi mes articles sur John Day et sur Sciences & Vie). (Un exemple d'article Web en français sur le même sujet, sensationnaliste, bourré d'erreurs et souvent ridicule est « Histoire d'Internet : l'espoir - épisode 3 ».) Pourtant, aucun progrès n'a été effectué en ce sens et cela ne changera probablement pas tant que les « reparteurs à zéro » ne traiteront pas leurs trois faiblesses.

D'abord, il y a une faiblesse de positionnement. Dans le monde réel, on n'a pas souvent le luxe de repartir de zéro. D'énormes investissements ont été faits, des millions de gens ont été formés, personne ne va jeter tout cela uniquement parce que Doyle dit dans un interview qu'il faut arrêter de mettre des rustines et qu'il faut repartir de zéro. Faire un réseau informatique meilleur, en partant de zéro, est de la recherche fondamentale, avec peu de perspectives de déploiement. C'est une activité noble et utile mais qui, dans un pays où lire la Princesse de Clèves est considéré inutile, ne rapporte rien. Alors, les promoteurs du redépart à zéro prétendent que leur activité pourrait avoir des applications concrètes, ce qui est franchement malhonnête.

Ensuite, ce n'est pas tout de critiquer, il faut proposer. Les reparteurs à zéro sont intarissables sur les défauts de l'Internet et complètement muets sur leur futur réseau « bien meilleur ». Ils ne citent de ce futur réseau que des vagues promesses (« sécurisé », « rapide », « fiable »), jamais de principes architecturaux concrets, encore moins de descriptions techniques, de prototypes, etc. Ils font penser à un apprenti médecin qui, notant avec gourmandise et un grand luxe de détails les nombreuses et sérieuses limites de la médecine moderne, proposerait de refaire la médecine en partant de zéro, sans expliquer le moins du monde pourquoi il fera mieux.

Mais la troisième faiblesse est la plus sérieuse : le cahier des charges. Quels sont les principes qu'ils veulent mettre en œuvre ? Actuellement, l'Internet permet à n'importe quelle entreprise ou association de fournir des services, que ce soit de connectivité ou de contenu. La plupart des reparteurs de zéro sont des nostalgiques de la téléphonie ou de la télévision d'autrefois, où ces possibilités étaient réservées à un petit cartel. Dans un tel contexte, résoudre certains problèmes, par exemple de sécurité, est relativement facile. Mais cela supprimerait complètement l'intérêt de l'Internet. Dans le fond, ce qu'ils reprochent à ce réseau, n'est-ce pas simplement qu'il est trop ouvert et trop libre pour eux ?


L'article seul

RFC 5635: Remote Triggered Black Hole filtering with uRPF

Date de publication du RFC : Août 2009
Auteur(s) du RFC : W. Kumari (Google), D. McPherson (Arbor Networks)
Pour information
Réalisé dans le cadre du groupe de travail IETF opsec
Première rédaction de cet article le 29 août 2009


Un des ennuis les plus fréquents sur l'Internet est l'attaque par déni de service. Répondre à ce genre d'attaques ne peut pas se faire par une mise à jour logicielle ou par un changement de configuration ; d'une manière ou d'une autre, il faut éliminer le trafic anormal qui constitue la DoS. Notre RFC 5635 présente une technique permettant de déclencher le filtrage à distance, et en le faisant en fonction de l'adresse source des paquets IP de l'attaquant.

Plusieurs techniques ont déjà été développées pour faire face aux DoS, résumées dans la section 1 du RFC. Filtrer le trafic sur son propre routeur ou pare-feu est souvent inefficace : le trafic anormal a déjà transité sur votre liaison Internet et cela suffit souvent à la rendre inutilisable. Le mieux est en général de filtrer chez le FAI. Filtrer par le biais d'ACL marche bien mais les routeurs sont en général bien plus rapides à router qu'à filtrer à l'aide d'ACL. Il est donc préférable d'utiliser le routage en créant des routes « bidon », qui aboutissent dans le vide (Null0 sur IOS, par exemple, ou bien route ... discard sur JunOS), et à qui on envoie le trafic indésirable. L'élimination des paquets sera ainsi faite à la vitesse maximale du routeur.

Autre problème avec le filtrage chez le FAI : le faire à la main, après échange de coups de téléphone, n'est pas très pratique, et impose des détails alors que l'attaque est déjà en cours. D'où l'utilité de pouvoir déclencher le filtrage à distance, selon la technique dite RTBH (Remote Triggered Black Hole), qui est décrite dans le RFC 3882. Dans ce RFC, on se sert de BGP pour annoncer le filtrage à un autre routeur, en marquant les annonces en question avec une communauté BGP particulière (une communauté est une sorte d'étiquette numérique attachée à l'annonce BGP).

C'était l'état de l'art documenté avant la sortie de ce RFC 5635. Le problème de cette méthode du RFC 3882 est que les routes, dans le protocole IP, sont en fonction de la destination. On va par exemple filtrer tout le trafic à destination du serveur victime d'une attaque. On empêche ainsi les dommages collatéraux sur les autres machines mais on rend le serveur attaqué complètement inaccessible (section 1 du RFC). Lors d'une attaque, on préférerait parfois filtrer selon la source.

Le principe est donc de combiner le RTBH (Remote Triggered Black Hole) classique avec les techniques RPF du RFC 3704. C'est là l'apport de notre RFC, détaillé en section 4.

Avant cela, le RFC rappelle, dans sa section 3, le fonctionnement du RTBH par destination tel que décrit dans le RFC 3882, en fournissant des détails nouveaux. Le principe du RTBH est que l'annonce BGP indique comme routeur suivant (next hop) une route vers un trou noir, où tous les paquets sont détruits. Les détails pratiques sont en section 3.2. Parmi eux, attention aux importants filtres de sortie, qui empêcheront les annonces BGP de destruction de fuir en dehors du réseau de l'opérateur.

Le déclenchement du filtrage par le client nécessite que celui-ci puisse communiquer ses desiderata. Il le fait en général en marquant ses annonces par une communauté BGP, choisie par l'opérateur. Celui-ci a même intérêt à prévoir plusieurs communautés, pour un filtrage plus fin.

La section 4 présente la nouvelle technique. Le principe est de réutiliser le mécanisme uRPF (unicast Reverse Path Forwarding) du RFC 3704. uRPF vérifie qu'il existe une route légitime pour l'adresse source du paquet entrant, afin d'éliminer des paquets dont l'adresse source est fausse. Si le routeur sait qu'une route vers un trou noir n'est pas légitime, alors, il peut filtrer en fonction de la source, si des routes vers ces adresses sources ont été installées par RTBH. Pour l'instant, aucun routeur ne fournit apparemment la possibilité de refuser uniquement les adresses pour lesquelles la route va dans un trou noir, mais elle devrait apparaitre bientôt.

La section 4.1 fournit les étapes exactes à suivre lorsqu'on met en œuvre ce filtrage. Lorsqu'on veut bloquer les paquets venant de 192.0.2.66, on doit :

  • Activer RPF sur les routeurs du FAI,
  • Annoncer, depuis le client, une route vers 192.0.2.66/32, marquée avec la communauté BGP de filtrage indiquée par le FAI. (Attention, cela veut dire que le client va annoncer des réseaux qui ne lui appartiennent pas : le FAI devra accepter ces annonces mais faire très attention à ce qu'elles ne se propagent pas au delà de son réseau.)
  • La route sera alors installée dans les routeurs du FAI, pointant vers un trou noir. Les tests RPF échoueront alors pour les paquets émis par l'attaquant et les paquets seront rejetés.

Permettre à n'importe quel client de vouer ainsi n'importe quelle adresse source au trou noir est évidemment dangereux et le RFC conseille de ne pas activer cette possibilité par défaut (contrairement à ce qu'on peut faire pour le filtrage selon la destination). Le RTBH reste utile même s'il n'est utilisé que dans le réseau de l'opérateur, car il évite de configurer manuellement tous les routeurs de ce dernier. La section 5 détaille les risques de cette technique et les précautions à prendre.

L'annexe A détaille la configuration des routeurs pour cette famille de techniques, avec des exemples concrets pour IOS et JunOS.

Un bon article sur RTBH est « Mitigating DoS/DDoS attacks with Real Time Black Hole (RTBH) filtering », avec exemples pour Cisco IOS.


Téléchargez le RFC 5635


L'article seul

RFC 5672: RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update

Date de publication du RFC : Août 2009
Auteur(s) du RFC : D. Crocker (Brandenburg InternetWorking)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dkim
Première rédaction de cet article le 27 août 2009


Depuis sa publication, le RFC 4871, qui normalise DKIM, le mécanisme d'authentification du courrier électronique, le RFC, donc, a connu un certain nombre d'implémentations et de déploiements. Ceux-ci ont mis en évidence des problèmes dans la norme. D'où ce nouveau RFC, un erratum, qui corrige la norme sur quelques points. Une nouvelle version de DKIM, dans le RFC 6376, a ensuite été adoptée, rendant ce RFC 5672 inutile.

Quel était le principal problème ? Comme l'explique la section 1 de notre RFC 5672, DKIM sert à prouver une identité, sous la forme d'un identificateur, typiquement un nom de domaine. Quelle est la sémantique de cet identificateur ? C'est justement ce qui n'était pas clair dans le RFC 4871. Celui-ci spécifiait deux identités, indiquées par les marques d= et i= de la signature. Un exemple de signature est :

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
         c=simple/simple; q=dns/txt; i=joe@football.example.com;
...

et on y voit deux identités légèrement différentes, example.com et joe@football.example.com. Je ne maintiens pas le suspense : la bonne, celle à indiquer l'utilisateur, est bien celle marquée par d=, ici example.com, ce qui n'était pas évident dans le RFC 4871. C'est ce nom qui devrait être affiché par le MUA comme ayant été authentifié (cf. section 15).

Les sections suivantes du RFC mettent chacune à jour une partie du RFC 4871 original, sous la forme « texte original / nouveau texte ». Certaines sections sont entièrement nouvelles, notamment pour introduire beaucoup de nouveau vocabulaire. C'est ainsi qu'est introduit, dans la section 6, le terme de SDID (Signing Domain IDentifier), qui désigne la « vraie » identité de l'émetteur du message. Le SDID de l'exemple précédent est donc example.com. La section 9 de notre RFC corrige la section 3.5 du RFC original en remplaçant le vague terme « domaine » par SDID. Et la section 10 de notre RFC, pour parler du nom qui figure après la marque i=, emploie désormais AUID (Agent or User Identifier) à la place du trop imprécis « identité ». (Le RFC 5672 précise aussi la sémantique de ce champ, insistant notamment sur le fait que sa ressemblance syntaxique avec une adresse de courrier électronique ne doit pas être prise trop au sérieux : le AUID n'est pas une adresse.)


Téléchargez le RFC 5672


L'article seul

Machan, ou l'équipe nationale de handball du Sri Lanka

Première rédaction de cet article le 26 août 2009


Il y a désormais eu plusieurs films sur le difficile parcours du combattant du candidat au voyage venu du Tiers-Monde et qui veut migrer vers un pays riche mais Machan (Sri Lanka National Handball Team)) est spécial. Réalisé par un italien, avec des moyens allemands, il est entièrement situé du côté des immigrés, les européens n'étant que des figurants. Il montre la misère au Sri Lanka sans être misérabiliste (les pires horreurs comme la vente de reins ne sont qu'évoquées, pas montrées). Et, surtout, il montre le courage et l'intelligence dont il faut faire preuve pour arriver à rejoindre les brillantes lumières de l'Europe.

Ce n'est pas une comédie, même si la presse l'a parfois présenté ainsi, et qu'il y a souvent des moments drôles. C'est un film d'aventure, d'amitié (« machan »), de tristesse et d'espoir.

Un bon résumé (mais attention, qui raconte presque tout le film, ne le lisez pas avant de la voir) figure dans « Machan - The Movie (2008) » de Jazon Bourne, avec un résumé de l'affaire original de 2004, dont le film s'est inspiré (là encore, je suggère de le lire après avoir vu le film). Et, si vous lisez le cinghalais, ce qui n'est pas mon cas, voyez cet article.


L'article seul

RFC 5625: DNS Proxy Implementation Guidelines

Date de publication du RFC : Août 2009
Auteur(s) du RFC : R. Bellis (Nominet UK)
Réalisé dans le cadre du groupe de travail IETF dnsext
Première rédaction de cet article le 26 août 2009


La connexion à l'Internet typique du particulier ou de la petite entreprise passe aujourd'hui par une boîte aux fonctions mal définies. Parfois, celle-ci assure, parmi ses autres tâches, le rôle d'un relais DNS. Et ces relais, programmés en général avec les pieds par un stagiaire en Chine, violent souvent les règles du protocole DNS, et causent d'innombrables problèmes. Ce RFC dresse la liste des problèmes potentiels et formule les règles que doivent suivre les relais pour ne pas trop casser le DNS. Cela servira, pour le cas improbable où les bricoleurs qui écrivent le logiciel de ces boîtes lisent les RFC...

Ces « boîtes » sont parfois nommées box (en anglais, ça fait plus sérieux) parfois « décodeurs » (en souvenir de Canal+, première entreprise qui a réussi à mettre des boîtes chez ses clients), parfois « modem », parfois « routeur », ce qui est techniquement souvent correct, mais insuffisant, vue la variété des fonctions qu'elles assurent. Au minimum, la « boîte » devrait faire passer les paquets IP d'un côté à l'autre (du réseau local vers celui du FAI et réciproquement). Mais, pour des raisons comme celles expliquées par le RFC dans sa section 5.3, beaucoup de boîtes s'arrogent des rôles comme celui de relais DNS, rôle qu'elles remplissent mal.

La section 1 du RFC rappelle l'excellente étude qu'avait fait le même auteur, Ray Bellis, employé du registre de .uk, pour le compte du SSAC de l'ICANN : cette étude, et celle du registre DNS suédois, montraient que la grande majorité des boîtes existantes, dans leur configuration par défaut) violaient largement le protocole DNS et qu'elles contribuaient ainsi à l'ossification de l'Internet (le fait qu'on ne puisse plus déployer de nouveaux services car les boîtes intermédiaires abusent de leur rôle et bloquent ce qu'elles ne comprennent pas). Des nouveaux services comme DNSSEC risquent donc d'être très difficiles à installer.

La boîte qui fait relais DNS (et pas simplement routeur IP, comme elle le devrait) n'a en général pas un vrai serveur DNS, avec capacités de cache et gestion complète du protocole. Elle est un être intermédiaire, ni chair, ni poisson, violant le modèle en couches, et dépend des résolveurs du FAI auquel elle transmet les requêtes. Le RFC commence donc par recommander de ne pas utiliser de tels relais. Néanmoins, s'ils existent, il faudrait au minimum qu'ils suivent les recommandations du document.

La section 3 remet ces recommandations dans le contexte du principe de transparence. Un relais DNS ne peut espérer mettre en œuvre toutes les fonctions du DNS, surtout celles qui n'existent pas encore. En effet, la boîte a en général des ressources matérielles assez limitées, elle n'a souvent pas de mécanisme de mise à jour simple, ce qui veut dire qu'elle tournera toute sa vie avec le même code, et son interface de configuration doit idéalement être simple.

Alors, le relais, puisqu'il ne peut pas gérer complètement le DNS, devrait le laisser en paix. L'étude du SSAC montrait que, plus la boîte joue un rôle actif dans le protocole DNS, plus elle fait de bêtises. Le relais devrait donc juste prendre les paquets d'un côté et les envoyer de l''autre, sans jouer à les interpréter, ce qu'il fait toujours mal. Et, dans tous les cas, le RFC recommande que les machines du réseau local puissent écrire directement au résolveur DNS de leur choix, si celui de la boîte est vraiment trop mauvais (ce n'est pas toujours possible, par exemple dans les hôtels où le port 53, celui du DNS, est souvent filtré).

Dans le cadre de ce principe de transparence, la section 4 du RFC détaille ensuite point par point toutes les règles à respecter particulièrement. Ainsi, la section 4.1 rappelle que les relais ne doivent pas jeter un paquet DNS simplement parce que des options inconnues apparaissent dans celui-ci. Beaucoup de boîtes jettent les paquets où les bits AD (Authentic Data) ou CD (Checking Disabled) sont à un, simplement parce qu'ils n'existaient pas à l'époque du RFC 1035 (section 4.1), le seul que le stagiaire qui a programmé la boîte a lu (quand il en a lu un). (Ces bits sont dans la plage Reserved for future use, notée Z.)

De même, certaines boîtes ne laissent pas passer les types d'enregistrement inconnus, la section 4.3 rappelle donc, suivant le RFC 3597 qu'une mise en œuvre correcte du DNS doit laisser passer les types inconnus, sinon il sera impossible de déployer un nouveau type.

Un autre point sur lequel les logiciels des boîtes (mais aussi beaucoup de pare-feux) sont en général défaillants est celui de la taille des paquets DNS. Là encore, si le programmeur a lu un RFC (ce qui est rare), il s'est arrêté au RFC 1035, sans penser que, depuis vingt-deux ans qu'il existe, des mises à jour ont peut-être été faites et que la taille maximum de 512 octets n'est donc plus qu'un souvenir. La section 4.4 doit donc rappeler que les paquets DNS ne sont pas limités à 512 octets et que des réponses de plus grande taille sont fréquentes en pratique. Le relais doit donc gérer TCP correctement (section 4.4.1), et accepter EDNS0 (section 4.4.2, voir aussi le RFC 6891..

Les boîtes maladroites peuvent aussi interférer avec la sécurité. La section 4.5 rappelle que TSIG (RFC 2845) peut être invalidé si la boîte modifie certains bits des paquets (ce qui existe) ou bien retourne des réponses non signées à des requêtes signées (ce qui est courant sur les points chauds Wifi).

Une autre section, la 5, couvre les questions de l'interaction avec DHCP. La plupart du temps, la machine de M. Toutlemonde obtient l'adresse IP du résolveur DNS via DHCP (option 6, Domain Name Server, RFC 2132, section 3.8). La plupart des boîtes indiquent leur propre adresse IP ici. Et, en général, il n'est pas possible de modifier ce paramètre (par exemple, la Freebox ne permet pas d'indiquer un autre serveur DNS, choisi par le client ; même chose chez SFR). La seule solution pour court-circuiter le service DNS par défaut est donc d'indiquer en dur les résolveurs souhaités, dans la configuration de chaque machine. La section 5.1 appelle donc à une option de la boîte permettant de changer les serveurs DNS annoncés.

DHCP permet également une option indiquant le nom de domaine du réseau (option 15, section 3.17 du RFC 2132) et la section 5.2 du RFC 5625 demande qu'elle soit vide par défaut, en l'absence d'un domaine local normalisé.

La section 5.3 est consacrée à une discussion sur la durée du bail DHCP. Une des raisons pour lesquelles beaucoup de boîtes indiquent leur propre adresse IP comme résolveur DNS est que, au démarrage, la boîte ne connait pas forcément les adresses des résolveurs DNS du FAI. Mais cette technique oblige ensuite la boîte à agir comme relais DNS, ce qui est précisément la source de beaucoup de problèmes. Une solution possible, suggérée par notre RFC, est d'annoncer l'adresse IP de la boîte avec une durée de bail ultra-courte, tant que la boîte n'est pas connectée à l'Internet, puis d'annoncer les résolveurs du FAI ensuite, avec une durée de bail normale.

Les interférences provoquées par les boîtes mal conçues peuvent aussi avoir un impact sur la sécurité. C'est l'objet de la section 6. Il y a des boîtes qui, ignorant le RFC 5452, réécrivent le Query ID, rendant ainsi les utilisateurs davantage vulnérables à la faille Kaminsky (section 6.1). Il y en a qui répondent aussi aux requêtes DNS venues du WAN, permettant ainsi les attaques décrites dans le RFC 5358 (section 6.2).

Bref, les relais DNS des boîtes sont souvent plus dangereux qu'utiles. Le principe d'ingéniérie simple « si vous voyez un système inconnu, bas les pattes » est malheureusement très largement ignoré dans l'Internet. Pourquoi ? Pour les boîtes, il y a plusieurs raisons, typiquement liées à l'isolement complet dans lequel vivent les programmeurs anonymes de ces machines. Au contraire des logiciels libres comme Unbound ou BIND, dont les auteurs participent régulièrement à la communauté DNS, les programmeurs des boîtes sont inconnus, ne fournissent pas d'adresse pour leur envoyer des rapports de bogue ou de remarques. Pas étonnant, dans ces conditions, que le logiciel soit de mauvaise qualité.

Les abonnés à Free noteront que la Freebox n'a pas les problèmes mentionnés dans le RFC puisqu'elle est purement routeur, elle ne sert pas de relais DNS. Les serveurs DNS qu'elle indique en DHCP sont situés derrière elle, dans les salles de Free.


Téléchargez le RFC 5625


L'article seul

« Dette technique » lors de l'écriture de logiciels

Première rédaction de cet article le 25 août 2009
Dernière mise à jour le 9 mai 2012


Les développeurs de logiciels, lorsqu'ils suivent les cours d'un établissement d'enseignement sérieux, apprennent un certain nombre de bonnes pratiques qui, si elles étaient systématiquement utilisées lorsqu'ils programment plus tard, dans le monde réel, mènerait à du logiciel de bien meilleure qualité. Au lieu de cela, les logiciels contiennent des bogues, parfois énormes, des failles de sécurité et sont souvent très difficiles à maintenir par les successeurs des premiers programmeurs.

Pourquoi les bonnes pratiques ne sont-elles pas davantage utilisées ? Les programmeurs mettent souvent en avant le manque de temps : à l'Université, on a des heures ou des jours pour programmer un crible d'Ératosthène ou une suite de Fibonacci avec tous ses détails, alors que, dans le monde réel, le temps manque, le chef réclame que le logiciel soit livré à temps, on prend donc des raccourcis et tant pis pour la qualité.

Ont-ils raison ou tort de « bâcler » le travail ? Le débat se focalise souvent en des termes binaires, le camp des « vrais programmeurs qui codent » accuse celui des experts d'irréalisme, celui des experts accuse les « bricoleurs » de mal faire le travail. Par exemple, dans une excellente discussion sur Server Fault, Laura Thomas écrit, en défense de l'approche « vite fait et pas parfaitement fait », « Another of my favorite mottos is "Don't let perfect get in the way of better." Sometimes people struggling for elegance, simplicity, or the "right way" will refuse improvement because it isn't good enough. » alors que Ben Dunlap répond « Filthy scripts have a tendency to punish your co-workers and successors, and to fail when unexpected circumstances arise, which they always do. So do get the job done, but find the right balance between expedience and ideals. Those ideals exist for a reason. ;-) ».

L'article de Martin Fowler, Technical debt (« dette technique »), évite au contraire de parler en terme de mal ou de bien, juste de compromis. Ne pas suivre complètement les pratiques idéales équivaut à s'endetter : il faudra payer un jour (rien n'est gratuit) mais, dans certains cas, s'endetter reste quand même une approche raisonnable. Il faut juste en être conscient.

Un autre excellent article sur ce même thème est celui de Anthony Ferrara, The Power of Technical Debt, où il compare la dette technique du programmeur à divers types de dettes qu'on trouve dans le monde financier (attention, les exemples sont plutôt empruntés au monde états-unien, les dettes ne fonctionnent pas forcément pareil dans les autres pays), analysant à chaque fois si cela peut être une bonne ou une mauvaise dette.


L'article seul

RFC 5612: Enterprise Number for Documentation Use

Date de publication du RFC : Août 2009
Auteur(s) du RFC : P. Eronen (Nokia), D. Harrington (Huawei)
Pour information
Première rédaction de cet article le 24 août 2009


L'arborescence de nommage de gestion, décrite dans le RFC 1155 puis dans le RFC 2578, prévoit un sous-arbre pour les organisations privées, 1.3.6.1.4.1. Ce RFC ajoute un numéro d'entreprise à ce sous-arbre, pour les exemples et la documentation.

Autrefois, ces noms et numéros réservés pour la documentation n'existaient pas, on utilisait des valeurs prises au hasard, ou bien qui reflétaient l'entreprise de l'auteur du RFC. Malheureusement, ces valeurs se retrouvaient parfois utilisées par des administrateurs réseau distraits, d'où la tendance actuelle à réserver des valeurs uniquement pour les cours, tutoriels, modes d'emploi, etc. C'est ce que font le RFC 5737 pour les adresses IPv4, le RFC 3849 pour les adresses IPv6, le RFC 2606 pour les noms de domaines, etc. Notre RFC le fait pour les numéros d'organisation (enterprise numbers) de l'arborescence de gestion, qui est utilisée notamment par SNMP mais également par Radius (les attributs vendor-specific) ou par Syslog (les structured data).

Ainsi, l'entreprise Netaktiv a t-elle obtenu en avril 2001 le numéro 9319 et son sous-arbre est donc 1.3.6.1.4.1.9319. Pour la documentation et les exemples, le nombre réservé est 32473 (sections 2 et 3 du RFC) donc le sous-arbre 1.3.6.1.4.1.32473. Le registre IANA contient désormais ce numéro.

Il se reflète également dans le domaine enterprise-numbers.org qu'on peut interroger via le DNS :

% dig +short TXT 32473.enterprise-numbers.org
"Example Enterprise Number for Documentation Use"

Téléchargez le RFC 5612


L'article seul

RFC 5617: DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)

Date de publication du RFC : Août 2009
Auteur(s) du RFC : E. Allman (Sendmail), J. Fenton (Cisco), M. Delany (Yahoo), J. Levine (Taughannock Networks)
Intérêt historique uniquement
Réalisé dans le cadre du groupe de travail IETF dkim
Première rédaction de cet article le 24 août 2009
Dernière mise à jour le 26 novembre 2013


Le protocole de signature des messages électroniques DKIM, normalisé dans le RFC 6376, a un petit défaut : si un message ne porte pas de signature, comment savoir si c'est parce que le domaine émetteur ne signe pas ou bien si c'est parce qu'un attaquant a modifié le message et retiré la signature ? (À noter que la solution proposée par ce RFC a finalement été officiellement abandonnée par l'IETF en novembre 2013.)

La solution qui avait été choisie par le groupe de travail DKIM de l'IETF était, comme documenté dans ce RFC 5617, de permettre à un domaine de publier ses pratiques de signature. Désormais, un domaine va pouvoir annoncer dans le DNS qu'il signe tous ses messages (et donc qu'un message sans signature est suspect) ou bien qu'il ne signe pas systématiquement et qu'il faut donc être indulgent à la vérification.

Dans le futur, il est théoriquement possible que DKIM soit tellement largement déployé que cette publication soit inutile, et qu'on puisse considérer que tout message doit être signé. Mais on en est très loin (section 1 du RFC).

Le RFC 5016 avait défini le cahier des charges pour un tel mécanisme de publication des pratiques. Voici donc sa réalisation.

La section 3 du RFC définit les grandes lignes du mécanisme :

  • Publication par l'émetteur, dans le DNS, d'un enregistrement à _adsp._domainkey.mydomain.example, indiquant les pratiques de signature de mydomain.example (mais pas celles des domaines fils comme child.mydomain.example, cf. section 3.1).
  • Consultation par le destinataire de cet enregistrement, le nom de domaine utilisé étant celui qui apparait dans le champ From: du message (l'Auteur, en terminologie DKIM). À noter que le message peut avoir des signatures pour d'autres domaines que celui de l'Auteur, par exemple s'il a été transmis via une liste de diffusion qui signe (cf. section 3.2).
  • Décision par le destinataire du sort du message, en fonction de ce qu'il a trouvé dans ADSP et de la présence ou pas d'une signature. Par exemple, si un message ne porte aucune signature mais que l'enregistrement ADSP indique que le domaine de l'auteur signe systématiquement, le message est très suspect. Par défaut, la situation actuelle est « pas de signature, pas d'enregistrement ADSP » (cf. section 3.3).

Place maintenant à la description détaillée du protocole, en section 4. Les enregistrements ADSP sont publiés sous forme d'enregistrements TXT. Les objections du RFC 5507 ne s'appliquent pas ici puisque l'enregistrement n'est pas immédiatement dans le domaine, mais dans _adsp._domainkey.LEDOMAINE. Dans le texte de l'enregistrement, la syntaxe habituelle de DKIM, clé=valeur est utilisée. Actuellement, seule la clé dkim est définie (section 4.2.1) et elle peut prendre les valeurs :

  • unknown : on ne sait pas (c'est la valeur par défaut, s'il n'y a pas d'enregistrement ADSP),
  • all : tout le courrier venant de ce domaine est signé,
  • discardable : tout le courrier venant de ce domaine est signé et peut être jeté à la poubelle sans remords s'il ne l'est pas.

Des futures valeurs pourront apparaitre plus tard dans le registre IANA (section 5).

On retrouve, dans le choix d'une valeur pour la clé dkim, un problème classique de l'authentification : que faire lorsqu'elle échoue ? Si on met unknown, ADSP ne sert à rien puisque le récepteur n'a aucune idée de s'il peut agir ou non. Si on met discardable, on fait courir un grand risque à son courrier puisque une bête erreur comme l'expédition d'un message depuis un site qui ne signe pas pourra entrainer la destruction du message. Je fais le pronostic que, par prudence, les émetteurs n'utiliseront que unknown ou all et les récepteurs ne jetteront le message que lorsqu'un discardable apparait. En pratique, il est donc probable qu'aucun message abusif ne sera éliminé par ADSP.

Les tests faits suite à des requêtes ADSP peuvent donc fournir des informations sur l'authenticité d'un message et ces informations peuvent être publiées dans un en-tête Authentication-Results: du RFC 7601. La méthode dkim-adsp s'ajoute donc aux méthodes d'authentification utilisables (section 5.4).

La section 6, les questions de sécurité, explore les risques et les problèmes associés à ADSP. Elle note par exemple, ce qui est plutôt amusant, que puisque des MUA très courants comme Outlook n'affichent pas l'adresse de courrier de l'expéditeur, authentifier le domaine de celle-ci (tout le but de ADSP) n'apporte pas grand'chose avec ces MUA.

Comme ADSP dépend du DNS, il en partage les vulnérabilités, et l'usage de DNSSEC peut donc être nécessaire.

Voici un exemple de requête dig pour trouver l'enregistrement ADSP de formattype.fr :

% dig +short TXT _adsp._domainkey.formattype.fr  
"dkim=unknown"

D'autres exemples, très détaillés figurent en annexe A, couvrant les différents cas.

L'annexe B est très intéressante et couvre plusieurs scénarios d'utilisation typiques, où l'usage d'ADSP n'est pas complètement évident. Le cas des listes de diffusion n'y apparait pas, alors qu'elles sont souvent un des plus gros casse-têtes avec DKIM. Si une liste de diffusion respecte le message original et ne le modifie pas, pas de problème. Elle peut laisser l'éventuelle signature DKIM originale (et, si elle le souhaite, ajouter sa propre signature, mais qui ne pourra pas utiliser ADSP puisque le domaine de l'auteur n'est pas celui de la liste). Mais si la liste modifie les messages, par exemple pour ajouter de la publicité à la fin, ou pour ajouter une étiquette dans le sujet, alors la signature DKIM originale ne correspondra plus. Le message sera alors jugé comme étant de la triche (ce qu'il est, puisque le message originel a été changé). Si le programme gestionnaire de listes supprime la signature et que le domaine de l'auteur publiait avec ADSP dkim=discard, ce n'est pas mieux, le message sera également considéré comme faux.

À l'heure de la publication du RFC, les mesures faites par DNSdelve montrent qu'il n'existe quasiment aucun domaine publiant de l'ADSP sous .fr. Si on veut tester, les domaines catinthebox.net, isdg.net ou wildcatblog.com publient de l'ADSP.

En novembre 2013, l'IESG a officiellement annoncé la fin d'ADSP et la reclassification de ce RFC comme « intérêt historique seulement ». Il y a certes eu des mises en œuvre d'ADSP mais peu de déploiements. Et parfois, ils se sont mal passés par exemple avec des politiques trop strictes qui faisaient rejeter les messages de certains utilisateurs. Pour connaître la politique DKIM d'un domaine, il faut désormais recourir à des méthodes autres.


Téléchargez le RFC 5617


L'article seul

RFC 5620: RFC Editor Model (Version 1)

Date de publication du RFC : Août 2009
Auteur(s) du RFC : O. Kolkman (IAB)
Pour information
Première rédaction de cet article le 24 août 2009


L'articulation compliquée entre l'IETF qui produit les normes TCP/IP et le RFC Editor qui les publie, n'a jamais cessé de faire couler de l'encre (ou d'agiter des électrons). Dans ce document, l'IAB décrit un modèle pour le RFC Editor, modèle où les fonctions de ce dernier sont éclatées en plusieurs fonctions logiques. Aujourd'hui effectuées par la même organisation, elles pourraient demain être réparties entre plusieurs groupes. Ce RFC était un premier essai (« version 1 ») et il a ensuite été remplacé par le RFC 6635.

Le document de référence actuel est le RFC 4844. Comme le rappelle la section 1, il décrit les tâches du RFC Editor de manière globale, comme si c'était forcément une seule entité (c'était, à l'origine, une seule personne, Jon Postel). La section 2 note que la tâche de RFC Editor est actuellement une partie de l'IASA et financée par son budget.

La section 3 s'attaque à la définition du rôle du RFC Editor sous forme de fonctions séparées. L'IAB voit quatre fonctions :

  • Éditeur des RFC,
  • Éditeur des contributions indépendantes,
  • Producteur des RFC,
  • Publieur des RFC.

Chaque section va ensuite détailler ces tâches.

L'Éditeur de la série des RFC (RFC Series Editor) est décrit en premier, en section 3.1. Il est responsable du travail à long terme, définir les principes qui assurent la pérennité des RFC, garder à jour les errata, développer le guide de style des RFC (ce qui inclus la délicate question du format), etc. Notre RFC décrit les compétences nécessaires, qui comprennent une expérience des RFC en tant qu'auteur.

L'Éditeur des contributions indépendantes (Independent Submission Editor) fait l'objet de la section 3.2. Les contributions indépendantes sont celles qui sont envoyées directement au RFC Editor, sans passer par l'IETF. Le RFC Editor doit donc jouer un rôle bien plus actif avec elles, notamment pour juger de leur valeur technique. Le responsable de cette tâche doit donc avoir une solide compétence technique et jouir d'une bonne réputation auprès des participants à l'IETF. (Le premier a été nommé en février 2010.) Son rôle est désormais décrit par le RFC 6548.

Le travail quotidien est, lui, assuré par le Producteur des RFC (RFC Production Center) dont parle la section 3.3. Il reçoit les documents bruts, les corrige, en discute avec les auteurs, s'arrange avec l'IANA pour l'allocation des numéros de protocoles, attribue le numéro au RFC, etc.

Les RFC n'étant publiés que sous forme numérique, il n'y a pas d'imprimeur mais le numérique a aussi ses exigences de publication et il faut donc un Publieur des RFC (RFC Publisher), détaillé en section 3.4. Celui-ci s'occupe de... publier, de mettre le RFC dans le dépôt où on les trouve tous, d'annoncer sa disponibilité, et de s'assurer que les RFC restent disponibles, parfois pendant de nombreuses années.

Chacune de ces fonctions pourra faire l'objet d'une attribution spécifique (à l'heure actuelle, elles sont toutes effectuées par le même groupe à l'ISI). L'annexe A décrit le mécanisme de sélection actuellement en cours.


Téléchargez le RFC 5620


L'article seul

RFC 5594: Report from the IETF workshop on P2P Infrastructure, May 28, 2008

Date de publication du RFC : Juillet 2009
Auteur(s) du RFC : J. Peterson (Neustar), A. Cooper (Center for Democracy & Technology
Pour information
Première rédaction de cet article le 24 août 2009


Le développement très rapide et très spectaculaire du pair-à-pair soulève plein de questions. Parmi elles, celle de la charge que font peser ces services sur les réseaux des opérateurs, et les points sur lesquels un travail de normalisation de l'IETF pourrait aider. C'étaient les deux thèmes du colloque organisé au MIT en mai 2008 et dont ce RFC est le compte-rendu.

La principale application du pair-à-pair aujourd'hui est le transfert de fichiers. Il n'y a pas de limite à la taille des contenus, notamment vidéo et les logiciels de pair-à-pair, comme le rappelle la section 1 du RFC, sont conçus pour utiliser le réseau à fond. C'était le point de départ du colloque : peut-on améliorer les choses ? Avant cela, il faut comprendre le phénomène et donc étudier les caractéristiques des réseaux pair-à-pair existants. Puis trois propositions ont émergé du colloque, un protocole de contrôle de congestion mieux adapté aux transfert de fichiers massifs, une étude des applications qui ouvrent plusieurs connexions simultanées, et une solution qui permettrait d'améliorer la sélection des pairs avant de commencer le transfert du fichier convoité.

Pour mieux comprendre le phénomène, le colloque a vu des exposés par des opérateurs (section 3). Par exemple, deux employés de Comcast ont décrit successivement les problèmes spécifiques aux réseaux câblés utilisant la norme DOCSIS, où chaque modem a accès à son tour. Par exemple, lorsque le CMTS donne accès au câble à un modem, celui-ci peut alors envoyer autant de données qu'il veut. Une machine en train d'envoyer un gros fichier pourra alors, à nombre de transferts égaux, prendre nettement plus de capacité que les autres.

Pour éviter les problèmes, outre les évolutions de la norme DOCSIS, certains opérateurs cherchent à mesurer en temps réel l'activité réseau des clients, pour ensuite limiter dans le CMTS leur accès au réseau. Outre qu'elle pose la question de la transparence du réseau, on peut noter que l'utilisateur n'est pas informé de cette situation (communiquer vers les clients des informations concrètes n'est jamais la priorité des opérateurs).

Autre point de vue, celui des développeurs de logiciels pair-à-pair (section 4). Stanislas Shalunov, de BitTorrent, a expliqué les défis auxquels étaient confrontés les développeurs et proposé des solutions. Là encore, les réseaux où beaucoup de ressources sont partagées, comme ceux fondés sur le câble TV, sont particulièrement affectés puisqu'un seul abonné peut en gêner beaucoup d'autres.

Les solutions possibles font l'objet de la section 5. La plus évidente est d'améliorer la sélection des pairs (section 5.1). Lorsqu'un client BitTorrent veut télécharger un fichier, il peut choisir n'importe lequel (ou lesquels) dans un essaim qui comporte souvent des centaines ou des milliers de machines. En général, il ne tient aucun compte de la topologie du réseau ou des informations contenues dans le système de routage. L'algorithme de sélection du pair varie selon les logiciels mais aboutit souvent à choisir une machine à l'autre bout du monde, alors qu'un pair volontaire était plus « proche ». Cela induit un délai supplémentaire pour l'utilisateur, et une charge plus grande du réseau pour l'opérateur.

Une solution serait donc d'avoir quelque part un service qui pourrait informer les pairs des conditions topologiques et les aider à choisir de meilleurs pairs.

Il n'est pas certain qu'il existe une solution idéale. Par exemple, si BitTorrent utilise une part d'aléatoire dans la sélection d'un pair, c'est aussi parce que cela évite la concentration des requêtes sur les machines les mieux placées, et permet de trouver ceux qui ont des parties rares d'un fichier.

En outre, les intérêts de l'opérateur et de l'utilisateur ne sont pas identiques. On pourrait imaginer des cas où la sélection qui soit optimale pour l'opérateur ne le serait pas pour l'utilisateur... qui risquerait donc de ne plus utiliser le système de sélection. Il est donc important que le système d'aide à la sélection ne soit donc qu'une indication parmi d'autres.

Compte-tenu de tout ceci, quelles sont les solutions techniques possibles ? Par exemple, le RFC cite :

  • Tenir compte des AS. Des études ont montré que, avec des essaims typiques (de 2 000 à 10 000 pairs), on pouvait obtenir la majorité des fichiers uniquement en demandant à l'intérieur de l'AS. (En revanche, un niveau de détail plus grand, par exemple chercher les pairs connectés au même DSLAM, ne rapporte quère de bénéfice, la probabilité de tout trouver dans le voisinage devient trop faible.)
  • Utiliser P4P, un système où l'opérateur met à la disposition de ses clients un service leur permettant de trouver les pairs les plus proches en communiquant des informations sur la topologie du réseau et le coût des différents liens.
  • Un système « multi-niveaux » où plusieurs services d'information coexisteraient, certains pour le contenu global, d'autres uniquement pour un contenu local, avec redirection des premiers vers les seconds. Comme le contenu peut être, dans certains cas, illégal, la question de la responsabilité de l'opérateur qui gère le service pourrait être engagée.
  • Créer un système de sélection du pair assisté par l'opérateur. Après tout, le FAI connait plein de choses sur son propre réseau, les liens de transit et ceux de « peering », les métriques OSPF ou BGP, la capacité des différents liens, etc. Cette information permettrait sûrement au logiciel de mieux choisir ses pairs. Dans cette optique, le FAI installerait un « oracle » qui serait un service d'information qui, contrairement à P4P, ne distribuerait pas cette connaissance (beaucoup d'opérateurs la considèrent comme confidentielle) mais qui recevrait une liste d'adresses IP de pairs potentiels et la renverrait triée, les « meilleurs » en premier. Cela pose évidemment un grand problème de passage à l'échelle. Pour un essaim de 10 000 pairs, la quantité d'information à transmettre à l'oracle est impressionnante. Pour les essaims du futur, qui pourraient compter des centaines de milliers de pairs, il faudra renoncer à tout transmettre. Mais le gros avantage de cette méthode est que l'opérateur ne voit que des adresses IP, et ne connait rien du contenu transféré, ce qui décharge complètement sa responsabilité juridique.
  • En informatique, des tas de problèmes de performance se résolvent en mettant des caches, des mémoires intermédiaires, rapides, entre le demandeur d'information et le lieu de stockage de cette information. Un FAI pourrait donc installer des caches pair-à-pair sur son réseau. Les risques juridiques sont alors à l'opposé de la solution précédente : le FAI garderait en effet sur ses propres machines un contenu dont une partie est considérée comme illégale par certains.

Une fois ces solutions énumérées, que peut faire l'IETF ? Vouloir normaliser un système pair-à-pair complet (un « BitTorrent IETF ») est clairement prématuré, dans l'état actuel de l'expérience avec le pair-à-pair, domaine très bouillonant. À la place, le RFC 5594 n'envisage que de la spécification de quelques composants ponctuels d'un tel système. Une longue section 5.1.6 énumère les actions possibles pour chacune des solutions citées plus haut :

  • Pour trouver le numéro d'AS d'une machine, il n'existe actuellement pas d'interface standard. L'IETF pourrait en développer une.
  • Pour interroger un « oracle », un protocole standard d'interrogation (qui ne préjugerait pas de comment l'oracle prend sa décision) serait également souhaitable.
  • Pour découvrir l'oracle, un moyen normalisé (même si ce n'est qu'une simple convention de nommage comme oracle.example.net) aurait bien des avantages. DHCP est un moyen possible, l'anycast un autre, un enregistrement SRV dans le DNS un troisième.
  • On l'a vu plus haut, lorsque le service que vend un FAI est limité, par exemple à une certaine quantité d'octets par mois, ou bien par shaping automatique, l'approche de la limite n'est pas communiquée à l'utilisateur, ou uniquement par des mécanismes non-standard et souvent peu adaptés à une récupération automatique (par exemple via une page Web). Un protocole standard de communication aiderait les utilisateurs à mieux surveiller leur consommation. Ce ne serait évidemment pas facile de développer un tel protocole, compte-tenu de la variété des offres commerciales (pensez au côté incompréhensible des offres dans la téléphonie mobile).
  • Si plusieurs services d'information sont possibles, avec redirection entre eux, un mécanisme standard pour cette redirection serait bienvenu.

Après une meilleure sélection des pairs, l'autre grand chantier que pose le pair-à-pair est le contrôle de congestion (section 5.2). La plupart des applications cherchent à transférer leurs données le plus vite possible. Avec l'abondance de contenu disponible en pair-à-pair, cela peut signifier une occupation permanente du réseau. Si les logiciels de pair-à-pair étaient plus modérés dans leur usage de la capacité réseau disponible, les choses iraient mieux. (Certains logiciels offrent des possibilités d'auto-limitation, par exemple, avec mldonkey, on peut mettre max_hard_upload_rate = 10 dans downloads.ini et on limite alors la consommation « montante » à 10 ko/s.)

Un exemple d'un meilleur comportement est le client BitTorrent officiel qui mesure en permanence le délai de transmission et cherche à le minimiser, ce qui laisse de la capacité pour les applications qui veulent une faible latence (comme la VoIP).

Une autre approche serait un contrôle de congestion pondéré, pour que TCP sur la machine laisse d'avantage de ressources à certaines applications (actuellement, depuis l'échec de TOS dans IP, l'application n'a pas de moyen standard d'indiquer ce genre de préférences, DiffServ (RFC 2474) est plutôt prévu pour être géré par le réseau (section 5.2.2 pour un traitement plus détaillé de la pondération).

Un autre endroit où mettre en œuvre une telle inégalité de traitement est bien sûr dans le réseau lui-même. Ainsi, un FAI peut déployer une architecture souvent appelée du terme marketing de qualité de service (alors que le but est au contraire de dégrader la qualité du service de certaines applications, au profit d'autres). Pour classer les données qui circulent dans son réseau, il peut utiliser les numéros de port (443 indique de l'HTTPS, 22 du SSH, etc) ou la DPI. Comme cette classification vise à diminuer la qualité de service de certains usages, les logiciels tentent en permanence d'y échapper et, de même que le numéro de port est devenu peu à peu inutile, tous les logiciels changeant de numéro ou détournant un numéro de port comme 443, la DPI motive les auteurs de logiciel à utiliser de plus en plus la cryptographie pour éviter à leur trafic d'être reconnu (section 5.3).

Autre question de justice : le cas des applications qui ouvrent plusieurs connexions TCP simultanées (section 6). La tendance avait été lancée par Netscape pour imposer son navigateur contre Mosaic. En effet, TCP essayant d'attribuer des parts identiques à toutes les connexions, avoir plusieurs connexions permet une part plus grosse. Il est donc nécessaire d'étudier plus attentivement la question.

Il y a bien longtemps que l'Internet ne vit plus exclusivement des subventions de l'armée états-unienne et tous les débats techniques du monde pèsent donc peu à côté des histoires de gros sous. La section 7 détaille donc les discussions autour du coût du pair-à-pair. Les chiffres rigoureux manquent dans ce domaine car, s'il est facile de connaître le prix d'un câble, celui de la congestion est bien plus dur à fixer. Il existe des estimations allant de 10 cents à 2 dollars US pour un gigaoctet transféré. La consommation qu'entraine le pair-à-pair pousse certains à réclamer le retour au tarif au volume.

Traditionnellement, l'IETF ne travaille pas sur les questions économiques, qui sont difficiles, vue la variété des modèles d'affaires, et de toute façon pas forcément de sa compétence. Mais il faudrait peut-être que l'IRTF commence un travail sur ce sujet.

Assez parlé, il faut maintenant agir. Quelles sont les prochaines étapes ? La section 8 cite les suivantes :

  • Travailler à un protocole de contrôle de congestion permettant aux applications pair-à-pair de réduire leur propre impact. À ma connaissance, ce travail n'a pas encore commencé.
  • Documenter précisement les effets de l'ouverture de connexions TCP multiples (section 6). Là non plus, je ne crois pas que ce travail aie déjà démarré.
  • Améliorer la séclection des pairs, par un nouveau protocole d'information (section 5.1). C'est désormais le travail du groupe Alto.

Les exposés faits lors du colloque peuvent être téléchargés en http://trac.tools.ietf.org/area/rai/trac/wiki/PeerToPeerInfrastructure.


Téléchargez le RFC 5594


L'article seul

Faille BIND permettant une DoS via les mises à jour dynamiques

Première rédaction de cet article le 29 juillet 2009


La mise à jour, lors d'urgences frénétiques, de logiciels critiques, est une occupation courante sur l'Internet. Aujourd'hui, c'est BIND, un habitué de ce genre de distractions, qui nous offre une telle émotion, avec la faille de sécurité CVE-2009-0696, alias VU#725188, la possibilité de planter BIND à distance par le biais d'une requête DNS de mise à jour dynamique, même si la configuration du serveur n'autorise pas de telles mises à jour.

Annoncée le 28 juillet par l'ISC, cette faille, spécifique à BIND (contrairement à la faille Kaminsky), vient d'une mauvaise analyse des requêtes de mise à jour dynamique (dynamic update, normalisé dans le RFC 2136). Lorsqu'il reçoit une requête DNS spécialement fabriquée, où le pré-requis à la mise à jour, dans le paquet, a le type ANY (normalement jamais utilisé), le serveur plante immédiatement et écrit dans son journal :

Jul 29 09:10:57 lilith named[2428]: db.c:619: \
           REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Jul 29 09:10:57 lilith named[2428]: exiting (due to assertion failure)

(On note que l'adresse IP de l'attaquant n'apparait pas dans ce message et que, de toute façon, un seul paquet UDP suffit et que son adresse source peut être mensongère.) Il n'y a plus qu'à redémarrer BIND et, entre temps, on n'a pas de résolution de noms. Si le domaine n'utilise que BIND (ce qui est hélas courant) et que l'attaquant vise tous les serveurs du domaine, il peut faire disparaitre le domaine de l'Internet. C'est d'ailleurs en raison de ce genre de risques qu'il faut que les serveurs Internet soient de diverses origines. Par exemple, il ne faut pas utiliser que BIND, il est important d'avoir également d'autres logiciels comme NSD.

Pour que le serveur soit vulnérable, il faut aussi qu'il fasse autorité pour au moins une zone DNS de type master (slave ne suffit pas). Comme BIND, par défaut, est master pour localhost et 0.0.127.in-addr.arpa, cela explique que la grande majorité des serveurs BIND sont vulnérables.

L'exploitation de cette faille a été rendue publique et peut-être aussi simple que ce programme écrit en Perl. Voici, vue par tshark, le paquet d'attaque (utilisant la zone localhost pour laquelle tous les BIND font autorité par défaut) :

Domain Name System (query)
    Transaction ID: 0x6142
    Flags: 0x2800 (Dynamic update)
        0... .... .... .... = Response: Message is a query
        .010 1... .... .... = Opcode: Dynamic update (5)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
    Zones: 1
    Prerequisites: 1
    Updates: 1
    Additional RRs: 0
    Zone
        localhost: type SOA, class IN
            Name: localhost
            Type: SOA (Start of zone of authority)
            Class: IN (0x0001)
    Prerequisites
        localhost: type ANY, class IN
            Name: localhost
            Type: ANY (Request for all records)
            Class: IN (0x0001)
            Time to live: 0 time
            Data length: 0
    Updates
        localhost: type ANY, class ANY
            Name: localhost
            Type: ANY (Request for all records)
            Class: ANY (0x00ff)
            Time to live: 0 time
            Data length: 0

On peut examiner le paquet complet sur pcapr.net.

La solution la plus propre est de mettre à jour BIND vers une version sûre, et d'urgence, en suivant la liste donnée par l'ISC. Avec les versions officielles de l'ISC, vous pouvez voir si un serveur est à jour avec :

% dig @ns1.EXAMPLE.net  CH TXT version.bind.

et vous obtenez le numéro de version que vous pouvez comparer à la liste des versions sûres. Attention : avec beaucoup de paquetages BIND de différents systèmes d'exploitation, le numéro de version n'est pas forcément modifié lors de l'application de mises à jour de sécurité.

Si cette mise à jour est difficile, pour une raison ou pour une autre, le plus simple est de « démasteriser », c'est-à-dire de supprimer les zones de type master de la configuration (named.conf). Sur un serveur qui est uniquement à autorité, cela n'est pas un problème. Sur un serveur récursif, cela entrainera quelques disfonctionnements mais qui ne sont probablement pas trop graves, par rapport aux risques de la faille.

Une des raisons pour lesquelles on n'a pas toujours la possibilité de faire une mise à jour est que les fournisseurs réagissent plus ou moins rapidement. À l'heure où j'écris, Debian a fait une mise à jour mais pas RHEL, pourtant bien plus cher.

Une dernière solution pour protéger votre serveur est de demander au pare-feu, si vous n'utilisez pas les mises à jour dynamiques, de les bloquer. Avec Netfilter, on peut bloquer une partie de ces requêtes et donc les attaques du script cité plus haut avec :

iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'

Mais cela n'empêche pas tout : comme le filtre ci-dessus travaille avec des offsets fixes, il peut être contourné, par exemple, si l'attaquant rajoute des options dans le paquet. (La difficulté à écrire des règles u32 pour le DNS a été abordée dans un autre article.)

Si vous voulez capturer les requêtes DNS de mise à jour dynamique, pour analyse ultérieure, et que vous utiliser dnscap, une requête comme :

# dnscap -w updates -mu -i eth0

conviendra (-mu ne garde que les requêtes d'opcode UPDATE). Si vous voulez juste les voir et pas les enregistrer sur disque, remplacez -w updates par -g.


L'article seul

L'AS 13214 perd à nouveau la boussole

Première rédaction de cet article le 28 juillet 2009


Le protocole BGP est une source de distraction sans fin pour les administrateurs réseaux de l'Internet. Comme n'importe lequel des dizaines de milliers d'opérateurs Internet de la planète peut annoncer les routes qu'il veut, des incidents se produisent régulièrement. La plupart du temps, les différents filtres limitant la casse, puis les systèmes immunitaires de l'Internet empêchent ces incidents de faire la une des journaux. Ce matin, c'est l'AS 13214 qui se signale à l'attention de tous, pour la deuxième fois en trois mois.

Vers 08h30 UTC, les utilisateurs du système d'alarme BGP Cyclops reçoivent des messages inquiétants annonçant qu'un autre AS que leur leur annonce leurs préfixes IP :

Alert ID:                     5078076
Alert type:                   origin change
Monitored ASN,prefix:         192.134.4.0/22
Date:                         2009-07-28 08:30:26 UTC
No. monitors:                 1
Announced prefix:             192.134.4.0/22
Announced ASPATH:             48285 13214

En clair, l'AS 13214 (DCP, en Suède) annonce des préfixes IP qui ne lui appartiennent pas, et ce en mettant son propre numéro d'AS dans le chemin BGP (ASPATH, qu'il faut lire de droite à gauche, le premier AS est le plus à droite). La lecture de la liste de diffusion Nanog montre vite que le problème est mondial : l'AS 13214 est en train d'annoncer toute la table de routage de l'Internet !

Le plus drôle est que le même AS avait fait la même bétise deux mois plus tôt.

Mais, pas de panique : un seul des moniteurs de Cyclops a vu le problème (la ligne No. monitors: 1). Cela veut donc dire qu'il ne s'est pas propagé loin. Les autres systèmes d'alarme comme BGPmon n'ont rien vu. Probablement, les filtres ont fonctionné dans la plupart des endroits.

Normalement, lorsqu'on échange en BGP avec quelqu'un, on n'accepte pas n'importe quoi de lui (sauf s'il s'agit de son fournisseur de transit). Au minimum, on limite le nombre de préfixes. Si on peut, on liste les préfixes que le pair BGP est autorisé à annoncer. Pourquoi Robtex, l'AS 48285 qui a relayé l'annonce erronée, ne le faisait-il pas, surtout après l'incident de Mai ? Parce que ce n'est pas facile : DCP est le fournisseur de transit de Robtex et on ne peut pas filtrer les annonces de son fournisseur, on est obligés de lui faire confiance.


L'article seul

Cryptographie en Python

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


Quant on fait de la programmation réseau, on a souvent besoin d'utiliser de la cryptographie. En effet, par défaut, les méchants qui sont situés entre les deux machines qui communiquent peuvent écouter tout le trafic et apprendre ainsi des secrets qu'on aurait préféré garder pour soi. Comment fait-on de la cryptographie en Python ?


L'article complet

« Courriel » n'est pas un bon mot pour désigner le courrier électronique

Première rédaction de cet article le 22 juillet 2009


Pour désigner le courrier électronique, le terme « officiel » en France qui doit, par exemple, être systématiquement employé dans les appels d'offres publics, est « courriel » (JO du 20 juin 2003). Ce terme est rejeté par ceux qui préfèrent utilisent des mots anglais comme mail ou email, mais aussi par ceux qui trouvent ce néologisme inutile et même néfaste.

Quel est le problème avec « courriel » ? C'est qu'il rend le medium explicite, au lieu de se concentrer sur le message. Si je dis « Jeanne m'a envoyé un message », quelle importance que celui-ci ait été un message papier ou numérique ? C'est le contenu qui compte. La plupart du temps, écrire « Jeanne m'a envoyé un courriel » surspécifie en donnant des détails inutiles.

Pour les rares cas où le medium utilisé est important (par exemple « PGP permet de sécuriser le courrier électronique »), autant utiliser le terme complet. Vouloir utiliser la forme condensée « courriel » ne vaut pas mieux que de le dire en anglais puisque ce mode de construction des mots, très courant aux États-Unis, ne l'est pas en France.

Si on veut être tout à fait précis, on peut aussi noter que « courrier électronique » n'est pas tout à fait rigoureux, c'est la numérisation qui compte, pas le fait qu'elle se fasse aujourd'hui surtout avec des électrons. Mais parler de « courrier numérique » serait sans doute déroutant pour beaucoup. La langue n'est pas toujours rigoureuse en matière d'étymologie.

Je continuerai donc à dire « Le RFC 6532 normalise un moyen de mettre des caractères Unicode dans les adresses de courrier électronique » ou bien « Pour l'activité professionnelle, le courrier est en général plus efficace que le téléphone car il laisse une trace et oblige à réfléchir ».

Merci à Fil pour ses pertinentes remarques.


L'article seul

De la Lune à Arpanet

Première rédaction de cet article le 21 juillet 2009


Hier, c'était le quarantième anniversaire du premier débarquement humain sur la Lune, un gigantesque projet états-unien, formidablement mis en scène, entre autre pour faire oublier la guerre du Viêt Nam. Quatre mois plus tard, et bien plus discrètement, le réseau Arpanet, le futur Internet faisait ses débuts, il comptait alors quatre ordinateurs.

Par rapport au formidable déploiement de moyens de communication qui avait été mis en place pour la mission Apollo 11, Arpanet a eu des débuts très discrets. Pourtant, c'était aussi un projet à forte composante militaire, il avait également nécessité des dépenses étatiques massives. Mais il n'y avait pas de jolies images à filmer...

Aujourd'hui, les missions Apollo n'ont laissé aucune trace. On n'est jamais revenu sur la Lune et on n'a pas fait un pas supplémentaire vers Mars. Les navettes spatiales, autobus de l'espace, ont remplacé les Saturn V puis ont disparu à leur tour. Le voyage de Collins, Aldrin et Armstrong n'a eu aucune influence sur la vie quotidienne quarante ans après.

Arpanet a connu un sort très différent : quarante ans après, et pas mal de milliards de dollars plus tard, son descendant direct, l'Internet, est dans la vie de tous. Des grands-mères de l'Iowa aux ingénieurs de Shanghai en passant par les associations de Salvador de Bahia, toute la planète l'utilise, tous les jours et en dépend désormais beaucoup.

Quel meilleur exemple de la difficulté de la prospective et de la nécessité de se méfier du cirque médiatique ? Quel journaliste ou politicien avait prévu le succès du réseau ?


L'article seul

Install Ubuntu / Linux on a HP / Compaq CQ71 - 103EF

First publication of this article on 21 July 2009
Last update on of 17 September 2010


I installed the operating system Ubuntu on a Compaq Presario CQ71 - 103EF laptop machine. This article is to share the information that I obtained during the process.

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


L'article complet

Extraire une partie d'un dépôt Subversion alors qu'il y a eu un renommage

Première rédaction de cet article le 21 juillet 2009


Le VCS Subversion offre la possibilité d'exporter une partie d'un dépôt (avec svndumpfilter) mais il offre aussi la possibilité de renommer, de déplacer un sous-arbre d'un point du dépôt à un autre, et ces deux fonctions s'entendent parfois mal.

Le mécanisme normal de filtrage, avec svndumpfilter, est bien documenté. On exporte le dépôt avec svnadmin dump, on le filtre avec svndumpfilter et hop :

% svnadmin dump /my/repository | svndumpfilter include /quizzie > quizzie.svn

et on a un dump quizzie.svn qui ne contient que le sous-arbre /quizzie. Mais la documentation prévient bien que cela peut entraîner des problèmes : « It is possible that at some point in the lifetime of your repository, you might have copied a file or directory from some location that svndumpfilter is excluding, to a location that it is including. In order to make the dump data self-sufficient, svndumpfilter needs to still show the addition of the new path - including the contents of any files created by the copy - and not represent that addition as a copy from a source that won't exist in your filtered dump data stream. » Bref, le filtrage peut aboutir à exclure des moments de l'histoire, sans lesquels on ne peut pas reconstituer un fil cohérent. Au moment de la restauration, on aura des problèmes comme :

% svnadmin load /my/new-repository < quizzie.svn
<<< Started new transaction, based on original revision 7
svnadmin: File not found: transaction '8-8', path 'quizzie/new-name/bar/myfile'
     * editing path : quizzie/new-name/bar/myfile ...

Prenons l'exemple suivant, tiré d'une expérience réelle : un répertoire a été déplacé de /foo/old-name en /other/new-name. On veut exporter le dépôt pour le passer à quelqu'un mais, comme le dépôt contient à la fois des choses privées et des choses publiques, on veut filtrer et ne garder que /other/new-name/bar (et son ancien nom, /foo/old-name/bar). Ce faisant, la révision où a été faite le renommage sera exclue (car située plus haut dans l'arbre). Cela produira l'erreur ci-dessus à la restauration (vous pouvez essayer, avec le script subversion-filtering-problem.sh).

Il existe plusieurs solutions à ce problème. Par exemple, il semble que des alternatives à svndumpfilter comme svndumpfilter2 ou svndumpfilter3 permettent d'éviter ce problème. Je n'ai pas eu de succès avec ces programmes (et je note que, dans les deux cas, passer un nom de répertoire inexistant ne produit aucune erreur, ce qui semble indiquer que le programmeur ne teste pas ce que fait son programme).

Ma solution a donc été de trouver la révision où est faite le renommage, de dumper (en filtrant) jusqu'à cette révision (exclue), de dumper (avec l'option --incremental) à partir de cette révision (également exclue) et, au rechargement, de faire un svn rename moi-même. La version modifiée du script, subversion-filtering-solution.sh, fait cela.

À noter que cette question a été discutée sur Server Fault. Vous y trouverez peut-être davantage de détails.


L'article seul

RFC 5598: Internet Mail Architecture

Date de publication du RFC : Juillet 2009
Auteur(s) du RFC : D. Crocker (Brandenburg Internetworking)
Pour information
Première rédaction de cet article le 20 juillet 2009


Le courrier électronique est aujourd'hui une des principales applications de l'Internet. Mais, bien qu'il existe plusieurs RFC normalisant ses composantes techniques (comme les RFC 5321 et RFC 5322), aucun document « officiel » ne décrivait l'architecture du courrier, ses principales composantes, leurs relations, et les termes à utiliser pour les désigner. C'est le rôle de ce nouveau RFC, dont le développement souvent douloureux a pris près de cinq ans.

Depuis bientôt trente ans qu'il existe, le courrier électronique a connu des hauts et des bas dans les médias. Très souvent, sa fin proche a été proclamée, au profit, par exemple, de la messagerie instantanée. On a même vu des discours à la limite du racisme, affirmant que le courrier électronique n'avait pas de sens en dehors de l'Europe parce que les africains seraient éternellement voués à la culture orale. Mais, malgré la concurrence de nouveaux gadgets qui brillent (le plus récent étant Google Wave), malgré les assauts du spam, malgré les réglements intérieurs décourageant l'usage du courrier électronique (comme je l'ai vu récemment dans une entreprise dont 100 % de l'activité concerne l'Internet), le traditionnel courrier marche encore très bien. Ce n'était donc pas inutile de documenter son architecture, tâche à laquelle s'est attelée un vétéran, Dave Crocker.

Le courrier s'étant développé de manière relativement informelle, sans architecture pré-définie (au contraire du défunt X.400, qui avait tenté une approche de haut en bas), même le vocabulaire n'est pas normalisé. La différence entre forwarding et redirecting n'a jamais ainsi été clairement expliquée, et c'est encore pire si on veut écrire en français. Résultat, les noms des menus dans les logiciels ne sont pas cohérents d'un logiciel à l'autre, et les discussions techniques sont souvent lentes et pénibles car il n'y a pas d'accord sur les concepts de base. C'est ainsi que le groupe de travail Marid avait perdu beaucoup de temps dans des débats byzantins.

Le RFC 5598 va donc souvent créer un vocabulaire nouveau, qui déroutera tout le monde.

Autre problème lorsqu'il faut décrire l'architecture du courrier : il a beaucoup évolué depuis le début. Comme un service de messagerie sans utilisateurs ne sert à rien, chaque changement s'est fait en maintenant la compatibilité et le résultat n'est donc pas toujours très organisé.

Ce RFC 5598 ne vise pas à améliorer le courrier, uniquement à décrire comment il fonctionne actuellement. Il résume le fonctionnement du courrier (section 1). Celui-ci repose sur trois séries de normes :

  • Le protocole SMTP (aujourd'hui normalisé dans le RFC 5321) qui décrit le moyen de faire circuler un message sur l'Internet,
  • Le format des messages, dit souvent « RFC 822 » (aujourd'hui normalisé dans le RFC 5322) et que notre RFC nomme IMF (Internet Message Format),
  • Une extension à ce format, MIME (aujourd'hui normalisé dans le RFC 2045), qui permet de gérer du texte dans différents jeux de caractères et des contenus multimédias.

La connaissance de l'histoire est souvent utile pour comprendre l'existant, d'autant plus que l'Internet repose largement sur le respect de la base installée : pas question de supprimer tout à coup un service utile. La section 1.1 retrace donc les (très) grandes lignes de l'évolution du courrier. Celui-ci a eu son premier document d'architecture avec le RFC 1506, qui empruntait à X.400 le vocabulaire de MUA et MTA. L'ensemble des MTA formait le MHS (Message Handling System). Mais les piliers que sont le protocole SMTP, le format IMF des messages, et le format des adresses avec le fameux @, sont restés très constants. Autre constante, la séparation entre le contenu du message et les informations de contrôle, qui permettent son acheminement.

Sont également restés les principes suivants :

  • Adressage global (stephane+blog@bortzmeyer.org fonctionne partout et désigne toujours la même boîte aux lettres),
  • Échange asynchrone, la grosse différence entre le courrier et la plupart des autres modes de communication,
  • Absence d'accord préalable entre les acteurs. Un étudiant chilien peut écrire à un chercheur d'une entreprise indienne, sans qu'aucun contrat n'aie été signé, ou aucun contact pris précédemment. (C'est un des points les plus attaqués par ceux qui, comme le MAAWG, voudraient limiter le courrier à un cartel de gros opérateurs.) Mais le RFC note que ce point est le principal facteur de succès du courrier électronique et qu'il doit être maintenu.

Autre méta-question, quel est le rôle d'une architecture ? La section 1.2 la voit comme la connexion entre un service rendu à l'utilisateur et le(s) protocole(s) qui mettent en œuvre ce service. C'est l'architecture qui permet de s'y retrouver dans les protocoles utilisés. Elle est donc d'un plus haut niveau que les protocoles. Mais attention, le protocole ne respecte pas forcément complètement l'architecture (surtout comme lorsque, comme ici, il a été développé bien avant...) et ce n'est pas forcément un défaut, l'architecture doit être une aide, pas un réglement à respecter aveuglément.

Bien, maintenant que les bases sont posées, chaque section va parler d'une classe d'objets différente. La section 2 commence avec les rôles des différents acteurs (actor roles). Quels sont les rôles joués ici ?

D'abord, il y a les utilisateurs (user actors), expliqués en section 2.1. Ce ne sont pas forcément des humains, il existe aussi des programmes qui écrivent, traitent et lisent les messages. Il y a quatre sortes d'utilisateurs (le RFC contient un diagramme de leurs interactions, en page 10) :

  • les auteurs,
  • les destinataires,
  • les répondeurs (return handlers),
  • les intermédiaires (mediators).

L'auteur est responsable du contenu du message, qu'il confie au MHS pour que celui-ci l'achemine au destinataire. Celui-ci lit le message. S'il y répond, créant un nouveau message, il devient Auteur et le précédent auteur devient Destinataire de ce nouveau message. Les répondeurs se chargent de générer des réponses lors d'évènements comme une adresse de destination inexistante (dans ce cas, l'auteur reçoit une réponse qui ne vient pas du destinataire).

Plus complexe, l'intermédiaire (section 2.1.4) va recevoir le message et le réémettre à des destinataires différents, parfois après modification. Un intermédiaire typique est un gestionnaire de liste de diffusion. Le RFC suggère une bonne définition pour un intermédiaire : il envoie des messages donc il est Auteur, mais les Destinataires de ces messages ne le considèrent pas comme tel.

Le second rôle est celui des serveurs (MHS actors), vus en section 2.2. Ce sont les programmes qui vont, collectivement, mettre en œuvre ce que les utilisateurs perçoivent comme une entité unique, le MHS (Message Handling System). La page 13 contient un joli diagramme de leurs interactions. Il y a :

  • l'origine (originator), le premier serveur qui reçoit le message, et a notamment pour travail de s'assurer de sa validité,
  • le relais (relay) qui reçoit le message d'un serveur et le transmet à un autre (un message passe souvent par plusieurs relais, le courrier n'étant pas implémenté directement entre deux machines). Suivant le RFC 2505, le relais ajoutera une trace dans les en-têtes des messages (l'en-tête Received:). Le relais travaille à un niveau en dessous de l'Intermédiaire, mais un niveau au dessus des routeurs IP,
  • le récepteur (receiver), le dernier serveur à traiter le message,
  • la passerelle (gateway), un serveur un peu particulier, qui tient de l'Intermédiaire et du Relais (section 2.2.3). Son travail est de faire passer le courrier vers des mondes utilisant d'autres types de courrier, par exemple un autre format que l'IMF du RFC 5322.

Après les Utilisateurs et les Serveurs, un autre rôle important est celui des Organisations (administrative actors, section 2.3). Plus formellement, on les nomme ADMD (ADministrative Management Domain). C'est au sein d'un ADMD que se prennent les décisions et que sont appliquées des politiques, par exemple des choix en terme de lutte anti-spam. Au niveau de l'ensemble de l'Internet, il n'y a pas unité de décision, il n'est pas envisageable de demander, par exemple, un déploiement généralisé de telle ou telle technique. En revanche, au sein d'un ADMD, de telles décisions sont possibles (c'est donc au courrier ce qu'un AS est au routage.) Beaucoup de décisions, par exemple en matière de filtrage, dépendent de si le message est interne à l'ADMD ou pas.

Le RFC 5598 discerne plusieurs sortes d'ADMD :

  • Ceux du bord (Edge),
  • Les consommateurs (Consumer),
  • Ceux de transit (Transit).

Un dessin page 17 illustre leurs relations. Lors de l'envoi d'un message, la transmission se fait en général entre les deux ADMD de bord, directement (à ce niveau d'analyse ; à un niveau plus bas, il y a plusieurs MTA). Parfois, un ou plusieurs ADMD de transit traitent le message. Parfois encore, l'ADMD du bord garde le message pour l'ADMD consommateur, comme lorsqu'il s'agit d'un accès Web aux boîtes aux lettres. (Voir aussi le RFC 5068.)

Pour désigner toutes les entités qui apparaissent dans le courrier, il faut des identificateurs. Il existe plusieurs identités possibles, exposées en section 3 :

  • Les boîtes aux lettres, identifiées par une adresse de courrier comme Jean.Durand@comptabilite.monentreprise.example. La partie à gauche du @ doit être considérée comme opaque par la plupart des programmes qui manipulent le courrier, surtout lorsqu'ils n'ont pas lu la norme. Elle ne doit être interprétée qu'à la destination finale. Les conventions comme les adresses incluant un + sont purement locales et ne doivent pas être utilisées par les autres acteurs. (Un autre exemple de telles conventions est le RFC 3192 avec ses adresses de fax comme FAX=+12027653000/T33S=1387@fax.example.org.) Aujourd'hui, ces adresses sont utilisées bien au delà du courrier, par exemple, bien des sites Web utilisent ces adresses comme identifiants pour leurs clients enregistrés (c'est le cas d'Amazon, par exemple).
  • Une autre identité est le nom de domaine, la partie à droite du @ dans une adresse. Il suit les règles générales des noms de domaine (plusieurs composants séparés par des points, etc).
  • L'identificateur du message (section 3.4.1). Chaque message a un identificateur unique, stocké dans le champ Message-ID: et dont la forme syntaxique ressemble à une adresse de courrier (mais ne l'est pas). Il est fixé par l'origine. Un exemple est <alpine.BSF.2.00.0907081901140.79224@in1.dns-oarc.net>. Cet identificateur sert à désigner un message sans ambiguité. C'est par exemple lui qui est utilisé comme référence dans les fils de discussion. Une question intéressante est de savoir à partir de quand affecter un nouvel identificateur lorsque le message est modifié. Le RFC ne fournit pas de règles strictes mais suggère que, si le changement ne met en jeu que la forme (par exemple un nouvel encodage), alors, il ne s'agit pas d'un nouveau message et on ne devrait pas mettre un nouvel identificateur. Mais il y a bien d'autres cas plus douteux. Le problème est analogue à celui qui se pose pour d'autres identificateurs comme les ISBN. Avec ces derniers, on constate en pratique que les éditeurs ont des pratiques très différentes quant à la réutilisation d'un ISBN.

Notre RFC se déplace ensuite vers des entités plus concrètes, les programmes serveurs (section 4). Illustrés page 24, leur présentation nécessite d'abord un petit détour sur le format des messages (section 4.1). Il y a le message proprement dit, normalisé dans le RFC 5322. Et il y a des métadonnées, couramment appelées l'enveloppe (section 4.1.1) et qui servent au MHS pour assurer une distribution correcte. Les informations de l'enveloppe sont souvent enregistrées dans le message, pour analyse et déboguage a posteriori (c'est le cas des champs Received:).

Dans le message lui-même, il y a deux parties, les en-têtes (section 4.1.2) et le corps (section 4.1.3). Les en-têtes (comme From:, Date: ou Subject:) sont structurées, pour permettre un traitement automatique, par exemple par Sieve. La liste des champs est décrite dans le RFC 4021 et on peut la modifier suivant les procédures du RFC 3864. Le corps du message n'est pas normalement structuré (mais la norme MIME lui a donné un certaine structure). Les informations de l'en-tête ne coïncident pas forcément avec celles de l'enveloppe (par exemple, si un message est envoyé à une liste de diffusion, le champ To: de l'en-tête indique la liste, le paramètre RCPT TO de l'enveloppe indiquera un destinataire individuel).

Enfin, il existe aussi des « méta-messages », automatiquement générés et analysables par un programme comme les MSN (Message Disposition Notification) des RFC 3297 et RFC 8098, ou comme les DSN (Delivery Status Notification) du RFC 3461, qui sont typiquement utilisés comme avis de non-remise d'un message.

Pour toutes ces parties d'un message, il existe des identités différentes. Une question aussi simple que « Quel est l'auteur du message ? » a ainsi plusieurs réponses possibles, toutes légitimes. Ce point est souvent mal compris par les utilisateurs, par exemple lorsqu'une technique d'authentification est utilisée. Qu'authentifie t-elle exactement ? Pas forcément ce que l'utilisateur croit...

La section 4.1.4 fait la liste de ces identités, en indiquant qui la met dans le message. Par exemple, RFC5322.From est le champ From: de l'en-tête, et est mis par l'Auteur. RFC5321.EHLO est le nom qu'annonce un serveur SMTP à ses pairs et est mis par l'Origine (MSA ou MTA). RFC2919.ListID est l'identité d'une liste de diffusion (cf. RFC 2919) et est mise par l'Intermédiaire. Dernier exemple (mais la liste du RFC est bien plus longue) : RFC791.SourceAddr est l'adresse IPv4 de la machine cliente (certains protocoles, comme SPFRFC 7208, l'utilisent).

Après cela, la section 4.2 peut commencer à lister les programmes serveurs de courrier. On y trouve le MUA (Mail User Agent), celui qui interagit directement avec l'utilisateur (Outlook, mutt, Thunderbird, etc), le MSA (Message Submission Agent, le premier serveur à recevoir le courrier), le MTA (Mail Transfer Agent), ce que l'utilisateur ne voit pas, Courier, Exchange, Postfix, etc)... Pour chacun d'eux, le RFC indique les identités qui sont pertinentes pour ce serveur. Par exemple, le MSA et le MTA manipulent des identités du RFC 5321, ce qui n'est pas le cas du MUA.

Cette section couvre en détail leurs fonctions. Par exemple, le MTA a droit à une section 4.3.2 qui précise son fonctionnement de « routeur de niveau 7 ». Comme tous les routeurs, il a besoin de recevoir l'information sur les routes existantes et, sur l'Internet, cela se fait essentiellement via les enregistrements MX du DNS.

Moins connu que le MUA et le MTA, le MDA fait l'objet de la section 4.3.3. Le Mail Delivery Agent est chargé du passage du message depuis le MHS jusqu'à la boîte aux lettres de l'utilisateur. Le courrier est reçu via le protocole LMTP (RFC 2033) ou bien par un mécanisme non normalisé (par exemple, sur Unix, via un appel d'un exécutable et transmission du courrier sur l'entrée standard de celui-ci). Parmi les plus connus, dans le monde Unix, procmail ou le local de Postfix.

L'acheminement du courrier suit en général un modèle de push où l'emetteur envoie le message vers un destinataire supposé toujours prêt. Mais le modèle du courrier permet également un fonctionnement en pull, avec des protocoles comme ceux du RFC 1985 ou du RFC 2645. (Les protocoles comme UUCP étant traités via un système de passerelle, cf. section 5.4). De même, une fois le message délivré, le destinataire peut y accéder selon un mode pull, avec POP (RFC 1939) ou IMAP (RFC 3501).

Comme tout ce RFC 5598, cette section parle d'architecture, pas de mise en œuvre. Dans la pratique, une implémentation donnée de cette architecture peut répartir ses serveurs de façon assez différente (section 4.5). Par exemple, il est fréquent que les fonctions de MSA et de MTA soient fusionnées dans le même serveur (et, avec Postfix, il est même difficile de séparer les deux fonctions).

La complexité des fonctions assurées par les intermédiaires (mediators) méritait bien une section entière, la 5. Contrairement au MTA, transporteur neutre, qui doit transmettre un message avec le minimum d'altérations, l'intermédiaire a le droit de réécrire partiellement le message. Par contre, contrairement au MUA, l'intermédiaire n'est pas censé composer de messages nouveaux, et doit toujours partir d'un message existant dont il préserve le sens général. Le RFC cite plusieurs exemples d'intermédiaires :

  • Les alias (comme gérés par les fichiers ~/.forward de Postfix et sendmail). Le destinataire décide alors de renvoyer le message à une nouvelle adresse (section 5.1). La fonction est typiquement mise en œuvre par le MDA. Le message est inchangé mais l'enveloppe indique désormais un nouveau destinataire (donc, l'identité RFC5322.To ne change pas mais RFC5321.RcptTo oui.) À noter que l'émetteur (RFC522.From ou bien RFC5321.MailFrom) n'est pas affecté donc les messages d'erreur n'iront pas au responsable de l'alias, ce qui en rend le déboguage très difficile. On peut contester ce classement des alias parmi les intermédiaires, puisque le message n'est pas modifié, mais notre RFC décide que le changement de destinataire est un changement de sémantique suffisant pour que cette fonction ne soit pas considérée comme faisant partie du MTA.
  • Les listes de diffusion sont sans doute l'exemple le plus connu d'intermédiaire. Elles font l'objet de la section 5.3. Recevant un message, elles le retransmettent à plusieurs destinataires, souvent après de légères modifications (comme l'ajout d'instructions de désabonnement ou la suppression de certaines pièces jointes). Les RFC 2369 et RFC 2919 créent des identités spécifiques aux listes de diffusion, qu'on retrouve dans les en-têtes (comme List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>). Beaucoup de listes de diffusion ajoutent également un champ Reply-To:, ce qui est en général une très mauvaise idée.
  • Un autre type d'intermédiaire est devenu plus rare avec le temps. À une époque, il y avait plusieurs systèmes de courrier, en général reposant sur des protocoles privés, et que certaines entreprises déployaient. C'était bien sûr ridicule (imagine t-on, sauf pour les militaires, de déployer un système de téléphonie fermé, reposant sur des protocoles spécifiques ?) mais, de la fin des années 1970 au début des années 1990, la pression idéologique était forte pour rejeter les protocoles Internet, gratuitement accessibles donc pas sérieux. Comme l'intérêt de tout système de courrier est dans le fait qu'on peut joindre des personnes différentes, il a donc fallu développer des passerelles (gateways). À une époque, la seule façon d'envoyer du courrier entre les deux systèmes de messagerie privés d'IBM était via une passerelle Internet... Les passerelles sont exposées en section 5.4. Comme, par définition, elles communiquement avec un monde non-Internet, une réécriture du message, parfois avec perte d'informations, est inévitable. Tout l'art de la conception d'une passerelle est donc de minimiser ces pertes. Il est amusant de noter qu'il existe des passerelles normalisées pour des protocoles comme le fax (RFC 4143) ou la voix (RFC 3801), ce que fait aujourd'hui, par exemple, la fonction répondeur téléphonique de la Freebox).
  • Un autre cas intéressant d'intermédiaire est le filtre (section 5.5), qui supprime des parties du message, par exemple parce qu'elles contiennent un virus MS-Windows (un logiciel comme Amavis permet de créer de tels filtres).

Par rapport aux débuts du courrier électronique, un des grands changements a concerné la sécurité, un sujet devenu bien plus important aujourd'hui. D'où la section 6.1, qui lui est consacrée. Elle rappelle que le MHS n'est pas obligatoirement sécurisé. Son but est en effet de permettre l'échange de courrier avec le moins d'embêtements possibles. Sans cette propriété, le courrier électronique n'aurait jamais décollé. Mais elle a aussi été exploitée par des méchants comme les spammeurs. Cependant, il existe de nombreuses techniques pour sécuriser le courrier, par exemple TLS (RFC 3207) pour sécuriser la communication entre deux serveurs, l'authentification SMTP (RFC 4954) pour s'assurer de l'identité d'un utilisateur ou encore PGP (RFC 4880) pour protéger le message de bout en bout.

Enfin, dernier gros morceau, l'internationalisation, en section 6.2. Si les RFC de base du courrier supposent uniquement l'utilisation d'ASCII, plusieurs extensions ont permis d'avoir aujourd'hui un courrier complètement internationalisé :

  • MIME (RFC 2045, RFC 2046, RFC 2047 et RFC 2049) a permis d'utiliser d'autres caractères que ceux d'ASCII dans le corps des messages et, via un surencodage, dans les en-têtes.
  • Le RFC 1652 a permis de transmettre des caractères de 8 bits (extension SMTP 8BITMIME).
  • Une série de RFC a permis l'utilisation d'adresses de courrier non limitées à l'ASCII.

Merci à Olivier Miakinen pour ses nombreuses corrections.


Téléchargez le RFC 5598


L'article seul

Super User, un site de Q&A pour utilisateurs

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


Jeff Atwood a annoncé le 14 juillet le lancement de la version « beta publique » de Super User, le troisième site de Q&A de la trilogie commencée par les fameux Stack Overflow et Server Fault. Super User est un site Web de questions & réponses pour utilisateurs des systèmes informatiques, avec système de réputation.

Comme pour ses deux prédécesseurs, Super User repose sur le principe que toute personne qui veut écrire doit s'authentifier (en OpenID, donc, http://www.bortzmeyer.org/ pour moi) et que les actions de cette personne (poser une question, proposer une réponse) lui vaudront petit à petit une réputation, déterminée par les votes des autres utilisateurs. Les simples lecteurs peuvent, eux, être anonymes.

Les réponses aux questions sont classées, non pas dans l'ordre chronologique comme sur un blog mais dans l'ordre décroissant des votes, ce qui permet à l'information la plus reconnue d'émerger hors du bruit. C'est un gros avantage, par exemple par rapport aux traditionnelles listes de diffusion où il faut faire un gros effort de synthèse lorsqu'on lit un fil riche, rempli de messages parfois incomplets ou contradictoires.

Pour ceux que ça intéresse, ma réputation est de 131 ce qui me permet, par exemple, de voter contre une contribution (il faut une réputation de 15 pour voter pour). À 250, je pourrai voter sur la fermeture ou la réouverture de mes propres questions et à 500, je pourrais réétiqueter les questions des autres.

Comme il est peu probable qu'un lecteur soit intéressé par tous les logiciels possibles, Super User permet d'étiquetter les questions et chercher ensuite selon ces étiquettes. Ainsi, http://superuser.com/questions/tagged/bittorrent donnera accès aux questions sur le système de partage de fichiers pair-à-pair BitTorrent et http://superuser.com/questions/tagged/firefox aux questions sur le navigateur Web Firefox.

Super User sera t-il un succès ? Ce n'est pas évident à prévoir. Stack Overflow a été un rapide succès car les programmeurs étaient très demandeurs d'informations (et que les créateurs de ce site étaient eux-même des gourous connus dans ce monde). Server Fault semble avoir pris moins vite, peut-être parce que c'est une autre communauté, ou bien parce que les administrateurs système avaient d'autres sources d'informations. Les utilisateurs ordinaires sont-ils prêts à se lancer dans un site sérieux et de qualité ? Contrairement aux programmeurs et aux administrateurs système, ce ne sont pas forcément des professionnels passionnés.


L'article seul

github, un nouveau site d'hébergement pour le développement logiciel

Première rédaction de cet article le 17 juillet 2009
Dernière mise à jour le 20 juillet 2009


github est un hébergeur de projets logiciels, comme SourceForge, mais bâti autour du VCS git (celui écrit par Linus Torvalds et utilisé pour le noyau Linux). Il permet d'avoir un compte gratuitement (pour les « petits » projets) et héberge, outre le VCS, un Wiki et quelques autres outils comme un système de veille permettant de surveiller d'autres projets.

Très perfectionné et très populaire, github a attiré beaucoup de projets libres en peu de temps. Par exemple, je viens de passer le développement du petit programme query-loc sur ce site.

Pour l'importation originale d'un projet, on peut utiliser son propre dépôt git (puisque git est un VCS distribué). S'il est public, github sait aller le chercher (pull) et le cloner. Sinon, on peut le faire soi-même (push) :

git remote add origin git@github.com:MYNAME/MYPROJECT.git
git push origin master

Si le dépôt était originellement géré par Subversion, deux solutions :

  • Le convertir soi-même (git-svn clone svn+ssh://svn.example.org/MYPROJECT, git-svn est distribué avec git) et, ensuite, on a un dépôt git que github peut tirer ou qu'on peut pousser.
  • Demander à github de le faire lui-même, si le dépôt Subversion est public. Attention, c'est fait de manière asynchrone et cela peut prendre du temps (un courrier vous prévient à la fin). Ça a bien marché à partir du dépôt d'echoping à Sourceforge pour faire un dépôt git expérimental. Attention toutefois, l'importation n'est que dans un seul sens, si on veut continuer à maintenir synchrones les dépôts, il faut le faire soi-même.

La plupart des projets hébergés par github sont libres mais pas tous. Le logiciel de github lui-même n'est pas libre aussi certains préfèrent utiliser Gitorious (que je n'ai pas testé).

Merci à Pablo Rauzy pour ses corrections et remarques. Quelques articles intéressants : « De subversion à git », « Subversion to Git » ou « GitHub issues ».


L'article seul

Le déploiement des résolveurs DNS menteurs

Première rédaction de cet article le 16 juillet 2009


L'annonce récente par Comcast du début du déploiement de résolveurs DNS menteurs pour ses clients a remis sur le devant de la scène une technique que, malheureusement, beaucoup de FAI déploient. Mais, d'abord, il faut bien comprendre de quoi il s'agit.

Comme à chaque nouvelle publication, il y a de nombreux débats sur cette mesure, par exemple sur Slashdot, sur DSLreports, ou sur la liste NNsquad. Mais ces débats ne sont pas toujours bien informés et mélangent parfois plusieurs choses. D'abord, qu'est-ce qu'un résolveur DNS menteur ? L'abonné typique d'un FAI utilise les résolveurs DNS de son FAI. Il connait leurs adresses IP via des protocoles comme DHCP. En général, à l'heure actuelle, la plupart des FAI laissent l'utilisateur libre d'utiliser d'autres résolveurs (dans le futur, cela pourrait changer, avec le blocage du port 53). Mais, évidemment, l'écrasante majorité des utilisateurs ne connait pas le DNS et n'ose pas changer les réglages et tombe donc sur les résolveurs du FAI. Il est donc tentant pour celui-ci de violer la neutralité du réseau et d'utiliser ces résolveurs pour rabattre du trafic vers ses serveurs, par exemple pour y installer de la publicité. (Certains FAI prétendent mettre en place des DNS menteurs pour « le bien des clients » alors qu'en réalité, ils sont poussés par des intermédiaires qui leur proposent de « monétiser » l'audience du site Web ainsi pointé, comme l'a bien expliqué le directeur technique de Free). C'est le rôle du résolveur DNS menteur, qui est typiquement chargé, lorsqu'il reçoit un code NXDOMAIN (No Such Domain, ce nom n'existe pas) de le remplacer par le code NOERROR et d'ajouter une adresse IP où écoute un serveur HTTP qui sert de la publicité.

Comcast n'est pas, et de loin, le seul FAI à faire cela. Aux États-Unis, RoadRunner le fait déjà (et plusieurs autres) et, en France, cela est apparemment fait par SFR. Je dis « apparemment » car, contrairement à Comcast, la plupart des FAI ne s'en vantent pas et n'annoncent jamais qu'ils procèdent à de telles manœuvres. Il est donc difficile de vérifier ces informations. Ignorant le RFC 4084, ils n'informent ni leurs clients, ni leurs potentiels futurs clients (essayez, avant de choisir un FAI, de connaitre leur politique en matière de réécriture DNS. Vous n'y arriverez pas.) Une fois que vous avez signé, vous pouvez toujours tester avec un client DNS comme dig. Si dig A nexistesurementpas.bortzmeyer.org affiche autre chose que status: NXDOMAIN, c'est que votre résolveur vous ment.

Cette pratique pose de nombreux problèmes techniques et politiques. Je ne les cite pas tous ici (un bon nombre ont été déjà notés, par exemple dans le document 32 du SSAC). Mais les principaux problèmes techniques sont :

  • Cette réécriture est conçue uniquement pour un client final qui utilise un navigateur Web. Les autres protocoles, ou bien les clients HTTP non-Web (par exemple les clients REST) récupèrent des adresses qui, au mieux ne leur servent à rien, au pire les déroutent.
  • Ce mensonge empêche le déploiement de toutes les techniques de sécurité du DNS de bout en bout comme DNSSEC (RFC 4033).
  • Les applications qui testent si une entrée est présente dans le DNS (par exemple les listes noires DNS ou simplement les programmes de détection de liens Web morts) ne peuvent plus fonctionner.

Mais les principaux problèmes que pose cette technique sont politiques :

  • Le titulaire d'un domaine en perd le contrôle puisque le résolveur menteur va prétendre que xxxxx.wikipedia.org existe, malgré le fait que le gérant de wikipedia.org ne l'ai pas créé. C'est donc un coup de force du gérant du résolveur DNS (le FAI) contre celui du domaine.
  • Le fait qu'un intermédiaire technique, le FAI, se permette de modifier les données en transit par son système est une violation de la neutralité du réseau, qui en appelle d'autres. Si on abandonne le principe du « transporteur neutre », qui relaie mécaniquement les paquets de ses clients, demain, on assistera à des ingérences encore plus nettes.

Ces résolveurs DNS menteurs ont des points communs, mais aussi des grosses différences, avec les jokers que mettent certains gérants de domaines dans leur zone (comme l'avait fait Verisign dans .com en 2003). Il y a notamment une différence technique : les jokers dans un domaine respectent le protocole DNS, les résolveurs menteurs non, donc seuls les premiers sont compatibles avec DNSSEC et une différence politique, les jokers dans un domaine sont mis par le titulaire du domaine, alors que le résolveur menteur est un tiers qui se permet de modifier les domaines qui ne sont pas à lui. À tout point de vue, les jokers dans un domaine, quoique une mauvaise idée, sont donc « moins graves ». Néanmoins, il est normal de ne pas les déployer, comme s'y est engagée, par exemple, l'AFNIC.

La confusion entre les deux techniques persiste trop souvent. Par exemple, le rapport 32 du SSAC, Preliminary Report on DNS Response Modification est très bien fait techniquement, comme d'habitude avec le SSAC, et fait bien le tour de la question. Mais il mélange trop les jokers dans un domaine (par exemple un TLD) et le mensonge par un résolveur, un serveur de noms récursif. (Probablement pour que l'ICANN puisse exercer une pression sur les TLD en leur interdisant les jokers, comme proposé à la réunion ICANN de Sydney.)

Comcast, en annonçant son début de déploiement de résolveurs DNS menteurs, a également tenu à citer l'IETF en affirmant que sa technique avait été présentée à la dite IETF. C'est exact (document draft-livingood-dns-redirect) mais cela oublie deux choses. L'une est que n'importe qui peut présenter n'importe quoi à l'IETF, il n'y a pas de barrière à l'entrée. Si l'approbation d'un RFC, surtout sur le chemin des normes, est une affaire sérieuse, la publication d'un Internet-Draft est entièrement automatique et ne vaut donc pas approbation du document. Ensuite, le document a bien été discuté au sein du groupe de travail DNSOP mais il a été très largement rejeté par tous les participants et a peu de chances de devenir un RFC un jour (ce qui n'empêchera pas Comcast ou les autres de continuer leurs pratiques, d'ailleurs). Au contraire, le RFC 4924 rappelle bien, dans sa section 2.5.2, que cette pratique est fortement déconseillée.


L'article seul

Votre serveur DNS peut-il faire passer des paquets de toutes les tailles ?

Première rédaction de cet article le 13 juillet 2009
Dernière mise à jour le 27 janvier 2010


Il y a très longtemps, lorsque les ministres ne parlaient pas de l'Internet à la télévision, la taille des paquets DNS était limitée à 512 octets (RFC 1035, section 2.3.4). Cette limite a été supprimée par le RFC 2671 en 1999. Mais dix ans sont une durée très courte pour le conservatisme de certains et beaucoup d'administrateurs réseaux qui mettent à jour leur version de Flash toutes les deux semaines n'ont jamais vérifié la configuration de leur pare-feux. L'OARC vient donc de publier un excellent outil qui permet de tester facilement si votre environnement DNS est correct.

L'outil en question consiste simplement en un serveur DNS spécifique, qu'on peut interroger (le nom est rs.dns-oarc.net et le type est TXT) avec n'importe quel client DNS. Voici un exemple avec dig :

% dig +short rs.dns-oarc.net txt
rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
"192.168.1.1 sent EDNS buffer size 4096"
"192.168.1.1 DNS reply size limit is at least 4023 bytes"

Ici, on voit que les réponses DNS de 4023 octets peuvent arriver.

Avec des résolveurs DNS mal configurés ou mal connectés (ici, ceux d'Alice, via une AliceBox) :

% dig +short rs.dns-oarc.net txt
rst.x486.rs.dns-oarc.net.
rst.x454.x486.rs.dns-oarc.net.
rst.x384.x454.x486.rs.dns-oarc.net.
"213.228.63.58 lacks EDNS, defaults to 512"
"213.228.63.58 DNS reply size limit is at least 486 bytes"

486 octets arrivent à passer, ce qui est insuffisant dans de nombreux cas.

Malheureusement, les environnements DNS bogués sont fréquents. Ce n'est pas forcément à cause du serveur de noms : cela peut être à cause d'un pare-feu stupidement configuré pour refuser les paquets DNS de plus de 512 octets ou bien par la faute d'une