Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

echoping

Ève

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


RFC 7464: JavaScript Object Notation (JSON) Text Sequences

Date de publication du RFC : Février 2015
Auteur(s) du RFC : N. Williams (Cryptonector)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF json
Première rédaction de cet article le 26 février 2015


Un document JSON est normalement formé d'un texte JSON tel qu'un tableau ou un objet. Mais certains usages de JSON auraient besoin d'un autre genre de documents, une suite de textes JSON, séparés par un caractère de séparation bien défini. C'est ce que normalise ce RFC. Le nouveau type de document, application/json-seq, est formé d'une suite de textes JSON, séparés par les caractères ASCII U+001E, alias RS (record separator) et U+000A, alias LF (line feed).

JSON est normalisé dans le RFC 7159. Il est très utilisé dans un grand nombre de contextes. Du fait qu'un document JSON est un texte JSON (par exemple un objet ou un tableau), une grande partie des analyseurs JSON lisent tout et mettent tout en mémoire avant de le passer à l'application. Ce n'est pas bien adapté au cas où on écrit du JSON dans un journal, par exemple, et où on ne connait pas à l'avance la fin du document. Souvent, il n'y a pas à proprement parler de fin, et on ne peut donc pas utiliser un tableau car on ne saurait pas où mettre le ] final. Pire, imaginons une séquence d'un million d'entrées, chacune faisant un kilo-octet. Avec un analyseur ordinaire, cela ferait un giga-octet à mettre en mémoire, une quantité non triviale. Certes, il existe des analyseurs en flux (streaming), mais ils ne sont pas très répandus, et notre RFC les trouve difficiles d'utilisation.

D'où l'idée de ce RFC : une séquence de textes JSON, qui n'est pas elle-même un texte JSON, et qui peut être produite et consommée de manière incrémentale.

La définition rigoureuse figure en section 2. À noter que deux grammaires ABNF sont données, une pour les générateurs de séquences JSON et une pour les analyseurs. En application du principe de robustesse, la grammaire est plus tolérante pour les seconds : elle permet que les membres d'une séquence ne soient pas des textes JSON valides, afin que l'analyseur puisse continuer à traiter la séquence (cf. section 2.3). En revanche, le générateur doit produire une séquence composée uniquement de textes JSON valides. La grammaire stricte, pour les générateurs, est donc :


JSON-sequence = *(RS JSON-text LF)
     
RS = %x1E
LF = %x0A

JSON-text = <given by RFC7159, using UTF-8 encoding>

RS et LF sont définis dans le RFC 20. À noter que RS, caractère ASCII très peu utilisé, se nomme Record Separator en ASCII mais INFORMATION SEPARATOR TWO dans Unicode. Le choix de ce séparateur a suscité d'intenses débats dans le groupe de travail, avant que le consensus se fasse sur RS. En langue naturelle, cette grammaire se résume en « une séquence JSON est composée d'un nombre quelconque de textes JSON, chacun précédé d'un RS et suivi d'un LF ». Ils sont forcément encodés en UTF-8 (RFC 3629). Comme RS est un caractère de contrôle, il ne peut pas apparaitre directement dans un texte JSON (RFC 7159, section 7) et il n'y a donc pas de risque de collision avec un vrai RS. Je laisse mes lecteurs aventureux chercher comment on entre un caractère RS dans un fichier, avec leur éditeur favori...

Autre grammaire, plus laxiste, pour les analyseurs. Elle est :


JSON-sequence = *(1*RS possible-JSON)
...
possible-JSON = 1*(not-RS)
not-RS = %x00-1d / %x1f-ff; any octets other than RS

Elle est bien plus tolérante que la grammaire du générateur. L'idée est que, si l'analyse d'un texte « possiblement JSON » échoue, l'analyseur pourra sauter au suivant (éventuellement en signalant à l'application qu'il y a eu un problème) et traiter le reste de la séquence. Comme le décrit bien la section 2.3, une erreur n'est pas forcément fatale. Si l'analyseur était trop puriste, il ne pourrait pas traiter un journal où certaines entrées ont été tronquées (et ne sont donc plus des textes JSON valides) suite à, par exemple, un disque plein.

Ce principe de robustesse ne pose pas de problèmes si les textes JSON sont des tableaux ou des objets : une éventuelle troncation se détecte sans ambiguité. Ainsi, [116, 943, 234, 3879 a clairement été tronqué (il manque le crochet final). Il y a davantage de problèmes dans les cas où les textes JSON sont des entiers ou des littéraux comme true. Si on trouve 3879, était-ce bien 3879 ou bien la troncation d'un entier plus long ? C'est là que le LF (U+000A) à la fin de chaque texte JSON est utile, comme canari pour détecter une troncation. Un analyseur doit donc vérifier sa présence (le RFC est plus tolérant, en acceptant n'importe quel ws - RFC 7159, section 2) si le texte JSON n'était pas auto-délimité (les tableaux, objets et chaînes sont auto-délimités, mais pas les nombres ou certains littéraux comme null).

Au passage, un mot sur la sécurité (section 3) : les analyseurs de séquences JSON, comme tous les analyseurs de JSON, seront souvent utilisés sur des documents venus de l'extérieur, pas forcément validés. Ils doivent donc être robustes et ne pas faire de buffer overflow sous prétexte qu'ils rencontrent du JSON bizarre. Et, si vous voulez signer vos séquences JSON, n'oubliez pas que JSON n'a pas de forme canonique, et les séquences encore moins (comme l'analyseur est plus laxiste que le générateur, lire et écrire une séquence peut la changer, par exemple en ajoutant des LF à la fin des textes). Toute opération peut donc potentiellement invalider une signature.

Question mises en œuvre, il semble (je n'ai pas encore testé) que le couteau suisse de JSON, jq, gère ce nouveau format. (Si vous ne connaissez pas jq, je vous recommande cet article.)


Téléchargez le RFC 7464


L'article seul

Fiche de lecture : André Marie, sur les traces d'un homme d'État

Auteur(s) du livre: Christophe Bouillon, Mathieu Bidaux
Éditeur: Autrement
978-2-7467-4006-8
Publié en 2014
Première rédaction de cet article le 25 février 2015


De temps en temps, je lis des livre qui ne parlent pas d'informatique. Alors, pourquoi ne pas s'intéresser à la vie d'un homme politique des IIIe et IVe républiques ? Ce n'est pas qu'André Marie a fait des choses extraordinaires, que ce soit en bien ou en mal. Mais il est bien représentatif d'une époque désormais lointaine.

La première chose qui m'a frappé, dans la biographie, c'est qu'André Marie lui-même a laissé peu de traces de son enfance et sa jeunesse et a peu écrit sur le sujet. Les auteurs ont donc choisi de remplir ces chapitres avec des récits d'autres personnes, ayant vécu plus ou moins au même endroit et à la même époque, comme André Maurois. Même chose pour la participation de Marie comme combattant à la Première Guerre mondiale, vue à travers des textes militaires mais pas des récits de Marie.

Ensuite commence la carrière politique d'André Marie. Là, c'est mieux documenté. Mais comme André Marie n'a rien fait d'exceptionnel, c'est plutôt une peinture de la vie politique française de l'entre-deux-guerres qu'une biographie. Si la postérité a surtout gardé le souvenir d'une république de notables, aimant les banquets lourdement arrosés, les auteurs nous font aussi revivre la violence de la politique à l'époque, les meetings, même ceux des hommes politiques les plus modérés, systématiquement attaqués par des gens violents, les menaces d'enlèvement de sa fille par des fascistes lorsque Marie s'oppose aux émeutiers du 6 février. Bref, être un notable de province du Parti Radical n'était pas de tout repos.

À propos de facisme, si André Marie a été plutôt lucide face à la montée du nazisme, voyant le danger et la nécessité de le contrer, il ne faut pas croire que toute sa politique a été aussi clairvoyante. Il s'est par exemple opposé jusqu'au bout (et même après) à l'indépendance de l'Algérie.

Comme l'avait prévu Marie, une nouvelle guerre éclate. Il est mobilisé, et fait prisonnier. Il était député avant la guerre mais sa captivité l'empêche de participer au vote donnant le pouvoir aux collaborateurs. On ne saura donc pas ce qu'il aurait voté. Marie est libéré, participe à la résistance, est fait prisonnier et termine la guerre à Buchenwald. À son retour, si sa santé est sérieusement compromise, sa carrière politique décolle, il devient ministre et même, pendant un temps très court, président du Conseil. Que fait-il ? Pas grand'chose, à part essayer de maintenir son gouvernement le plus longtemps possible. Redevenu simple ministre, il donne son nom à une loi de financement de l'enseignement privé par l'argent public.

Une seconde fois, il sera pressenti pour devenir président du conseil et les auteurs de sa biographie consacrent plusieurs pages à des négociations... qui ne déboucheront finalement sur rien. Beau résumé de la politique politicienne sous la 4e République : on écrit un chapitre sur un événement qui ne s'est finalement pas produit.

Comme beaucoup de chevaux de retour de la 3e et de la 4e, André Marie ne survivra pas politiquement à la Ve République et se contentera d'une activité de notable de province classique, caractérisée par une extrême longévité au même poste (maire de Barentin pendant vingt-neuf ans).

Bref, une vie bien remplie et un livre pas ennuyeux du tout mais pour quel bilan finalement ?


L'article seul

RFC 7398: A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance

Date de publication du RFC : Février 2015
Auteur(s) du RFC : M. Bagnulo (UC3M), T. Burbridge (BT), S. Crawford (SamKnows), P. Eardley (BT), A. Morton (AT&T Labs)
Pour information
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 19 février 2015


Ce nouveau RFC est situé à l'intersection du groupe de travail IETF ippm et du plus récent groupe lmap. Ce dernier travaille pour les Large-Scale Measurements of Broadband Performance, c'est-à-dire pour les mesures objectives des performances des différents FAI, telles qu'elles sont menées par des associations de consommateur, ou l'État, ou un régulateur (comme ce que fait l'ARCEP avec son Observatoire sur la qualité du service fixe d'accès à l'Internet). Ces mesures peuvent être faites à des fins de comparaison, mais aussi de diagnostic. La référence normalisée en matière de métrologie est évidemment composée des RFC du groupe ippm (hélas non cités dans le rapport ARCEP mentionné plus haut). Ces RFC définissent les métriques essentielles comme le temps d'acheminement d'un paquet (RFC 2679) ou comme la capacité (RFC 5136). Comme la valeur de ces métriques dépend du point où se fait la mesure, il fallait pouvoir exprimer cette information. C'est le but de ce RFC, exprimer rigoureusement la mesure a été faite.

Prenons l'exemple d'une sonde Atlas « pinguant » un amer situé sur un autre continent, par exemple une ancre Atlas. Le résultat peut être très différent selon que la sonde soit située chez M. Michu et connectée avec du WiFi, ou bien qu'elle soit dans un data center, toute proche d'un gros point d'échange. Comment exprimer cette information sur la localisation de la sonde ? La terminologie utilisée aujourd'hui est souvent floue. Par exemple, on va dire que la sonde est « située chez l'utilisateur ». Mais ce n'est pas assez précis. Est-elle directement sur la box ou bien derrière, connectée par un réseau WiFi bien surchargé ?

On définit donc un chemin de référence (reference path) qui est le chemin suivi par les paquets IP de la mesure. Sur ce chemin se trouvent des points de mesure (measurement points) où peuvent être installés les appareils de mesure. Ces termes viennent de la norme UIT Y.1541, de la section 5.1 du RFC 3432 et de la section 4 du RFC 5835.

Donc, d'abord (section 3 du RFC), la terminologie essentielle :

  • Le chemin de référence (reference path) est une suite d'équipements (routeurs, commutateurs, bornes WiFi...) et de liens qui sont traversés par les paquets.
  • Un abonné (subscriber) est la personne ou l'organisation qui a loué les services d'un prestataire, peut-être avec des restrictions sur ce qu'il peut faire (cf. la norme UIT Q.1741).
  • Un composant dédié (dedicated component) est une ressource (matérielle ou virtuelle) du chemin de référence qui est entièrement dédiée à un abonné. Un composant partagé est, lui, partagé entre les abonnés.
  • Une démarcation (service demarcation point) est la frontière où les responsabilités du prestataire s'arrêtent. Par exemple, dans le cas d'un accès ADSL typique, la démarcation est juste avant la box (côté utilisateur), le FAI n'étant pas responsable du réseau local à la maison. Pour un McDo avec WiFi, la démarcation est les murs du restaurant (les ondes peuvent sortir mais McDo ne s'engage nullement à ce que le WiFi fonctionne dehors).
  • Les segments du chemin de référence peuvent être gérés ou non-gérés (managed paths and unmanaged paths). Attention, le terme est très chargé, car souvent utilisé de manière propagandiste dans les discussions sur la neutralité du réseau. Ici, la définition se place du point de vue du prestataire, par exemple du FAI : est géré ce dont il est responsable, le reste étant considéré comme non-géré (il faudrait plutôt dire « géré par quelqu'un d'autre »).

La section 4 donne un exemple typique de chemin de référence : la machine de l'utilisateur, le réseau local privé de l'utilisateur, une démarcation avant d'arriver dans le réseau du FAI, l'interconnexion entre le FAI et son transitaire, éventuellement plusieurs transitaires, encore une interconnexion avec le FAI du destinataire, une nouvelle démarcation, qui mène au réseau local privé du destinataire, puis la machine de destination. Dommage que traceroute ne montre pas les chemins comme cela :-) Ces démarcations et interconnexions ne se voient en effet pas facilement dans les paquets IP et doivent donc être documentées explicitement lorsqu'on fait des mesures.

La section 5 est ensuite consacrée aux points de mesure. Chacun doit recevoir un numéro unique, pour permettre de décrire précisement la mesure, et le RFC propose un schéma de numérotation : mpXNN où X est le numéro du réseau (0 chez l'utilisateur, 9 chez le destinataire, et obligation de changer de numéro quand on change d'acteur) et NN une machine ou un lien sur le réseau, avec des numéros croissants quand on s'éloigne de l'utilisateur. Ainsi, on aura, par exemple mp000 pour la machine de départ chez l'utilisateur (la sonde Atlas dans mon exemple plus haut), mp120 pour une mesure faite sur le DSLAM du FAI, mp200 pour le premier routeur du transitaire, etc. À noter que les contraintes pratiques fait que les points de mesure ne sont pas forcément placés idéalement. Par exemple, on voudrait mesurer dans la box mais elle ne le permet pas et on place alors un point de mesure dans un appareil externe. Ce n'est pas idéal, par exemple du fait que la connexion entre la box et cet appareil peut introduire des problèmes.


Téléchargez le RFC 7398


L'article seul

RFC 7454: BGP operations and security

Date de publication du RFC : Février 2015
Auteur(s) du RFC : J. Durand (CISCO), I. Pepelnjak (NIL), G. Doering (SpaceNet)
Réalisé dans le cadre du groupe de travail IETF opsec
Première rédaction de cet article le 19 février 2015


Tout l'Internet repose sur le protocole BGP, qui permet l'échange de routes entre opérateurs Internet. (BGP est normalisé dans le RFC 4271.) La sécurité de BGP est donc cruciale pour l'Internet, et elle a fait l'objet de nombreux travaux. Ce nouveau RFC résume l'état actuel des bonnes pratiques en matière de sécurité BGP. Du classique, aucune révélation, juste la compilation de l'état de l'art. Ce RFC porte aussi bien sur la protection du routeur, que sur le filtrage de l'information (les routes) reçues et transmises.

Ce genre de compilation aurait plutôt due être faite dans le cadre du project BCOP mais celui-ci semble mort.

La section 2 de ce RFC rappelle qu'il n'a pas de caractère obligatoire : il expose des pratiques de sécurité générales, et il est toujours permis de faire des exceptions, en fonction des caractéristiques spécifiques du réseau qu'on gère.

Donc, au début (sections 4 et 5 du RFC), la protection de la discussion entre deux routeurs, deux pairs BGP qui communiquent (sécurité du canal). Ensuite (sections 6 à 11), la protection des informations de routage échangées, le contrôle de ce qui est distribué (sécurité des données).

Commençons par sécuriser le routeur (section 4). Il devrait idéalement être protégé par des ACL qui interdisent les connexions vers le port 179, celui de BGP, sauf depuis les pairs connus. Les protections de TCP ne suffisent pas forcément, la mise en œuvre de TCP dans les routeurs est parfois faite de telle façon qu'on peut planter le routeur juste en envoyant plein de demandes de connexion. Il faut donc les jeter avant même que TCP ne les voit. De telles ACL sont parfois mise en place automatiquement par le logiciel du routeur, mais dans d'autres cas elles doivent être installées manuellement.

Rappelez-vous qu'un router a à la fois des fonctions de contrôle (control plane, ce qui inclut BGP) et de transmission (data plane). Idéalement, les ACL pour protéger le contrôle devraient être spécifiques à cette fonction et ne pas affecter la transmission des paquets (mais le matériel et le logiciel ne permettent pas toujours cette séparation). Certains routeurs permettent également de mettre en place un limiteur de trafic, pour éviter du trafic excessif, même en provenance de pairs connus. Le RFC 6192 décrit avec plus de détails la protection des fonctions de contrôle d'un routeur.

Ensuite (section 5 du RFC), la protection des sessions BGP avec les pairs légitimes (cf. RFC 6952). Si les deux routeurs ne prennent aucune précaution, un attaquant pourrait, par exemple, couper leur session BGP en envoyant de faux paquets TCP de type RST (cf. RFC 5961). Pire, il pourrait, avec des techniques comme l'usurpation ARP, injecter de faux paquets dans une session BGP existante. Pour se protéger contre les attaques TCP, il faut utiliser une authentification TCP, comme la traditionnelle (et bien dépassée) TCP-MD5 du RFC 2385. Beaucoup d'opérateurs exigent une telle authentification lorsqu'on fait du BGP avec eux (particulièrement sur un point d'échange, où des inconnus peuvent facilement fabriquer de faux paquets). Mais on ne peut pas dire que 100 % des sessions BGP dans le monde sont protégées, en raison du surcoût d'administration qui en résulte (choisir les mots de passe, les distribuer, les changer, etc). En outre, MD5 étant désormais bien affaibli (RFC 6151), il faudrait désormais utiliser le mécanisme AO du RFC 5925. Le RFC note que, malgré le caractère antédiluvien de TCP-MD5, c'est toujours la solution la plus utilisée par les opérateurs. Mes lecteurs qui configurent tous les jours des appairages BGP connaissent-ils des gens qui utilisent AO ?

Une autre solution serait de se servir d'IPsec entre les routeurs mais personne ne le fait.

Autre précaution, filtrer les paquets IP en entrée du réseau de l'opérateur pour interdire les paquets prétendant avoir une adresse IP source située dans le réseau de l'opérateur. Sans cette précaution, même les sessions iBGP pourraient être attaquées.

Dernière protection des sessions BGP, GTSM (RFC 5082) qui consiste à tester que le TTL des paquets entrants est à la valeur maximale (255), et que le paquet vient donc bien du réseau local (s'il était passé par, ne serait-ce qu'un seul routeur, le TTL aurait été décrémenté).

Après avoir protégé les routeurs, et la session BGP sur TCP qui les relie, voyons les données. Sécuriser la session ne sert à rien si le pair légitime et authentifié nous envoie des informations fausses. La section 6 de notre RFC se consacre donc au filtrage des préfixes annoncés. D'abord, les préfixes non routables (ceux marqués Global: false dans le registre des adresses spéciales IPv4 ou son équivalent IPv6) devraient évidemment être rejetés. Mais il est également recommandé de ne pas accepter les préfixes non alloués (par le système d'allocation d'adresses IP IANA->RIR->LIR). Comme la liste de ces préfixes change tout le temps, les filtres doivent être mis à jour automatiquement, à partir de la liste à l'IANA. Comme il y a un délai entre l'allocation d'un préfixe à un RIR et son utilisation réelle sur ce terrain, il n'est pas nécessaire de tester tous les jours (le RFC recommande de tester au moins une fois par mois). Si, pour une raison ou pour une autre, on ne peut pas vérifier la liste en ligne, il vaut mieux ne pas filtrer les préfixes, plutôt que de le faire sur la base d'une liste dépassée : une des plaies de l'Internet est la nécessité de dé-bogoniser (faire retirer des listes de bogons ces listes d'adresses IP non allouées) tout nouveau préfixe, processus qui peut être lent et nécessite pas mal de tests sur les looking glasses. En IPv4, il ne reste plus de préfixes non alloués et ce test régulier n'est donc plus nécessaire.

Tester auprès de l'IANA ne permet que des filtres grossiers, éliminant les annonces de préfixes non alloués à un RIR, ce qui ne sert que pour IPv6, ne vérifie pas les préfixes plus spécifiques que ce que l'IANA alloue, et n'empêche pas un malveillant ou un maladroit d'annoncer les préfixes d'un autre AS. Il peut donc être intéressant de filtrer de manière plus précise, en regardant les IRR. Un IRR est une base de données publiquement accessible, stockant les préfixes et l'AS autorisé à les annoncer (en langage RPSL, cf. RFC 4012). Ces IRR sont gérés par certains opérateurs, ou par les RIR. Par exemple, la base de données du RIPE-NCC contient cette information :

route:          217.70.176.0/20
descr:          GANDI is an ICANN accredited registrar
descr:          for more information:
descr:          Web:   http://www.gandi.net
origin:         AS29169
mnt-by:         GANDI-NOC

On voit ici que seul l'AS 29169 (Gandi) est autorisé à annoncer le préfixe 217.70.176.0/20. En opérant récursivement (car un AS peut être un fournisseur d'un autre AS situé derrière lui et il faudra donc suivre les informations sur les AS relayés), on peut établir une liste de tous les préfixes qu'un pair peut annoncer, et ne pas accepter les autres. Des outils existent pour produire automatiquement des filtres sur le routeur à partir du RPSL (comme IRRToolSet). Malheureusement, aucun IRR n'est parfait (et certains sont vraiment imparfaits) : préfixes absents (surtout les plus spécifiques, en cas de dés-agrégation des annonces), information dépassée, etc. Les IRR des RIR sont proches des opérateurs et donc a priori ont une information fiable mais ce n'est que théorique (les préfixes IP « du marais », alloués avant l'existence des RIR, sont une source particulièrement importante de problèmes). En outre, l'IRR d'un RIR ne couvre que la région de ce RIR, et on peut donc avoir besoin d'en consulter plusieurs (on a un pair états-unien, on regarde la base de l'ARIN, mais ce pair a des clients sud-américains et on doit donc aussi regarder la base de LACNIC...), ce qui justifie les IRR privés, comme RADB, qui essaient de consolider l'information des RIR.

