XMLfr : l'espace XML francophone

Aujourd'hui 9 février est un triste jour pour l'Internet, c'est la présentation du projet de loi LOPPSI à l'Assemblée. C'est un texte de loi très vaste qui recouvre beaucoup de choses, d'ailleurs, pas seulement l'Internet.

LOPPSI impose le principe d'un filtrage obligatoire de l'Internet (article 4), comme à Dubaï, en Tunisie ou en Chine. Vous trouvez que la référence à la dictature chinoise est exagérée ? Mais ce sont les députés de la majorité qui citent la Chine en modèle. Bien sûr, on nous annonce que cela sera seulement pour lutter contre la pédophilie. Mais l'expérience prouve amplement que ce ne sera qu'un début et, qu'une fois la lourde infrastructure de filtrage en place, elle sera mise au service de bien d'autres causes, comme la protection de l'industrie du divertissement en filtrant les sites comme The Pirate Bay.

L'idée de filtrage obligatoire est ancienne. La loi ne donne pas de détails techniques, qui sont repoussés à un futur décret. Peut-être y aura t-il un serveur BGP place Beauveau, annonçant les adresses IP à null router, et avec qui les opérateurs devront peerer. Ou bien peut-être LOPPSI imposera t-elle l'empoisonnement des résolveurs DNS des FAI (avec des outils comme ceux de Nominum. PC Inpact avait fait une bonne liste des études techniques existantes. Dans tous les cas, cela ajoutera un composant au réseau, et donc une fragilité supplémentaire. On peut donc remercier le gouvernement Fillon pour avoir contribué à dégrader le fonctionnement du réseau.

Que doit faire le citoyen inquiet, à juste titre, de cette avancée de la censure ? D'abord, écrire à son député. Ensuite, pour les prochaines élections, les régionales, le 14 et 21 mars, penser aux partis qui s'opposent clairement à LOPPSI (n'hésitez pas à m'en signaler d'autres) :

• NPA,
• Europe Écologie,
• Parti Pirate.

Une bonne synthèse de la loi se trouve dans un article de PCinpact. On peut lire le projet entier sur le site de l'Assemblée.

Les statues meurent aussi, France, 1953, Alain Resnais & Chris Marker

C’est assez exceptionnel de retrouver ces deux réalisateurs aux manettes de ce court métrage documentaire de 30 min qui commence ainsi : « Quand les hommes sont morts, ils entrent dans l’histoire. Quand les statues sont mortes, elles entrent dans l’art. Cette botanique de la mort, c’est ce que nous appelons la culture. »

C’est de la destinée de l’art et de la culture noire africaine dont il question avec, dans cette séquence, une fulgurance qui brosse sans concession des décennies du choc culturel afrique noire / occident blanc.

Tout l’art du documentaire à partir d’images d’archives est condensé dans ces quelques minutes.

Alain Resnais, à propos de son entretien avec deux représentants de la commission de censure qui avait fait interdire le film, avait déclaré :

« Quant à eux, ils savaient tout ce qui se passait en Afrique et nous étions même très gentils de ne pas avoir évoqué les villages brûlés, les choses comme ça ; ils étaient tout à fait d’accord avec le sens du film, seulement (c’est là où ça devient intéressant), ces choses-là, on pouvait les dire dans une revue ou un quotidien, mais au cinéma, bien que les faits soient exacts, on n’avait pas le droit de le faire. Ils appelaient ça du « viol de foule ». L’interdiction eut des conséquences très graves pour le producteur. Quant à nous – est-ce un hasard ? – ni Chris Marker ni moi ne reçûmes de propositions de travail pendant trois ans. »

En raison de problèmes de spam, désormais les commentaires sur Figoblog sont modérés a priori.

Bon, vu la foule de gens qui se pressent pour commenter, je sens que ça ne va pas vous gêner énormément.
Surtout vu la foule de billets que j'écris en ce moment.

Mais au cas où vous mettriez un "vrai" commentaire, ne vous inquiétez pas de devoir attendre un ou deux jours avant de le voir apparaître.

Histoire de ne pas avoir fait le billet rien que pour ça, je vous offre en prime une photo d'un bouquin que j'ai récemment emprunté à la bibliothèque :

Un livre qui vous apprend que manger une figue n'est jamais un acte totalement anodin.

Le NAT est depuis longtemps une des plaies de l'Internet. Justifié au début par le manque d'adresses IPv4, il est désormais de plus en plus utilisé en raison de l'épuisement des adresses v4, mais aussi sur des sites qui croient qu'il leur simplifie la vie, voire qu'il améliore leur sécurité. Une des conséquences du NAT tel qu'il est déployé pour IPv4 est que les adresses privées sont prises dans une réserve d'assez petite taille et qu'on voit désormais des cas de recouvrement d'adresses IP entre deux réseaux utilisant cette technique. Ce RFC décrit deux cas de cette catégorie.

L'utilisation « canonique » du NAT est avec un réseau local qui utilise des adresses privées du RFC 1918 et une seule adresse IP publique, attribuée par le FAI et affectée au routeur qui connecte le réseau local à l'Internet. Dans cette configuration (section 3.2.1), les limites et les problèmes du NAT sont bien connus. (Voir les RFC 2993, RFC 3424, RFC 5218, etc.) Mais, en raison du succès du NAT, on voit de plus en plus apparaitre des configurations moins classiques, qui apportent de nouveaux problèmes.

L'Internet avait été prévu pour un espace d'adressage unique (section 1 du RFC), où chaque machine avait une adresse unique au monde. Le déploiement souvent irrefléchi du NAT a mené à une séparation Identificateur/Localisateur de fait (et mal faite) : désormais, il existe plusieurs machines sur l'Internet qui ont l'adresse 192.168.1.1.

Parmi les causes de ce déploiement du NAT :

• Le non-déploiement d'IPv6 (ipv6-et-l-echec-du-marche.html) qui, aujourd'hui, coûte très cher à la société,
• Une impression (non fondée) comme quoi l'utilisation d'adresses privées améliorerait la sécurité du réseau et la protection de la vie privée des utilisateurs,
• La facilité d'usage du NAT qui peut être déployé unilatéralement par un site. Pour les gens qui ne croient pas à l'action collective (qui est nécessaire pour IPv6), le NAT est perçu comme plus facile. Il n'y a pas besoin d'administrateur système, rien à configurer, on branche la box et c'est parti.

Les problèmes que pose le NAT sont décrits dans le RFC 3027. Notre RFC 5684, lui, détaille deux cas problématiques, liés au déploiement de NAT emboîtés (passage par au moins deux routeurs NAT). Il s'appuie sur la terminologie du RFC 2663.

Le réseau théorique utilisé pour notre RFC est dessiné dans la figure 1, section 3.Il représente ces deux cas de NAT emboîtés. La facilité apparente de déploiement du NAT a une conséquence néfaste : comme il n'y a pas besoin de se concerter avec d'autres personnes, on voit de plus en plus des NAT emboîtés apparaître sans que cela résulte d'un choix délibéré, mais simplement de l'addition de décisions individuelles.

Si vous lisez le RFC, gardez bien sous la main tout le temps cette figure 1, elle vous servira.

                               Public Internet
                           (Public IP addresses)
       ----+---------------+---------------+---------------+----
           |               |               |               |
           |               |               |               |
       192.0.2.1      192.0.2.64     192.0.2.128     192.0.2.254
       +-------+        Host A          Host B      +-------------+
       | NAT-1 |        (Alice)         (Jim)       |    NAT-2    |
       | (Bob) |                                    | (CheapoISP) |
       +-------+                                    +-------------+
       10.1.1.1                                        10.1.1.1
           |                                               |
           |                                               |
       Private Network 1                      Private Network 2
     (private IP addresses)                 (private IP addresses)
       ----+--------+----      ----+-----------------------+----
           |        |              |           |           |
           |        |              |           |           |
       10.1.1.10 10.1.1.11     10.1.1.10   10.1.1.11   10.1.1.12
        Host C    Host D       +-------+    Host E     +-------+
                               | NAT-3 |    (Mary)     | NAT-4 |
                               | (Ann) |               | (Lex) |
                               +-------+               +-------+
                               10.1.1.1                10.1.1.1
                                   |                       |
                                   |                       |
               Private Network 3   |         Private Network 4
             (private IP addresses)|       (private IP addresses)
               ----+-----------+---+       ----+-----------+----
                   |           |               |           |
                   |           |               |           |
               10.1.1.10   10.1.1.11       10.1.1.10   10.1.1.11
                Host F      Host G          Host H      Host I
         
   Figure 1. Multi-level NAT topology with Overlapping Address Space

Les ennuis commencent avec le pair à pair (section 3.1.2). Comme plusieurs machines ont la même « identité », la même adresse IP, les communications pair-à-pair sont difficiles. D'abord, pour se trouver, les machines vont avoir besoin d'un serveur extérieur, qui va organiser les rendez-vous. Ensuite, même si les machines apprennent l'adresse IP d'une autre via ce serveur, elles ne pourront pas forcément la contacter, en raison de l'absence d'adresse unique. Par exemple, une machine pourra contacter, à la place du pair convoité, une autre machine de son réseau local, qui aura la même adresse IP que le pair qu'on veut joindre.

Ann et Lex ont même un problème supplémentaire, qui fait l'objet de la section 3.2.2 : il y a duplication des adresses IP. Plusieurs machines ont la même adresse, car l'allocation n'est pas coordonnée et l'espace du RFC 1918 étant très petit, les collisions sont inévitables. Si les routeurs d'Ann et de Lex tentent d'utiliser le classique ARP sur toutes leurs interfaces, ils peuvent obtenir des réponses différentes selon l'interface. Une telle configuration, qui marchera a priori (« Je peux voir YouTube », en raison du NAT) produira des phénomènes bizarres et difficilement explicables à première vue.

Le fait qu'il y aie plusieurs niveaux de NAT dans ces cas cause également d'autres surprises (section 3.2.3), comme le fait que les machines aux adresses privées peuvent communiquer avec l'Internet mais pas entre elles, même lorsqu'elles sont clientes du même FAI. Parfois, une communication est possible via le routeur NAT, si celui-ci permet les connexions « en épingle à cheveux » (où le paquet va au routeur de sortie puis tourne en épingle à cheveux pour revenir vers le réseau privé). Les RFC 4787 et RFC 5382 demandent qu'un tel routage soit possible.

Mais, même lorsque « ça marche », la configuration reste bancale. Ainsi, on ne peut plus utiliser l'adresse IP d'une machine, normalement unique, comme identité (section 3.2.4). Cela fait que les paquets peuvent être transmis à la mauvaise machine. Le RFC donne l'exemple d'un résolveur DNS. S'il utilise des adresses privées et qu'un des réseaux locaux connectés utilise des adresses de la même plage, les machines de ce réseau ne pourront pas joindre leur résolveur. Le RFC recommande donc que les serveurs vitaux, comme le résolveur DNS, reçoivent toujours des adresses globales.

Un autre cas où des recouvrements des plages d'adresses IP peut se produire est celui des VPN, dans la section 4. Quelle que soit la technologie utilisée pour les réaliser (IPsec, L2TP, etc), le VPN donne accès à un réseau dont les adresses sont souvent privées. Si, sur son réseau d'attachement physique, le client VPN utilise également des adresses privées, le risque de collision est important. Un exemple que cite le RFC en section 4.2.1 est celui où le serveur DHCP du réseau local de la machine cliente a la même adresse (privée...) qu'une machine du réseau distant. Au moment de renouveler le bail DHCP, les paquets iront sur le site distant et pas sur le réseau local... Le RFC recommande donc que les paquets à destination des adresses IP du serveur DHCP et du premier routeur ne soient jamais envoyées à travers le VPN, même dans le cas où celui-ci est configuré pour faire passer la totalité du trafic, ce qu'on nomme le non-split VPN, et qui est souvent préféré pour des raisons de sécurité. Le RFC conseille aussi de garder la possibilité du split VPN (où seul les paquets à destination du réseau de l'entreprise sont routés via le VPN), qui limite les risques de collision.

La section 5 reprend et résume les recommandations de notre RFC 5684. Elles viennent en sus de celles des RFC 4787, RFC 5382 et RFC 5508. Si elles sont suivies, les conséquences de l'adressage privé seront minimisées.

Si elles ne le sont pas, plusieurs accidents auront lieu, parfois avec des conséquences néfates pour la sécurité (section 7), comme l'envoi de paquets à une machine autre que celle à qui ils étaient normalement destinés. Le RFC conseille de toute façon d'avoir également une authentification forte et de ne pas se fier uniquement à l'adresse IP source.

Ah, un dernier conseil, personnel : pour limiter le risque de collisions lorsque vous utilisez des adresses RFC 1918, n'utilisez pas le début des plages. Pour vous éloigner des autres, numérotez avec un numéro « haut », choisi au hasard, par exemple avec 10.198.200.0/22 ou 10.243.24.0/22 plutôt qu'avec le banal 10.1.0.0/24 que tout le monde utilise...

Un œil innocent ? La carrière et la vision documentaire de Georges Rouquier jusqu’en 1945, par John H. Weiss (format PDF, 22 pages) Traduction par Patrick Peccatte de l’article : “An Innocent Eye? The Career and Documentary Vision of Georges Rouquier up to 1945” by John H. Weiss, from Cinema Journal, Vol. 20, No. 2 (Spring, 1981), pp. 38-62.... Lire Traduction d'un article sur le cinéaste Georges Rouquier

J’ai déjà eu l’occasion de parler du dernier ouvrage de Marie-Anne Dujarier, notamment dans Le devenir algorithmique et dans Le juste prix, où elle met en évidence, au travers d’exemples auxquels nous sommes tous confrontés, les mécanismes par lesquels le consommateur est mis au travail.

Voici les deux derniers en date me concernant :

C’est quand même fort de payer pour un service, et de se retrouver à devoir produire le service soi-même ! Assurément, l’économie des services a des vertus que l’économie des marchandises n’a pas. Mais, certains cas encore plus aberrants peuvent se produire, comme cette histoire relaté par Hervé Kempf :

Cent vingt touristes venus de la région de chinoise de Hubei se sont révoltés contre les organisateurs de leur voyage [à Macao, près de Hong-kong] parce qu’ils n’en pouvaient plus de faire du shopping : « Les guides nous ont dit que si l’on  n’achetait rien aux magasins où l’on s’était arrêtés, ils nous abandonneraient sur la plage de Hac Sa ». Devant le refus des voyageurs d’acheter, les organisateurs les ont emmenés sur la plage, ce qui, en décembre, n’était pas une partie de plaisir, les empêchant de rentrer dans les cars chauffés. On en est venu aux mains, et la police a dû envoyer une unité anti-émeutes pour calmer les non-consommateurs révoltés. (Pour sauver la planète, sortez du capitalisme, P.54)

Il existe peu de livres sur les CPL et je crois que celui-ci est le seul en français (une bibliographie des équivalents en anglais figure à la fin de l'ouvrage). Cette technique est en général sous-estimée et beaucoup de déploiements de réseaux locaux ou distants ne l'envisagent même pas. Pourtant, elle a de nombreuses propriétés intéressantes. (J'ai décrit mon utilisation dans « CPL (Courants porteurs en ligne) à la maison ».)

Comprendre les CPL nécessite des compétences en électricité, en informatique et en réseaux. Ce livre a donc un vaste champ à couvrir. Je vais commencer par ce qui est le moins bien couvert : la partie sur la configuration d'IP est faible (chapitres 10 et 11), surtout composée de copies d'écran (qui permettent de remplir les pages à bon marché). Même les commandes tapées dans un xterm sont montrées sous forme de copie d'écran, intéressant paradoxe. Cette partie « réseaux » contient des archaïsmes étonnants pour un livre récent (comme la discussion des classes, supprimées onze ans avant la parution du livre, ou comme la commande ipchains de Linux, complètement remplacée par iptables depuis belle lurette). Par contre, IPv6, technologie stable depuis longtemps, ne fait l'objet d'aucune mention, alors qu'elle est particulièrement utile dans le cas des réseaux domestiques, où on a plusieurs objets à connecter et jamais assez d'adresses IPv4.

D'un autre côté, j'ai apprécié que l'auteur fasse un effort pour ne pas parler uniquement de MS-Windows, comme tant de livres « pour les nuls ». Il y a même une discussion de la configuration d'un réseau sur FreeBSD, ce qui est rare pour un ouvrage destiné à un public assez large. Mais, globalement, toutes les parties du livres consacrées à IP donnent l'impression que l'éditeur a demandé qu'on en parle, mais que l'auteur n'était pas le plus à l'aise sur ce sujet.

Et sur l'électricité ? Étant plutôt rouillé sur ce sujet, mes cours de physique étant assez lointains, j'espérais une révision mais j'ai été un peu déçu. Le livre suppose qu'on s'y connait déjà en électricité et qu'on n'a pas besoin de se faire expliquer trop longuement l'impédance ou la capacité (chapitres 2 et 8).

Une des difficultés qui se dressent sur le chemin de l'auteur d'un livre sur les CPL est que le domaine est peu normalisé (chapitre 1). S'il existe un consortium industriel nommé Homeplug qui édicte des spécifications de base pour les CPL domestiques, il n'y a pour l'instant aucune norme réelle (produite par exemple par l'IEEE). Résultat, l'auteur est souvent obligé de présenter des techniques spécifiques à un constructeur. Mais il a fait l'effort de ne privilégier aucun constructeur et de bien préciser ce qui est « standard » et ce qui ne l'est pas.

Par exemple, même avec Homeplug, la configuration des adaptateurs est entièrement faite par des protocoles non-standard. Il existe toutefois des interfaces communes qui commencent à émerger et c'est dans ce livre (chapitre 9) que j'ai appris l'existence de l'excellent outil plconfig qui marche bien sur ma Debian :

% plconfig -r eth1

- Parameters and Statistics response from 00:0c:b9:09:b7:ed
  Tx ACK Counter:             45547
  Tx NACK Counter:            18848
  Tx FAIL Counter:            5
  Tx Contention Loss Counter: 33611
  Tx Collision Counter:       13485
  Tx CA3 Latency Counter:     3463
  Tx CA2 Latency Counter:     34789
  Tx CA1 Latency Counter:     4109
  Tx CA0 Latency Counter:     0
  Rx Cumul. Bytes per 40-symbol Packet Counter: 13628962
...

La partie « couche 2 » est bien meilleure (chapitres 3 et 5), avec une intéressante discussion des différents modes de communication entre adaptateurs CPL (du pair-à-pair de Homeplug au mode maître-esclave), et une présentation détaillée les mécanismes d'accès au réseau (CSMA/CA, dont il oublie toutefois de noter que c'est un terme marketing : il y a aussi des collisions en CSMA/CA).

J'ai aussi apprécié la section sur le rayonnement radio des CPL (chapitre 8) ou bien le chapitre 12 sur la création d'un réseau CPL pour une collectivité locale, même si ce dernier restera purement théorique pour moi.

Du fait de l'intérêt des technologies CPL, et du petit nombre de documents existants, je ne regrette pas d'avoir acheté ce livre et je remercie l'auteur pour l'effort qu'il a fait pour diffuser de l'information sur une technique peu connue. Mais je pense quand même qu'il reste de la place pour un livre plus pédagogique.

Je cherche un moyen de trouver l'adresse IP avec laquelle mon serveur de noms interroge le monde extérieur. C'est bien plus compliqué que cela n'en a l'air.

Lorsque j'appelle www.example.org, l'application que j'utilise (que ce soit Firefox ou curl) fait appel (en général via le sous-programme ()) à un résolveur DNS ; sur Unix, son adresse est trouvé dans /etc/resolv.conf. Il y a des fois où j'aimerai bien savoir quelle adresse utilise ce résolveur pour interroger les serveurs faisant autorité. On ne peut pas simplement prendre l'adresse qui se trouve dans /etc/resolv.conf pour au moins trois raisons :

• Le résolveur peut faire appel à un autre résolveur (appelé un forwarder ; avec BIND, c'est le nom de la directive qui sert à configurer un tel « résolveur supérieur »).
• Le résolveur peut être derrière un routeur NAT, qui va changer son adresse.
• Le résolveur n'utilise pas forcément la même adresse pour les requêtes sortantes et les requêtes entrantes.

Je vois trois façons possibles de trouver l'adresse utilisée par la résolution de noms :

• Regarder sa configuration en détail, notamment des directives comme "forwarder" et "query-source" sur BIND. Cela ne marche que si on accès à cette configuration, ce qui n'est pas le cas de tout le monde.
• Sur une zone qu'on contrôle, écouter le trafic (par exemple avec tcpdump) sur tous les serveurs de noms faisant autorité et faire une requête pour "nexistepas.MAZONE" (il vaut mieux utiliser un nom non existant pour ne pas risquer qu'il soit dans le cache d'un résolveur). Cela oblige à avoir une zone dont on contrôle tous les serveurs de noms et ce n'est pas très pratique.
• Avoir quelque part une zone spécialement configurée pour servir de réflecteur qui, aux requêtes DNS, renvoie l'adresse IP du client qui l'a interrogé. C'est de loin la meilleure méthode.

Mais un tel service existe t-il ? Aucun serveur de noms standard ne sait faire cela, il faut donc écrire un serveur adapté. Par manque de temps, je cherche un service déjà existant.

Le premier testé est celui créé par l'OARC pour un tout autre but, replysizetest et disponible en rs.dns-oarc.net et rs.ripe.net. Ignorons le but principal de ce service, ce qui m'intéresse ici est qu'il donne l'adresse IP de son client DNS. Ainsi, depuis Free, j'obtiens :

% dig +short TXT rs.dns-oarc.net  
...
"213.228.63.32 sent EDNS buffer size 4096"

% dig +short TXT rs.dns-oarc.net             
...
"209.85.228.94 lacks EDNS, defaults to 512"

À noter qu'il fonctionne également avec IPv6 (contrairement à ce que j'avais écrit dans une précédente version de l'article).

À noter également que l'OARC a un outil équivalent qui avait également été fait dans un autre but (détecter les résolveurs vulnérables à la faille Kaminsky) et qui peut également être « détourné » pour nos recherches :

% dig +short porttest.dns-oarc.net TXT

porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"192.134.4.162 is GREAT: 26 queries in 3.9 seconds from 8 ports with std dev 21270"

% dig +short amiopen.openresolvers.org TXT
"Your resolver at 192.134.7.248 is CLOSED"

Ce service est-il une solution parfaite ? Outre qu'il est un peu lent car il fait bien autre chose que renvoyer l'adresse IP, je regrette qu'il ne puisse pas renvoyer une adresse binaire (en réponse à une question de type A ou AAAA).

Les entreprises qui font du load-balancing ont souvent des noms qu'on peut résoudre dans le DNS pour obtenir l'adresse IP du résolveur, à des fins de déboguage. C'est le cas de whoami.ultradns.net et de whoami.akamai.net. Ces deux services ont l'avantage de renvoyer l'adresse IPv4 en binaire (il faut donc faire une requête de type A et pas TXT), ce qui est pratique. Celui d'UltraDNS a l'inconvénient de planter complètement avec des adresses IPv6 (renvoyant NXDOMAIN au lieu du normal NODATA, ce qui est une bogue énorme

% dig AAAA whoami.ultradns.net
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51301
...

Encore mieux, le service de Cedexis (merci à Stéphane Enten), 1-01-2743-000d.cdx.cedexis.net. Si le nom est un peu bizarre (le service ne semble pas encore stabilisé et plante parfois), le réflecteur marche très bien, renvoyant un CNAME vers un nom qui code le client, indiquant même le numéro d'AS :

% dig +short A 1-01-2743-000d.cdx.cedexis.net
client-ip-208.75.84.80--client-asn-23372.

Je continue à chercher. Si vous avez des idées...

Un bref article sur Officina della Storia - rivista on-line di storia contemporanea, site italien dédié à l'histoire contemporaine et réalisé en coopération avec l'Università degli Studi della Tuscia à Viterbe : Flickr et PhotosNormandie: un projet de redocumentarisation d'un fonds photographique historique Cet article est en français. (Merci à... Lire Flickr et PhotosNormandie - article sur Officina della Storia

Pendant que les moutons fidèles de Steve Jobs se pressaient pour le voir présenter un nouvel engin ultra-fermé et contrôlé par Apple, un autre évenement suscitait de nombreux articles (moins nombreux, quand même), le début de diffusion des signatures par les serveurs racines du DNS. Ce processus avait été annoncé en octobre dernier et, jusqu'à présent, suit à peu près son cours.

Hier soir (heure française), un serveur racine a commencé à diffuser des informations signées avec DNSSEC. C'est L.root-servers.net, géré par l'ICANN qui s'y est collé pour être le premier. Le déploiement progressif (jusqu'en juillet), permet aux administrateurs réseaux de vérifier leur configuration, même si eux-mêmes ne font pas de DNSSEC. Ils doivent en effet s'assurer que leur réseau laisse passer les réponses DNS de grande taille.

Les autres serveurs racines suivront petit-à-petit, selon le plan publié sur le site officiel. En mai, certains des réseaux qui ont une configuration boguée (bloquant les résponses supérieures à 512 octets ou bien ne gérant pas la fragmentation) n'auront plus d'accès au DNS.

Quelques observations amusantes ou intéressantes. La réponse envoyée par L.root-servers.net atteint désormais dans les 600 octets pour une question typique (celle qui mène à une référence vers un TLD, par exemple dig AAAA www.bortzmeyer.fr), mais 1900 octets si on demande toutes les informations (dig ANY .). À cause de la taille des enregistrements NSEC, les demandes pour les TLD inexistants sont un peu plus grosses que les références (dans les 650 octets). Et la requête initiale des résolveurs (priming), dig NS ., atteint maintenant 800 octets.

Comme annoncé, la clé publiée n'est pas celle de signature et on ne peut donc pas encore valider la racine :

% dig +dnssec +multi @L.root-servers.net DNSKEY .

; <<>> DiG 9.5.1-P3 <<>> +dnssec +multi @L.root-servers.net DNSKEY .
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47275
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.			IN DNSKEY

;; ANSWER SECTION:
.			86400 IN DNSKEY	256 3 8 (
				AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/
				KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/
				AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++
				+++++++++++++++++++++++++++++++++++++++++++8
				) ; key id = 23763
.			86400 IN DNSKEY	257 3 8 (
				AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/
				KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/
				AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++8=
				) ; key id = 19324
.			86400 IN RRSIG DNSKEY 8 0 86400 20100204235959 (
				20100121000000 19324 .
				NO9bHgWYB3wQlVZXQKwDGUjTgIyfz1i8aWH8nBlT5isn
				Ybr6PTfR4fWlSx8+avFfR0fVekauaQelKOyiUav4H9Y1
				AZ2OBguu7RjozQu1qErKboWd1NglIIOGar0Ol4Ur9+4b
				o2LSxjp/X4ESypW0lX04z5uB6DZZei1zafzRGUnLIMdV
				9xdKEOJrm9UCKvYK5g8bjRq8KA8vT+pidexZMrBQ3ie8
				R9daf/s6VK7zUJK0jF1vqhPbZFSQmBpJUlxh4VnOv7nn
				hcq4Moj49wqmNxKRqfvSwHAJBG6dEgShnlu/rfVsdxfF
				UCjIGX8YnSC7lYqODwgUGh+i/arAAK+bzg== )

;; Query time: 135 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Thu Jan 28 09:31:22 2010
;; MSG SIZE  rcvd: 736

Plusieurs organisations ou personnes ont déjà publiées d'intéressantes statistiques. Par exemple, l'OARC a publié « L-Root now serving "DURZ" signed responses » avec des jolis graphiques qui montrent notamment :

• L'augmentation de taille des réponses au priming, de 630 (en moyenne) à 760 (en moyenne, c'est moins que ce que je mesure car certains résolveurs demandent sans EDNS, cf. RFC 2671),
• Un bond considérable des requêtes en TCP, venant des résolveurs qui, bêtement, n'utilisent pas EDNS et récupèrent donc des réponses tronquées. Mais le pourcentage reste négligeable (http://stats.l.root-servers.org/cgi-bin/dsc-grapher.pl?window=604800&plot=transport_vs_qtype&server=L-root))

L'IETF vient de créer un groupe de travail sur le création d'un codec audio libre. Le groupe Internet Wideband Audio Codec (dit simplement codec) commence ainsi une existence qui sera certainement agitée.

Le projet de création de ce groupe avait été un des points chauds de la réunion IETF d'Hiroshima en novembre 2009. Suivant cette réunion, de très longs débats avaient eu lieu en ligne, et ont mené, le 26 janvier, à l'annonce par l'IESG de la création de ce groupe, membre du secteur « Applications et infrastructure temps-réel ». Ses présidents sont Michael Knappe et Peter Saint-Andre (M. XMPP).

Quel est le problème à résoudre ? Il existe un grand nombre de codecs pour le son. Aucun n'est particulièrement enthousiasmant pour l'IETF et cela rend plus difficile le fonctionnement d'applications sonores sur l'Internet. L'IESG pointe trois gros points qu'aucun des codecs existants ne satisfait complètement :

• Optimisé pour les applications interactives (comme la téléphonie), au contraire de, par exemple, MP3, optimisé pour le téléchargement,
• Publié par une SDO ouverte (au contraire, là encore, de MP3, contrôlé par une organisation privée) de manière à ce que les évolutions du codec n'échappent pas à la communauté,
• Format libre, implémentable par tous (MP3 est pourri de brevets). Cela sera certainement un des points les plus délicats, compte-tenu du nombre de brevets, et de la difficulté (ou du coût) à obtenir une licence pour les codecs existants.

La charte du groupe est donc la création d'un codec combinant ces trois qualités. Il est probable qu'il faudra le développer en partant de zéro, mais la charte n'exclut pas la possibilité d'adopter un codec existant, si on trouve le mouton à cinq pattes. (Je ne m'y connais pas assez pour déterminer si Vorbis ou Speex sont des bons candidats.)

Les exigences techniques impliquent notamment une bonne adaptation aux protocoles interactifs (avec, par exemple, adaptation dynamique de la qualité sonore à la capacité réseau disponible), et une bonne interaction avec les protocoles IETF existants comme RTP et SIP.

Le travail devra se faire en liaison avec l'UIT, notamment son Study Group 16, avec l'idée de tenter une publication commune de la future norme. Le résultat n'est pas garanti car les précedentes collaborations entre l'IETF et l'UIT ont parfois été orageuses (cf. RFC 5704).

Mais les brevets seront certainement le principal obstacle sur le chemin du futur codec, le monde de l'audio étant truffé de brevets futiles, acceptés par des offices des brevets paresseux, incompétents ou simplement intéressés à ce que le maximum de brevets soit déposé. La charte du groupe de travail prévoit, en cohérence avec les RFC 5378 et RFC 3979, de donner la priorité à un codec non encombré par des brevets.

Le calendrier de développement prévu est assez ambitieux, vue l'ampleur du projet (et l'IETF n'est pas connue pour le respect des calendriers...). Il est prévu que le gros du travail technique soit terminé à l'été 2011.

Quels étaient les problèmes qui ont suscité tant de discussions à l'IETF ? Il y avait la crainte que des codecs existants soient écartés d'avance au profit de la tâche lourde et complexe du développement d'un nouveau codec (d'où la mention dans la charte qu'un codec existant peut être utilisé, s'il correspond au cahier des charges, d'autant plus que la situation peut changer, par exemple sur la question de la politique de licence). Il y a eu aussi un gros débat sur la possibilité de produire un codec meilleur que tous les existants, tout en le gardant libre (cela parait irréaliste). Et, bien sûr, il y a eu de longues polémiques sur la politique de l'IETF par rapport aux brevets...

Dans la note Comment pensent les pauvres ?, j’évoquais l’économiste Esther Duflo. Puis un très bon article de synthèse de Jean Luc Raymond sur Esther Duflo a attiré encore plus mon attention sur ses travaux.

C’est sur la méthode qu’elle utilise que je voudrais porter un éclairage, tant elle m’apparaît intéressante. Méthode dont elle retrace l’origine dans cette vidéo :

Esther Duflo – La méthode expérimentale
par larepubliquedesidees (Vous pouvez visionner les autres vidéos de cette séance sur La république des idées.)

Esther Duflo commence donc par préciser que sa méthode provient de la démarche des essais cliniques qui a révolutionné la pratique de la médecine et de la pharmacologie au XX° siècle. Le Comité international des rédacteurs de revue médicales en donne la définition suivante :

« Tout projet de recherche qui affecte de façon prospective des sujets humains à des groupes d’intervention et de comparaison afin d’étudier la relation de cause à effet entre un acte médical et l’évolution d’un état de santé ».

L’import de la méthode des essais cliniques dans le champ social s’est fait dans les années 60, aux USA, sur des questions d’assurance santé et d’aide aux personnes en difficulté. Mais l’approche n’a pas été généralisée dans toutes les démarches ; elle n’a été mise en œuvre que dans quelques gros projets bénéficiant d’un budget de plus d’un million de dollars.

Duflo précise que, à la différence de ce qui avait été fait jusqu’alors, son groupe a utilisé cette méthode :

• sur la thématique du développement ;
• sur des petits projets, plus flexibles ;
• avec des acteurs qui n’étaient plus simplement les grandes administrations ;
• avec une approche beaucoup plus contributive entre les intervenants.

Si je reprends ces idées, c’est d’abord parce que je trouve la démarche intéressante certes, mais c’est aussi pour faire le rapprochement avec la pharmacologie dont parle fréquemment Bernard Stiegler et que développe Ars Industrialis.

Tout d’abord, on ne s’étonnera pas des nombreuses similitudes avec les démarches agiles dans l’informatique. Toutes ces méthodes ont ceci de commun qu’elles cautionnent et partagent une vision et un discours pharmacologique. Ce qui induit toutes les problématiques d’itérations, de tests et d’expérimentations (mais aussi l’importance du hasard au cœur même de la méthode) au cours desquelles les remèdes et les dosages sont évalués.

Nous sommes là pleinement dans des pratiques pharmacologiques : toutes les méthodes agiles, les essais cliniques, l’importance du feedback,  la logique « beta », le rôle déterminant de la contribution, l’économie du libre, etc., tout ce foisonnement repose sur la mise oeuvre d’une pratique pharmacologique car on agit toujours à la fois sur le corps des individus et sur le corps social (souvenons-nous qu’innover c’est socialiser).

Une pratique pharmacologique est une démarche qui combine les fondements des études en essais cliniques avec les pratiques agiles, dans une perspective contributive avec un but thérapeutique

Le 26 janvier à l'AFNIC, j'ai participé à un séminaire sur la « Veille sur l'Internet ». J'ai surtout insisté sur la distinction entre la source (la personne ou organisation qui émet l'information), le canal (le mécanisme par lequel l'information est transportée) et l'outil (le logiciel utilisé pour la visualisation). Comprendre les différences et les articulations entre ces trois concepts permettrait de mieux évaluer l'information reçue et éviterait de dire (comme je l'ai parfois entendu) « Je l'ai lu sur Internet », voire « Je l'ai lu sur Google ».

Mais j'ai aussi parlé des outils et il y a même eu la traditionnelle démo à la fin, avec Liferea et pidgin. Voici les transparents présentés :

• Format PDF adapté à la lecture sur écran,
• Format PDF adapté à l'impression,
• Source LaTeX/Beamer, .

Le 12 janvier, discrètement, l'une des fonctions les plus anciennes de l'Internet, celle d'éditeur des RFC, a changé de main.

Depuis le début (le RFC 1 date de 1969), la fonction de « RFC editor », le relecteur, le publicateur et le gardien de ces textes sacrés de l'Internet était à l'ISI, d'abord sous la forme d'une personne, Jon Postel, puis sous celle d'un petit groupe (l'ISI a récemment publié un bilan de son action). Un mécanisme d'abord assez informel, assuré avec sérieux (et conservatisme) par des gens connus et jouissant de la confiance de l'IETF. Désormais, suite à un appel d'offres, la fonction est plus classiquement traitée par une organisation qui a reçu formellement la délégation : AMS, une organisation spécialisée dans la gestion de SDO dans le monde des réseaux informatiques (mais il y avait d'autres candidats).

Le premier RFC publié par le nouvel éditeur a été le RFC 5735, suivi depuis par de nombreux autres.

Contrairement à ce que prétendent certains ignorants, la délicate question de la période de transition entre IPv4 et IPv6 n'a jamais été négligée à l'IETF. Bien au contraire, plusieurs mécanismes ont été normalisés pour assurer le passage d'un protocole à l'autre. Le mécanisme « RD », décrit dans ce RFC 5569, est un de ces mécanismes, modifiant le 6to4 du RFC 3056 pour garantir un chemin de retour symétrique aux paquets IP. RD permet à un FAI de vendre un service IPv6 alors que son réseau interne est essentiellement IPv4. Il est surtout connu pour être la technologie déployée par Free à partir de décembre 2007.

S'il existe plusieurs mécanismes de coexistence d'IPv4 et d'IPv6, c'est parce que les besoins sont différents. Certains FAI ont un réseau interne entièrement IPv6 depuis de nombreuses années comme Nerim. D'autres n'ont pas encore commencé le déploiement. Parfois, le FAI est en avance sur ses clients, parfois c'est le contraire comme c'était le cas pour Free où de nombreux utilisateurs réclamaient IPv6 depuis longtemps. Il existe donc une variété de techniques de coexistence v4/v6. RD se positionne pour le cas où le FAI :

• n'a toujours pas migré la totalité de son réseau interne en IPv6,
• a une connectivité IPv6 externe, et des adresses IPv6 allouées par un RIR,
• a certains clients qui réclament une connectivité IPv6,
• et, de préférence, contrôle le routeur situé chez les clients (cas des « boxes »).

La section 1 du RFC décrit ainsi comment Free a migré vers 6RD fin 2007 (un autre compte-rendu a été fait par Alexandre Cassen à la réunion RIPE-58 à Amsterdam). Il a fallu mettre à jour le logiciel de la Freebox et ajouter des serveurs relais 6RD en sortie mais il n'a pas été nécessaire de toucher aux DSLAM (qui ne gérent malheureusement pas IPv6).

La section 2 revient plus en détail sur le cahier des charges : casser le cercle vicieux courant avec IPv6 où les FAI n'installent pas IPv6 parce que leurs clients ne le demandent pas et où les clients ne se mettent pas à IPv6 parce que peu de FAI le transmettent. Le protocole « idéal » semblait être 6to4 du RFC 3056. Simple, déjà mis en œuvre, y compris en logiciel libre et sans état (chaque paquet est traité indépendamment) donc passe bien à l'échelle. Mais il a des limites, notamment le fait le retour du paquet n'est pas garanti : la machine avec laquelle on communique va chercher son propre relais 6to4 et ne va pas forcément en trouver un. RD est une modification de 6to4 pour utiliser comme préfixe, non plus le préfixe 6to4 commun à tous de 2002::/16 mais un préfixe par FAI. Ainsi, le FAI doit désormais lui-même installer des relais, il ne peut plus se reposer sur les relais existants mais, en contre partie, il contrôle complètement le routage, y compris sur le chemin du retour et se retrouve ainsi dans un cas plus classique où ses routeurs servent ses clients (alors que, avec 6to4, tout le monde sert tout le monde, ce qui est très bien lorsque cela marche).

On peut se poser la question de savoir s'il s'agit vraiment d'IPv6 « natif ». Sans doute pas (le paquet circule dans le réseau de Free encapsulé IPv4, ce qui réduit la MTU à 1480 octets).

Une fois ce principe posé, la section 3 spécifie le protocole, très proche du 6to4 du RFC 3056. Les acteurs sont :

• Les machines sur le réseau local du client, elles parlent IPv6 nativement sur ce réseau local (si elles utilisent l'auto-configuration sans état, la Freebox leur a envoyé le préfixe par RA),
• Les CPE (la Freebox, chez Free), qui doivent parler 6RD pour traduire dans les deux sens,
• Les relais 6RD, en bordure du réseau du FAI. Chez Free, ce sont des PC Unix.

6to4 soulève traditionnellement des gros problèmes de sécurité, documentés dans le RFC 3964. 6RD en supprime certains, si l'implémentation suit les recommandations de la section 5, et effectue les vérifications demandées, mais l'usurpation d'adresse IP demeure relativement facile.

Le déploiement de 6RD chez Free a permis à la France de faire un bond dans les statistiques IPv6 comme l'a montré le rapport de Lorenzo Colitti (Google), Global IPv6 Statistics - Measuring the Current State of IPv6 for Ordinary Users.

Mais la normalisation de 6RD est aussi l'occasion de voir le processus IETF en action, lorsque l'auteur de la proposition n'est pas un habitué de l'IETF et n'a pas la culture « maison », ce qui était le cas de Rémi Després, un des concepteurs de Transpac, et qui a eu le courage de se plonger dans un monde bien différent, ce qui est toujours plus difficile que de rester seul dans son coin à expliquer qu'on a raison. Comme avec n'importe quelle organisation humaine, l'intégration du « petit nouveau » ne s'est pas fait sans mal mais, finalement, le RFC a été publié.

(Petite note au passage: ce RFC n'a que le statut de « Pour information » et la « vraie » norme IETF sur ce protocole n'apparaitra que plus tard. Notre RFC 5569 décrit le déploiement actuel, un « meilleur » protocole est en préparation.)

Il est resté de nomnbreux mois dans la file d'attente du RFC Editor, en raison de son statut de « soumission indépendante », dont les droits n'ont pas été définis avant le RFC 5744. Mais l'approbation technique était ancienne, datant d'avril 2009. Comme l'avait signalé l'auteur, dans son coup de gueule en séance plénière de l'IETF à Hiroshima en novembre 2009, « Ce RFC décrit comment déployer IPv6 en cinq semaines et voilà cinq mois qu'il attend, pour des raisons non-techniques. »

En 2007 est paru l'article « Some thoughts on security after ten years of qmail 1.0 », de Dan Bernstein, sur la sécurité des logiciels. Comme toujours avec cet auteur, l'article mélange bonnes idées, mauvaises idées et franche mauvaise foi.

Bernstein n'a pas changé sur un point, la malhonnêteté intellectuelle. Ainsi, en discutant de la sécurité des MTA, il tape uniquement sur sendmail, qui n'est plus guère utilisé sur les nouveaux sites, et ne dit pas un mot de Postfix, Exim ou Courier. Et pour cause, cela démolirait sa thèse comme quoi qmail est le seul MTA sûr...

D'autre part Bernstein se vante lourdement et tout le temps du défi de sécurité qu'il avait lancé pour qmail en mars 1997 : le principe est d'offrir une récompense monétaire à celui qui trouvera une faille de sécurité dans qmail. La récompense attend toujours qu'on la réclame. Mais ce genre de défis ne vaut pas grand'chose. D'une part, l'absence de signalement peut indiquer l'absence d'intérêt et pas l'absence de bogue (c'est courant pour les logiciels peu utilisés). Mais, surtout, ce genre de défis est en général soumis à des règles fixées par l'auteur et soigneusement conçues pour qu'on ne puisse jamais s'y conformer. Ainsi, le défi de sécurité qmail exclut les attaques par déni de service, de loin les plus fréquentes. Cela me rappelle un contrat de maintenance d'une entreprise privée pour s'occuper d'un serveur Windows où le contrat excluait les dommages liés aux virus. Exclure les conséquences des virus de l'administration d'une machine Windows, c'est comme exclure les dégâts des eaux du contrat de maintenance d'un sous-marin...

Mais est-il possible d'inclure les attaques par déni de service dans les conditions d'un tel défi ? Ce n'est pas une question facile : il existe deux sortes d'attaques par déni de service, celles qui reposent sur la force brute (on a une ligne rapide et une grosse machine et on écrase la victime sous le poids, par exemple en envoyant des millions de paquets) et celles qui reposent sur l'amplification, où un trafic faible pour l'attaquant peut faire beaucoup de dégâts. Par exemple, la faille dynamic update de BIND en juillet 2009 était dans cette catégorie : un seul paquet DNS pouvait stopper complètement le serveur. S'il n'y a pas de méthode générale pour faire face aux attaques par force brute, en revanche, on peut éviter les amplifications, les attaques où l'assaillant peut obtenir des résultats sans disposer des dizaines de milliers de machines d'un botnet. Il n'y a donc pas de raison d'exclure toutes les attaques par déni de service. Mais on comprend mieux cette décision de Bernstein quand on voit qu'une telle faille de sécurité a déjà été trouvée pour qmail... et refusée par l'auteur. Bref, les défis de sécurité lancés par l'auteur d'un logiciel ne servent pas beaucoup, il rejetera toujours les bogues trouvées. (Une liste des bogues de qmail est disponible, plusieurs affectant la sécurité.)

Maintenant, quelles sont les idées intéressantes dans ce papier ? Parmi les principales, il y a l'idée que les bogues dans le code sont inévitables mais ne devraient pas forcément être des failles de sécurité. Si le code, par exemple le code d'analyse des en-têtes d'un message, a une bogue, elle va empêcher l'analyse correcte desdits en-têtes mais elle ne devrait pas pouvoir mener à une attaque du système. Bernstein ne les cite pas, mais c'est une des motivations derrière les langages purs, comme Haskell, où le code, par défaut, ne peut pas avoir d'effets de bord. L'idée de base est que le code d'analyse des en-têtes devrait avoir des entrées et des sorties limitées et aucun accès au système (ce qui est très difficile à assurer dans un langage comme C).

Bernstein s'attaque aussi à certaines idées fausses en sécurité comme le fait de corriger les bogues (alertes de sécurité accompagnées de patches) : cela revient à résoudre les attaques d'hier, alors qu'il faudrait plutôt travailler à rendre plus difficiles celles de demain.

Comme beaucoup de programmeurs expérimentés, Bernstein met en garde contre l'optimisation prématurée, cette tendance à se préoccuper de performance sans avoir mesuré (et c'est un des rares points où il fait une auto-critique, à propos de l'optimisation du mécanisme de stockage de la liste des domaines gérés par qmail). Il plaide donc fortement pour faire passer la sécurité avant la performance, surtout si on n'a pas réellement mesuré le coût en performance d'une mesure de sécurité.

Bernstein suggère aussi des pistes pour limiter le nombre de bogues. Un exemple serait un mécanisme dans le langage de programmation pour mettre à jour automatiquement les variables « de résumé » (comme « le nombre d'éléments non nuls de la liste », sans doute du genre de ce que permettent les triggers de SQL. De même, il appelle de ses vœux des mécanismes pour étendre automatiquement les tableaux (mais sans citer les langages qui font déjà cela depuis longtemps comme Perl).

Parmi les autres idées de Bernstein, concevoir systématiquement les langages de programmation de façon à ce que les programmes bogués soient plus durs à faire que les programmes corrects. Il cite l'exemple de l'addition d'entiers. En C, par défaut, l'addition se fait modulo la taille de int et il faut explicitement utiliser une bibliothèque de bigint pour avoir l'addition courante. Cela devrait être le contraire, les cas où on veut vraiment une addition modulo étant rares. (Ce point a fait l'objet d'une bonne discussion sur LWN.)

Bernstein pointe aussi du doigt les problèmes de sécurité posés par l'analyse, le fait de convertir des données non structurées en données structurées, avec ses conséquences comme le besoin d'échappement, source, par exemple, de tant d'injections SQL.

Comment améliorer aujourd'hui la sécurité des logiciels ? Bernstein a plein d'idées. L'une d'elles a donné naissance à un logiciel spécifique, isolate. Le principe est de faire tourner le programme après avoir sérieusement limité ce qu'il a le droit de faire. Par exemple, sur Unix :

• L'empêcher de créer fichiers ou prises en mettant "RLIMIT_NOFILE" à 0 avec "setrlimit()",
• Le faire tourner sous un UID spécifique,
• etc.

L'IANA vient d'allouer deux préfixes IPv4 à l'APNIC, les 1.0.0.0/8 et 27.0.0.0/8. Comme l'a noté le NRO, cela rapproche dangereusement de la fin des adresses IPv4. Mais un autre point a été moins traité : ces adresses ne vont-elles pas poser des problèmes à leur titulaire ?

En théorie, une adresse IP n'est qu'une série de chiffres. Elles devraient donc toutes être équivalentes. Mais, en pratique, ce n'est pas le cas. Certaines adresses valent plus que d'autres. Ici, le problème potentiel avec 1.0.0.0/8, comme discuté sur Nanog est que ces adresses sont simples et jolies. Cela pourra permettre à leur titulaire de parader mais cela augmente aussi le risque de collision : des tas de cours ont été écrits où l'adresse IP d'exemple est 1.2.3.4 et on ne sait pas combien d'équipements ont été configurés avec cette adresse, ou combien de sites ont stupidement utilisé ce préfixe pour la partie privée de leur réseau... (Cela a déjà été fait par des incompétents comme les gens d'anoNet ou, pour un autre préfixe qui va bientôt être distribué, par ceux, tout aussi stupides, de Hamachi.) Notez au passage que le choix des deux préfixes qui viennent d'être alloués a été fait au hasard, selon la méthode du RFC 2777, justement pour tenir compte de cette inégalité des adresses.

Comme l'a dit Alain Durand dans la discussion Nanog « L'eau à la fin du tonneau (d'adresses IPv4) est moins propre »...

Sur le même sujet, un bon article d'Andree Toonk, « Issues with allocating from 1.0.0.0/8 » qui, en se basant sur l'analyse des annonces BGP des derniers mois, montre que le problème est réel, et une excellente étude du RIPE montrant à quel point certaines parties de 1.0.0.0/8 sont polluées.

Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter.

Réservez votre weekend du 24/25 avril pour venir voir le soleil en discutant de Django et plus généralement du web, troller sur les derniers buzzwords et tout simplement rencontrer des personnes intéressantes.

Participer

L'événement est gratuit et bénévole. Par contre les inscriptions sont OBLIGATOIRES pour que l'on arrive avec des chaises pains au chocolat pour tout le monde.

Notez que vous pouvez faire un don lors de l'inscription si vous voulez supporter l'événement. Il n'y a pas eu d'asso créée pour l'occasion car de l'expérience que j'ai ça ajoute de la paperasse pour pas grand chose au final (et ça j'en ai suffisamment pour franchement pas avoir envie d'en ajouter !). Puis je voulais tester dans quelle mesure le modèle du don fonctionne aussi, vous vivez une expérience :-).

Il est également possible de sponsoriser l'événement. Je donne 2 exemples avant que vous vous demandiez comment faire les choses proprement s'il n'y a pas d'asso :

• payez le billet/l'hôtel de vos salariés/intervenants pour venir à Marseille, je suis conscient que le choix de ne pas le faire à Paris peut poser des problèmes à ce niveau mais j'aimerais bien que ce ne soit pas un trop gros frein ;
• offrez le goûter/les boissons/un repas/ce que vous voulez pour l'événement et vous récupérez directement la note que vous mettez en compta.

Je ne sais pas encore quelle visibilité auront les sponsors, mais ils en auront donc manifestez-vous !

Intervenir

Le programme n'est pas encore complet et j'en profite pour faire un appel à orateurs car sur 2 jours il y a vraiment de la place pour beaucoup de choses intéressantes. Je vais essayer de contacter le plus de personnes proches auxquelles je pense mais c'est pas comme pour le vaccin, n'hésitez surtout pas à m'envoyer directement un mail si vous êtes motivé(e) !

Dans la façon dont je vois les choses, ça peut être assez éloigné de Django donc soumettez moi vos idées et on en discute.

Il y aura également de la place pour des ateliers/sprints pour ceux qui ne peuvent pas se retenir de coder plus d'une journée.

Logistique

C'est sur ce plan là où on est un peu à la bourre, notamment au niveau du logement mais on va travailler d'arrache pied avec Jean-Michel pour tenter de proposer une bonne solution.

D'ailleurs, tout cela n'aurait pas pu être possible sans Jean-Michel qui m'a motivé et qui a réussi à trouver des salles ! Il mérite un vrai bisou de poney magique. Merci également aux orateurs qui ont déjà répondu présent !

J'ai dû oublier la moitié de ce que je voulais dire dans ce billet, ah oui, le tag officiel c'est #djangocong car ça faisait marrer sur irc. J'espère vous retrouver nombreux, en attendant vous pouvez suivre @djangocong sur twitter pour être informé de l'avancée des préparatifs ;-).

Note : si vous êtes graphiste et que vous avez une idée de logo pour l'événement, ça serait bienvenu. Si vous avez en plus de faire un design de site, ça serait encore mieux !

La question peut être choquante si l’on s’imagine que la richesse est un attribut qui ne détermine pas les modes de pensées et que, l’un dans l’autre, ce qui distingue le riche du pauvre est seulement que le premier a de l’argent.

L’entretien avec l’économiste Esther Duflo parue dans le Télérama n° 3131 est à ce titre éclairant.

Pourquoi les gens (on parle ici des populations défavorisées des pays en voie de développement) n’envoient-ils pas leurs enfants se faire vacciner ? Pourquoi ne dépensent-ils pas tout leur argent pour se nourrir, alors qu’ils meurent de faim ? Pourquoi assiste-t-on a de tels comportements illogiques du point de vue de l’économiste, se demande Esther Duflo.

Elle donne deux pistes qui me semblent importantes.

« On sait que l’homme, aussi pauvre soit-il, ne peut pas penser toute la journée à des choses négatives : il se fabrique un « filtre » pour appréhender le réel, il « colore » les choses, refuse d’imaginer qu’il va tomber malade et qu’il devrait s’assurer. Bref, il finit par faire des arbitrages qui nous paraissent illogiques. »

« On oublie que dans nos sociétés privilégiées, on a de moins en moins de décisions à prendre, alors que ceux qui vivent avec moins d’un dollar par jour ont des dizaines de choix cruciaux à faire quotidiennement.  La plupart [...] ne sont pas assurés d’avoir encore du boulot demain. On comprend mieux pourquoi la vaccination n’arrive pas en tête de leurs préoccupations… »

« Votre cerveau se remplirait soudain de préoccupations auxquelles aujourd’hui vous ne pensez même plus. »

Finalement, je me dis que ces aspects psychologiques et cognitifs sont partagés par tous, car moi aussi j’ai un « filtre psychologique à emmerdements », et moi aussi j’ai un « cognitive overflow » qui m’empêche d’avoir le temps de me faire vacciner ou de renouveler ma carte d’identité périmée depuis un an.

Seulement voilà, les impacts sont tous autres car le pauvre est empêtré dans des problématiques de subsistantes alors que nous sommes quand même au niveau des consistances.

Le tremblement de terre qui a frappé Haïti le 12 janvier 2010 a déjà fait l'objet de beaucoup d'articles, notamment sur les mesures d'aide qui ont été prises. Je voudrais ici détailler un aspect tout à fait secondaire, mais qui illustre bien le fonctionnement actuel de l'Internet : la reconfiguration du domaine de premier niveau , pour lui garantir un fonctionnement prolongé. (Cet article est conçu pour tous, des détails techniques sur le DNS figurent à la fin.)

Comme tous les pays, Haïti a un nom de domaine dit « de tête » ou « de premier niveau », qui identifie le pays. En l'occurrence, c'est . On peut donc avoir des ressources Internet avec des noms comme www.fds.edu.ht ou rddh.org.ht. Les liaisons Internet ont toutes été détruites lors du tremblement de terre mais les ressources (par exemple les sites Web) accessibles via un nom en .HT étaient parfois hebérgés à l'extérieur du pays et pouvaient donc continuer à être accessibles... si les noms en .HT marchaient toujours. Malheureusement, beaucoup de domaines (y compris des domaines de tête) sont publiés par un nombre de serveurs très limités, tous situés en un seul endroit. En cas de panne électrique ou de coupure de la liaison Internet, le service de noms ne fonctionne plus et, même si le serveur Web est toujours là, les clients ne peuvent plus trouver son adresse et donc le joindre.

Au contraire, est bien géré (et bravo à ce sujet à Stéphane Bruno et Max Larson Henry) : il a six serveurs de noms, deux en Haïti, un en France, un au Canada, un aux États-Unis et un autre, géré depuis les États-Unis mais physiquement distribué sur toute la planète. .HT n'a donc jamais cessé de fonctionner.

Par contre, cela ne pouvait pas durer éternellement : pour des bonnes raisons techniques, les serveurs secondaires, situés à l'étranger, arrêtent tout service s'ils ne peuvent pas joindre le primaire pendant un certain temps. Et, de toute façon, toute modification des noms en .HT est gelée tant que le primaire n'est pas joignable.

S'il n'y avait pas d'urgence immédiate, il fallait néanmoins agir. En l'absence de toute communication avec les gérants du .HT, dans la nuit du 14 au 15 janvier, les responsables des serveurs secondaires, sous l'impulsion de Bill Woodcock, de PCH, ont commencé à reconfigurer .HT pour un fonctionnement plus durable. Une copie de la base de données du registre se trouvait en Australie, chez Cocca. Un de leurs techniciens, Garth Miller, a configuré une machine comme primaire, les gérants des secondaires ont changé à leur tour la configuration de leurs machines (merci à Jean-Philippe Pick pour avoir réagi particulièrement vite) et, le 16 janvier au soir, après quelques problèmes techniques, .HT retrouvait un fonctionnement normal, qui pourra durer jusqu'à ce que les liaisons Internet avec les gérants de .HT et leurs ordinateurs soient rétablies. (Nous avons appris depuis que l'immeuble où se trouvait les serveurs a été réduit en poussière. Des organismes comme l'AFNIC travaillent à remplacer ces machines dès que les secours d'extrême urgence pourront laisser la place à l'envoi de matériel informatique. Une partie de l'infrastructure Internet sur place fonctionne encore, notamment le point d'échange sur la colline de Boutilliers, grâce à Reynold Guerrier.)

Le point important à noter est qu'aucun autorité n'a ordonné ou même approuvé ce changement. Aucun comité ne s'est réuni. Aucune signature n'a été donnée. Les seules personnes pouvant décider, à Port-au-Prince, étant injoignables, le travail de reconfiguration a été fait entièrement entre administrateurs système des serveurs secondaires. La sécurité de l'Internet n'est en effet pas celle de murs de béton défendus par des règlements et des procédures. C'est celle d'un organisme vivant, dont les leucocytes sont intelligents et capables d'initiative. (Bien sûr, les administrateurs de .HT ont été informés.)

Les leçons à en tirer ? La première est d'assurer la redondance des serveurs de noms. Ils doivent être plusieurs, et répartis en des endroits très différents, pour faire face aux différents types de panne. On peut noter par exemple que n'a que deux serveurs (un troisième est annoncé mais ne répond jamais), tous les deux à Dhâkâ. En cas de problème frappant cette ville, comme une inondation, tous les noms se terminant par .BD disparaissent. De même, n'a que deux serveurs, tous les deux à Papeete. N'importe quelle carastrophe naturelle rendrait donc ce domaine inutilisable.

La redondance des serveurs est une chose, celle des données en est une autre. (Dans le cas d'un registre de noms de domaines, la base de données contient la liste des noms délégués.) S'il n'y avait pas eu une copie de la base de données à l'extérieur du pays, elle était peut-être perdue. Il faut donc aussi s'assurer que les données sont réparties.

Bien sûr par rapport au drame que viennent de vivre les habitants d'Haïti, c'est tout petit. Mais j'espère que les petites gouttes d'eau feront les grandes rivières : chaque problème réparé est un outil en plus pour les autres réparations. Au fait, depuis ce travail, Stéphane Bruno a pu être joint, il va bien et il a approuvé le changement. Même chose pour Max Larson Henry.

D'autres utilisations intelligentes de l'Internet ont été faites comme le moteur de recherche des disparus de Google (disponible en anglais, français et créole) ou comme le flux d'informations Twitter de Carel Perdre.

Comme promis, quelques détails techniques, pour ceux qui connaissent le DNS. Ce protocole est très résistant aux pannes et, si les serveurs sont bien répartis comme ils doivent l'être, un domaine peut résister à n'importe quelle catastrophe. Mais que se passe t-il ensuite ? Les serveurs secondaires (le terme correct aujourd'hui est d'ailleurs « serveur esclave » pour de bonnes raisons mais, dans le contexte d'Haïti, j'ai préféré l'éviter) continuent à servir la zone pendant une période qui est gouvernée par le champ Expire de l'enregistrement SOA (cf. RFC 1035, section 3.1.3). Ce champ vaut actuellement pour .HT 1296000 secondes soient deux semaines et, si rien n'avait été fait, le domaine .HT aurait donc disparu dans quinze jours (le but de ce champ est d'éviter qu'un ancien esclave oublié continue à servir des données dépassées éternellement). Il y a une seconde raison pour le travail de reconfiguration qui a été fait : il permet de modifier la zone et donc, si nécessaire, d'ajouter des nouveaux domaines ou bien de changer les adresses IP des serveurs de noms des domaines existants, pour assurer leur continuité (un serveur esclave, comme son nom l'indique, ne peut pas modifier les données). Aujourd'hui, on voit que les quatre serveurs extérieurs (dont le serveur anycast de PCH) sont bien à jour (ils ont tous le même numéro de série, qui est postérieur au séisme) :

% check_soa ht
There was no response from ns2.nic.ht
There was no response from ns1.nic.ht
dns.princeton.edu has serial number 2010011820
charles.cdec.polymtl.ca has serial number 2010011820
ht-ns.anycast.pch.net has serial number 2010011820
ns3.nic.fr has serial number 2010011820

Le domaine nic.ht a été à son tour reconfiguré sur le même principe, avec l'idée de faire revivre le NIC à distance.

D'autres articles sur les technologies de l'information et Internet, dans le tremblement de terre :

• Un bon exposé de la situation (http://www.circleid.com/posts/20100126_haitis_telecommunications_sector_in_the_aftermath/) du réseau à Haïti
• Un autre article, contenant peu de détails, sur la reconfiguration de ".HT" : « Situation in Haiti and the DNS (http://blog.icann.org/2010/01/haiti/) »
• Un effort beaucoup plus considérable, pour actualiser les cartes d'OpenStreetMap (http://www.ecrans.fr/Haiti-Mobilisation-autour-d-une,8961.html)

Le groupe de travail rtgwg de l'IETF travaille entre autre à définir des protocoles et des méthodes pour éliminer les micro-boucles lors d'un changement des routes dans un réseau IP. Une micro-boucle est la boucle temporaire qui se forme entre deux (parfois davantage) routeurs lorsqu'ils n'ont pas mis à jour leur table de routage pile en même temps. Pendant quelques secondes, le routeur A envoie les paquets à B, qui les envoie à A, qui les envoie à B... Notre RFC 5715 explique le problème, ses causes et ses effets, et expose les solutions existantes.

La section 1 rappelle le fonctionnement du routage IP. Les routeurs n'ont pas une vue commune du réseau. Lorsque celui-ci change, que ce soit suite à une « mauvaise nouvelle » (la rupture d'un câble) ou suite à une « bonne nouvelle » (l'ajout d'un nouveau lien), il faut un temps fini pour propager l'information à tous les routeurs et pour que ceux-ci mettent à jour leur FIB. Pendant ce temps de convergence, les routeurs ne fonctionnent pas sur une vision commune et les micro-boucles apparaissent. Les paquets vont alors tourner en rond, consommant de la capacité du réseau, avant d'être jetés lorsque leur TTL (Hop Count en IPv6) est terminé.

Ces micro-boucles sont-elles graves ? En général, les protocoles situés au dessus corrigent automatiquement. Mais de nouveaux services Internet pourraient être plus sensibles et souhaiteraient une transition sans douleur, sans délai et sans perte de paquets.

Cet idéal est évidemment utopique mais il existe quand même des méthodes pour améliorer les choses comme celles du RFC 4090 pour MPLS ou du RFC 5714 pour IP.

Parmi les voies possibles pour traiter le problème des micro-boucles, il y a des techniques de convergence suffisamment rapides pour que le problème soit minimal, ou bien des topologies du réseau qui rendent les micro-boucles rares ou impossibles.

La section 2 est consacrée à étudier plus en détail ce qu'est une micro-boucle et dans quelles conditions elles se forment. La micro-boucle est un phénomène temporaire, inévitable dans un paradigme de routage « saut après saut » qui est celui d'IP (chaque routeur ne se préoccupe que du saut suivant). Elle est « micro » par sa durée et par le petit nombre de routeurs en jeu (souvent seulement deux). La création d'une boucle nécessite au moins une des conditions suivantes :

• Liens dont les coûts sont asymétriques,
• Existence entre deux routeurs de deux chemins, de coût égal, avec des routeurs qui tranchent de manière différente lorsque deux chemins sont possibles et équivalents,
• Et surtout, ce qui est la cause des micro-boucles, changement de topologie du réseau, pendant la phase de transition. Ce changement est souvent une panne mais ce peut aussi être un ajout d'un nouveau lien, ou bien une action délibérée de l'administrateur réseaux, par exemple parce qu'il change le coût d'un lien.

• Consommation inutile de la capacité du réseau (un paquet peut passer 128 fois dans chaque sens, avant que son TTL n'expire),
• Risque pour la convergence des routeurs car le trafic des protocoles de routage, s'il est pris dans la boucle, risque de ne pas atteindre son destinataire, l'empêchant de mettre sa table à jour.

Que peut-on faire contre les micro-boucles ? C'est un travail pour la section 4 et des suivantes. Il existe plusieurs stratégies, limiter les dégâts, empêcher les boucles de se former, les supprimer quand elles apparaissent ou bien minimiser le risque d'occurrence (par exemple par des réseaux avec davantage de maillage). Elles sont détaillées dans les sections suivantes. D'abord, la section 5 explique comment limiter les dégâts, soit en accélérant la convergence du réseau, soit avec la méthode PLSN (Path Locking with Safe Neighbors), non encore décrite dans un RFC (mais résumée en section 7), qui consiste à tenir compte de l'état du réseau avant et après le changement avant de choisir d'envoyer dorénavant du trafic à un voisin. La simulation montre que cette méthode est efficace mais elle ne fait que limiter les micro-boucles, pas les empêcher.

Et la prévention ? La section 6 est là pour ça. Elle ne liste pas moins de huit méthodes pouvant empêcher les micro-boucles de se former. Mais toutes ne sont pas réalistes. Parmi elles :

• Au lieu de faire passer d'un coup le coût d'un lien coupé de N à « infini », l'incrémenter doucement. L'analyse montre que cela suffira (section 6.1).
• Divers systèmes d'overlays ou de tunnels (sections 6.2 à 6.4). Cela aurait évidemment les inconvénients habituels des tunnels (comme la faible performance de beaucoup de routeurs avec ce type de trafic).
• La cause fondamentale des micro-boucles étant le manque d'information, on pourrait aussi marquer les paquets pour indiquer par où ils sont passés, ce qui permettrait de détecter facilement qu'un paquet est déjà passé et qu'il y a donc une boucle (section 6.5). Mais cela compliquerait les routeurs de manière non-standard.
• On pourrait enfin introduire davantage de synchronisation entre les mises à jour des FIB de chaque routeur (sections 6.7 et 6.8). Actuellement, le changement de FIB se fait dans chaque routeur indépendamment. On pourrait imaginer que chaque routeur calcule la nouvelle FIB (sans l'installer), qu'un algorithme permette de sélectionner le moment du changement et, si tous les routeurs sont à l'heure avec NTP, ils basculeraient au même moment.

Et la suppression des boucles, une fois qu'elles sont formées ? Pour détecter la micro-boucle, La section 8 examine deux possibilités, une forme de mémoire des paquets déjà vus, dans le routeur (très consommatrice en ressources) et une méthode plus simple : détecter une boucle au fait qu'un paquet entre par l'interface où on le ferait sortir (mais cela ne marche que pour les boucles simples, symétriques).

Quel que soit le mécanisme adopté, il va falloir le déployer dans l'Internet existant et la section 9 rappelle donc l'importance de la compatibilité avec cet existant.

Enfin, une comparaison des différentes méthodes occupe la section 10. Plusieurs méthodes semblent réalistes pour les protocoles futurs.

IP a une propriété très utile : la route entre deux points n'est pas fixée à l'avance et peut être modifiée même en cours de conversation. Cela permet aux réseaux IP de continuer à fonctionner même lorsque des coupures surviennent, s'il existe un chemin alternatif. Par contre, trouver ce chemin alternatif et l'utiliser prend du temps et ce délai peut être fatal à certaines applications plus ou moins temps-réel. D'où la nécessité de développer une méthodologie et des mécanismes pour un reroutage rapide. Ce RFC 5714 est consacré à décrire le cadre général de ce reroutage rapide.

De tels mécanismes existent déjà pour certains protocoles de couche 2, comme SONET, ou de couche « 2,5 » comme MPLS. Mais le but du travail sur le reroutage rapide IP est d'avoir une solution générale pour tous les réseaux IP.

Donc, après une section 1 de terminologie, commençons par décrire le problème (section 2). Lorsqu'un lien physique tombe en panne, même si des liens alternatifs sont disponibles, il s'écoule une période non nulle pendant laquelle les paquets ne peuvent plus être transmis. Ces paquets sont alors souvent jetés par les routeurs. Traditionnellement, dans un réseau IP, les durées de ces périodes atteignaient facilement plusieurs secondes. Pour certains applications (par exemple SMTP) ce n'est pas un problème. Mais certains services récents ont davantage de mal à tolérer ces courtes coupures. Calculer de nouvelles routes, dans un environnement distribué comme l'Internet, ne peut pas être « temps-réel ». Mais il existe une autre solution : calculer à l'avance les routes de secours ce qui permettrait de remplacer la route passant par le lien en panne en un temps bien plus court. C'est l'approche utilisée par le mécanisme Fast Reroute de MPLS (RFC 4090) et le but du projet IP Fast Reroute est de spécifier des mécanismes analogues dans un environnement purement IP.

Ces mécanismes sont loin d'être complètement définis, notre RFC 5714 se contenant de définir un cadre général pour leur élaboration. D'autre part, le projet se limite pour l'instant aux IGP à état des liaisons (section 3), une extension aux autres IGP ou bien aux protocoles de routage externes comme BGP étant possible dans le futur.

La section 4 du RFC analyse le problème. D'où vient le délai avant que la route alternative soit utilisable ? Il y a plusieurs sources de retard :

• Le temps de détection de la panne. Lorsque celle-ci peut être détectée physiquement (câble Ethernet débranché, avec perte du signal de lien), ce temps est parfois de quelques milli-secondes. Mais, lorsque la détection se fait par l'absence, pendant une certaine période, d'un message (par exemple le paquet "Hello" d'OSPF), alors, des durées de plusieurs dizaines de secondes sont possibles.
• Le temps pour le routeur de se reconfigurer.
• Le temps pour le routeur de passer l'information à ses voisins (de dix à cent milli-secondes par saut entre deux routeurs).
• Le temps de recalculer les tables de routage (quelques milli-secondes avec un algorithme comme celui de Dijkstra).
• Le temps de recharger les nouvelles tables, par exemple en reconfigurant les ASIC. Il peut atteindre des centaines de milli-secondes.

Quels sont les mécanismes disponibles pour faire mieux ? La section 5 les expose. Pour la détection de la panne (section 5.1), l'aide du matériel est bien pratique : si la fibre est coupée, la disparition de la lumière indique le problème immédiatement. Mais il existe aussi des protocoles indépendants du protocole de routage, et dédiés à la détection de pannes, comme BFD.

Pour réparer la panne, l'idée de base est de pré-calculer les chemins alternatifs, ce qui permettra de les installer rapidement (section 5.2). La plupart des pannes devraient pouvoir être réparées avec les techniques du RFC 5286, qui ne nécessitent pas de marquage spécial des paquets IP. Pour les autres, des techniques plus avancées sont nécessaires comme le calcul et le stockage à l'avance de plusieurs FIB dans les routeurs, combinés avec un mécanisme de signalisation permettant d'indiquer que le paquet doit prendre la route de secours. Des mécanismes reposant sur un routage explicite, par exemple avec des tunnels, sont également possibles.

Au fait, j'ai utilisé des termes vagues comme « la plupart ». Peut-on les quantifier ? La section 5.2.2 analyse le succès de chaque mécanisme en fonction de la topologie.

Enfin, pour la prévention des micro-boucles, la section 5.3 renvoie au RFC 5715 qui liste les possibilités.

Résumé

L'application de règles heuristiques explicites permet tout à la fois d'optimiser la recherche d'informations sur Internet et de favoriser la sérendipité. Un exemple de recherche documentaire concernant des images historiques illustre ce point de vue.

Recherche d'informations sur Internet, sérendipité et heuristique Paru en 2008, l'article de Nick Carr Is Google Making us Stupid? critiquait les effets d'Internet sur nos facultés de cognition. Selon l'auteur, l'usage intensif du réseau et singulièrement des outils de recherche altèrerait nos capacités de concentration et de réflexion. L'article a... Lire Heuristique et sérendipité : un exemple en images

Il y a quelque chose que je n’arrive pas à m’expliquer : pourquoi, dans les organisations, y a-t-il aussi peu de tableaux dans les locaux ? Je ne parle pas de ces ridicules trépieds ou ces petits tableaux blancs que l’on peut coller au dos d’une porte : je parle de vrais tableaux de plus de trois mètres de long et d’un mètre de haut. Quelque chose où la pensée peut se matérialiser tout en étant à ses aises.

Dans l’enseignement la présence des tableaux est une évidence, alors pourquoi ne l’est-elle pas dans ces organisations qui mettent en avant la valorisation de la connaissance dans leur activité ? Quel crédit apporter à une entreprise qui n’a pas de grands tableaux dans ses locaux ? Même dans les salles dédiées à la formation, on se retrouve parfois avec un simple projecteur et un misérable trépied avec du papier déjà rempli. C’est quand même pas compliqué de mettre des tableaux !

Le tableau est un support de travail qui nous a accompagné et avec lequel nous nous sommes formés durant toute notre scolarité et puis, lorsqu’on rentre dans la vie professionnelle ..pschiiiit. Il disparaît.

Pourquoi ? Peut être pour monter qu’ici on n’a plus rien à apprendre ? Plus rien à transmettre ni à enseigner ?

On a pu s’émerveiller des locaux de Google (resto, mobilier, salle de jeu, poufs, etc) mais l’essentiel c’est les grands tableaux blancs. Dans les locaux de Google Paris, c’est carrément les murs qui sont des tableaux blancs. Je suis vraiment pour ce type d’initiative où « Mur = Tableau = Support de travail ».

Comme une partie de Capgemini vient de déménager à Suresnes, je constate que les locaux sont beaux, agréables, fonctionnels …mais on a encore oublié les grands tableaux !

Depuis le temps qu'on parle d'empoisonnement DNS, par exemple suite à la faille Kaminsky, je n'avais jamais eu l'occasion d'en observer un en vrai. Des essais, bien sûr, des résultats de tests, mais une vraie attaque menée dans le but de détourner du vrai trafic, j'en avais entendu parler mais jamais vu ça de mes propres digs. C'est désormais fait.

Tout a commencé sur Twitter : (17:07:09) oneeyed: whois.com hacked http://bit.ly/7IaCfm. Je regarde et http://whois.com/, service de recherche via whois, semble normal. D'autres personnes le voient normal. En fait, le site Web est intact, il n'a pas été défiguré, c'est le DNS du FAI Free qui a des problèmes. Je ne m'en étais pas aperçu car j'utilise mon propre résolveur DNS. Mais, en interrogeant ceux de Free, on trouve des données normales sur le serveur 212.27.40.241 mais pas sur l'autre résolveur que Free met à la disposition de ses clients :

% dig +short @212.27.40.240 A whois.com
94.102.7.12

Donc, il semble bien qu'il y aie eu empoisonnement (par un moyen inconnu de moi) d'un des résolveurs DNS de Free. Pendant un certain temps (environ une heure, semble t-il), tous les clients de Free qui tombaient sur ce résolveur étaient envoyés au mauvais serveur. Le problème a ensuite disparu, probablement parce qu'un technicien de Free a redémarré le serveur.

Quelques leçons :

• Ce genre de problèmes n'est pas spécifique à Free : d'autres FAI peuvent l'avoir et rien n'indique qu'il soit dû à une erreur ou une défaillance de Free. On trouve plus facilement des rapports sur Free car ce fournisseur a des gens férus de techniques, alors qu'ils sont complètement absents chez d'autres FAI, qui peuvent donc faire n'importe quoi en étant sûrs de ne pas être observés.
• Je n'ai pas vu le serveur « pirate » et "94.102.7.12" ne le sert apparemment plus, donc je ne sais pas quel était le but poursuivi par l'attaquant.
• Bien sûr, DNSSEC aurait détecté le problème. Mais DNSSEC soulève d'autres questions.

Merci à Samuel Tardieu pour m'avoir signalé le cas rigolo. Voir aussi la discussion sur Reddit.

Julien Gautier est membre d’Ars Industrialis et s’occupe également de Skhole. Le 10 décembre 2009 il est intervenu dans le cadre de la journée organisée par SAGA à Bobigny.

Voici l’enregistrement audio (également disponible dans le Podcast Ars Industrialis)

Au delà de la qualité de l’intervention sur le fond, j’ai beaucoup apprécié le rythme et la prosodie du discours.

Un grand moment.

Pendant longtemps, les documentations ou cours sur TCP/IP utilisaient dans les exemples des adresses IP prises un peu au hasard, par exemple sur le réseau de l'auteur. Cela entrainait des problèmes si un lecteur prenait ces exemples trop littéralement et réutilisait ces adresses, rentrant ainsi en conflit avec les adresses existantes. Le RFC 1166 avait donc commencé la bonne tradition de réserver des adresses pour la documentation, tradition que continue notre RFC 5737 (voir aussi le RFC 5735).

Comme le rappelle la section 1, la limite du préfixe 192.0.2.0/24 qui avait été réservé par le RFC 1166 était qu'il était tout seul : un cours sur OSPF ou BGP était assez difficile à faire avec des adresses commençant toutes par 192.0.2. Deux autres préfixes ont donc été ajoutés, 198.51.100.0/24 et 203.0.113.0/24 (section 3). IPv6, lui, a le 2001:db8::/32 du RFC 3849 et les noms de domaine ont les example.org et autres example.net du RFC 2606.

Puisque ces trois préfixes IPv4 sont réservés à la documentation, ils ne devraient jamais apparaitre sur des vrais réseaux, par exemple via BGP (section 4). On peut donc les ajouter aux listes de bogons.

À noter enfin que, contrairement à ce qu'on lit parfois, le préfixe 128.66.0.0/16 n'est pas réservé (section 5) pour la documentation et peut être utilisé pour de vraies allocations.

Lors du débat politicien sur l', de nombreux intervenants se sont réclamés du christianisme. Par exemple, « [Être français] c'est a dire reconnaitre tout autant " le blanc manteau de ses cathédrales "et ses raçines judéo-chrétiennes que les principes de liberté-égalité-fraternité du pacte républiquain [sic] ». Ou bien « La France et notre identité nationale, c'est une cathédrale au centre de Paris et non pas une mosquée. ». C'est donc l'occasion de relire leur texte sacré, la Bible.

Pas de chance, première histoire que je lis (Josué, 6.21), j'apprends que juste après la victoire des bons contre les méchants, « Ils [les gentils] vouèrent à l'interdit tout ce qui se trouvait dans la ville, aussi bien l'homme que la femme, le jeune homme que le vieillard, le taureau, le mouton et l'âne, les passant tous au tranchant de l'épée. » Puis (6.24), « Quant à la ville, ils l'incendièrent ainsi que tout ce qui s'y trouvait, sauf l'argent, l'or et les objets de bronze et de fer qu'ils livrèrent au trésor de la maison du Seigneur. » On ne dit pas ce qu'ils ont fait des enfants... (Traduction TOB.)

Charmantes coutumes, sans doute courantes à l'époque. D'autres que les hébreux le faisaient sans doute à l'époque. Mais on n'a pas fait des massacres et des pillages commis par eux un livre sacré.

Ah, au fait, pourquoi cette bataille de Jéricho ? Parce que les hébreux, revenant d'Égypte, n'avaient pas de terre et trouvaient plus simple de prendre par la force celle des autres.

On comprendra que je me sente peu d'affinités avec mes « racines judéo-chrétiennes ».

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 (qui-controle-les-serveurs-racine.html). 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 (http://www.icann.org/en/announcements/announcement-04feb08.htm) 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 (http://www.icann.org/en/announcements/announcement-26oct09-en.htm) 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.