Si vous trouvez que cette imperfection des IRR est bien ennuyeuse, le RFC recommande que vous agissiez de votre côté : vérifiez que vos préfixes sont correctement publiés dans les IRR.

Actuellement, la sécurité des données BGP repose essentiellement sur ce filtrage à partir des IRR et sur la réactivité des administrateurs réseau. Dans le futur, il est possible qu'un système plus fiable soit adopté et déployé, le couple RPKI+ROA, alias SIDR pour Secure Inter-Domain Routing. SIDR repose sur une infrastructure de certification, la RPKI (RFC 6480), et sur des objets signés, les ROA (RFC 6482), annonçant quel AS peut annoncer tel préfixe. SIDR fournit deux services, dont seul le premier est un peu déployé aujourd'hui :

  • La validation de l'origine de l'annonce (le premier AS sur le chemin). Décrite dans le RFC 6811, elle est aujourd'hui disponible dans la plupart des routeurs, et des ROA sont effectivement publiés.
  • La validation du chemin d'AS complet. Surnommé « BGPsec » (RFC 7353 et RFC 7132), la normalisation technique de ce service est loin d'être complétée et il n'existe donc pas de mise en œuvre disponible.

Ces mécanismes SIDR devraient, une fois largement déployés, résoudre la plupart des problèmes décrits dans cette section 6 de notre RFC 7454. Mais cela prendra de nombreuses années et il est donc nécessaire de ne pas abandonner les méthodes actuelles comme les systèmes d'alarme.

Pour la validation de l'origine de l'annonce, notre RFC recommande que la politique de filtrage des annonces (qui est une décision locale de chaque touteur) suive les règles du RFC 7115. Pour les résumer, lorsqu'une annonce BGP est comparée au contenu de la RPKI :

  • S'il existe un ROA et que l'annonce est valide selon ce ROA, on accepte l'annonce,
  • S'il existe un ROA mais que l'annonce n'est pas valide, on rejette l'annonce (attention, rappelez-vous qu'au début de toute nouvelle technique de sécurité, il y a pas mal de faux positifs),
  • S'il n'existe pas de ROA, on accepte l'annonce, avec une préférence plus faible.

Le système RPKI+ROA pose de nouveaux et intéressants problèmes et il est donc recommandé de lire « On the Risk of Misbehaving RPKI Authorities » d'abord.

D'autres filtrages sont possibles en entrée. Par exemple, les opérateurs filtrent les annonces trop spécifiques, afin notamment d'éviter la croissance indéfinie de leurs bases de données et tables de routage. Chacun choisit les valeurs quantitatives précises et il n'y a pas de consensus documenté sur ce point (on peut consulter les documents RIPE-399 et RIPE-532) mais on peut observer qu'un préfixe plus long que /24 en IPv4 et /48 en IPv6 a très peu de chances d'être accepté dans l'Internet. Voici un exemple de filtrage IPv4 sur JunOS :

policy-statement no-small-and-big-prefixes {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;
            route-filter 0.0.0.0/0 prefix-length-range /0-/7 reject;
        }
}
protocols {
            bgp {
               ...
               import no-small-and-big-prefixes;

Typiquement, on filtre aussi en entrée les annonces portant sur les préfixes internes. Normalement, ce n'est pas à nos voisins d'annoncer nos routes !

Autres préfixes souvent filtrés, les routes par défaut, 0.0.0.0/0 en IPv4 et ::0/0 en IPv6.

Naturellement, les recommandations de filtrage dépendent du type d'appairage BGP : on ne filtre pas pareil selon qu'on parle à un pair, à un client ou à un transitaire (voir la section 6 du RFC pour tous les détails). Ainsi, pour reprendre le paragraphe précédent, sur la route par défaut, certains clients d'un opérateur demandent à recevoir une telle route et c'est tout à fait acceptable.

La section 7 est consacrée à une pratique très utilisée et très discutée, l'amortissement (damping). Lorsqu'une route vers un préfixe IP donné passe son temps à être annoncée et retirée, on finit par l'ignorer, pour éviter que le routeur ne passe son temps à recalculer ses bases de données. Pour réaliser cela, à chaque changement d'une route, on lui inflige une pénalité, et au bout d'un certain nombre de pénalités, on retire la route. Malheureusement, cette technique mène parfois à supprimer des routes et à couper un accès (voir RIPE-378). Avec de meilleurs paramètres numériques, comme recommandé par le RFC 7196 et RIPE-580, l'amortissement redevient utilisable et recommandable.

Autre technique de filtrage des erreurs, décrite en section 8, l'imposition d'un nombre maximum de préfixes annoncés par un pair BGP. S'il en annonce davantage, on coupe la session BGP. Un dépassement du nombre maximal est en effet en général le résultat d'une fuite, où, suite à une erreur de configuration, le routeur ré-annonce des routes reçues d'un autre. Parfois, c'est toute la DFZ qui est ainsi annoncée par accident aux pairs ! Notre RFC demande donc instamment qu'on limite le nombre de préfixes accepté pour une session BGP. Pour un pair sur un point d'échange, le seuil devrait être inférieur au nombre de routes de la DFZ (dans les 530 000 en IPv4 aujourd'hui, et 21 000 en IPv6), pour détecter les annonces accidentelles de toute la DFZ. On peut aussi avoir des seuils par pair, fondés sur le nombre de routes qu'ils sont censés annoncer. Pour un transitaire, par contre, le seuil doit être plus élevé que le nombre de routes dans la DFZ, puisqu'on s'attend à tout recevoir d'eux (mais une valeur maximale est quand même utile en cas de désagrégation intensive). Comme l'Internet change tout le temps, il faut réviser ces limites, et suivre les alertes (sur certains routeurs, on peut configurer deux seuils, un pour déclencher une alerte, et un autre, supérieur, pour réellement couper la session). Voici un exemple sur JunOS :

group Route-Server-LINX-V4 {
    family inet {
        unicast {
            prefix-limit {
               maximum 100000;
            }
	}
}

Après le filtrage par préfixe, il peut aussi y avoir du filtrage par chemin d'AS (section 9 de notre RFC) et par routeur suivant (next hop, section 10). Voyons d'abord le filtrage par chemin d'AS. Par exemple, un client d'un opérateur ne devrait pas annoncer des routes avec n'importe quels AS mais seulement avec un chemin comportant uniquement son propre AS (et, si le client a lui-même des clients, avec l'AS de ces clients secondaires). Si l'opérateur n'arrive pas à avoir une liste complète des AS qui peuvent se retrouver dans les chemins de ses clients, au moins peut-il limiter la longueur de ces chemins, pour éviter la ré-annonce accidentelle de routes. D'autre part, on n'accepte pas, dans le cas normal, de routes où un AS privé (64512 à 65534 et 4200000000 à 4294967294, voir RFC 6996) apparait dans le chemin. Conséquence logique, on n'annonce pas à ses voisins de routes avec des chemins d'AS qui incluent un AS privé, sauf arrangement spécifique. Et le chemin d'AS dans une annonce BGP doit toujours commencer par l'AS du voisin (sauf si on parle à un serveur de routes). Enfin, un routeur BGP n'acceptera pas d'annonces où il voit son propre AS dans le chemin, et ce comportement par défaut ne devrait pas être débrayé.

Quant au filtrage sur le routeur suivant (section 10 du RFC), il consiste à refuser une route si l'attribut BGP NEXT_HOP (RFC 4271, section 5.1.3) n'est pas l'adresse du voisin. Attention, ce test doit être débrayé si on parle à un serveur de routes, celui-ci ne souhaitant pas traiter les paquets IP. Idem (débrayage du test) si on fait du RTBH (RFC 6666).

Pour finir, je recommande trois lectures,


Téléchargez le RFC 7454


L'article seul

RFC 7444: Security Labels in Internet Email

Date de publication du RFC : Février 2015
Auteur(s) du RFC : K. Zeilenga, A. Melnikov (Isode)
Pour information
Première rédaction de cet article le 19 février 2015


On a souvent besoin, lorsqu'on transmet un document, d'indiquer le niveau de sensibilité ou de confidentialité du document. Quelque chose du genre SECRET ou CONFIDENTIEL. Cela peut être fait de manière non structurée, par du texte (par exemple dans l'objet du message) mais cela ne permet pas aux logiciels d'agir automatiquement sur la base de ce texte. D'où l'idée d'un nouveau champ dans l'en-tête du message, SIO-Label:, pour indiquer de manière structurée la sécurité souhaitée pour ce message.

Dans beaucoup d'organisations (l'armée étant un exemple typique), la présence d'une telle indication a des conséquences pratiques comme « les documents marqués CONFIDENTIEL ou supérieur doivent être enfermés dans un coffre quand on sort du bureau » ou bien « on ne doit envoyer les documents marqués SECRET qu'aux gens disposant de telle habilitation ». D'où l'importance de pouvoir indiquer ces niveaux de sécurité. À noter qu'ils sont présentés et discutés dans la norme UIT X.841, Security information objects for access control.

Le protocole XMPP avait déjà une norme pour les niveaux de sécurité, XEP-0258. Ce nouveau RFC part des mêmes concepts et les applique au courrier électronique (RFC 5322).

La section 1.1 de notre RFC rappelle les anciennes méthodes. Typiquement, on met en avant un texte qui indique le niveau de sécurité. Par exemple :


To: author <author@example.com>
From: Some One <someone@example.net>
Subject: [SECRET] the subject 

SECRET

Text of the message.

SECRET

Dans ce message à la syntaxe RFC 5322, le niveau de sécurité (SECRET) a été mis dans le champ Subject: (encadré entre crochets pour être clairement séparé de l'objet normal), et répété au début (marquage FLOT First Line Of Text) et à la fin (LLOT Last Line Of Text) du message. De telles conventions sont fréquentes dans une communauté donnée (par exemple dans la même organisation, ou bien dans un groupe de gens travaillant sur le même projet). Elles vont sans doute continuer à être utilisées pendant longtemps, le nouveau système venant juste d'être spécifié. Pour un humain, même distrait, ces marques indiquent clairement le caractère secret du message. Mais, comme indiqué plus haut, ce n'est pas exploitable par un logiciel.

On notera que le RFC 2634 proposait déjà un mécanisme pour ces niveaux de sécurité, lié à l'utilisation de S/MIME. Notre nouveau RFC spécifie une solution alternative (S/MIME n'a pas été un grand succès...), plus légère. La solution du RFC 2634 était très perfectionnée (avec signature pour éviter qu'un tiers malveillant ne modifie les marques). Ici, on fait plus simple et on suppose qu'il existe un autre mécanisme pour assurer l'intégrité.

Donc, la solution nouvelle est de mettre un champ SIO-Label: dans le message. On suppose que le MUA proposera à l'utilisateur une liste de choix possibles et, une fois le choix fait, le logiciel le traduira dans le format standard. Les MTA et MDA pourront utiliser ce champ pour prendre des décisions. Par exemple, si un MTA a été configuré pour faire suivre automatiquement le courrier de jean@example.com à marie@internautique.fr, il pourra refuser de faire suivre un message marqué SECRET, ne sachant pas si la destinataire a l'habilitation nécessaire. Autre utilisation, le MUA du destinataire pourra afficher clairement le niveau de sécurité. On peut imaginer bien d'autres usages, comme le tri automatique des messages dans des dossiers différents selon le niveau de sécurité.

Les intermédiaires comme les MTA sont autorisés à modifier le champ SIO-Label: (ou l'ajouter s'il n'est pas présent) et, dans ce cas, il doivent indiquer les anciennes valeurs dans le champ SIO-Label-History: qui, comme son nom l'indique, garde trace des changements effectués.

La section 4 décrit formellement la grammaire des nouveaux en-têtes. SIO-Label: comprend une série de paramètres, chacun formé d'une clé et d'une valeur. Le paramètre principal est sans doute label qui indique le niveau de sécurité. Quelles valeurs peut-il prendre ? Plutôt que d'essayer de normaliser une liste de valeurs (ce qui ne marchera jamais, chaque organisation ayant déjà sa liste), notre RFC délègue à d'autres normes, indiquées par le paramètre type. Ainsi, type=":ess"; label="MQYGASkCAQM="; indique que le type est ESS (Enhanced Security Services for S/MIME, RFC 2634, déjà cité) et le label est alors un encodage en BER d'une étiquette ESS. Un type :x411 va indiquer un encodage BER d'une étiquette de sécurité X.411. Enfin, un type :xml indique que le label est l'encodage en Base64 d'un élément XML qui, on le suppose, fera référence à une norme de niveaux de sécurité (si label est trop long, il peut être écrit en plusieurs fois, avec un astérisque et un numéro d'ordre derrière label). Dans cet exemple, la norme est http://example.com/sec-label/0 (un exemple imaginaire) :


       type=":xml";
       label*0="PFNlY0xhYmVsIHhtbG5zPSJodHRwOi8vZXhhbX";
       label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY3lJ";
       label*2="ZGVudGlmaWVyIFVSST0idXJuOm9pZDoxLjEiLz";
       label*3="48Q2xhc3NpZmljYXRpb24+MzwvQ2xhc3NpZmlj";
       label*4="YXRpb24+PC9TZWNMYWJlbD4=";

Ce qui se traduit, une fois le Base64 décodé, par :


<SecLabel xmlns="http://example.com/sec-label/0">
       <PolicyIdentifier URI="urn:oid:1.1"/>
       <Classification>3</Classification>
</SecLabel>

Un autre paramètre fréquent est marking qui indique le texte à afficher à l'utilisateur (marking="FOR YOUR EYES ONLY";). Si vous êtes un vrai paranoïaque, vous avez déjà noté que rien ne garantit que ce texte soit cohérent avec le vrai niveau de sécurité, label (cf. section 7). Plus rigolos, fgcolor et bgcolor permettent de suggérer des couleurs à utiliser pour l'affichage, couleurs indiquées par un code hexadécimal ou un nom (cela me semble une mauvaise idée : l'intérêt des niveaux de sécurité écrits sous une forme structurée est justement que le logiciel qui les affichera aura toute l'information pour choisir une couleur adaptée à son utilisateur). En combinant ces paramètres, un en-tête complet pourrait être :

SIO-Label: marking="TOP SECRET";
       fgcolor= #000011; bgcolor=fuschia;
       type=":x411"; label="MQYGASkCAQM="

On a vu qu'un logiciel de courrier était autorisé à modifier les niveaux de sécurité. Dans ce cas, pour permettre l'analyse de ce qui s'est passé, il devrait enregistrer le niveau précédent dans l'en-tête SIO-Label-History:, normalisé dans la section 5 de notre RFC. Cet en-tête de traçabilité (comme Received:) indique si le SIO-Label: a été ajouté par le logiciel, supprimé ou modifié. Voici un exemple où le message a été modifié deux fois, par l'ajout d'un niveau, puis par sa suppression :

SIO-Label-History: marking="EXAMPLE CONFIDENTIAL";
       type=":ess"; label="MQYGASkCAQM=";
       change=delete;
       changed-by="smtp.example.com";
       changed-at="18 Feb 2013 9:24 PDT";
       changed-comment="Pas confiance dans celui-là, je supprime"
SIO-Label-History: new-marking="EXAMPLE CONFIDENTIAL";
       new-type=":ess"; new-label="MQYGASkCAQM=";
       change=add;
       changed-by="smtp.example.net";
       changed-at="18 Feb 2013 7:24 PDT";
       changed-comment="Pas de niveau indiqué, j'en mets un"

Les deux en-têtes SIO-Label: et SIO-Label-History: sont désormais dans le registre des en-têtes.

La bonne utilisation de ces niveaux de sécurité nécessite quelques précautions (section 7 du RFC). Par défaut, le message, y compris ses en-têtes et donc y compris SIO-Label:, n'est pas protégé et un méchant peut donc mettre un faux niveau ou modifier un niveau existant. Ce RFC ne fournit pas à lui seul de services de sécurité et ne dispense donc pas de mettre des protections adaptées, comme PGP pour assurer la confidentialité du message ou TLS pour qu'il soit transporté sans modification.

À noter également un paradoxe des niveaux de sécurité : leur seule présence donne déjà une indication à un éventuel espion. Si OSS 117 est dans un bureau du KGB et n'a que quelques secondes pour choisir les documents à emporter, le fait que les documents les plus intéressants soient marqués en gros « ultra-secret » va l'aider. C'est encore plus vrai si les niveaux de sécurité sont trop parlants, du genre « Project Roswell/Area51 Secret ».

Je ne connais pas de mise en œuvre de ce RFC. Certains clients de messagerie ont déjà des niveaux de sécurité, utilisant d'autres normes. Voir par exemple TrustedBird, présenté aux JRES en 2009. Si vous êtes intéressés par ces questions, vous pouvez aussi regarder la spécification de XIMF.


Téléchargez le RFC 7444


L'article seul

RFC 7465: Prohibiting RC4 Cipher Suites

Date de publication du RFC : Février 2015
Auteur(s) du RFC : A. Popov (Microsoft)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 19 février 2015


Fini, RC4, au moins dans TLS ! Cet algorithme de cryptographie, qui était secret à l'origine et prétendait être ainsi plus sûr, a fait l'objet de tellement d'attaques cryptanalytiques réussies qu'il ne doit plus être utilisé dans le protocole TLS.

Normalisé dans le RFC 5246, TLS sécurise un grand nombre de protocoles TCP/IP, le plus connu étant HTTP. Comme tous les protocoles IETF utilisant la cryptographie, il n'est pas lié à un algorithme de cryptographie particulier. En effet, les progrès de la cryptanalyse font que les algorithmes qui semblaient sûrs à une époque ne durent pas forcément éternellement. Il est donc crucial de permettre l'arrivée de nouveaux algorithmes, et le retrait des vieux (comme cela a été fait pour MD5, cf. RFC 6151). C'est ce qu'on nomme l'agilité cryptographique. Dans TLS, la liste des algorithmes acceptés est enregistrée à l'IANA et ceux acceptés par le client TLS sont transmis au début de la négociation, dans le message ClientHello (RFC 5246, section 7.4.1.2). Parmi ceux proposés, le serveur en choisira un et l'indiquera dans le message ServerHello (RFC 5246, section 7.4.1.3). (En fait, c'est un peu plus compliqué, le client transmet des suites, chaque suite contenant plusieurs algorithmes, notamment un asymétrique, et un symétrique comme l'est RC4. Par exemple, TLS_ECDH_ECDSA_WITH_RC4_128_SHA est l'algorithme asymétrique ECDSA avec RC4) Depuis ce RFC 7465, les suites cryptographiques utilisant RC4 ne doivent plus apparaître dans ces messages.

RC4 n'a pas été normalisé (il était secret au début, un exemple illustrant bien la vanité de la sécurité par l'obscurité) mais a été documenté dans le livre de Schneier, « Applied Cryptography » (à partir de la deuxième édition). Parmi les attaques réussies contre RC4 :

Toutes ces attaques ne sont pas forcément exploitables de manière réaliste. Mais la cryptanalyse progresse tous les jours. Si l'attaque est un peu trop dure aujourd'hui, elle sera possible demain et triviale après-demain (sans compter le fait qu'en cryptanalyse, tout n'est pas publié, certaines organisations ne disent pas ce qu'elles font). Notre RFC estime qu'aujourd'hui, ces attaques sont presque utilisables en pratique. Il est donc temps de virer RC4.

La section 2 est donc simple et courte : le client TLS ne doit plus indiquer de suite cryptographique utilisant RC4 et, s'il le fait, le serveur ne doit plus les sélectionner. Si la totalité des suites proposées par le client utilise RC4, le serveur doit rejeter la connexion, en utilisant l'alerte insufficient_security(71) (cf. RFC 5246, section 7.2). Ce dernier point avait fait l'objet d'un débat dans le groupe de travail, car il revient à rejeter complètement certaines mises en œuvre de TLS (rappelons que certains sont toujours incapables de parler les versions 1.1 et 1.2 de TLS, malgré les failles de sécurité que cela cause). Toutefois, ce cas de logiciels ne gérant que RC4 semble rare dans la nature.

Par contre, le registre IANA ne dispose pas d'un moyen pour indiquer cette obsolescence de RC4 donc des programmeurs / administrateurs système distraits ne feront peut-être pas attention à ce RFC. Diffusez-le largement !


Téléchargez le RFC 7465


L'article seul

RFC 7457: Summarizing Known Attacks on TLS and DTLS

Date de publication du RFC : Février 2015
Auteur(s) du RFC : Y. Sheffer (Porticor), R. Holz (TUM), P. Saint-Andre (&yet)
Pour information
Réalisé dans le cadre du groupe de travail IETF uta
Première rédaction de cet article le 10 février 2015


Depuis quelques années, on entend souvent parler de failles dans TLS ou dans les mises en œuvre de TLS, comme OpenSSL. Un groupe de travail a été créé à l'IETF pour essayer de durcir la sécurité de TLS, le groupe UTA (Using TLS in Applications). Son premier RFC est un rappel de ces récentes failles. C'est l'occasion de réviser BEAST, CRIME ou Heartbleed.

Le protocole de cryptographie TLS (autrefois nommé SSL) est normalisé dans le RFC 5246. Les attaques récentes contre TLS sont très variées : mauvaise utilisation de TLS par les applications (la principale motivation pour la création du groupe UTA, et son centre d'intérêt principal), bogues dans un programme mettant en œuvre TLS, erreurs dans le protocole, erreurs dans un des algorithmes cryptographiques qu'il utilise... Ce RFC dresse une liste des problèmes de sécurité de ces dernières années, mais on peut être sûr que la liste va s'allonger. Comme le dit la NSA, « Attacks always get better; they never get worse » (cf. RFC 4270).

Le gros morceau du RFC est sa section 2, qui liste les problèmes. Par exemple, la plus évidente est d'empêcher complètement l'usage de TLS (ce qu'on nomme parfois SSL stripping). Par exemple, si un client HTTP se connecte en HTTP et compte sur le serveur pour le rediriger en HTTPS, un attaquant actif peut modifier la redirection, empêchant ainsi TLS de démarrer. Le SSL stripping est donc un cas particulier des attaques par repli (downgrade attacks). Normalement, HSTS (RFC 6797) est la bonne solution contre cette attaque.

Pour HTTP, il est habituel de démarrer directement en TLS. Pour les protocoles où on démarre sans TLS et où on utilise ensuite une commande STARTTLS pour commencer à chiffrer (comme SMTP), une attaque par repli analogue est possible en supprimant la commande STARTTLS. La seule protection possible serait un équivalent de HSTS (le RFC oublie de mentionner DANE, qui pourrait être utilisé à des fins de signalisation). Autre problème avec STARTLS, les attaques où le tampon d'entrée n'est pas vidé après le passage à TLS, ce qui fait que les commandes injectées avant que TLS ne sécurise la connexion sont exécutées après, en les croyant sûres (CVE-2011-0411). Ce n'est pas une faille du protocole mais de l'application.

Autre attaque, avec un nom rigolo, cette fois, BEAST (CVE-2011-3389). Elle ne touchait que TLS 1.0 (version dépassée depuis longtemps) et seulement le mode CBC.

Plusieurs attaques sont du type padding oracle. C'est le cas de Lucky Thirteen (CVE-2013-0169). Elle peut être combattue en utilisant un mode de chiffrement intègre, ou bien en faisant le chiffrement avant de calculer le MAC (mécanisme dit « encrypt-then-MAC » et recommandé pour TLS par le RFC 7366). Une autre attaque padding oracle, Poodle (CVE-2014-3566 ou bien l'article d'Andréa Fradin), qui ne touche que des versions encore plus anciennes (avant que cela ne s'appelle TLS) et n'a pas de solution connue (à part arrêter d'utiliser des versions archaïques de SSL).

Le protocole TLS est complexe et plein de failles se cachent dans des détails subtils. Par exemple, l'attaque triple handshake (CVE-2014-1295) permet de faire en sorte que deux sessions TLS utilisent les mêmes clés, autorisant ainsi plusieurs autres attaques.

Passons à des attaques plus cryptographiques, celles portant sur l'algorithme RC4. RC4 est utilisé depuis longtemps, a des faiblesses connues depuis longtemps (voir le RFC pour une bibliographie comportant plusieurs articles), et ces faiblesses commencent à devenir exploitables en pratique (aujourd'hui, elles requièrent encore trop de calculs). Il ne faut donc plus utiliser RC4 (un RFC est en préparation, qui explicitera cette recommandation).

La compression des données dans TLS apporte ses propres attaques comme CRIME (CVE-2012-4929). Pour les empêcher, on peut couper la compression ou, pour certaines attaques, choisir des solutions au niveau de l'application.

Autre propriété de TLS qui semblait pratique quand elle a été définie, mais qui s'est avérée dangereuse, la renégociation (CVE-2009-3555). La solution a été fournie par le RFC 5746.

TLS utilisant presque toujours des X.509 pour authentifier le serveur (et parfois le client), il n'est pas étonnant que les failles de X.509, ou d'un des algorithmes utilisés dans les certificats, se retrouvent dans la liste des problèmes de sécurité avec TLS. C'est le cas par exemple de l'attaque RSA de Klima, V., Pokorny, O., and T. Rosa, « Attacking RSA-based sessions in SSL/TLS ». ou de celle de Brubaker, C., Jana, S., Ray, B., Khurshid, S., et V. Shmatikov, « Using frankencerts for automated adversarial testing of certificate validation in SSL/TLS implementations ».

Une autre attaque possible est lorsque l'attaquant met la main sur la clé privée a posteriori, et qu'il a enregistré le trafic chiffré. Avec la plupart des algorithmes utilisés par TLS, la connaissance de la clé privée permet de déchiffrer le trafic passé, qui peut être encore intéressant. Cela permet, par exemple, l'utilisation de Wireshark pour analyser un trafic HTTPS. Mais c'est dangereux pour la vie privée : un attaquant patient et ayant beaucoup de place sur ses disques durs pourrait enregistrer tout le trafic chiffré, attendant le moment où il entre en possession des clés privées (ce que fait la NSA, cf. RFC 7258). On peut se protéger contre ces attaques en sécurisant mieux ses clés privées (un HSM ?) mais le mieux est sans doute de passer aux algorithmes qui fournissent la perfect forward secrecy.

Même lorsque le protocole est parfait, des failles peuvent apparaitre en raison de bogues dans les programmes qui mettent en œuvre TLS. On peut même dire qu'il y a bien plus de bogues d'implémentation que de protocole, et elles sont en général plus facilement exploitables, et avec des conséquences plus graves. Ces failles peuvent être dans les bibliothèques TLS (comme OpenSSL, qui en a connu beaucoup, dont la fameuse Heartbleed, CVE-2014-0160, cf. RFC 6250 ou bien l'article de Fradin) ou dans les programmes qui utilisent ces bibliothèques (une excellente étude à ce sujet est celle de Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., et V. Shmatikov, « The most dangerous code in the world: validating SSL certificates in non-browser software »). Une liste non-exhaustive de ces bogues dans les applications :

  • Absence de vérification du certificat, comme l'ont fait pendant longtemps les bibliothèques Python (voir le CVE-2013-2191). Ce n'est pas une faille du protocole mais de l'application ou des bibliothèques.
  • Si on vérifie le certificat, absence du test du nom du serveur dans le certificat. La faille « goto fail » était de cette catégorie. Voir mon exposé à Devoxx (et ses transparents).

Il n'y a pas que des attaques dues aux bogues du protocole ou des implémentations. Un méchant peut aussi utiliser les simples attaques par déni de service. TLS impose davantage de calculs aux machines qui communiquent et cela peut être utilisé pour le déni de service. Si les processeurs ont progressé (rendant réaliste l'idée d'activer systématiquement TLS pour toutes les connexions), un attaquant disposant d'un grand botnet peut toujours épuiser les capacités de sa victime, en lui imposant des calculs cryptographiques complexes.

De même que les programmeurs d'application peuvent se tromper, mal interpréter les complexes API des bibliothèques TLS, et introduire ainsi des failles de sécurité, les utilisateurs finaux peuvent également prendre des décisions qui annulent la sécurité de TLS, quelle que soit la qualité des protocoles et des logiciels. L'utilisabilité est un élément de la sécurité, si on ne veut pas que M. Michu fasse des erreurs. Par exemple, les logiciels permettent d'accepter un mauvais certificat et les utilisateurs disent presque toujours Oui (et souvent pour des raisons rationnelles). Ici, un exemple avec le logiciel de messagerie instantanée Pidgin :

Lutter contre ce problème nécessitera à la fois HSTS (pour priver de choix l'utilisateur), de l'épinglage des clés, et de meilleurs interfaces utilisateur, une tâche très complexe.

Si vous voulez vous documenter sur ces problèmes TLS, le RFC recommande l'article de Sarkar, P. et S. Fitzgerald, « Attacks on SSL, a comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 and RC4 biases ».


Téléchargez le RFC 7457


L'article seul

Fiche de lecture : Sécurité et espionnage informatique \ Connaissance de la menace APT

Auteur(s) du livre: Cédric Pernet
Éditeur: Eyrolles
978-2-212-13965-5
Publié en 2015
Première rédaction de cet article le 10 février 2015


Les médias sont plein de récits d'attaques informatiques spectaculaires, où deux lycéens piratent le Pentagone, par des méthodes techniques très avancées, ou bien où une horde de Chinois, forcément fourbes et cruels, s'emparent des plans du dernier avion de combat. Dans la communication sur les attaques informatiques, un sigle s'est imposé : APT pour Advanced Persistent Threat. Peu de gens ont une idée précise de ce que cela veut dire mais c'est en général un synomyme de « attaque qui n'a pas été faite par un gusse dans son garage, un après-midi où il s'ennuyait ». Vous voulez en savoir plus ? Alors, je vous recommande le livre de Cédric Pernet, un expert de la question, et qui sait bien expliquer posément ce que sont les APT, dans leur complexité.

Le livre est court, 220 pages, ce qui le rend accessible aux gens curieux mais pressés (et le prix est élevé, à 40 €...) Mais il couvre bien tous les aspects d'une APT. L'auteur discute d'abord d'une définition rigoureuse de ce concept (on a vu plus haut que le terme est souvent utilisé à tort et à travers, en général avec une bonne dose de sensationnalisme). La définition de l'auteur (« une attaque informatique persistante ayant pour but une collecte d'informations sensibles d'une entreprise publique ou privée ciblée, par la compromission et le maintien de portes dérobées sur le système d'information ») ne fait pas appel au terme « avancé ». En effet, son analyse est que les APT ne sont pas forcément d'une haute technologie. Elles se caractérisent davantage par la mobilisation de moyens humains importants (des dizaines, voire des centaines de personnes), par la ténacité, par le professionnalisme et le souci du détail, que par la sophistication des techniques utilisées.

L'auteur expose ensuite les différentes phases d'une APT : la phase de reconnaissance, où le groupe d'attaquants rassemble toutes les informations possibles sur sa cible, celle de la compromission initiale, où l'attaquant a trouvé une faille à exploiter pour pénétrer dans le système, par exemple par du hameçonnage ciblé (spear phishing), une phase de « renforcement des accès et mouvements latéraux », où l'attaquant va mettre en place des moyens de revenir même si la faille originelle est comblée (rappelez-vous qu'une APT prend du temps), et où il va se déplacer dans le système d'information, à la recherche de nouvelles machines à compromettre, et enfin une phase d'exfiltration des données, où l'attaquant va tenter de faire sortir tous les giga-octets qu'il a obtenu, afin de les rapporter chez lui, mais sans se faire détecter.

Vu du point de vue de l'attaquant, une APT n'est pas forcément glamour et spectaculaire. La phase de reconnaissance, par exemple, est plutôt routinière. C'est un travail de besogneux, pas de flamboyants hackers. Des tas d'informations sont disponibles publiquement, il faut les récolter. L'auteur note que « une préparation rigoureuse et minutieuse est la clé de la réussite [de l'APT] », ce qui est aussi exaltant qu'une leçon de morale du temps de Jules Ferry (« c'est en travaillant bien qu'on réussit »).

(Au passage, Cédric Pernet parle longuement de l'utilisation de whois et du DNS. Ces outils sont utilisés par les agresseurs en phase de reconnaissance, mais peuvent aussi servir aux investigateurs, cf. mon exposé à CoRI&IN.)

Même la phase de compromission initiale n'est pas forcément glorieuse. Lors d'une APT, on n'utilise pas forcément des attaques premier jour (attaques encore inconnues) : c'est parfois dans les vieux pots qu'on fait les meilleures soupes et certaines APT n'ont utilisé que des vulnérabilités connues depuis des années... et qui ne sont pas toujours patchées.

J'ai noté que, malgré le métier de l'auteur, ce livre ne parle guère de la « réponse à incidents ». Il décrit les APT, pour les solutions et les réactions, il faudra attendre un autre livre.

Le livre se termine par une description de plusieurs APT fameuses et moins fameuses. L'auteur, qui rappelle régulièrement la complexité de ce monde et la difficulté à acquérir des certitudes en béton sur les attaquants et leurs méthodes, se méfie des attributions trop enthousiastes. L'attribution, c'est un des exercices les plus difficiles de la lutte contre les APT, c'est tenter de nommer l'attaquant. Comme une attaque numérique ne laisse pas de traces indiscutables (pas d'ADN, pas de mégots de cigarettes, pas d'empreintes digitales), on pourra toujours contester une attribution. D'autant plus que certains n'hésitent pas à ouvrir le feu avant d'être sûr, par exemple lorsque le FBI a accusé le régime nord-coréen d'être derrière l'attaque de Sony.

Donc, quelques cas pittoresques traités dans ce livre :

  • PutterPanda, une campagne d'espionnage visant notamment l'aéronautique, et qui viendrait de Chine.
  • Careto, une campagne d'APT caractérisée par la richesse et la complexité des techniques utilisées (dont certaines achetées aux mercenaires de Vupen).
  • Hangover qui serait d'origine indienne.
  • Flame (alias Flamer, alias Wiper, rappelez-vous que les noms sont donnés par les défenseurs, pas par les attaquants, et que plusieurs équipes ont pu analyser la même APT), un système d'espionnage très perfectionné, qui a frappé au MOyen-Orient, et qui serait développé par la même équipe que Stuxnet (que Cédric Pernet ne classe pas dans les APT).

Une APT fameuse manque : celle que la NSA pratique en permanence contre les systèmes informatiques du monde entier...

Pour résumer, un excellent livre, très documenté, sérieux, prudent, et pédagogique, même si je regrette l'abus d'anglicismes (certes très utilisés dans le métier), comme 0day au lieu de « premier jour », watering hole plutôt que « point d'eau », sinkhole au lieu d'« évier », logger au lieu de « journaliser », etc. L'auteur a récemment donné un interview à SécuritéOff.

Une note d'humour pour finir : le dos du livre annonce « Il [l'auteur] est suivi par plus de 3 000 abonnés sur Twitter. » Curieuse métrique : j'ai bien plus d'abonnés, sans pouvoir prétendre au même niveau d'expertise.

Autres compte-rendus de ce livre :


L'article seul

The Sichuan pepper "attack": from DNS censorship to DNS redirection

First publication of this article on 5 February 2015


It is well-known, for many years, that the Chinese governement censors the Internet via several means, including DNS lies. For a long time, these DNS lies have been generated by the netwok itself: when a DNS query for a censored name is seen, an active censorship device generates a lie and sends a reply with a wrong IP address. A few weeks ago, there have been a change in this system: the IP addresses returned by the Great FireWall are more often actual addresses used by real machines, which suddently have to sustain a big traffic from China.

This technique have been studied and documented in several papers such as "The Great DNS Wall of China" or "Source code to identify the fake DNS packets from China". Basically, every DNS request in a chinese network, whatever the destination IP address, is examined and, if the qname (Query Name) in it matches a predefined list of censored domains, a fake reply is generated and sent to the requester. The bad consequences of this technique outside of China have been described in articles like "Accidentally Importing Censorship" or "China censorship leaks outside Great Firewall via root server": since the censorship system acts whatever the destination IP address is, if one of your DNS packets happen to goes through China, you will be subjected to chinese censorship.

To see this DNS tampering, one just has to query any IP address in China (it does not need to be an existing machine, since the fake DNS reply is made by the network, not by an evil DNS server, the address here was choosen at random and tested to be sure it does not reply to any other packet):

      
% dig @218.76.74.42 A www.ssi.gouv.fr

; <<>> DiG 9.9.5-8-Debian <<>> @218.76.74.42 A www.ssi.gouv.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
      
    

As expected, this non-existing machine does not reply. But if we try with a censored name, here Facebook:

      
% dig @218.76.74.42 A www.facebook.com

; <<>> DiG 9.9.5-8-Debian <<>> @218.76.74.42 A www.facebook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30344
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.facebook.com.      IN A

;; ANSWER SECTION:
www.facebook.com.       2655 IN A 67.205.10.141

;; Query time: 313 msec
;; SERVER: 218.76.74.42#53(218.76.74.42)
;; WHEN: Wed Feb 04 12:06:43 CET 2015
;; MSG SIZE  rcvd: 50
      
    

This time, we get an IP address, and completely unrelated to Facebook (it is a USAn hoster). It is not just a match of the string that triggers the lying answer, the system actually understands DNS:

      
% dig @218.76.74.42 A www.facebook.com.example.net

; <<>> DiG 9.9.5-8-Debian <<>> @218.76.74.42 A www.facebook.com.example.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached	       
      
    

Besides going to China and testing from your laptop, there are other ways to see this DNS tampering: one is to use the RIPE Atlas probes. Few of them are in China and many seem immune to the DNS tampering, probably because they are located on a network with a safe VPN connection to the outside.

% python resolve-name.py --country=CN --requested=30 www.facebook.com
Measurement #1854647 for www.facebook.com/A uses 15 probes
[66.220.158.19] : 4 occurrences
[179.60.192.3] : 2 occurrences
[31.13.79.246] : 3 occurrences
[31.13.68.84] : 3 occurrences
[173.252.74.22] : 1 occurrences
[153.122.20.47] : 2 occurrences
[31.13.68.70] : 3 occurrences
[67.205.10.141] : 1 occurrences
[173.252.73.52] : 1 occurrences
[114.200.196.34] : 1 occurrences
[31.13.76.102] : 1 occurrences
Test done at 2015-02-04T11:11:19Z
    

(The program resolve-name.py is on Github.) Most answers are actually Facebook's but not all (for instance, 114.200.196.34 is a Korean access provider).

And a last solution is to use the cloud, actually a Web site hosted in China which allows you to perform DNS requests, for instance, http://viewdns.info/chinesefirewall.

Until the beginning of 2015, the returned IP addresses were apparently non-reachable addresses, unallocated, or even "class D" (multicast, 224.0.0.0/4) or "class E" (unused, 240.0.0.0/4) addresses. When the unsuspected chinese user tried to reach Facebook, he got one of these unrouteable addresses and it ended in a timeout. But a change was done at the beginning of 2015. Now, the returned IP addresses are, much more often , actually assigned to a real machine. Suddenly, several system administrators reported a lot of traffic coming from China, asking for sites like Facebook, something that never happened before.

The first report, seen from the chinese site (chinese users sent to unexpected Web sites) was "Visitors to blocked sites redirected to porn". Many other reports documented the other side, the point of view of the site suddently receiving chinese traffic. See "Fear China", "DDOS on La Quadrature du Net, analysis" or "DDoS from China – Facebook, WordPress and Twitter Users Receiving Sucuri Error Pages".

Let's look at this traffic, as seen by one of the Web servers of CGT. The HTTP server log contains:

      
x.y.z.t - - [27/Jan/2015:07:48:29 +0100] "GET /plugins/like.php?href=https://www.facebook.com/yvesrocher.nederland&width=325&height=35&colorscheme=light&layout=standard&action=like&show_faces=false&send=false HTTP/1.1" 404 1184 "https://secureorder.yves-rocher.nl/control/main/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0"
      
    

(The source IP address was from "Graduate University of Chinese Academy of Sciences") The request is for /plugins/like.php, Facebook's "Like" button. It does not exist on the server and the HTTP status code is therefore 404 (not found). What is interesting is the Referer: HTTP field, here https://secureorder.yves-rocher.nl/control/main/. It shows that the chinese client did not want explicitely to visit Facebook (he probably knows that this would be hopeless from China) but he visited a site (https://secureorder.yves-rocher.nl/control/main) which includes a Facebook "Like" button, therefore triggering a HTTP request to Facebook and, because of the DNS tampering, actually going to the CGT server. Here is a part of the HTML source code of the Referer:

  
<iframe src="https://www.facebook.com/plugins/like.php?href=https://www.facebook.com/yvesrocher.nederland&width=325&height=35&colorscheme=light&layout=standard&action=like&show_faces=false&send=false" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:325px; height:35px; margin-top:4px;" allowTransparency="true"></iframe>	   
  

Unfortunately, the HTTP server, like most HTTP servers, did not log the Host: field in the HTTP request. This field indicates which host was requested by the client. Here, we can guess it was www.facebook.com, from the requested path (/plugins/like.php). But it would be better if all HTTP servers were to log the Host: field (in Apache, it is the %v format directive). On another HTTP server, which was victim of the same Sichuan pepper issue, and had this logging activated, we see:

x.y.z.t - - [21/Jan/2015:00:53:33 +0100] "GET /plugins/like.php?href= [...] "Mozilla/5.0 (Linux; U; Android 4.4.4; zh-CN; L39h Build/14.4.A.0.108) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 UCBrowser/10.0.0.488 U3/0.8.0 Mobile Safari/534.30" 0 www.facebook.com

The www.facebook.com clearly indicates that the original user really wanted to go to Facebook, and was distracted by the DNS tampering.

Another very common HTTP request is:

  
x.y.z.t	- - [27/Jan/2015:07:48:41 +0100] "GET /announce?info_hash=%0eo%40%e7.u%f7%a3%3e%e6%e9%a9%5e%e45%8bK%1b%de.&peer_id=-QD1900-8xIYnIZ1_GUL&port=4385&uploaded=0&downloaded=32208896&left=1168225415&key=87d43d95&compact=1&numwant=200&no_peer_id=1 HTTP/1.0" 404 1015 "-" "qqdownload/1.9.273.0"
  

(The original source IP address was "China Mobile Communications Corporation".) The requested path, /announce?info_hash is typical of BitTorrent clients going to a BitTorrent tracker. QQdownload is a popular BitTorrent client in China. On another machine, where Host: logging is activated, we see that the requested host was indeed a tracker, tracker.thepiratebay.org, also censored in China.

OK, so we see a lot of HTTP traffic, coming almost only from chinese IP addresses, and we see that the requested names are indeed censored in China. Can we prove that the Great FireWall redirected to the IP addresses of the victims? We can do it with http://PassiveDNS.cn/, a passive DNS (a system which records DNS answers observed on the network) database located in China. First, we can check (like we did with dig to a chinese IP address) that names like tracker.thepiratebay.org are indeed tampered with, using the API client of PassiveDNS.cn, flint:

% flint rrset tracker.thepiratebay.org A
[api error]: http://www.passivedns.cn/api/rrset/keyword/tracker.thepiratebay.org/rtype/1/

:-( This request works for non-censored names. I suspect that censored names, being redirected to many IP addresses, exceed some limit of PassiveDNS.cn, leading to this bug. But the Web interface of PassiveDNS.cn still works so we can see indeed that we have many IP addresses for tracker.thepiratebay.org. It is not a trick specific to The Pirate Bay, all the other censored names show the same behaviour. But what is more interesting is how many names point to the IP address of the victim, 212.234.228.143?

% flint rdata 212.234.228.143 A | more  
212.234.228.143 A In rdata
--------
50congres.cgt.fr                                212.234.228.143 2014-11-26 10:10:13
accounts.youtube.com                            212.234.228.143 2015-01-28 10:26:25
adecco.cgt.fr                                   212.234.228.143 2014-11-29 12:56:14
adm-salaries.cgt.fr                             212.234.228.143 2015-01-04 06:39:26
aful.cgt.fr                                     212.234.228.143 2015-02-04 06:04:32
platform.twitter.com                            212.234.228.143 2015-01-15 23:20:37
plus.google.com                                 212.234.228.143 2015-02-03 03:23:34
tracker.thepiratebay.org                        212.234.228.143 2015-01-31 23:58:02
www.bloomberg.com                               212.234.228.143 2015-02-01 10:00:13
www.facebook.com                                212.234.228.143 2015-02-01 21:37:59
www.kanzhongguo.com                             212.234.228.143 2015-01-15 23:18:35
...

So, we can see that the original interpretation is correct: the Great Firewall, through DNS tampering, redirects many very popular names to innocent servers.

How many sites are used as "sinkholes" by the chinese censorship system? Let's query repeatedly www.facebook.com to an IP address in China (123.123.123.123) during 17 hours (on February 2nd). We retrieve 5559 answers. This is 1856 distinct IP addresses because some addresses are sent several times. So, it does not look random. Here are the most popular addresses (the owner name has been retrieved through the very useful cymruwhois package):

205.186.162.167 (MEDIATEMPLE - Media Temple, Inc.,US): 26
77.66.57.6 (NGDC NetGroup A/S,DK): 24
205.157.169.156 (ASN-PENNWELL - PennWell corporation,US): 24
216.201.83.226 (NATIONALNET-1 - NationalNet, Inc.,US): 24
64.20.49.2 (NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US): 24
193.188.112.80 (AS6453 - TATA COMMUNICATIONS (AMERICA) INC,US): 23
114.130.54.22 (BCC-MANGOCLIENT-AS-AP Bangladesh Computer Council,BD): 22
216.57.200.175 (WHIDBEY1 - Whidbey Internet Services,US): 22
74.121.192.250 (BLACKMESH-RST - BlackMesh Inc.,US): 21
137.117.70.70 (MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft Corporation,US): 21
70.32.110.223 (MEDIATEMPLE - Media Temple, Inc.,US): 21
184.173.133.194 (SOFTLAYER - SoftLayer Technologies Inc.,US): 21
5.9.26.245 (HETZNER-AS Hetzner Online AG,DE): 20
195.205.239.197 (TPNET Orange Polska Spolka Akcyjna,PL): 20
222.230.141.241 (VECTANT VECTANT Ltd.,JP): 20
91.213.100.50 (BRACK-AS Brack.ch AG,CH): 20
14.139.212.165 (NKN-CORE-NW NKN Core Network,IN): 20
54.235.118.83 (AMAZON-AES - Amazon.com, Inc.,US): 20
200.57.151.168 (Triara.com, S.A. de C.V.,MX): 20
62.109.134.70 (IGNUM-AS Ignum s.r.o.,CZ): 20
...  

As you can see, many IP addresses are used in the Great FireWall lies.

Now, let's indulge in some speculation. How are the IP addresses of the victim choosen? At random, and the Great FireWall administrators do not care of the consequences? On purpose, to turn every chinese Internet user into an involuntary accomplice of the dDoS? We must admit that we don't know.

This sort of "attack by referral" is a scourge of the Internet, because there is a very little to do against it. A famous example a few years ago, not involving the DNS, was D-Link NTP "attack".

Thanks to Benjamin Sonntag and Éric Duval for the data.


L'article seul

Fiche de lecture : Le poisson et le bananier

Auteur(s) du livre: David Bellos
Éditeur: Flammarion
978-2-0812-5624-8
Publié en 2011
Première rédaction de cet article le 5 février 2015


Ce n'est pas un roman, quoique le titre puisse faire croire mais une passionnante réflexion d'un traducteur sur son métier. La traduction, note-t-il, a commencé le jour où on s'est dit que les gusses de l'autre côté de la colline avaient peut-être des choses intéressantes à dire, et qu'il fallait donc traduire leur charabia. Mais, depuis, des tas de problèmes se sont posés. Faut-il traduire le plus littéralement possible ou bien faut-il prendre des libertés avec le texte original ? Comme il existe de facto une hiérarchie des langues (certaines sont plus prestigieuses que d'autres, ou utilisées par des empires plus puissants), la traduction « amont » (vers une langue plus prestigieuse) est-elle différente de la traduction « aval » (vers un idiome qui est moins considéré) ?

Le titre du livre dérive de la première question : un traducteur de la Bible, devant traduire que Jésus était sous un figuier, écrivant pour des gens originaires d'un pays où il n'y a pas de figuier, a fait s'assoir le Christ sous un bananier, arbre rare en Palestine... Un bel exemple de traduction « libre ».

Bellos couvre d'innombrables problèmes de traduction, et les solutions qui y ont été apportées. Comment traduire en français les romans russes du 19e siècle, où des dialogues entiers sont « en français dans le texte », le passage à cette langue indiquant un registre soutenu ? Pourquoi le méchant nazi dans les films sur la Seconde Guerre mondiale parle-t-il un français (ou un anglais) parfait, sauf qu'il hurle de temps en temps raus ou schnell ? Quelles sont les contraintes spécifiques du traducteur de BD (la taille fixe des phylactères...) ? Comment traduire les passages qu'on ne comprend pas (il y en a toujours, et le traducteur, contrairement au lecteur normal, ne peut pas sauter ce qu'il ne comprend pas) ?

L'original de ce livre est en anglais mais j'ai lu une traduction en français, ce qui m'a semblé bien adapté au sujet :-)

C'est en tout cas un livre à lire absolument si on est confronté à des traductions, et qu'on veut savoir comment ça s'est passé derrière, quelles étaient les conditions de production de la traduction, et quels sont les choix auxquels est confronté un traducteur. En prime, c'est vivant et drôle.

La page officielle de l'éditeur.


L'article seul

RFC 7451: Extension Registry for the Extensible Provisioning Protocol

Date de publication du RFC : Février 2015
Auteur(s) du RFC : S. Hollenbeck (Verisign Labs)
Pour information
Réalisé dans le cadre du groupe de travail IETF eppext
Première rédaction de cet article le 4 février 2015


Le protocole d'avitaillement EPP, normalisé dans le RFC 5730, est extensible : on peut rajouter des éléments afin de gérer des politiques locales. Jusqu'à présent, ces extensions n'étaient pas collectées en un endroit unique, ce qui pouvait mener à des duplications d'efforts inutiles. Ce nouveau RFC crée un registre d'extensions EPP, géré souplement (y mettre une extension est simple et ne nécessite pas d'accord formel de l'IETF) et qui permettra aux développeurs d'extensions de vérifier facilement si quelqu'un a déjà fait un travail analogue.

EPP est surtout connu pour son utilisation par les registres de noms de domaine. C'est ce protocole qui est utilisé par le titulaire du nom, ou par son bureau d'enregistrement, pour créer un nom, le modifier ou le supprimer. Chaque registre ayant sa propre politique d'enregistrement, le schéma EPP standard ne peut donc pas convenir à tout le monde (« one size does not fit all »). Voilà pourquoi beaucoup de registres ont créé des extensions. Le RFC 3735 les guide dans cette tâche, mais n'indique guère comment publier ces extensions (cf. la section 2.1 du RFC 3735). On a vu ainsi plusieurs registres développer des extensions différentes, et incompatibles, pour le même problème (comme d'indiquer les informations à propos de la TVA sur les objets créés en EPP).

Notre RFC crée donc un registre IANA des extensions EPP. La section 2 du RFC spécifie les détails de ce registre, et des mécanismes d'enregistrement d'une extension. La politique est « norme nécessaire » (cf. RFC 5226, section 4.1), ce qui impose qu'une spécification publique de l'extension soit disponible, et qu'elle soit évaluée par un expert nommé par l'IANA.

Les éventuelles discussions sur la nouvelle extension, ou la qualité de sa documentation, se feront sur la liste de l'actuel groupe de travail IETF EPPEXT, eppext@ietf.org. Même lorsque le groupe de travail sera dissous, la liste continuera donc.

Parmi les critères d'évaluation, outre ceux du RFC 3735, notre RFC rappelle l'importance d'évaluer les conséquences de l'extension pour la vie privée. Une préoccupation qui était absente du RFC 3735 mais qui a bien plus d'importance aujourd'hui. Autrement, notre RFC recommande aux experts évaluateurs d'être souples : si l'extension à EPP a été documentée et est effectivement déployée, elle mérite d'être enregistrée, même si l'expert a des objections techniques. Ainsi, ce n'est pas un problème si plusieurs extensions proches sont enregistrées : cela reflète la réalité. Si quelqu'un veut déposer une extension très proche d'une extension existante, on lui fera remarquer (et il pourra alors choisir d'utiliser plutôt l'extension existante) mais on ne le bloquera pas. (Ce point est celui qui avait fait l'objet des plus chaudes discussions dans le groupe de travail EPPEXT : certains auraient préféré une politique d'enregistremet plus stricte, limitant les doublons.)

Et comment fait-on pour enregistrer ? On envoie à l'IANA un formulaire (un gabarit se trouve dans la section 2.2.2 et des exemples réels dans la section 3) informant du nom de l'extension, de l'endroit où se trouve sa spécification (un URL suffit), des coordonnées de la personne ou de l'organisation qui enregistre, du TLD auquel elle s'applique (ou « N'importe lequel » si elle est d'usage général), ainsi que d'informations sur les éventuels boulets juridiques, par exemple un brevet sur ladite extension (cf. RFC 3979 et RFC 4879). Voici un exemple de formulaire d'enregistrement rempli (IPR = Intellectual Property Rights) :

   -----BEGIN FORM-----
   Name of Extension:
   "An Example Extension for the .example Top-Level Domain"

   Document Status:
   Informational

   Reference:
   http://www.example.com/html/example-epp-ext.txt

   Registrant Name and Email Address:
   John Doe, jdoe@example.com

   TLDs: .example

   IPR Disclosure:
   http://www.example.com/ipr/example-epp-ext-ipr.html

   Status: Active

   Notes: None
   -----END FORM-----

Et un exemple réel, l'enregistrement de l'extension « période de rédemption » du RFC 3915. La spécification étant un RFC, le contact est l'IESG :


      -----BEGIN FORM-----
      Name of Extension:
      "Domain Registry Grace Period Mapping for the
      Extensible Provisioning Protocol (EPP)"

      Document Status:
      Standards Track

      Reference:
      http://tools.ietf.org/html/rfc3915

      Registrant Name and Email Address:
      IESG, <iesg@ietf.org>

      TLDs: Any

      IPR Disclosure: None

      Status: Active

      Notes: None
      -----END FORM-----

Cette extension est une des quatre premières du registre IANA.


Téléchargez le RFC 7451


L'article seul

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

Date de publication du RFC : Février 2015
Auteur(s) du RFC : M. Duke (F5), R. Braden (ISI), W. Eddy (MTI Systems), E. Blanton, A. Zimmermann (NetApp)
Pour information
Réalisé dans le cadre du groupe de travail IETF tcpm
Première rédaction de cet article le 3 février 2015


C'est un RFC récapitulatif. Il ne normalise rien de nouveau mais dresse une liste commentée des RFC dont la connaissance est indispensable, ou simplement utile, au programmeur qui met en œuvre TCP.

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

Mais le RFC normatif, le RFC 793, quoique toujours valable, est bien vieux et beaucoup de choses ont été ajoutées ou retirées à TCP depuis. Comme pour beaucoup d'autres protocoles Internet (par exemple le DNS), TCP met donc le programmeur en face d'une rude tâche : avant de commencer à coder, il doit d'abord dresser la liste de tous les RFC dont il aura besoin. Et il faudra qu'il pense à chaque fois à regarder si des errata ont été publiés. C'est cette tâche d'établissement de liste que lui épargne notre RFC en dressant cette liste, et en la rangeant en trois sections, ce qui est impératif pour un TCP moderne (section 2 de notre RFC), ce qui est fortement souhaité (section 3), et ce qu'on peut ajouter si on veut (section 4). Ce « méta-RFC » a donc une bibliographie particulièrement longue, comportant 135 autres RFC. Le groupe de travail avait discuté de l'utilisation d'une autre méthode qu'un RFC, par exemple un Wiki, qui pourrait être plus facilement maintenu à jour, mais sans arriver à se décider pour une autre solution. (Notre nouveau RFC succède au RFC 4614, actualisant ses recommandations.)

Par exemple, le document original sur TCP ne contient rien sur le contrôle de congestion, qui ne sera décrit que dans le RFC 2001. Ce RFC 2001 (ou plus exactement son successeur, le RFC 5681) fait désormais partie de ceux qu'il faut lire. Notez que cette importance n'est pas forcément liée au statut officiel du RFC : le RFC 5681 n'est que projet de norme, alors qu'il est considéré essentiel. On trouve aussi dans cette section le RFC 6298, sur le calcul du délai avant retransmission, ou le RFC 6691 sur le calcul de la MSS.

Dans la section de ce qui est fortement recommandé (section 3), on trouve par exemple le RFC 7323 qui décrit plusieurs extensions nécessaires pour tirer des performances élevées, ou bien le RFC 3168 qui normalise ECN, ou encore le RFC 6582, sur l'algorithme NewReno.

Cette section compte également des RFC décrivant l'abandon d'options ou d'extensions inutiles, voire néfastes. C'est le cas du RFC 6633 qui supprime le mécanisme de répression de l'émetteur.

La sécurité ayant bien plus d'importance aujourd'hui, d'autres RFC décrivent comment se défendre contre certaines vulnérabilités par exemple la lecture du RFC 5961 va apprendre aux programmeurs de TCP comment résister aux attaques en aveugle, et celle du RFC 6528 est indispensable pour empêcher un attaquant d'insérer des paquets dans une session TCP existante.

D'autres extensions sont moins consensuelles et restent plutôt expérimentales à ce jour (section 4) comme l'algorithme Eifel du RFC 3522. Certaines de ces extensions non consensuelles sont encore récentes et s'imposeront peut-être, comme l'extension de la fenêtre initiale (RFC 6928) ou comme l'algorithme de réduction proportionnelle (RFC 6937).

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

Le protocole T/TCP, normalisé dans le RFC 1644, aurait permis de diminuer nettement la durée des connexions courtes, celles où on échange peu de données (beaucoup de connexions HTTP sont dans ce cas). Promu par des experts comme Stevens, implémenté dans des systèmes comme FreeBSD (option MSG_EOF de sendto), il a été remisé au grenier après que des analyses plus poussées aient montré ses failles de sécurité (il facilite l'utilisation de TCP avec usurpation d'adresses IP). Même sort pour le plus récent RFC 6013 qui décrivait un TCP Cookie Transaction mais qui n'a finalement pas suscité beaucoup d'intérêt. En revanche, TCP Fast Open (RFC 7413) est actuellement la méthode à la mode pour diminuer la latence.

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

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

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

La section 8 couvre enfin un cas délicat : les extensions à TCP qui, bien que largement utilisées, n'ont jamais fait l'objet d'un RFC ni même, souvent, d'une description formelle. C'est par exemple le cas de la prédiction d'en-tête, une méthode développée par Van Jacobson et Mike Karels à la fin des années 1980 pour accélérer le traitement des paquets TCP en essayant de prédire ce qu'allaient contenir leurs en-têtes. On programme un chemin rapide pour les paquets qui sont conformes aux prévisions et un chemin plus lent pour les paquets (minoritaires) qui surprennent. Van Vacobson avait décrit cette astuce dans un célèbre message de 1988 « The idea is that if you're in the middle of a bulk data transfer and have just seen a packet, you know what the next packet is going to look like ».

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


Téléchargez le RFC 7414


L'article seul

RFC 7440: TFTP Windowsize Option

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : Patrick Masotta (Serva)
Chemin des normes
Première rédaction de cet article le 29 janvier 2015


TFTP est un très vieux protocole de transfert de fichiers, surtout utilisé pour le démarrage de machines n'ayant pas les fichiers nécessaires en local, et devant les acquérir sur le réseau (par exemple via PXE). Reposant sur UDP et pas TCP comme tous les autres protocoles de transfert de fichiers, il peut être mis en œuvre dans un code de taille minimal, qui tient dans la mémoire morte. Par défaut, TFTP n'a pas de fenêtre d'envoi : chaque paquet doit faire l'objet d'un accusé de réception avant qu'on puisse envoyer le suivant. Ce RFC ajoute une option à TFTP qui permet d'avoir une fenêtre d'envoi, accélérant ainsi les transferts de fichier.

C'est le RFC 1350 qui est l'actuelle norme TFTP. Ce vieil RFC décrit le fonctionnement de base de TFTP en notant que « [each data packet] must be acknowledged by an acknowledgment packet before the next packet can be sent », ce qu'on nomme le lock-step. Dit autrement, TFTP a une fenêtre de taille 1. Vu par le dissecteur de paquets de pcapr, cela donne une stricte alternance des données et des accusés de réception :

1.		192.168.0.1	»	192.168.0.13	tftp	Write Request, File: rfc1350.txt\000, Transfer type: octet\000
2.		192.168.0.13	»	192.168.0.1	tftp	Acknowledgement, Block: 0
3.		192.168.0.1	»	192.168.0.13	tftp	Data Packet, Block: 1
4.		192.168.0.13	»	192.168.0.1	tftp	Acknowledgement, Block: 1
5.		192.168.0.1	»	192.168.0.13	tftp	Data Packet, Block: 2
6.		192.168.0.13	»	192.168.0.1	tftp	Acknowledgement, Block: 2
7.		192.168.0.1	»	192.168.0.13	tftp	Data Packet, Block: 3
8.		192.168.0.13	»	192.168.0.1	tftp	Acknowledgement, Block: 3

À l'époque du RFC 1350, il n'y avait aucun moyen de changer cela, TFTP n'ayant pas de mécanisme d'options. Mais le RFC 1782, remplacé depuis par le RFC 2347, lui en a donné un.

L'absence d'un mécanisme de fenêtre (ou, ce qui revient au même, le fait que la fenêtre soit de taille 1) serait dramatique pour des transferts sur l'Internet, où la latence est souvent élevée. Mais TFTP n'est quasiment utilisé que sur des LAN, où la latence est faible et les pertes de paquet rares. L'option Blocksize du RFC 2348, permettant des paquets plus grands que les 512 octets originaux, avait jusqu'à présent suffi à calmer les désirs de performance meilleure. Mais TFTP reste lent, et cette lenteur pose un problème lorsqu'on veut transférer de gros fichiers, comme une image Linux ou comme les PE de Microsoft utilisés par WDS/MDT/SCCM lorsqu'on démarre en PXE. Contrairement à ce que croient beaucoup de gens, TFTP est très loin d'être en voie d'extinction et il est donc justifié de chercher à l'améliorer. Le RFC se vante qu'avec cette option, TFTP peut aller aussi vite que les autres protocoles de transfert de fichier.

L'option elle-même est décrite dans la section 3. Le mécanisme d'option du RFC 2347 consiste en l'ajout de l'option à la fin du paquet Read Request ou Write Request. L'option comporte un nom (windowsize dans notre cas), et une valeur, qui est le nombre de blocs dans une fenêtre (rappelez-vous que, grâce à une autre option, celle du RFC 2348, un bloc ne fait pas forcément 512 octets). On peut envoyer autant de blocs qu'indiqué dans cette option, avant d'exiger un accusé de réception (la section 4 montre un schéma détaillé d'un transfert de données, avec une fenêtre de taille 4). Le récepteur des données accuse réception du dernier bloc (cela accuse implicitement réception des blocs précédents). Les accusés de réception TFTP indiquent en effet le numéro de bloc reçu (RFC 1350, dessin 5.3). Si un bloc se perd, l'émetteur des données s'en rendra compte en ne recevant d'accusé de réception que pour le bloc précédant le perdu, il pourra alors réémettre.

L'option windowsize aura dû être préalablement acceptée par le pair, via un OACK (Option Acknowledgment, RFC 2347).

Pour choisir des bonnes valeurs de fenêtre, une expérience a été faite (section 5), transférant un fichier de 180 Mo, avec des blocs de taille 1 456 sur un Ethernet gigabit, entre deux PC. Avec la fenêtre de 1 (la valeur obligatoire, avant notre RFC), le transfert prend 257 secondes. Il baisse ensuite lorsque la taille de la fenêtre augmente (76 secondes pour une fenêtre de 4, 42 secondes pour une fenêtre de 16) puis plafonne, aux alentours de 35 secondes, d'une fenêtre de taille 64 (pour les grandes fenêtres, le risque accru qu'un paquet dans la fenêtre soit perdu compense l'avantage qu'il y a à ne pas attendre les accusés de réception, il ne sert donc à rien d'augmenter indéfiniment la taille de la fenêtre). Un transfert avec un protocole classique (SMB/CIFS) prend 23 secondes. On voit donc que TFTP peut presque atteindre la même valeur.

Cela ne veut pas dire qu'il faut forcément choisir aveuglément une fenêtre de 64 blocs dans tous les cas : la valeur optimale dépend du réseau entre les deux machines. Le RFC recommande donc de tester avant de choisir.

TFTP utilise UDP, qui n'a pas de mécanisme de contrôle de la congestion. Un émetteur de données TFTP doit donc suivre les règles de prudence du RFC 5405 (notamment sa section 3.1) pour ne pas surcharger le réseau (section 6 de notre RFC). Contrairement à TCP, TFTP n'offre pas de mécanisme permettant de réduire la taille de la fenêtre en cours de route. En cas de gros problème de perte de paquets, la seule solution est d'avorter le transfert (ce qu'on nomme un circuit breaker) et de réessayer avec d'autres paramètres.

On trouve plein de traces TFTP sur pcapr mais aucune avec cette option. Parmi les mises en œuvres de TFTP, si le mécanisme d'options du RFC 2347 est souvent présent, ainsi que l'option de taille de bloc du RFC 2348, en revanche notre nouvelle option de taille des fenêtres ne semble pas encore souvent là. Parmi les programmes qui gèrent cette option : Serva (cité au paragraphe suivant), Node-tftp...

Un bon article de l'auteur du RFC explique cette option, les options précédentes, et leur implémentation dans Serva : « Advanced Topics on TFTP ».


Téléchargez le RFC 7440


L'article seul

RFC 7443: Application Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : P. Patil, T. Reddy, G. Salgueiro (Cisco), M. Petit-Huguenin (Impedance Mismatch)
Pour information
Réalisé dans le cadre du groupe de travail IETF tram
Première rédaction de cet article le 29 janvier 2015


ALPN, normalisé dans le RFC 7301, est une option du protocole de sécurité TLS pour permettre à un client TLS d'indiquer au serveur TLS quelle application il veut utiliser (car il n'y a pas que HTTPS qui utilise TLS...) Cela permet, notamment, d'utiliser un seul port (le seul qui passera depuis tous les réseaux, 443) pour plusieurs applications. Ce nouveau RFC 7443 utilise ALPN pour permettre à un client STUN de signaler au serveur TLS qu'il veut faire du STUN, et lui permet également de spécifier quel usage de STUN (par exemple le relayage des sessions TCP nommé TURN).

STUN sert normalement aux clients tristement coincés derrière un stupide boitier, genre routeur NAT, pour communiquer avec d'autres malheureux dans le même cas (et qui ne peuvent donc pas être appelés directement). Il est surtout utilisé pour le pair-à-pair et pour la communication multimédia (téléphonie sur IP par exemple). STUN peut fonctionner sur TLS, pour plus de sécurité (RFC 5389, section 7.2.2, et RFC 7350 si on utilise UDP). Notre nouveau RFC permet à STUN-sur-TLS d'utiliser l'extension TLS ALPN en indiquant comme application un de ces deux choix :

  • stun.turn : utilisation de STUN et de TURN (RFC 5766),
  • stun.nat-discovery : utilisation de STUN pour découvrir les caractéristiques d'un routage NAT.
  • Après une sérieuse discussion à l'IETF, il a été décidé qu'il n'y aurait pas d'application « STUN générique » (par exemple pour des usages futurs encore inconnus).

Ces deux noms sont désormais enregistrés dans la liste des protocoles applicatifs ALPN.

À l'heure actuelle, il ne semble pas qu'il y ait encore de mise en œuvre de ce système mais les clients WebRTC devraient logiquement être dans les premiers à s'y mettre.


Téléchargez le RFC 7443


L'article seul

Ce que nous apprend Ghost au sujet des vieilles API

Première rédaction de cet article le 27 janvier 2015


Vous avez certainement déjà tout lu sur la vulnérabilité « Ghost » de la GNU libc (alias CVE-2015-0235). Si ce n'est pas le cas, vous pouvez vous documenter sur le blog du découvreur ou bien en lisant cette analyse technique ultra-détaillée. Mais un aspect de cette faille a été peu remarqué : qui diable utilise encore l'API gethostbyname, complètement dépassée ?

La faille se trouvait en effet dans une fonction nommée __nss_hostname_digits_dots qui est appelée par les fonctions, bien plus connues, gethostbyname et gethostbyaddr. Ces fonctions servent à traduire un nom de domaine en adresse IP, en général en faisant appel au DNS. Elles sont dépassées depuis longtemps et ne devraient plus être utilisées, notamment parce qu'elles ne permettent pas de faire de l'IPv6.

Ce point a bien été noté par les découvreurs de la faille (et, indépendamment, par certains sur les rézosocios), auteurs qui notent, dans le rapport technique, « The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead. ». En effet, en 2015, on n'imagine pas qu'il puisse exister des programmes qui se limitent volontairement à IPv4, en utilisant ces vieilles API.

Car ce n'est pas qu'une matière d'esthétique : les fonctions officiellement remplacées par des meilleures ne sont pas forcément aussi bien maintenues, et on peut penser que les failles n'y sont pas aussi vite repérées et corrigées. Les programmes utilisant les anciennes API ont donc plus de chance d'avoir des failles de sécurité comme Ghost.

Au fait, que faut-il utiliser depuis plus de quinze ans ? getaddrinfo, introduit à l'origine dans le RFC 2133 et actuellement normalisé dans le RFC 3493. (Vous trouverez mes exemples personnels dans mon article sur les structures de données réseau en C.) gethostbyname avait été marqué obsolescent dans POSIX en 2001 et supprimé complètement en 2008...

Aujourd'hui, si on cherche les « parts de marché » respectives de gethostbyname et getaddrinfo, on trouvera probablement qu'un grand nombre de programmes utilise toujours l'ancienne API. Ignorance, lecture de vieux HOWTO dépassés, cours jamais mis à jour...

Également à lire, sur Ghost :


L'article seul

Davantage de cloche à vache : la NSA espionne aussi le DNS

Première rédaction de cet article le 24 janvier 2015


Quelques jours après le FIC (Forum International sur la Cybersécurité, où on avait beaucoup parlé de méchants hackers, forcément djihadistes), un article du Monde nous rappelle que les plus grandes attaques contre la sécurité de l'Internet viennent des États. L'article révèle l'existence du programme MoreCowBell (« davantage de cloche à vache ») de la NSA, programme d'espionnage du DNS. L'article du Monde est assez flou, questions détails techniques, donc voici quelques explications supplémentaires.

Vous pouvez également en trouver, et jusqu'à saturation, dans « NSA’s MORECOWBELL: Knell for DNS », écrit par les personnes qui ont préparé l'article du Monde (Grothoff est l'auteur de GNUnet, Ermert est une excellente journaliste connaissant bien l'Internet, Appelbaum travaille sur Tor). Dans cet article en anglais (il y a une traduction en français, vous aurez tous les détails sur MoreCowBell mais aussi sur les travaux de l'IETF pour améliorer le DNS, sur les systèmes alternatifs de nommage comme GNUnet, etc. Au cas où vous n'ayez pas envie de changer de page Web, voici mes informations à moi.

Pour résumer l'article du Monde, la NSA espionne le DNS de deux façons :

  • Récolte passive de données, probablement via une écoute directe du trafic Internet (quelque chose que la NSA fait souvent), suivie d'une dissection automatique des paquets DNS et stockage dans une base de données. Rien d'extraordinaire, le trafic DNS étant en clair, et des services moins secrets le font depuis longtemps, comme DNSDB ou PassiveDNS.cn.
  • Récolte active de données par des attaques par dictionnaire, où une sonde (dans le cas de la NSA, la sonde passe par des résolveurs DNS ouverts, comme Google Public DNS, pour mieux dissimuler ses traces) interroge des serveurs DNS sur des noms possibles ou vraisemblables (en utilisant tous les mots du dictionnaire, par exemple). C'est ce que le Monde, curieusement, appelle « adresses fictives mais plausibles ». Les serveurs DNS reçoivent ce genre d'attaques très souvent (ce sont en général des spammeurs qui cherchent à se constituer des listes de noms de domaine).

Comme toujours avec la NSA, rien de surprenant (seuls les naïfs seront étonnés), des techniques classiques, mais déployées à grande échelle.

Maintenant, sur quelques points obscurs de l'article du Monde :

  • « Serveur DNS interne » est apparemment un néologisme du Monde pour résolveur.
  • « Les numéros IP "en chiffres", correspondant aux adresses "en mots", sont gérés par l’Internet Assigned Numbers Authority (IANA) » C'est tellement résumé que c'est quasiment faux : si l'IANA attribue bien les préfixes (et encore, c'est fini depuis longtemps en IPv4), ce sont les RIR qui font le gros du travail et définissent les politiques d'attribution.
  • La phrase « quand ils reçoivent une demande pour une adresse qui n’existe pas, ils renvoient un message d’erreur accompagné de deux suggestions » est probablement une allusion aux possibilités d'énumération liées à l'ancienne technologie NSEC, possibilités décrites (avec la solution) dans mon article sur le RFC 5155.
  • MoreCowBell, si on se fie aux PowerPoint de la NSA, n'utilise pas que le DNS, mais aussi HTTP. Quand le Monde écrit « quand une attaque est déclenchée, l’interrogation des serveurs DNS va servir à évaluer son efficacité en temps réel. Grâce à MoreCowBells [sic], la NSA saura si le service attaqué continue à fonctionner ou s’il a été coupé », il confond probablement ces deux protocoles. Le DNS ne peut pas servir à savoir si un serveur a cessé de fonctionner.
  • En revanche, « s’il a été déplacé vers un autre serveur par mesure de protection, elle va le repérer à nouveau, ce qui permettra de reprendre l’attaque » peut en effet se faire avec le DNS mais cela n'a rien d'extraordinaire : bien des attaquants qui font des dDoS font pareil.

Par-delà ces détails dans les explications, voilà pourquoi il est essentiel de travailler à améliorer la protection de la vie privée dans le DNS (il faut aussi travailler à mettre fin aux délirants pouvoirs de la NSA, une menace pour tout le monde, mais c'est une autre histoire). À l'IETF, le principal effort, dans la lignée du RFC 6973, est fait dans le groupe de travail DPRIVE. Son premier RFC sera sans doute le document de description du problème. Pour le chiffrement des requêtes DNS, afin d'assurer leur confidentialité, ma proposition préférée est T-DNS mais l'idée d'utiliser l'ALPN de TLS est également tentante. Une partie de l'effort IETF est également faite dans le groupe de travail DNSOP, où se fait l'élaboration de la proposition de minimisation des données envoyées.

Et, bien sûr, une autre solution serait d'utiliser des systèmes alternatifs au DNS, prenant mieux en compte le respect de la vie privée. Ils existent (Namecoin, Tor / dot-onion, etc) mais ils posent de redoutables problèmes.

Un autre article en français sur ce programme est dans 01 Net.


L'article seul

RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : B. Carpenter (Univ. of Auckland), T. Chown (Univ. of Southampton), F. Gont (SI6 Networks / UTN-FRH), S. Jiang (Huawei Technologies, A. Petrescu (CEA, LIST), A. Yourtchenko (cisco)
Pour information
Réalisé dans le cadre du groupe de travail IETF 6man
Première rédaction de cet article le 23 janvier 2015


C'est vrai, ça, pourquoi 64 ? Les adresses du protocole IPv6 ont deux parties, une qui identifie le réseau et l'autre qui identifie la machine. Cette dernière est souvent considérée comme faisant forcément 64 bits. Est-ce vraiment une taille impérative ? Et, si oui, pourquoi ? (Si vous êtes pressé, les réponses du RFC sont « non, mais quand même oui » et « essentiellement en raison de la base installée ».)

Pendant la phase de conception d'IPv6, il y avait eu toute une discussion à l'IETF sur la taille idéale des adresses. La plupart des propositions initiales suggéraient 64 en tout, ce qui était déjà beaucoup pour les processeurs de l'époque (de même que, quand IPv4 avait été conçu, peu de processeurs pouvaient traiter 32 bits comme une donnée de base). Mais c'est finalement 128 bits qui a été choisi. 64 bits permettaient déjà d'adresser plus de machines qu'on ne pouvait en rêver. Mais 128 bits permettait plus de souplesse, et autorisait le développement de mécanismes d'adresse rigolos, par exemple d'utiliser des clés crytographiques comme adresses (RFC 7343).

Une fois ce choix fait, le RFC sur l'adressage IPv6, le RFC 4291, introduisait la notion d'identificateur d'interface (interface identifier ou IID). L'adresse comprend alors deux parties, n bits pour identifier le réseau et 128-n bits pour l'identificateur d'interface. Comme précisé par le RFC 7136, ces identificateurs d'interface n'ont pas de signification en dehors de la machine qui les a alloués et doivent donc être traités comme des valeurs opaques.

Le routage se fait sur la base du préfixe réseau, dont la longueur peut être quelconque, jusqu'à 128 bits. Tous les protocoles de routage gèrent des longueurs de préfixe variables, sans supposition a priori.

Bon, donc, le routage n'impose pas de préfixe de longueur 64, et se moque de la longueur du préfixe. Mais l'autoconfiguration d'adresse sans état (SLAAC), du RFC 4862, elle, considère la longueur 64 comme spéciale ? Non plus. Ce chiffre 64 n'apparait pas dans le RFC 4862 car la longueur de l'identificateur d'interface dépend du type de réseau sous-jacent et est donc spécifiée dans un autre RFC, spécifique à chaque technologie. Pour Ethernet, c'est le RFC 2464, et la longueur spécifiée est bien 64. Donc, pour Ethernet, si on veut de l'auto-configuration sans état, on ne peut pas avoir de réseau ayant un préfixe plus long que 64 bits. DHCP (RFC 3315) suit la même règle et n'a donc pas de chiffre « 64 » magique.

Si l'identifiant d'interface à 64 bits est aujourd'hui largement répandu, c'est en partie à cause de la part de marché d'Ethernet. Il était plutôt prévu de le mettre à 48 bits au début avant que les identifiants EUI-64 ne remplacent les EUI-48. Résultat, le RFC 4291 a sérieusement réduit la souplesse d'IPv6 en parlant d'identificateurs d'interface de 64 bits et en laissant entendre qu'ils étaient forcément dérivés d'une adresse MAC (le RFC 7136 a partiellement corrigé cette erreur mais trop tard, beaucoup de gens sont aujourd'hui persuadés que les 64 derniers bits d'une adresse IPv6 sont forcément une adresse Ethernet). Quant à l'autre choix, de fixer les identificateurs d'interface à 64 bits, il n'a pas empêché le RFC 6164 de recommander 1 seul bit pour cet identificateur, dans le cas de liaisons point-à-point.

Malheureusement, un certain nombre de logiciels et de matériels ont peut-être été bâtis en supposant un identificateur d'interface de 64 bits et, hélas, une autre longueur, bien que techniquement correcte, posera des problèmes si on s'approche de ces logiciels et matériels. Pourquoi diable le RFC 4291 a-t-il sanctifié cette valeur de 64 bits ? Et peut-on encore la changer ?

D'abord (section 2 du RFC), les avantages qu'il y a à avoir une frontière fixe entre le réseau et l'identificateur d'interface. Pour l'auto-configuration sans état (SLAAC pour StateLess Address AutoConfiguration), il faut que la longueur du préfixe, pour un type de réseau physique donnée, soit identique pour toutes les machines du réseau local, et connue à l'avance, donc fixe. Bien sûr, elle n'est pas forcément de 64 bits. Mais le poids d'Ethernet, où cette longueur est de 64 bits, et le désir de simplifier les choses (cf. RFC 5505) poussent à l'uniformisation.

Le RFC 4291 (section 2.5.1), on l'a vu, cite déjà cette limite fixe de 64 bits. Le préfixe du réseau local a donc forcément 64 bits de long, quelle que soit la taille du préfixe qui nous a été alloué (au moins un /56, si on suit le RFC 6177). Cela simplifie la conception des réseaux (préfixe de longueur identique sur tous les liens réseaux d'un campus, par exemple, un très gros avantage par rapport à IPv4, où le manque d'adresses oblige à calculer au plus juste chaque longueur de préfixe), la gestion des préfixes (pas besoin de faire un calcul à chaque allocation, un nouveau lien, paf, je lui donne un /64), la configuration des routeurs et la documentation du réseau de l'organisation sont plus simples.

Garantir une certaine taille pour l'identificateur d'interface permet de choisir le mécanisme qu'on veut pour leur allocation. Des préfixes longs risqueraient de réduire la taille de l'espace des identificateurs d'interface, au point de contraindre l'administrateur réseaux dans sa politique d'allocation.

Les sections suivantes du RFC examinent les arguments contre cette taille fixe de 64 bits mais je vous révèle la fin du RFC tout de suite : l'IETF estime que les avantages d'une longueur d'identificateur d'interface plus ou moins fixée à 64 bits l'emportent sur les inconvénients.

Bon, maintenant, pour la culture de mes lecteurs, quels auraient été les raisons de ne pas imposer une taille spéciale aux identificateurs d'interface ? D'abord, le /64 partout peut mener à du gaspillage. J'ai un réseau avec une demi-douzaine de serveurs statiquement configurés, ou bien utilisant DHCP (donc pas de SLAAC), même si chacun d'eux a plusieurs adresses IP, pourquoi ne pourrais-je pas utiliser un /96 ou similaire, pour économiser des adresses ? Bien sûr, l'espace d'adressage d'IPv6 est très grand mais un utilisateur donné peut n'avoir reçu qu'un seul /64, et comment fait-il alors s'il veut mettre plusieurs réseaux physiques derrière ?

Le RFC 7368, portant sur les réseaux à la maison, écarte la solution des préfixes plus longs (cf. sa section 3.4.1) et préfère mettre la pression sur les FAI pour qu'ils distribuent plus d'un préfixe /64. Il n'y a en effet aucune raison de faire des économies : l'espace IPv6 actuellement utilisé (le 2000::/3, qui ne représente que 13 % de l'espace d'adressage possible) permet 35 billions de /48 donc en donner un à chaque utilisateur humain ne pose aucun problème. Même avec un très mauvais « ratio HD », 0,89, on pourrait encore allouer un trillion de préfixes /48 (voir le RFC 4692, sur ces calculs et sur la notion de ratio HD).

Un autre argument a parfois été présenté pour justifier des préfixes plus longs que 64 bits : cela permet d'avoir davantage de réseaux locaux lorsqu'on a reçu une allocation trop petite. Ceci dit, avec un /48, on a 65 536 réseaux, ce qui est déjà énorme. Il a aussi été dit que des préfixes plus longs que 64 bits permettraient, sinon davantage de réseaux, en tout cas une meilleure agrégation des préfixes mais cet argument ne semble pas tenir non plus : même dans le pire cas (routage complètement à plat, zéro agrégation), router des milliers de préfixes ne pose aucun problème.

Une autre raison pour souhaiter des préfixes plus spécifiques que 64 bits vient des exigences de traçabilité. Moins de bits pour l'identifiant d'interface voudrait dire moins de possibilités qu'une machine prenne l'adresse qu'elle veut, ce qui faciliterait la tâche de l'administrateur réseaux. Comme le précédent, cet argument semble très faible : il existe d'autres méthodes pour surveiller ses machines (par exemple ndpmon).

Beaucoup plus sérieux est le risque d'attaque sur le protocole NDP par épuisement du cache (voir les supports d'exposé de Jeff Wheeler). L'idée de l'attaquant est d'envoyer des paquets à des tas de machines non existantes. Le routeur menant au lien de ces machines va devoir faire une résolution d'adresse IP en adresse MAC, avec NDP et, la machine n'existant pas et ne répondant donc pas, le routeur va devoir mettre une demande en attente, dans une mémoire qui a une taille fixe et qui peut donc être vite remplie (le RFC 3756 détaille cette attaque). Avec un /120 (ou bien avec les préfixes typiques d'IPv4, pour qui cette attaque est également possible), l'attaquant ne pourra occuper que 256 entrées dans la mémoire. Avec un /64, il aura beau jeu pour la remplir complètement (même un /96 serait largement suffisant pour l'attaquant). C'est d'ailleurs un argument du RFC 6164 (section 5.2) pour justifier sa recommandation d'un /127.

Notre nouveau RFC estime que ce risque, quoique réel, n'est pas suffisant pour justifier des préfixes ultra-longs (genre /120) et qu'il vaut mieux déployer les recommandations du RFC 6583.

La section 3 parlait des arguments en faveur d'un préfixe plus long que 64 bits. Mais il y a aussi un autre débat, qui est celui sur les préfixes de longueur variable. Un argument en faveur de « tout le monde en /64 » était que cela fournissait une longueur de préfixe constante. Que se passe-t-il si elle ne l'est pas ? La section 4 du RFC se penche là-dessus. D'abord, par rapport aux normes. Malheureusement, la situation est confuse. Si les RFC 4291, RFC 6177, RFC 5453, RFC 6741 et RFC 7084 font tous référence à une longueur magique de 64 bits, ils ne sont pas forcément très clairs et précis sur le statut de cette référence : simple exemple, constatation de l'existant ou réelle normalisation ? Le RFC 5942 dit au contraire que les mises en œuvre d'IPv6 ne doivent pas supposer une longueur de préfixe fixe.

Les RFC décrivant le cas particulier d'une technologie de couche 2 donnée sont en général plus clairs, et beaucoup imposent un identificateur d'interface de 64 bits (et donc un préfixe de 64 bits) pour l'autoconfiguration sans état. C'est le cas des RFC 2464 (Ethernet, déjà cité), RFC 2467 (FDDI), RFC 4338 (Fibre Channel), RFC 5072 (PPP), etc.

D'autres RFC semblent (mais c'est souvent vague) supposer qu'un identifiant d'interface fait forcément 64 bits. C'est le cas du RFC 4862 pour les adresses locales au lien, du RFC 4429 pour la détection d'adresses dupliquées, du RFC 5969 sur 6rd, du RFC 6437 au sujet du flow label, etc. Dans certains cas, la dépendance vis-à-vis de la longueur du préfixe est plus nette, comme une technique pour étendre un préfixe IPv6 reçu en 3G sur une interface WiFi (RFC 7278), dans les CGA du RFC 3972 ou dans les adresses protégeant la vie privée du RFC 4941.

Et si on est courageux, et qu'on essaie quand même de mettre des identificateurs d'interface dont la longueur est différente de 64 ? Que risque-t-on ? D'abord, certains routeurs peuvent avoir mal lu les spécifications et penser que des identificateurs d'interface entre 65 (RFC 7136) et 126 (RFC 6164) sont invalides, refusant de configurer ainsi une interface ou, pire, refusant ensuite de transmettre des paquets. (Je n'ai pas connaissance d'un étude systématique de routeurs à ce sujet, ni de récit détaillé d'un problème avec un routeur.) CGA, on l'a vu, ne marcherait pas du tout. On peut changer sa spécification mais attention, diminuer la taille de l'identificateur d'interface diminuerait la sécurité de CGA (même chose pour les techniques qui visent à protéger la vie privée par des identificateurs d'interface choisis aléatoirement, cf. section 4.5). Par contre, NAT64 (RFC 6146) marcherait sans doute, jusqu'à 96 bits de préfixe réseau (car il faut garder au moins 32 bits pour l'adresse IPv4 de destination). En revanche, NPT (Network Prefix Translation, RFC 6296) est lié aux 64 bits. Même chose pour ILNP (RFC 6741).

Le mécanisme DAD (Duplicate Address Detection, RFC 4862, section 5.4) pourrait avoir des problèmes si on réduisait trop la taille des identificateurs d'interface. Par exemple, avec un /120, et les adresses du RFC 7217, il n'y aurait que 256 identificateurs d'interface possible et donc des risques de collision élevés. Enfin, les adresses locales au lien, bien que prises dans un espace très large (fe80::/10) sont en fait quasiment toujours formées pour un préfixe de longueur 64 (et l'espace réel est donc fe80::/64) et il n'y a pas de moyen simple de le changer (ce n'est que rarement une option de configuration de la machine).

La section 4.3 contient les résultats d'essais systématiques d'essais de préfixes différents de /64, essais faits avec plusieurs systèmes d'exploitation. Avec des préfixes plus longs ou plus courts que 64 bits, et un routeur qui annonce, via les RA (Router Advertisement), un tel préfixe dans le champ Prefix Information Option, tout marche bien sur tous les Unix et sur Windows (l'essai a également été fait sans le bit L dans l'option, bit qui indique que le préfixe pour être utilisé pour déterminer si le préfixe est sur le lien local et, dans ce cas, les machines ignorent à juste titre le préfixe). Par contre, l'option Route Information Option du RFC 4191 marche nettement moins bien sur les Unix, mais c'est le cas même avec une longueur de 64 bits.

D'autre part, les informations recueillies par les participants à l'IETF sur divers réseaux indiquent que les routeurs routent bien sur des préfixes de longueur quelconque (la recherche d'une route du préfixe le plus long est un algorithme de base d'IP, il est plus ancien qu'IPv6). Et, dans les expériences pratiques, DHCP ne semble pas avoir de problème non plus (un déploiement réel utilise des /120...)

Certains routeurs ont des problèmes de performance car ils traitent à part les préfixes plus longs que 64 bits. Cela fonctionne mais pas aussi vite.

Au moins un équipement réseau à une TCAM limitée à 144 bits ce qui fait que les ACL ne peuvent pas être définies pour un préfixe quelconque, puisqu'elles permettent également de mettre deux ports de 16 bits chacun. Avec un tel équipement, on ne peut pas utiliser d'ACL avec un préfixe plus long que 112 bits.

Bref, la situation des mises en œuvre d'IPv6 ne semble pas trop mauvaise. Contrairement à ce que l'on aurait pu craindre, peu ou pas de programmeurs ont, en lisant trop vite les spécifications, considéré qu'un identificateur d'interface était toujours de 64 bits et, donc, peu de programmes ont cette taille « câblée en dur ». Évidemment, on ne peut pas être sûr tant qu'on n'a pas testé toutes les implémentations, une tâche impossible.

Il n'y a pas que le code IPv6 proprement dit : il y a aussi les outils auxiliaires comme les IPAM. Ont-ils également une taille de préfixe magique fixée dans leur code ? Apparemment, cela n'a pas été testé.

Il y a aussi les craintes liées aux humains : si on décidait de mettre des identificateurs d'interface d'une longueur différente de 64 bits, ne risque-t-on pas d'avoir à reprendre la formation de certains, qui ont mal compris leur cours IPv6 et croient que 64 bits a une signification spéciale ?

Un éventuel changement de la longueur des identificateurs d'interface a aussi des conséquences pour la sécurité. D'abord, la vie privée (section 4.5) : si on tire au sort un identificateur d'interface, pour le rendre difficile à deviner par un observateur indiscret, l'identificateur ne doit évidemment pas être trop petit, sans cela l'observateur pourrait essayer la force brute pour le deviner. Il est difficile de donner un chiffre précis mais notre RFC estime qu'un préfixe de plus de 80 bits, laissant moins de 28 bits pour l'identificateur d'interface, serait trop prévisible.

La longueur de l'identificateur d'interface a également des conséquences pour le balayage (RFC 5157) : il est beaucoup plus difficile de balayer systématiquement un réseau IPv6 qu'un réseau IPv4, en raison du nombre d'adresses possibles. Si on a un long préfixe, le balayage devient réaliste : un /120 IPv6 prendrait autant de temps à balayer qu'un /24 IPv4, c'est-à-dire très peu de temps. (Le problème est proche de celui des CGA, et de celui de la vie privée, déjà cité : beaucoup de techniques de sécurité dépendent de la taille de l'espace possible, en la réduisant, on facilite les attaques.)

En conclusion, si certains points d'IPv6 ne devraient absolument pas dépendre de la longueur du préfixe, qui est un simple paramètre (le routage, par exemple), d'autres sont bien plus liés au nombre magique de 64. Sans compter le risque qu'une partie de la base installée (et pas seulement logicielle, aussi les humains) ait attribué à ce nombre 64 encore plus d'importance que ce que les normes IPv6 prévoient. Le RFC décide donc d'entériner cet usage et de recommander qu'on ne s'éloigne pas de 64 sans de très bonnes raisons.


Téléchargez le RFC 7421


L'article seul

RFC 3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6

Date de publication du RFC : Décembre 2003
Auteur(s) du RFC : O. Troan, R. Droms
Chemin des normes
Première rédaction de cet article le 18 janvier 2015


On peut en IPv6 déléguer un préfixe d'adresse IP d'un routeur à un autre routeur. Par exemple, le routeur du FAI peut, via DHCP, déléguer au routeur CPE le préfixe que celui-ci annoncera ensuite en RA (Router Advertisement) sur le réseau local.

Vous verrez rarement cette option DHCP (DHCP est dans le RFC 3315) sur vos réseaux locaux. Son utilité principale est au sein du réseau d'un FAI, pour distribuer aux clients, non pas uniquement des adresses (comme on le fait en IPv4, où il n'y a pas assez d'adresses pour attribuer des préfixes), mais des préfixes entiers. Notez qu'il s'agit bien de délégation : le routeur qui reçoit un préfixe peut en faire ce qu'il veut, y compris le sous-déléguer en préfixes plus petits (les réseaux locaux n'ont pas forcément qu'un seul lien, ils peuvent être multiples, cf. RFC 7368). Cette option de délégation de préfixe est donc utile pour tous les cas où le routeur qui délègue (le déléguant, le serveur DHCP) ne connait pas la topologie du réseau chez le routeur qui reçoit la délégation (le requérant, le client DHCP) et ne peut donc pas attribuer les préfixes à chaque sous-réseau. Elle suit les exigences posées dans le RFC 3769, le cahier des charges de cette option.

Bien sûr, une autre solution serait une délégation manuelle (envoyer le préfixe par courrier au client et attendre qu'il le configure dans son routeur CPE) mais cette méthode dynamique rend beaucoup plus facile une future renumérotation.

Donc, si vous voulez le modèle général de fonctionnement, regardez la section 5 : le routeur déléguant a un certain nombre de préfixes IP à distribuer, le routeur requérant, demande en DHCP un ou plusieurs préfixes, le déléguant lui répond avec les préfixes attribués. Chaque préfixe a une durée de vie associée et le requérant devra donc demander un renouvellement.

La délégation de préfixe est indépendante de celle d'adresse. Le routeur client peut utiliser DHCP pour avoir adresse et préfixe, ou bien seulement pour l'adresse ou seulement pour le préfixe.

Les préfixes ainsi délégués ne sont pas liés à une interface réseau particulière, au sens où les adresses réseau le sont, et le routeur client, qui a reçu la délégation, peut l'utiliser sur d'autres interfaces que celle où il l'a reçue.

Maintenant, le format des options. Pour le comprendre, il faut dire un mot de la notion d'IA_PD (section 3 du RFC). Une IA_PD (Identity Association for Prefix Delegation) est un ensemble de préfixes IP gérés collectivement. Le routeur requérant ne reçoit pas un seul préfixe mais une ou plusieurs IA_PD, chacune pouvant comporter plus d'un préfixe. Chaque IA_PD est associée à un IAID, qui est un identificateur unique pour le routeur requérant, et qui lui permet d'avoir plusieurs IA_PD (par exemple si deux de ses interfaces sont connectées à des FAI différents).

En section 9, le format des messages DHCP. L'option IA_PD (code 25 dans le registre IANA des options DHCP) est envoyée par le routeur requérant dans sa question (message Solicit, cf. RFC 3315, section 17.1, pour dire qu'il veut des préfixes) et par le routeur déléguant dans sa réponse (message Advertise, cf. RFC 3315, section 17.2, pour indiquer les préfixes délégués). Dans les deux cas, elle comprend l'IAID (un nombre sur quatre octets choisi par le requérant), et une série d'options parmi lesquelles se trouvent les options IAPREFIX (code 26) qui contiennent les préfixes IP et leurs durées de vie. Dans la requête, il peut évidemment n'y avoir aucun préfixe (le routeur requérant demande mais ne propose rien). Chaque option IAPREFIX contient un seul préfixe mais il peut y avoir plusieurs options de ce type dans une option IA_PD.


Téléchargez le RFC 3633


L'article seul

À propos de la panne d'Oxalide

Première rédaction de cet article le 16 janvier 2015
Dernière mise à jour le 22 janvier 2015


Ce matin, l'hébergeur Oxalide a été en panne pendant environ une heure et demie, entraînant l'indisponibilité d'un grand nombre de sites Web, notamment de la presse française.

C'est ainsi que 20 Minutes, l'Express, le Parisien, Slate, Mediapart, Marianne, FranceInfo (mais pas Charlie Hebdo) ont été injoignables. Comme tous les zexperts, je ne sais pas ce qui s'est passé donc je vais me contenter de dire ce que j'ai observé.

Plusieurs de ces sites Web renvoyaient un message « 504 Gateway Time-out - nginx » qui est le message typique de CloudFlare lorsque leurs relais n'arrivent pas à joindre le site réel (CloudFlare n'est pas un CDN, ils n'ont pas une copie du site Web, ils servent juste d'écran, notamment en cas de dDoS).

Oxalide avait arrêté d'envoyer des annonces BGP, le protocole qui sert à annoncer au reste de l'Internet qu'on est joignable. (Pourquoi ? Ne me posez pas la question, j'ai dit que je n'en savais rien.) Voici le looking glass de Hurricane Electric, http://lg.he.net, pendant la panne, le préfixe IP 91.208.181.0 est inconnu :

Voyons les annonces BGP pendant la période de la panne. On utilise pour cela les données de RouteViews. Elles sont en binaire, au format MRT (RFC 6396), il faut les transformer en texte avec bgpdump. On sait d'après Twitter l'heure approximative de la panne, on va donc récupérer le fichier, le transformer en texte et le fouiller :

% wget ftp://archive.routeviews.org/route-views.linx/bgpdata/2015.01/UPDATES/updates.20150116.0845.bz2
% bgpdump  updates.20150116.0845 > updates.20150116.0845.txt

Et explorons ce fichier, avec un éditeur ordinaire. On voit bien la panne. L'annonce du préfixe 91.208.181.0/24 a commencé à être perturbée vers 08:51:01 UTC. À noter qu'il existe deux types de mise à jour BGP dans un message, l'annonce de nouvelles routes (ANNOUNCE) et le retrait de routes qui ne sont pus bonnes (WITHDRAW). Paradoxalement, la disparition d'une route (ici celle vers 91.208.181.0/24) se traduit d'abord par des ANNOUNCE avant d'avoir le premier WITHDRAW. En effet, les routeurs BGP tentent de passer par un autre chemin et relaient d'abord les autres informations qu'ils ont, avant de renoncer et de retirer la route. Une panne se signale donc d'abord par une floppée d'ANNOUNCE. La première était :

TIME: 01/16/15 08:51:01
TYPE: BGP4MP/MESSAGE/Update
FROM: 195.66.224.21 AS6939
TO: 195.66.225.222 AS6447
ORIGIN: IGP
ASPATH: 6939 8218 47841
NEXT_HOP: 195.66.224.21
ANNOUNCE
  91.208.181.0/24

À 08:51:01 (UTC), le routeur 195.66.224.21 transmet à son pair 195.66.225.222 une nouvelle route vers 91.208.181.0/24, car il vient de perdre celle qu'il connaissait avant. Dans les secondes qui suivent, des tas d'autres routeurs font pareil avant de se résigner, et de retirer la route :

TIME: 01/16/15 08:51:10
TYPE: BGP4MP/MESSAGE/Update
FROM: 195.66.224.175 AS13030
TO: 195.66.225.222 AS6447
WITHDRAW
  ...
  91.208.181.0/24
  ...

Attention au passage lorsque vous lisez l'attribut ASPATH (chemin d'AS), il se lit de droite à gauche, l'AS d'origine est 47841 (Oxalide).

Une heure et demie après, la route vers 91.208.181.0/24 réapparait (avec les deux autres préfixes IPv4 habituels d'Oxalide) :

TIME: 01/16/15 10:20:13
TYPE: BGP4MP/MESSAGE/Update
FROM: 195.66.224.51 AS6453
TO: 195.66.225.222 AS6447
ORIGIN: IGP
ASPATH: 6453 1299 47841
NEXT_HOP: 195.66.224.51
ANNOUNCE
  95.131.136.0/21
  146.185.40.0/21
  91.208.181.0/24

En regardant le looking glass, on voit que tout est revenu :

Enfin, presque, Emile Aben me fait remarquer qu'IPv6 a mis plus de temps, le préfixe 2a02:c70::/32 n'est revenu que vers 11:15 UTC.

Des articles sur cette panne :


L'article seul

Continuons à soutenir Charlie Hebdo

Première rédaction de cet article le 15 janvier 2015


Dans l'émotion, depuis l'attaque des intégristes islamistes contre Charlie Hebdo, beaucoup de gens ont réagi, en manifestant, en envoyant une aide financière, en organisant discussions et réunions... Il est important que le soutien se fasse désormais sur le long terme, étant donné qu'il est certain que l'intégrisme armé ne s'arrêtera pas là.

D'abord, puisque les intégristes ont protesté contre la dernière couverture de Charlie Hebdo, il est important de la faire circuler le plus possible :

Ensuite, pour l'aide financière, on peut apparemment (je n'ai pas essayé) faire des dons à http://jaidecharlie.fr/ (non, pas de HTTPS, ce qui est dommage pour un site de dons, il vaut peut-être mieux aller directement chez le prestataire financier). Mais j'ai préféré m'abonner, ce qui me semble plus approprié lorsqu'un journal est menacé. Charlie ne propose apparemment pas d'abonnements en ligne depuis son site, il faut donc le faire via la poste ou bien via un prestataire. Comme je n'ai pas pu créer un compte chez A2 presse, qui n'aime pas mon adresse (« Le champ E-Mail valide n'est pas une adresse e-mail correcte »), je suis donc allé chez ViaPresse, dont la sécurité est nulle mais dont le site Web fonctionne. J'ai payé via PayPal, au moins, ViaPresse (ou sa plateforme de paiement) n'aura pas mon numéro de carte de crédit (mais la NSA saura ainsi que je me suis abonné à Charlie).

Le numéro de Charlie Hebdo d'hier (le premier après l'attentat) a été numérisé et peut être trouvé en ligne (également, au format CBZ). Au passage, je vous recommande l'article « Comment trouver Charlie Hebdo en ligne ».


L'article seul

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

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu