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.


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.)

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...


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, peut de programmes ont cette taille « câblée en dur ». Évidemment, on ne peut pas etre 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 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

Mon blog dans les oignons

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


Cela faisait longtemps que je voulais m'amuser avec cela, donc, désormais, ce blog est désormais également accessible en Tor hidden service, c'est-à-dire avec un nom de domaine en .onion.

Quel est l'intérêt de faire cela ? Le réseau Tor est connu pour permettre une connexion aux services de l'Internet qui soit anonyme (attention à votre sécurité toutefois : aucune technique n'est parfaite et rien n'est jamais complètement anonyme) et qui résiste à la censure. Tor assure ce service en relayant chaque requête par plusieurs nœuds Tor. Seul le premier connait le client initial (il ne connait pas la destination) et seul le dernier connait le serveur visé (il ne connait pas le client initial). Bon, ça, c'est Tor qui protège le client. Mais si on a envie de protéger le serveur ? Lorsqu'on publie traditionnellement sur l'Internet, on annonce un nom de domaine et n'importe qui peut investiguer, trouver (par exemple avec dig) l'adresse IP associée, se servir de whois pour trouver où et par qui est connectée cette machine, bref, même si on n'a pas mis son nom et son adresse dans les informations distribuées par le serveur, on peut être retrouvé facilement, ce qui est un problème si on veut bloguer alors qu'on vit sous une dictature intégriste et moyenâgeuse.

C'est là qu'interviennent les Tor hidden services. L'idée de base est que le serveur fabrique une identité sous forme d'une clé cryptographique, l'envoie à quelques relais Tor, qui inscrivent cette identité dans, par exemple, une DHT, et les clients qui se connecteront à Tor trouveront ainsi les points de rendez-vous, permettant de se connecter à votre serveur, sans que les clients ne trouvent son adresse. Comme toutes les techniques de sécurité, cela n'est pas invulnérable à tout attaquant, donc, attention, si les enjeux sont élevés, il faut prévoir également d'autres précautions.

Pour savoir si le serveur à contacter est un serveur « normal » sur l'Internet ou bien si c'est un de ces services discrets (ce que les médias à sensation nomment le « Dark Web »), les services discrets ont un nom dans le TLD (non officiellement délégué ou reconnu) .onion. C'est ainsi que ce blog est (le lien ne marchera que si vous avez un client Tor) http://7j3ncmar4jm2r3e7.onion/

Pour configurer ce service, la documentation en ligne est suffisante. J'ai juste installé Tor sur une machine Debian (aptitude install tor), ajouté et configuré Apache (attention à n'écouter qu'en local, avec Listen 127.0.0.1:80), puis configuré Tor

HiddenServiceDir /var/lib/tor/blog/
HiddenServicePort 80 127.0.0.1:80

Et c'est tout (en supposant que l'Apache ne serve qu'un site, sinon il faudra mettre le nom en .onion dans ServerName). Tor crée la clé et la publie auprès des relais. On peut la lire dans /var/lib/tor/blog/hostname (où blog est le nom du service caché, utilisé dans la directive HiddenServiceDir). Attention toutefois à certains pièges : le but étant d'être autant que possible anonyme, Tor ne servira à rien si vous laissez des choses comme ServerAdmin jeankevin@chezmoi.example, choses qu'Apache publiera dans certains cas. Vérifiez donc bien que vous ne laissez pas d'indications dans vos textes ou votre configuration !

Bien sûr, dans le cas de ce blog, le service discret Tor n'a aucun intérêt pour l'auteur puisque le même contenu est publié par ailleurs par une technologie classique. Mais, dans un monde où on peut être assassiné pour des dessins qui déplaisent aux censeurs, beaucoup de gens ont intérêt à publier discrètement.

De nombreux sites sont ainsi accessibles via .onion même si, pour certains, cela peut sembler surprenant.

Si vous voulez des informations techniques en français, il y a l'article de Benjamin Sonntag. Vous y noterez (à la fin de la section « Héberger votre site avec Tor ») un point dont je n'ai pas parlé, la possibilité de choisir un nom plus parlant, au lieu de la clé cryptographique aléatoire que Tor génère par défaut. Cette possibilité me semble une faiblesse de sécurité mais les gens de Tor ne sont pas d'accord (la section « Part three: their vanity address doesn't mean the world has ended »).

Je paie une bière au premier ou à la première qui m'indiquera l'adresse IP de la machine qui héberge ce service, je vais peut-être découvrir (c'est mon premier service Tor discret) que j'ai fait une grosse erreur de configuration (rappelez-vous l'avertissement plus haut : les erreurs arrivent et, en sécurité, elles peuvent coûter cher).

Avec mes remerciements à Ser Davos, le « chevalier à l'oignon », un des personnages les plus sympathiques de Game of Thrones.


L'article seul

RFC 7437: IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : M. Kucherawy
Première rédaction de cet article le 9 janvier 2015


Voici un nouveau RFC « bureaucratique » autour des processus menant au choix et à la désignation des membres d'un certain nombre d'organismes de la galaxie IETF, comme l'IAB ou l'IESG. Les amateurs de droit constitutionnel seront ravis...

Il n'y a pas de grands changements depuis le RFC 3777 qui, depuis plus de dix ans, était la référence sur ces amusants sujets. Ce nouveau RFC 7437 est surtout la consolidation, dans un document unique, des modifications éparpillées qui avaient été apportées au RFC 3777, comme par exemple celle du RFC 6859, qui ajoutait l'IAOC à la liste des comités dont les membres n'était pas éligibles à un poste au NomCom, le comité de nomination. Ce RFC 7437 ne marque donc pas une réforme significative du fonctionnement de l'IETF mais il permet d'avoir un document à jour. L'annexe A du RFC contient la liste complète des changements depuis le RFC 3777.

Ce RFC concerne la désignation des membres de l'IAB, de l'IESG et de certains membres de l'IAOC (voir la section 4 du RFC 4071 sur le sens de ce « certains »). Il ne concerne pas l'IRTF et ses comités propres. Il ne concerne pas non plus le fonctionnement quotidien de ces comités, juste la désignation de leurs membres.

Le processus tourne autour d'un comité nommé NomCom (pour Nominating Committee, comité de nomination).Comme expliqué en section 2, il faut bien différencier les nommés (nominee), les gens dont les noms ont été soumis au NomCom pour occuper un poste à l'IAB, l'IESG ou l'IAOC, des candidats (candidate) qui sont les gens retenus par le NomCom. Le NomCom, comme son nom l'indique, n'a pas de pouvoir de désignation lui-même, celle-ci est décidée (on dit officiellement « confirmée ») par un organisme différent pour chaque comité (l'IAB pour l'IESG, l'ISOC pour l'IAB, etc). Une fois confirmé, le candidat devient... candidat confirmé (confirmed candidate).

La section 3 de notre RFC explique le processus général : il faut désigner le NomCom, le NomCom doit choisir les candidats, et ceux-ci doivent ensuite être confirmés. Cela peut sembler compliqué, mais le but est d'éviter qu'une seule personne ou une seule organisation puisse mettre la main sur l'IETF. Le processus oblige à travailler ensemble.

À première vue, on pourrait penser que le NomCom a un vaste pouvoir mais, en fait, au début du processus, il ne peut pas décider des postes vacants, et, à sa fin, il n'a pas le pouvoir de confirmation.

Un point important et souvent oublié est celui de la confidentialité (section 3.6 du RFC). En effet, l'IETF se vante souvent de sa transparence, tout doit être public afin que chacun puisse vérifier que tout le processus se déroule comme prévu. Mais le travail du NomCom fait exception. Toutes ses délibérations, toutes les informations qu'il manipule, sont confidentielles. Autrement, il serait difficile de demander aux personnes nommées de fournir des informations personnelles, et les personnes extérieures au NomCom qui sont interrogées hésiteraient à s'exprimer franchement sur tel ou tel candidat. Et la publicité des débats risquerait d'encourager des campagnes de soutien extérieures au NomCom, et du lobbying, toutes choses qui sont formellement interdites. La section 8, sur la sécurité, revient sur cette importance de la confidentialité : puisque le NomCom enquête littéralement sur les nommés, il peut récolter des informations sensibles et il doit donc faire attention à les garder pour lui.

Voici, par exemple, l'annonce de la sélection des membres de l'IESG, début 2014.

Et le NomCom lui-même, comment est-il choisi (section 4) ? De ses quinze membres, seuls dix ont le droit de vote. D'abord, les dix membres du NomCom votants doivent répondre à un certain nombre de critères (section 4.14) : ils doivent avoir été physiquement présents à trois des cinq précédentes réunions de l'IETF (c'est une des exceptions au principe comme quoi la participation à l'IETF n'impose pas de venir aux réunions physiques), et c'est vérifié par le secrétariat de l'IETF. Et ils doivent (évidemment), être très familiers avec les processus internes de l'IETF. Une fois qu'on a un ensemble (pool) de volontaires qui acceptent de participer au NomCom (voyez un appel à volontaires typique), comment choisit-on les dix membres de plein exercice ? Eh bien, c'est là que c'est amusant, ils sont choisis au hasard... Il n'existe en effet pas de critères consensuels sur la meilleure méthode de choix des membres du NomCom (rappelez-vous qu'à l'IETF, on ne peut pas voter, puisqu'il n'y a pas de notion de « membre » et donc pas de corps électoral rigoureusement défini). Le tirage au sort se fait selon la méthode, ouverte et publiquement vérifiable, spécifiée par le RFC 3797.

Le président du NomCom, lui, est désigné par l'ISOC. La liste des membres du NomCom est en ligne.

Une fois sélectionnés, les membres du NomCom se mettent au travail (section 5 du RFC). Ils ne sont bien sûr pas éligibles pour les postes qu'il vont devoir pourvoir. Lorsqu'ils doivent prendre une décision, le NomCom vote (une procédure rare à l'IETF). Les nominations peuvent être faites par n'importe quel participant à l'IETF, y compris le nommé lui-même. La décision de retenir tel ou tel nommé comme candidat doit s'appuyer sur sa connaissance de l'IETF et ses qualifications pour le poste (qui ne sont pas forcément les mêmes pour tous les comités : par exemple, l'IAOC nécessite des compétences administratives qui sont moins importantes à l'IAB). L'IETF étant une organisation de grande taille, le NomCom ne connait pas forcément tout le monde, et peut donc aller à la « pêche aux informations » en consultant des gens extérieurs sur tel ou tel nommé.

Les informations récoltées par le NomCom, et ses discussions sont archivées (mais non publiques : voir plus haut au sujet de la confidentialité). Ces archives sont directement utiles s'il faut, par exemple, remplir un poste et qu'on ne veut pas recommencer le processus de zéro pour certains nommés.

Les humains étant ce qu'ils sont, il y aura des désaccords en interne. Comment le NomCom gère-t-il les contestations (section 6) ? Idéalement, le NomCom doit essayer de les régler tout seul (ne serait-ce que pour préserver la confidentialité déjà mentionnée). Si cela ne marche pas, le problème est transmis à l'ISOC, qui nomme un arbitre, dont les décisions sont définitives (pas d'appel).

J'ai parlé ici surtout de pourvoir des postes, mais il peut aussi y avoir révocation (recall, section 7) d'un membre d'un des comités concernés. Cette révocation peut être demandé par au moins vingt participants à l'IETF, qui doivent être éligibles au NomCom, à l'ISOC. Un Recall Committee est alors créé, et peut décider à la majorité des trois quarts d'une révocation, sur la base des griefs présentés par les signataires de la demande de révocation.

Bien des choses au sujet du NomCom ne sont pas écrites, et la tradition orale joue un rôle important dans son fonctionnement. L'annexe B rassemble plusieurs grains de sagesse issus de cette tradition. Par exemple, avoir été président d'un groupe de travail IETF est considéré comme une bonne préparation à l'IESG. Il y a aussi des considérations sur l'équilibre global entre les membres d'un comité. Il ne s'agit pas seulement que chaque membre soit individuellement bon, il faut aussi que le comité rassemble des gens de perspectives différentes (âge, expérience, région d'origine, monde académique vs. entreprises à but lucratif, etc). La tradition orale recommande aussi d'éviter qu'une même organisation n'occupe trop de postes dans un comité. Même si les gens de cette organisation ne forment pas un bloc, l'impression donnée serait mauvaise pour l'IETF. (Lors de l'annonce IESG de début 2014, citée plus haut, notez le dernier paragraphe : les deux directeurs de la zone routage à l'IETF travaillent pour Juniper.)


Téléchargez le RFC 7437


L'article seul

RFC 7426: SDN Layers and Architecture Terminology

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : E. Haleplidis (University of Patras), K. Pentikousis (EICT), S. Denazis (University of Patras), J. Hadi Salim (Mojatatu Networks), D. Meyer (Brocade), O. Koufopavlou (University of Patras)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF sdnrg
Première rédaction de cet article le 9 janvier 2015


S'il y a un buzzword populaire en ce moment, dans les technologies de réseau, c'est bien SDN. Ce sigle désigne une approche de contrôle centralisé d'un réseau, par le biais d'ordres envoyés depuis la machine d'administration, vers tous les éléments actifs du réseau (les routeurs, par exemple). Comme tous les buzzwords, son utilisation massive pour désigner tout et n'importe quoi entraîne pas mal de confusion, et ce RFC de l'IRTF essaie de clarifier un peu en précisant la terminologie du SDN (Software-Defined Networking), et en explorant les protocoles actuels qui participent au système SDN.

Le problème est d'autant plus difficile que tout le monde veut être SDN aujourd'hui. Si, comme la plupart des administrateurs réseaux professionnels, j'utilise un script qui utilise SSH pour se connecter sur tous mes routeurs afin de changer leur configuration, je fais du SDN ? (Réponse : oui, selon la plupart des définitions de SDN qu'on peut trouver, non selon les marketeux, car cette solution ne permet pas de nouvelles ventes.)

La définition que donne le RFC est « le SDN, c'est une approche du réseau fondée sur la programmabilité, qui sépare le plan du contrôle de celui de la transmission, et qui utilise des interfaces standardisées ». Une interface est là où deux entités interagissent. Ce peut être fait avec un protocole réseau, ou une API locale. Le maître d'un réseau SDN (le contrôleur) va configurer des éléments du réseau (network device), les engins qui assurent les fonctions comme la transmission des paquets. Le logiciel utilisé se divise entre applications (qui sont un but en elles-mêmes) et services (qui n'existent que pour fournir des fonctions aux applications, via une jolie API).

Et ces histoires de plan dont j'ai parlé plus haut ? Un plan est une collection de ressources (matériel et logiciel) qui sont responsables d'une activité donnée. Le RFC distingue cinq plans :

  • Plan de transmission (forwarding plane) : faire suivre les paquets d'une interface à l'autre,
  • Plan de contrôle (control plane) : détermine les règles que va suivre le plan de transmission. Par exemple, sur un routeur haut de gamme, le plan de contrôle, qui tourne sur du matériel généraliste, fait tourner les protocoles comme BGP ou OSPF, déterminant la table de routage, tandis que le plan de transmission, composé d'ASIC spécialisés, utilise cette table de routage pour transmettre les paquets à la bonne interface.
  • Ces deux premiers plans sont classiques et souvent utilisés dans les discussions réseau. Le RFC en ajoute trois autres : d'abord, plan des opérations (operations plane, la gestion globale de la machine), et plan de gestion (management plane, la supervision et la configuration de la machine).
  • Et enfin, le plan des applications (application plane), qui comprend les services et les applications proprement dites.

Le RFC introduit aussi le concept de couche d'abstraction (AL, Abstraction Layer), qui est la vision qu'une ressource va présenter au monde extérieur. Ainsi, le DAL (Device Abstraction Layer, aussi appelé HAL pour Hardware Abstraction Layer), est la vision externe d'un engin, ce que connaitra le reste du monde. Il y a de la même façon un CAL (Control Abstraction Layer), un MAL (Management Abstraction Layer) et un NSAL (Network Services Abstraction Layer). Oui, moi aussi, je trouve cela bien abstrait.

La section 3 détaille certains de ces concepts. On a, de bas en haut (en mettant en bas ce qui est concret et en haut ce qui est utile) :

  • L'élément du réseau, par exemple un commutateur, qui contient le plan de transmission et celui des opérations, et qui montre à l'extérieur le DAL. Il est décrit plus en détail en section 3.2.
  • Côte-à-côte, les plans de contrôle (faisant appel au CAL) et de gestion (faisant appel au MAL). Sur un engin ancien, ils sont intégrés aux précédents mais le SDN prône leur séparation (qui était réalisée depuis longtemps dans les routeurs), pouvant aller jusqu'à les mettre dans des machines différentes. La distinction entre ces deux plans est subtile, l'intéressante section 3.5 la traite plus en détail. En gros, le plan de contrôle s'occupe plutôt de réactions rapides (genre moins d'une seconde), et a des états de courte durée (genre une minute). Le plan de gestion prend en charge des phénomènes moins rapides.
  • Les services et applications, parlant au NSAL.

Le RFC 7276 avait déjà un schéma de ce genre. Comme on représente les composants avec le matériel en bas et les applications et services en haut, les interfaces sont souvent étiquetées « Nord » et « Sud » selon qu'elles connectent à un composant situé plus haut ou plus bas (et tant pis pour les Australiens qui mettent le Nord en bas). Ainsi, l'interface du plan de gestion avec le plan des opérations (via le DAL) est, pour le plan de gestion, une Southbound interface (MPSI : Management Plane Southbound Interface).

Le RFC note que, pour le plan de gestion, la facilité d'usage doit être un critère plus important que les performances (cf. RFC 3535) ce qui implique entre autres des fichiers de configuration sous forme texte, en UTF-8 (cf. RFC 6632). Il existe déjà plusieurs protocoles pour la communication Sud du plan de gestion, par exemple NETCONF (RFC 6241), ForCES (RFC 5810), et même les bons vieux syslog (RFC 5424) et SNMP (RFC 3411).

La section 4 met tout cela en perspective dans le cas du SDN, notamment en regardant où les protocoles existants se situent. En gros, les contrôleurs SDN existants sont plutôt dans le plan de contrôle et utilisent son interface Sud (CPSI, Control Plane Southbound Interface) pour parler au matériel. Le protocole utilisé pour cela est typiquement OpenFlow. Leur interface Nord (le NSAL) n'est pas normalisée.

Pour les protocoles IETF existants, quelle est leur place dans ce schéma ? Commençons par ForCES (RFC 3746). L'idée de base est de normaliser le protocole de communication entre le plan de contrôle et celui de transmission, afin de pouvoir réaliser un routeur en combinant un control/routing engine et un forwarding engine de fournisseurs différents, ce qui est impossible aujourd'hui. Si ForCES vise surtout la communication entre plan de contrôle et plan de transmission, il est assez souple (définition des éléments gérés indépendante du protocole) pour pouvoir peut-être s'utiliser pour des communications avec le plan de gestion et le plan des opérations.

Le protocole NETCONF (RFC 6241) est, lui, un protocole de gestion à distance d'équipement réseau (qui pourrait remplacer le traditionnel script qui se connecte en SSH sur tous les équipements avant de configurer avec la CLI). Il est donc partiellement concurrent de SNMP, notamment pour les opérations de modification (set en SNMP). Et NETCONF, dans le monde SDN, peut servir de MPSI (Management Plane Southbound Interface). Son langage de modélisation, YANG (RFC 6020), semble très populaire en ce moment à l'IETF.

Au contraire de ForCES et de NETCONF, issus directement de l'IETF, OpenFlow vient du privé (université Stanford) et est géré aujourd'hui par une organisation ad hoc, Open Networking Foundation. Son but est de contrôler de manière centralisée un ensemble de commutateurs réseau. C'est entre autres un DAL (Device Abstraction Layer) pour le CPSI (Control Plane Southbound Interface).

Dans un routeur classique, la base d'informations (RIB, Routing Information Base) est gérée par les protocoles dynamiques comme OSPF et a peu d'interfaces vers l'extérieur. On peut définir des routes statiques, on peut obtenir quelques statistiques et de la journalisation mais on n'a pas d'interface standard avec le système de routage, permettant de manipuler davantage celui-ci. Le but du projet I2RS (Interface to the Routing System) à l'IETF est justement de spécifier cette interface, en utilisant YANG et en réutilisant autant que possible des systèmes existants. Le projet en est actuellement à ses débuts.

Tous ces protocoles nouveaux et qui brillent ne doivent pas faire oublier les traditionnels, comme SNMP. Après tout, le terme « SDN » est en grande partie du marketing, le contrôle des éléments réseau via des protocoles se pratiquait longtemps avant que le sigle SDN soit inventé. Donc, SNMP (RFC 3417, RFC 3412, RFC 3414) est un protocole de gestion de réseaux, actuellement dans sa version 3. Les objets définis dans une MIB peuvent être interrogés (get) et modifiés (set mais, en pratique, c'est bien plus rare qu'on utilise SNMP pour cela). Comme NETCONF, il peut servir de MPSI.

Deux autres protocoles sont moins souvent cités lorsqu'on parle de faire du SDN avec les protocoles IETF existants mais ils méritent quand même une mention. D'abord, PCE (RFC 4655), qui vise à réaliser le calcul de chemins dans le réseau en un endroit différent de celui qui fera la transmission. Par exemple, une machine spécialisée, le PCE (Path Computation Element) va calculer des routes et les transmettre au routeur, le PCC (Path Computation Client), via le protocole PCEP (PCE communication Protocol, RFC 5440). Au contraire de la plupart des protocoles vus ici, qui sont Nord-Sud (communication entre des entités de niveau différent), PCEP est Est-Ouest (on peut dire aussi « horizontal », mais le terme n'est pas dans le RFC) faisant communiquer des machines situées au même niveau conceptuel.

Et enfin le protocole BFD (RFC 5880), un protocole de détection de pannes dans les routeurs, prévu pour être très rapide, afin de détecter les problèmes plus tôt que par les techniques de gestion classiques. C'est conceptuellement un service du plan de contrôle.

Pour résumer ? Lire la section 5 et bien se rappeler que 1) SDN ne se limite pas à utiliser OpenFlow 2) Il y a beaucoup de marketing et beaucoup moins de substance.

Quelques lectures classiques citées par notre RFC (la bibliographie de ce RFC est particulièrement longue, reflet de la complexité, de la richesse, et de la confusion du sujet). D'abord, les articles historiques :


Téléchargez le RFC 7426


L'article seul

Liberté des crayons

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


C'était le slogan le plus émouvant à la manifestation place de la République à Paris aujourd'hui, pour défendre la liberté, après l'attaque contre Charlie Hebdo. Après une longue série de cris « Liberté d'expression », nous sommes passés à « Liberté des crayons » en brandissant chacun un crayon, un stylo...

Autres slogans pour la liberté : « Nous sommes tous Charlie », « Ensemble unis pour la démocratie », « Charlie... berté », « Dans tous les journaux, des caricatures » et l'ancien, inattendu, mais pas déplacé « Faites l'amour, pas la guerre ».

On n'est pas encore absolument sûrs des motivations des attaquants. Si, comme c'est probable, il s'agit d'intégristes islamistes, il faut se rappeler que les intégristes ne sont pas seulement quelques haineux isolés, mais qu'il s'agit d'un courant politique puissant, en plein essor, et dangereux. Les habitants de Kobané le vivent tous les jours.


L'article seul

RFC 7416: A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : T. Tsao, R. Alexander (Cooper Power Systems), M. Dohler (CTTC), V. Daza, A. Lozano (Universitat Pompeu Fabra), M. Richardson (Sandelman Software Works)
Pour information
Réalisé dans le cadre du groupe de travail IETF roll
Première rédaction de cet article le 6 janvier 2015


Le protocole de routage RPL (Routing Protocol for Low power and lossy networks) est conçu pour des objets connectés, nombreux, mais pas gérés, et qui doivent s'organiser tout seuls pour trouver un chemin dans le réseau. Ces objets peu intelligents soulèvent souvent des problèmes de sécurité spécifiques : ils ne sont pas gérés par un administrateur système compétent, ils ont des capacités de calcul limitées, ce qui réduit le recours à la cryptographie, ils ont une interface utilisateur réduite au minimum, ce qui fait qu'entrer une clé WPA est très pénible, etc. Ce nouveau RFC documente les problèmes de sécurité de RPL.

C'est que l'Internet des Objets est à la mode. On voudrait que chaque brosse à dents soit connectée à l'Internet, et qu'elle discute avec le tube de dentifrice et le frigo sans qu'un humain n'ait besoin de configurer manuellement le routage. On a des solutions techniques pour cela, celle qui est au cœur de ce RFC étant le protocole de routage RPL, normalisé dans le RFC 6550. Mais si ces solutions permettent au LLN (Low-power and Lossy Network, réseau limité en capacité et en énergie, cf. RFC 7102) de fonctionner, elles ne garantissent pas sa sécurité. Or, ces réseaux d'objets ont souvent des exigences sérieuses en sécurité (pensez à la distribution d'électricité, par exemple). Les RFC 6574 et RFC 7397 avaient déjà abordé ce problème. Ici, on n'examinera pas l'ensemble des problèmes de sécurité des LLN, on se concentrera sur le routage.

Pour une introduction générale aux problèmes de sécurité du routage, on peut aussi consulter le RFC 4593 (qui détaille notamment les types d'attaquants) et l'article de C. Karlof et D. Wagner, « Secure routing in wireless sensor networks: attacks and countermeasures ». La section 4.3 de notre RFC se focalise sur les problèmes spécifiques aux LLN (déjà abordés dans les RFC 5548, RFC 5673, RFC 5826 et RFC 5867) :

  • Les machines connectés au LLN (les objets) ont des ressources limitées en énergie (batterie de capacité limitée), mémoire et CPU. Comme toujours, la sécurité sera un compromis et, dans le cas d'un LLN, un compromis difficile : il va falloir faire de sérieux sacrifices.
  • Les LLN sont a priori de grande taille. Il ne s'agit pas de quelques ordinateurs qu'on a configurés manuellement mais de centaines ou de milliers d'objets dispersés sur le site. Toute solution de sécurité qui nécessiterait une action compliquée de configuration sur chaque objet est vouée à l'échec.
  • Les objets sont censés fonctionner de manière autonome, et se débrouiller seuls, dans un réseau qui n'est pas géré et évolue sans cesse.
  • La sécurité physique est très minimale. Les objets sont placés à des endroits divers, parfois éloignés, sans qu'on puisse forcément les enfermer dans une cage.
  • Certains objets s'endorment de temps en temps, pour économiser l'énergie. Cela complique sérieusement le déploiement de certaines solutions de sécurité. Par exemple, si on distribue de nouvelles clés cryptographiques, les nœuds endormis ne les auront pas eues.

Malgré ces conditions difficiles, on voudrait que RPL obtienne :

  • Des données de routage quand il en a besoin (disponibilité),
  • Des données de routage non modifiées en route (intégrité),
  • Des données de routage qui viennent bien des machines autorisées (authenticité),
  • Et, même si c'est nettement moins important, des données de routage qui ne sont pas publiées à tous les vents (confidentialité).

La section 6 de notre RFC énumère les attaques possibles, en insistant sur celles spécifiques aux LLN (ou qui sont plus graves pour un LLN). D'abord, il y a le risque d'usurpation d'un nœud existant. Une machine méchante peut arriver, se glisser dans le réseau, et communiquer en prétendant être un des nœuds légitimes. Rappelez-vous que, dans RPL, n'importe quel nœud peut être routeur et donc annoncer des routes. Un usurpateur peut ainsi détourner le trafic destiné à un autre nœud. Ce détournement peut avoir de sérieuses conséquences, même si on a déployé une sécurité applicative (par exemple en utilisant TLS systématiquement) : le méchant peut retarder des messages, les re-jouer, etc. Même si les techniques de sécurité utilisées empêchent ce méchant d'usurper l'identité d'une machine existante, on peut quand même avoir des attaques où le méchant usurpe une identité, n'importe laquelle, non plus dans le but de se faire passer pour tel ou tel nœud mais simplement pour exploiter les droits d'un membre du LLN. Là encore, il peut annoncer des routes (détournant par exemple tout le trafic vers lui). Enfin, si le réseau est très ouvert (n'importe qui peut s'y joindre, identité ou pas), des attaques par épuisement des ressources peuvent avoir lieu. Rappelez-vous que, dans un LLN, certaines ressources sont sévèrement limitées, comme la capacité des batteries. En envoyant beaucoup de messages sans intérêt (spam), un attaquant pourrait priver pas mal de membres du LLN d'énergie.

Si on réussit à authentifier correctement tous les nœuds du LLN, et donc à empêcher les attaques du paragraphe précédent, un méchant a encore la possibilité de modifier les informations de routage, et donc, au final, de contrôler les routes utilisées. Un nœud authentifié peut encore mentir (annoncer des routes qu'il n'a pas ou bien le contraire, c'est un exemple de comportement byzantin), mais on peut aussi imaginer une modification de l'information entre les nœuds (WiFi pas protégé, par exemple).

Enfin, si on réussit à empêcher mensonges et modifications, l'attaquant peut quand même dans certains cas lancer des attaques contre le réseau en l'empêchant tout simplement de fonctionner (attaque par déni de service). Certaines solutions aux problèmes précédents peuvent aggraver ce risque. Ainsi, si on met de la cryptographie partout, un attaquant peut envoyer des messages, certes faux et détectables, mais qu'il faudra tenter de déchiffrer, ce qui consommera des ressources.

La section 7 de notre RFC couvre les contre-mesures générales, qui peuvent être utilisées dans beaucoup de cas (la section 8 parlera des contre-mesures effectivement existantes dans RPL).

Par exemple, contre les écoutes purement passives, la solution est évidemment le chiffrement des messages de routage. Le mécanisme obligatoire en RPL est AES en mode CCM (RFC 3610). Par contre, ZigBee n'a pas de protection à ce niveau et compte sur celles du niveau 2.

Pour les attaques actives, c'est évidemment plus difficile. Une méthode d'attaque courante dans les réseaux ouverts, comme le sont souvent les LLN, est d'envoyer un grand nombre de machines joindre le réseau, pour ensuite le contrôler par la simple majorité (attaque Sybil). La solution est d'authentifier les machines, via une clé publique. Cela ne protège pas contre les byzantins. Un protocole comme OSPF, où tout le monde reçoit toute l'information, peut se défendre contre les byzantins en comparant ce que reçoivent les différents nœuds. RPL n'a pas cette possibilité et il faut donc chercher des nœuds de confiance, qui fourniront une information qu'on pourra comparer avec celle reçue des pairs (BGP a le même problème et utilise ce genre de solutions). On peut aussi utiliser des canaris, des machines qui doivent être joignables en permanence : si elles cessent de l'être après une nouvelle annonce de route, cela peut signifier une attaque. Si un nœud tente une attaque « évier » (attirer tout le trafic par des annonces de routage mensongères, pour ensuite le jeter), il faudra également le détecter et le noirlister (ne plus tenir compte de ses annonces). On pourra aussi utiliser des indications géographiques (un capteur situé dans le bâtiment A.2 pourra trouver suspect que la meilleure route vers un collecteur du même bâtiment passe par un autre bâtiment).

Et les attaques contre les batteries, surchargeant le réseau de messages à traiter pour vider les accus ? Il faudra sans doute des limiteurs de trafic (voire des quotas de trafic), des mécanismes de détection des nœuds trop bavards, etc.

Enfin, la section 8 de notre RFC décrit les méthodes déployées dans RPL. Comme vu plus haut, RPL a un mécanisme de chiffrement, pour assurer la confidentialité (section 10.9 du RFC 6550) mais qu'il n'est pas obligatoire d'activer car RPL peut se reposer sur la sécurité de la couche 2 (WPA en WiFi par exemple). C'est un peu la même chose pour l'intégrité des messages (à mon avis bien plus importante que la confidentialité, pour un protocole de routage) : si RPL peut compter sur une couche 2 sécurisée, c'est bon, sinon, RPL a son propre mécanisme d'intégrité, avec un MAC calculé, par exemple, avec AES.

Pour la disponibilité du réseau, RPL prévoit les mécanismes suivants dans ses routeurs :

  • Ils peuvent limiter la cardinalité des voisins,
  • Garder en mémoire plusieurs chemins pour une destination donnée (avec choix aléatoire),
  • Avoir des quotas de transmission et de réception,
  • Utiliser des informations extérieures à RPL pour évaluer la fiabilité d'une information RPL (comme l'utilisation de la géographie connue dans l'exemple précédent).

À noter que RPL n'a pas de mécanisme de gestion des clés cryptographiques. Celles-ci doivent être fournies et renouvelées en dehors de RPL.

Pour résumer, on peut dire que les exigences de ces réseaux d'objets (autoconfiguration, non-gestion) ne vont pas dans le sens de la sécurité et on peut donc s'attendre à pas mal de problèmes dans les années à venir.


Téléchargez le RFC 7416


L'article seul

RFC 7435: Opportunistic Security: Some Protection Most of the Time

Date de publication du RFC : Décembre 2014
Auteur(s) du RFC : V. Dukhovni (Two Sigma)
Pour information
Première rédaction de cet article le 3 janvier 2015


Les révélations de Snowden ont sérieusement relancé l'intérêt pour la sécurité informatique, et notamment sur les risques d'espionnage. Mais, en sécurité, le mieux est parfois l'ennemi du bien. Certaines exigences de sécurité peuvent mener à des solutions techniquement parfaites mais tellement compliquées à utiliser qu'elles ne seront que peu ou pas déployées. C'est par exemple le cas de l'authentification pour utiliser le chiffrement. Si on impose l'authentification forte du pair avant de chiffrer, on risque de ne pas pouvoir chiffrer, dans des cas où ce serait pourtant bien utile. Ce nouveau RFC, par le mainteneur de Postfix, définit un concept utile, cela de sécurité opportuniste (opportunistic security) : on chiffre quand on peut, même sans authentification, et on authentifie si c'est possible. L'idée est d'augmenter sérieusement la part de trafic chiffré dans l'Internet.

Un petit détour technique, avant de commencer le RFC. Pourquoi chiffrer sans authentifier est-il dangereux ? Si on ne veut que la confidentialité, mais qu'on se moque de l'identité du pair avec qui on communique, pourquoi s'embêter à authentifier, surtout lorsqu'on sait que chiffrer est si simple et authentifier si compliqué ? C'est parce que chiffrer sans authentifier vous rend vulnérable à l'Homme du Milieu. Celui-ci, tapi dans le réseau, entre Alice et Bob, va recevoir les messages d'Alice et les transmettre à Bob (et réciproquement) et cela, évidemment, après lecture. Chiffrer ne sert à rien s'il y a un homme du milieu : Alice croit chiffrer pour Bob alors qu'elle chiffre en fait pour l'espion qui pourra donc lire le texte en clair avant de le chiffrer et de le passer à Bob.

À noter que l'homme du milieu est forcément actif : il doit maintenir un canal de communication avec Alice et un avec Bob. Parfois, pour des raisons pratiques ou bien juridiques (un attaquant actif peut relever de lois pénales plus sévères), l'attaquant reste passif et, dans ce cas, le chiffrement seul, sans authentification, protège parfaitement. Attention, toutefois : pas mal de personnes semblent croire que seul le FAI ou bien la NSA peuvent faire des attaques actives : or, celles-ci sont plus faciles que ne le croit M. Toutlemonde (usurpation ARP par exemple).

La solution correcte aux attaques de l'homme du milieu est l'authentification : si Alice vérifie qu'elle parle bien à Bob, et uniquement à lui, alors, elle pourra détecter quand un homme du milieu sera présent, et éviter ainsi de lui passer ses secrets. C'est le mode « tout ou rien » (soit on authentifie, soit on avorte la communication) qui était traditionnel dans les protocoles IETF (à part quelques exceptions comme la sécurité « mieux que rien » du RFC 5386). Mais l'authentification n'est pas facile. Prenons un exemple, celui de HTTPS, qui utilise la plupart du temps des certificats X.509 pour l'authentification. Des tas de choses peuvent aller mal : certificats expirés, signés par une autorité inconnue de ce navigateur, auto-signés pour éviter de payer des AC à l'utilité douteuse, et tous les autres malheurs qui ponctuent la vie de l'internaute qui essaie de se connecter en HTTPS. L'utilisateur se rabat donc souvent sur du simple HTTP non chiffré. De peur de l'homme du milieu, il fait tout passer en clair ! Cet état de chose est évidemment absurde. Lorsqu'on a un des fameux avertissements de sécurité « ce certificat a un problème incompréhensible pour vous, qu'est-ce que vous décidez ? », c'est dans la grande majorité des cas une erreur du serveur et pas une attaque de l'homme du milieu. Il vaudrait donc mieux, lorsque le site est également accessible en HTTP ordinaire, chiffrer sans authentification : cela ne peut jamais être pire que de ne pas chiffrer du tout. (Les sites HTTPS à plus haut niveau de sécurité, comme une place de marché Bitcoin, imposent HTTPS, et, en cas d'erreur, il n'y a qu'à pleurer en attendant la réparation.)

Ce débat sur l'authentification obligatoire est aussi ancien que la cryptographie. Je me souviens des vieux dinosaures de la sécurité regardant SSH avec méfiance, lors de son introduction, car l'authentification n'était pas obligatoire. Mais les solutions que prônaient ces sympathiques tétrapodes étaient tellement complexes à déployer que les gens ne chiffraient pas, et utilisaient telnet. Il est donc clair que SSH, même avec son modèle TOFU (Trust On First Use) d'authentification plutôt faible, a amélioré la sécurité de l'Internet. Le TOFU n'est pas parfait (il est vulnérable si l'homme du milieu est présent dès la première connexion, et il ne permet pas de savoir si un changement de clé est normal ou pas) mais il a permis de remplacer massivement l'ancien telnet par un protocole chiffré.

Outre HTTPS et SSH, plusieurs protocoles utilisent du chiffrement, et ont des solutions plus ou moins bonnes pour l'authentification. Des solutions comme DANE (RFC 6698) ont été proposées pour résoudre une partie des problèmes d'authentification mais, à l'heure actuelle, il est clair que l'Internet n'a pas de solution d'authentification généraliste techniquement correcte, politiquement sûre, et effectivement déployée.

Ce débat a mené au terme de sécurité opportuniste (opportunistic security), qui date de bien avant le RFC. Mais il n'était pas défini rigoureusement. Parfois, il désignait le fait de faire de la crypto sans que l'utilisateur l'ait explicitement demandé (ce que fait HTTPS Everywhere en transformant d'autorité des sessions HTTP en HTTPS), parfois il désignait le chiffrement sans authentification (c'est le sens qu'il a dans le RFC 5386), parfois la capacité de basculer automatiquement en mode non-chiffré (la définition du Wikipédia anglophone) et parfois enfin du chiffrement avec authentification mais sans avoir de configuration spécifique par pair (c'est ainsi que le RFC 4322 utilise le terme). Notre RFC lui donne une définition stable, qui sera utilisée dans les documents ultérieurs de l'IETF, comme le futur HTTP 2 ou comme DANE pour SMTP.

Bref, on change de perspective : d'un modèle où on authentifie systématiquement, protégeant contre les attaques passive et actives (et où l'absence d'authentification n'est citée que comme « mode dégradé », voire coupe la communication complètement), on passe à un modèle plus réaliste où l'état de base est l'absence de toute protection (la réalité de l'Internet d'aujourd'hui) et où tout gain en sécurité, même imparfait, est une amélioration par rapport à cet état de base. Avec la sécurité opportuniste, on chiffre quand c'est possible et on authentifie quand on peut. « Opportuniste » est donc un terme positif dans ce RFC. Il repose sur l'idée d'un « plancher de sécurité » en dessous duquel on ne descendra pas, et du « au moins aussi sûr » où on déploie tout système (comme le chiffrement) qui va améliorer les choses, ou en tout cas ne jamais les dégrader. Ce nouveau modèle ne change rien au cas où l'on imposait une sécurité minimale (par exemple avec HSTS, RFC 6797), il concerne les communications qui se font actuellement en clair.

La section 3 de notre RFC définit ce qu'est la sécurité opportuniste. Elle a (en simplifiant) trois niveaux, le niveau de base, où tout est en clair (c'est la majorité du trafic Internet aujourd'hui), le niveau où on chiffre, mais sans authentifier, et le niveau le plus sûr, où on chiffre après authentification. Ce dernier niveau est le meilleur mais la devise de la sécurité opportuniste est « mieux vaut le deuxième niveau que de rester bêtement sans sécurité du tout ». (Ce modèle est simplifié car il peut y avoir plusieurs niveaux de chiffrement ; par exemple, on va essayer de chiffrer en mode PFS mais, si cela échoue, on chiffre quand même, dans un mode moins sûr.) Ce modèle de sécurité opportuniste repose sur quatre principes :

  • Les politiques de sécurité existantes continuent comme avant. Si vous avez mis StrictHostKeyChecking yes dans la configuration d'OpenSSH, la sécurité opportuniste ne vous concerne pas, OpenSSH imposera une authentification de toutes les machines, même la première fois que vous vous connectez.
  • Priorité à la communication. En cas de problème d'authentification, on considère qu'il vaut mieux continuer de manière non sûre plutôt que de renoncer (c'est de fait la politique de nombreux utilisateurs).
  • S'adapter au pair et donc utiliser, pour chaque couple de machines qui communiquent, la sécurité maximale possible pour ce couple. Si un pair ne parle que DES, c'est nul, mais on l'utilise quand même, sans pour autant descendre le niveau de sécurité de la communication avec les autres pairs. (Il existe plusieurs méthodes pour déterminer les capacités du pair, certaines dans la session elle-même, comme la négociation des algorithmes de chiffrement dans TLS, d'autres externes, comme DANE.)
  • Franchise. Dans les messages aux utilisateurs, ou dans les journaux, on ne prétend pas qu'on a obtenu un niveau de sécurité qui ne correspond pas à la réalité. Si on n'a pas pu authentifier, on le dit (cela va poser d'intéressants problèmes d'interface utilisateur...)

La section 4 du RFC illustre le concept de sécurité opportuniste avec SMTP (domaine de compétence principal de l'auteur). Une extension à SMTP, STARTTLS, normalisée dans le RFC 3207, permet d'utiliser TLS pour chiffrer la session. Elle est aujourd'hui largement déployée, par exemple par Facebook ou par Google. À noter que cette extension n'est pas protégée cryptographiquement, et donc vulnérable aux attaques par repli (downgrade attacks) où l'attaquant actif va essayer de faire croire qu'un des pairs ne gère pas la sécurité maximale, menant à l'emploi de solutions de sécurité inférieures (ces attaques, un des points faibles de la sécurité opportuniste, sont traitées également dans la section 6). STARTTLS ne protège donc guère contre un attaquant actif. Donc, utiliser le texte en clair lorsqu'il y a un problème TLS (mauvais certificat, par exemple, ce qui est très fréquent avec SMTP sur TLS) n'a guère de sens : de toute manière, un attaquant actif pourrait supprimer le STARTTLS. Bref, SMTP ne devrait pas se rabattre sur le texte en clair alors que du chiffrement sans authentification est possible.

Ne manquez pas également de lire la section 6, qui résume le problème de sécurité, et qui note que la sécurité opportuniste peut aussi aider contre des attaquants ayant de grands moyens, genre NSA (RFC 7258), en les obligeant à utiliser des attaques actives (comme les attaques QUANTUM).


Téléchargez le RFC 7435


L'article seul

RFC 7422: Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments

Date de publication du RFC : Décembre 2014
Auteur(s) du RFC : C. Donley (CableLabs), C. Grundemann (Internet Society), V. Sarawat, K. Sundaresan (CableLabs), O. Vautrin (Juniper Networks)
Pour information
Première rédaction de cet article le 26 décembre 2014


Un nouveau RFC pour Big Brother : quand un FAI veut savoir quel abonné utilisait telle adresse IP à tel moment, c'est simple, non, il lui suffit de regarder les journaux du système d'allocation d'adresses ? En fait, non, c'est simple en théorie, mais cela a beaucoup été compliqué par le développement du partage d'adresses, dont l'exemple le plus connu est le CGN. Si la police ou les ayants-droit disent à un FAI « on voudrait savoir qui utilisait 192.0.2.199 le mercredi 24 décembre à 08:20 », le FAI va se rendre compte que des dizaines d'abonnés utilisaient cette adresse IP à ce moment. Trouver l'abonné exact va nécessiter d'examiner d'énormes journaux. Ce RFC propose donc une méthode pour réduire la taille de ces journaux, en attribuant les ports du CGN de manière partiellement déterministe. L'examen des journaux pourra donc être plus efficace et on trouvera plus vite le méchant abonné qui a osé commettre des délits impardonnables, comme de partager des œuvres culturelles.

Le problème de l'identification d'un abonné précis, en présence de partage d'adresses IP est difficile. (Cela concerne IPv4 seulement car IPv6 n'a pas ce problème et son déploiement natif complet résoudrait le problème pour moins cher - cf. RFC 7021 ; mais, comme disaient les Shadoks, « pourquoi faire simple quand on peut faire compliqué ? ») Je recommande fortement la lecture du RFC 6269 pour en saisir tous les aspects. Notez déjà un point important : si on n'a pas noté, au moment de l'observation du comportement illégal, non seulement l'adresse IP source, mais également le port source, on n'a guère de chance de remonter jusqu'à un abonné individuel, dès qu'il y a utilisation du CGN. Un premier pré-requis est donc que les serveurs journalisent le port source (comme demandé par le RFC 6302) et que les systèmes d'observation du réseau enregistrent ce port. Ensuite, muni de l'adresse IP source, du port source, et d'une heure exacte (ce qui suppose que tout le monde utilise NTP ou équivalent, cf. RFC 6269, section 12), on peut aller voir le FAI et lui poser la question « on voudrait savoir qui utilisait 192.0.2.199:5347 le mercredi 24 décembre à 08:20 » (notez la nouveauté, la mention du port, ici 5347). Si le FAI alloue dynamiquement adresses et ports en sortie, et journalise ces allocations, il lui « suffira » de faire un grep dans les journaux pour donner la réponse. Mais, et ce mais est à l'origine de notre nouveau RFC, ces journaux peuvent être de très grande taille.

Le partage massif d'adresses, tel que pratiqué dans les CGN, est motivé par l'épuisement des stocks d'adresses IPv4. Plusieurs RFC décrivent des variantes du concept de CGN (RFC 6264, RFC 6333...) mais tous ont un point commun : une adresse IP est partagée, non pas seulement entre les membres d'un même foyer, mais entre des abonnés d'un même FAI, abonnés qui ne se connaissent pas, et ne forment pas légalement une entité unique. Pas question donc, dans un état de droit, de punir tous les utilisateurs de 192.0.2.199 parce que l'un d'entre eux a fait quelque chose d'illégal, comme de distribuer des fichiers pris dans l'entreprise qui pirate les ordinateurs de ses clients.

A priori, l'information sur qui utilisait quel couple {adresse, port} à un moment donné est connue du CGN. Il l'enregistre, quelque chose du genre (syntaxe imaginaire) :

2014-12-24T08:20:00 Outgoing connection from 10.4.8.2:6234, allocate 192.0.2.199:5347
2014-12-24T08:21:15 192.0.2.199:5347 is now free (used for 10.4.8.2:6234)

Le FAI sait donc que l'adresse interne correspondant à 192.0.2.199:5347 était 10.4.8.2 et il peut alors consulter son plan d'adressage interne pour savoir de quel abonné il s'agit (ou bien consulter un autre journal si ces adresses internes sont elle-mêmes dynamiques). Au fait, si vous voulez un exemple réel des journaux d'un routeur CGN, voici un extrait de la documentation de Juniper :

Jun 28 15:29:20 cypher (FPC Slot 5, PIC Slot 0) {sset2}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: any, ge-1/3/5.0:10.0.0.1:8856 -> 128.0.0.2:80, creating forward or watch flow ; source address and port translate to 129.0.0.1:1028 
Jun 28 15:29:23 cypher (FPC Slot 5, PIC Slot 0) {sset2}[FWNAT]:ASP_NAT_POOL_RELEASE: natpool release 129.0.0.1:1028[1] 

Comme dans mon exemple imaginaire, on y voit que deux entrées sont enregistrées, pour l'allocation du port et pour sa libération (sur les routeurs A10, on peut configurer séparement les formats de journalisation pour ces deux événements, avec les mots-clés fixed-nat-allocated et fixed-nat-freed).

Mais quelle est la taille de ces journaux de ces CGN ? L'expérience montre des tailles de 150 à 175 octets par entrée, ce qui est la taille de mon exemple imaginaire ci-dessus, qui journalise en mode texte (cela peut bien sûr se faire de manière structurée dans une base de données, ou bien cela peut se comprimer, les journaux texte se réduisent facilement d'un facteur 2 ou 3 à la compression). Mais à quelle rythme les entrées sont-elles créées ? Il ne semble pas y avoir beaucoup d'études précises sur ce sujet mais des observations chez des FAI états-uniens indiquent des moyennes par abonné autour de 33 000 connexions par jour. Cela ferait plus de 5 mégaoctets par jour et par abonné. Avec un million d'abonnés, le FAI devrait stocker 150 téraoctets par mois. Et il faut la capacité d'acheminer ces journaux : avec seulement 50 000 abonnés, il faut dédier 23 Mb/s entre le routeur CGN et le serveur de journalisation.

Et, une fois stockées les données, il reste à les fouiller. Il faut trouver deux évenements (le début de l'allocation et sa fin) au milieu de ces énormes fichiers, ce qui va prendre du temps.

Une solution élégante, préconisée par notre RFC, est d'avoir un mécanisme déterministe d'allocation des ports en sortie, de manière à ne pas avoir à journaliser l'allocation. Il suffira alors de faire tourner l'algorithme à l'envers pour savoir qui avait tel couple {adresse IP publique, port}.

Quelle est la dynamique d'allocation des ports ? Même si un abonné utilise des milliers de connexions par jour, à un instant donné, sa consommation est bien plus faible. Si le rapport entre le nombre d'abonnés et le nombre d'adresses IP publiques est faible (mettons de l'ordre de 10), chaque abonné pourra utiliser des milliers de ports sans gêner les autres. On peut donc allouer des intervalles entiers de ports, sans avoir besoin de journaliser chaque allocation d'un port donné. Il « suffit » donc d'avoir une fonction déterministe, qui associe à chaque adresse IP interne une adresse IP externe et un intervalle de ports externes. Un exemple trivial d'une telle fonction serait l'allocation de l'intervalle 1024-2999 au premier (dans l'ordre des adresses IP internes) abonné, de 3000-4999 au deuxième, etc. Lorsqu'on a épuisé les numéros de port, on passe à la deuxième adresse IP publique et on recommence. En sens inverse, lorsqu'on recevra la requête « qui utiisait 192.0.2.1:4219 le mercredi 24 décembre à 08:20 ? », on saura, sans consulter le journal, que c'était le deuxième de nos abonnés (deuxième intervalle de ports de la première adresse publique). Cette fonction n'est qu'un exemple, la décision d'utiliser telle ou telle méthode est une décision purement locale. (Attention à ne pas allouer les ports séquentiellement dans l'intervalle donné, afin de limiter les risques pour la vie privée de l'abonné. La section 5 du RFC détaille ce risque pour la vie privée, et suggère des mesures.)

Pour cela, le routeur CGN a besoin de connaitre la liste des adresses internes (avec certains CGN comme DS-Lite, technique de coexistence temporaire IPv4/IPv6, ce seront des adresses IPv6, cf. la section 4 de notre RFC), celles des adresses externes disponibles pour sa fonction de CGN, le nombre total d'abonnés (pour calculer le rapport avec le nombre d'adresses publiques), le nombre de ports par utilisateur, la liste des ports à ne pas utiliser, et, bien sûr, la fonction déterministe de correspondance entre une adresse interne et un couple {adresse externe, port externe}. Parmi les fonctions possibles :

  • Allocation séquentielle (comme dans l'exemple proposée plus haut, ou dans l'exemple plus détaillé de la section 2.3 du RFC),
  • Entrelacement : si on a un facteur de 10 entre le nombre d'abonnés et le nombre d'adresses publiques, on alloue à chaque abonné un port sur dix. Le premier abonné a les ports 1024, 1034, 1044, etc,le deuxième 1025, 1035, etc,
  • Alternance sur l'adresse : un abonné utilise toujours le même port externe mais avec une adresse IP publique différente par connexion. Cela ne marche que si on a autant d'adresses IP publiques que de connexions par abonné mais cela simplifie beaucoup la recherche,
  • Méthode cryptographique, inspirée de la section 2.2 du RFC 6431 : on chiffre une concaténation d'une clé et d'autres informations et le résultat chiffré nous donne le port externe à utiliser. Attention, il faudra la clé pour inverser la fonction et donc retrouver l'abonné, il ne faut pas la jeter si on veut pouvoir répondre à des demandes concernant un passé un peu lointain, alors que les clés ont été changées.

Outre les ports « système » (RFC 6335), exclus de l'allocation, il est prudent de garder en réserve un intervalle de ports pour des allocations dynamiques traditionnelles, avec journalisation de l'allocation. Cela permet, par exemple, de gérer les utilisateurs avancés qui utilisent tellement de connexions sortantes qu'ils épuisent l'intervalle des ports. Avec cette réserve, on pourra toujours les satisfaire. Il faudra certes enregistrer ces allocations mais on aura quand même gagné en taille, en ne journalisant que moins d'information.

Comme on n'a rien sans rien, la plupart des méthodes d'allocation déterministe sont moins « efficaces » qu'une allocation purement dynamique, au sens où elles sous-utilisent les ports (pour les utilisateurs peu gourmands). En outre, elles imposent davantage de travail aux équipes opérationnelles (choix d'un algorithme, réglage de ses paramètres...). D'autre part, il ne faut pas s'imaginer qu'un CGN dissimule sérieusement l'abonné final, l'algorithme d'allocation des ports peut toujours être rétroingénierié (cf. section 6, sur la sécurité).

À noter qu'il faut aussi, pour que tout se passe bien, noter la configuration du CGN et ses éventuels changements. Pas question d'appliquer l'algorithme d'aujourd'hui à une requête judiciaire qui concernerait le mois précédent, si l'algorithme ou ses paramètres ont changé. Il faut donc que le routeur CGN journalise également les changements de paramètres (comme le nombre de ports par abonné).


Téléchargez le RFC 7422


L'article seul

RFC 7405: Case-Sensitive String Support in ABNF

Date de publication du RFC : Décembre 2014
Auteur(s) du RFC : P. Kyzivat
Chemin des normes
Première rédaction de cet article le 24 décembre 2014


La plupart des RFC contenant une grammaire formelle pour un format ou un protocole, utilisent le langage ABNF, normalisé dans le RFC 5234. Une des particularités d'ABNF, qui agace beaucoup de monde depuis le début, est le fait que les chaînes de caractères sont forcément insensibles à la casse. Si on veut les rendre sensibles à la casse, ce qui est une demande assez fréquente, il faut utiliser des trucs plus ou moins propres. D'où ce nouveau RFC qui fait sauter l'obstacle en permettant enfin d'indiquer qu'une chaîne de caractères est sensible à la casse.

Voici un exemple tiré du RFC 7208, qui décrit SPF :

mx  = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]

Du fait de l'insensibilité à la casse, un enregistrement SPF peut inclure mx:example.net/26 mais aussi mX:example.net/26, MX:example.net/26 ou Mx:example.net/26. Ce comportement est souvent raisonnable mais, dans certains cas, il ne convient pas et on ne peut plus alors utiliser des chaînes de caractères, il faut (RFC 5234, section 2.3), indiquer explicitement les valeurs numériques de chaque caractère. Par exemple, dans le RFC 4997, les identificateurs sont forcément en majuscule et le littéral THIS doit donc être défini par :

   THIS         = %d84.72.73.83

Si on l'avait défini :

   THIS         = "THIS"

alors, il aurait pu être écrit en minuscules ou en mixte.

Donc, désormais, la règle est que les chaînes de caractères en ABNF peuvent être précédées de %i pour indiquer qu'elles sont insensibles à la casse ou %s pour dire qu'elles ne le sont pas. Comme %i est la valeur par défaut (pour préserver la compatibilité), elle sera souvent omise. La définition du RFC 4997 plus haut aurait donc pu être :

   THIS         = %s"THIS"

À ma connaissance, les différents outils ABNF en http://tools.ietf.org/ n'ont pas encore fait l'objet d'un examen systématique pour déterminer s'ils intégraient la nouvelle norme.


Téléchargez le RFC 7405


L'article seul

RFC 7413: TCP Fast Open

Date de publication du RFC : Décembre 2014
Auteur(s) du RFC : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain (Google)
Expérimental
Réalisé dans le cadre du groupe de travail IETF tcpm
Première rédaction de cet article le 19 décembre 2014


Quand on parle de performances sur l'Internet, on se focalise souvent exclusivement sur la capacité du réseau. C'est, par exemple, l'argument quasi-exclusif des FAI : « Avec la fibre Machin, passez à la vitesse supérieure, XXX Mb/s ». Mais un autre facteur de la qualité de l'expérience utilisateur est la latence, à savoir le temps qu'il faut attendre pour recevoir une réponse. Par exemple, pour accéder à une page Web, avant même d'envoyer le premier octet « utile », il faut réaliser une « triple poignée de mains » (RFC 793, section 3.4) avec le serveur, pour établir la connexion, et cette poignée de mains nécessite pas moins de trois paquets, donc il faudra attendre trois fois le temps d'un aller simple, avant de pouvoir foncer et envoyer les images de chats (ou de loutres). Ce nouveau RFC, encore officiellement expérimental, mais déjà largement déployé, vise à raccourcir ce délai d'ouverture d'une connexion avec le serveur.

L'idée est ancienne (on la trouve par exemple dans le système T/TCP du RFC 1644, et dans les autres systèmes résumés en section 8) mais le problème est plus difficile à résoudre qu'il n'en a l'air, notamment si on veut garder un bon niveau de sécurité (le problème qui a tué T/TCP). L'idée est ancienne, car devoir attendre trois voyages avant de pouvoir envoyer les données contribue sérieusement à la latence d'applications comme le Web. Si le serveur est à 100 ms de distance, on attendra au moins 300 ms avant que des données ne commencent le voyage. Et, contrairement à la capacité, la latence ne s'améliore pas avec le temps et les progrès de l'électronique. Des mesures faites sur Chrome montre que la triple poignée de mains de TCP est responsable de 25 % de la latence moyenne des requêtes HTTP. Il existe des solutions pour certaines applications. Par exemple, pour HTTP, on peut utiliser les connexions persistantes (RFC 7230, section 6.3). L'établissement de ces connexions prendra autant de temps qu'avant mais ce « coût » ne sera payé qu'une fois : les requêtes/réponses ultérieures avec le même serveur HTTP réutiliseront la connexion TCP existante (et, si elles ne viennent pas, la connexion finit par être coupée, par exemple au bout de cinq minutes pour Chrome). Le problème est que ces connexions persistantes ne sont pas assez répandues. Les mesures des auteurs du RFC (Radhakrishnan, S., Cheng, Y., Chu, J., Jain, A., Raghavan, B., « TCP Fast Open », Proceedings of 7th ACM CoNEXT Conference, 2011) montrent que 35 % des requêtes nécessitent la création d'une nouvelle connexion TCP. Il serait agréable de pouvoir accélérer ces créations. La triple poignée de mains prend trois paquets, SYN (du client vers le serveur), SYN + ACK (du serveur vers le client) et ACK (du client vers le serveur). Les données ne voyagent qu'après. L'idée de base de TCP Fast Open (TFO), technique venant de chez Google, est de mettre les données dès le premier paquet SYN du client.

Le plus drôle est que le TCP original n'interdit pas de mettre des données dans le paquet SYN (section 2 de notre RFC). Bien au contraire, c'est explicitement autorisé par la section 3.4 du RFC 793 (« Although these examples do not show connection synchronization using data-carrying segments, this is perfectly legitimate [...] »). Mais avec une grosse restriction, que les données ne soient délivrées au serveur d'applications qu'une fois la triple poignée de mains terminée, ce qui en supprime l'intérêt. Cette règle a pour but d'éviter que des données soient envoyées deux fois (le paquet SYN peut être perdu et retransmis). Les variantes de TCP qui ont essayé d'optimiser le temps d'ouverture de connexion ont en général choisi de sacrifier de la sécurité, afin de maintenir la sémantique de TCP, ce qui n'est en général pas considéré comme acceptable de nos jour (RFC 4614). TCP Fast Open sacrifie, lui, la non-duplication des données : un serveur Fast Open peut, dans certains cas (par exemple si le serveur a redémarré entre les deux SYN), recevoir deux fois les mêmes données envoyées dans un paquet SYN. Ce n'est pas toujours si dramatique que ça en a l'air. Pour HTTP, le premier paquet de données du client sera sans doute un GET /something HTTP/1.1 et cette requête peut être effectuée deux fois sans conséquences graves. Première chose à retenir, donc, sur Fast Open : il ne convient pas à toutes les applications. TCP Fast Open est juste un compromis. Les systèmes ne doivent donc pas l'activer par défaut (les exemples plus loin montrent comment un programme Unix peut activer explicitement Fast Open). La section 4.2 insistera sur ce point.

Et la sécurité ? Le TCP normal présente une vulnérabilité : les paquets SYN n'ayant aucune forme d'authentification, un attaquant peut, en trichant sur son adresse IP, envoyer des paquets SYN sans révéler son identité et ces paquets, s'ils sont assez abondants, peuvent remplir la file d'attente du serveur (attaque dite « SYN flood »). C'est encore pire avec Fast Open puisque ces requêtes en attente comprennent des données, et peuvent déclencher l'exécution de commandes complexes (GET /horrible-page-dont-la-génération-nécessite-10000-lignes-de-Java-ou-de-PHP HTTP/1.1...) Les techniques du RFC 4987 ne sont en général pas appliquables à Fast Open. C'est pour cela que Fast Open ajoute un composant essentiel : un petit gâteau (cookie) généré par le serveur et que le client devra transmettre pour bénéficier du Fast Open.

La section 3 décrit en termes généraux le protocole. À la première connexion Fast Open d'une machine vers une autre, le client envoie l'option TCP (pour les options TCP, voir la section 3.1 du RFC 793) 34 TCP Fast Open Cookie (désormais dans le registre IANA mais attention, les mises en œuvre actuelles utilisent souvent la valeur expérimentale précédente) avec un contenu vide. Si le serveur gère Fast Open, il répondra (dans le SYN + ACK) avec un gâteau (cookie), généré par lui et imprévisible. Dans les connexions TCP ultérieures, le client renverra l'option Fast Open Cookie avec le même gâteau. Le serveur le reconnaitra alors. Les requêtes SYN comportant ce gâteau pourront inclure des données, elles seront transmises tout de suite aux applications qui le demandent (et on aura alors du beau TCP Fast Open) et le premier paquet de réponse pourra inclure des données (dans les limites données par le RFC 5681). On voit donc que la première connexion entre deux machines ne bénéficiera pas de Fast Open. Mais toutes les suivantes, oui (sur Linux, le noyau se souviendra du gâteau). Si le serveur ne gère pas cette option, il répond par un SYN + ACK sans l'option, informant ainsi le client qu'il ne doit pas compter sur Fast Open.

Voici, vu avec tcpdump, un exemple d'une session TCP Fast Open d'une machine Debian/Linux (version jessie) vers Google. Le gâteau (32a8b7612cb5ea57) est en mémoire chez le client (les options TCP sont affichées entre crochets, la « nôtre » est exp-tfo) :

20:10:39.920892 IP (tos 0x0, ttl 64, id 6594, offset 0, flags [DF], proto TCP (6), length 158)
    106.186.29.14.53598 > 173.194.38.98.80: Flags [S], cksum 0x5c7d (incorrect -> 0x9bd5), seq 1779163941:1779164027, win 29200, options [mss 1460,sackOK,TS val 114031335 ecr 0,nop,wscale 7,exp-tfo cookie 32a8b7612cb5ea57], length 86
20:10:39.923005 IP (tos 0x0, ttl 57, id 3023, offset 0, flags [none], proto TCP (6), length 52)
    173.194.38.98.80 > 106.186.29.14.53598: Flags [S.], cksum 0xae4c (correct), seq 1775907905, ack 1779164028, win 42900, options [mss 1430,nop,nop,sackOK,nop,wscale 6], length 0
20:10:39.923034 IP (tos 0x0, ttl 64, id 6595, offset 0, flags [DF], proto TCP (6), length 40)
    106.186.29.14.53598 > 173.194.38.98.80: Flags [.], cksum 0x5c07 (incorrect -> 0x95af), ack 1, win 229, length 0
20:10:39.923462 IP (tos 0x0, ttl 57, id 3024, offset 0, flags [none], proto TCP (6), length 589)
    173.194.38.98.80 > 106.186.29.14.53598: Flags [P.], cksum 0xcdd1 (correct), seq 1:550, ack 1, win 670, length 549
20:10:39.923475 IP (tos 0x0, ttl 57, id 3025, offset 0, flags [none], proto TCP (6), length 40)
    173.194.38.98.80 > 106.186.29.14.53598: Flags [F.], cksum 0x91d0 (correct), seq 550, ack 1, win 670, length 0
20:10:39.923492 IP (tos 0x0, ttl 64, id 6596, offset 0, flags [DF], proto TCP (6), length 40)
    106.186.29.14.53598 > 173.194.38.98.80: Flags [.], cksum 0x5c07 (incorrect -> 0x9382), ack 550, win 237, length 0
20:10:39.923690 IP (tos 0x0, ttl 64, id 6597, offset 0, flags [DF], proto TCP (6), length 40)
    106.186.29.14.53598 > 173.194.38.98.80: Flags [R.], cksum 0x5c07 (incorrect -> 0x937d), seq 1, ack 551, win 237, length 

Notez la longueur du premier paquet, 86 octets (une requête HTTP), alors qu'elle est normalement nulle, sans Fast Open.

Il y a en tout sept paquets. Sans Fast Open, la même requête HTTP aurait pris deux paquets de plus :

20:11:13.403762 IP (tos 0x0, ttl 64, id 55763, offset 0, flags [DF], proto TCP (6), length 60)
    106.186.29.14.42067 > 173.194.38.96.80: Flags [S], cksum 0x5c19 (incorrect -> 0x858c), seq 720239607, win 29200, options [mss 1460,sackOK,TS val 114041380 ecr 0,nop,wscale 7], length 0
20:11:13.405827 IP (tos 0x0, ttl 57, id 7042, offset 0, flags [none], proto TCP (6), length 52)
    173.194.38.96.80 > 106.186.29.14.42067: Flags [S.], cksum 0x5792 (correct), seq 687808390, ack 720239608, win 42900, options [mss 1430,nop,nop,sackOK,nop,wscale 6], length 0
20:11:13.405857 IP (tos 0x0, ttl 64, id 55764, offset 0, flags [DF], proto TCP (6), length 40)
    106.186.29.14.42067 > 173.194.38.96.80: Flags [.], cksum 0x5c05 (incorrect -> 0x3ef5), ack 1, win 229, length 0
20:11:13.405915 IP (tos 0x0, ttl 64, id 55765, offset 0, flags [DF], proto TCP (6), length 126)
    106.186.29.14.42067 > 173.194.38.96.80: Flags [P.], cksum 0x5c5b (incorrect -> 0xaa0c), seq 1:87, ack 1, win 229, length 86
20:11:13.407979 IP (tos 0x0, ttl 57, id 7043, offset 0, flags [none], proto TCP (6), length 40)
    173.194.38.96.80 > 106.186.29.14.42067: Flags [.], cksum 0x3ce6 (correct), ack 87, win 670, length 0
20:11:13.408456 IP (tos 0x0, ttl 57, id 7044, offset 0, flags [none], proto TCP (6), length 589)
    173.194.38.96.80 > 106.186.29.14.42067: Flags [P.], cksum 0x9cce (correct), seq 1:550, ack 87, win 670, length 549
20:11:13.408469 IP (tos 0x0, ttl 57, id 7045, offset 0, flags [none], proto TCP (6), length 40)
    173.194.38.96.80 > 106.186.29.14.42067: Flags [F.], cksum 0x3ac0 (correct), seq 550, ack 87, win 670, length 0
20:11:13.408498 IP (tos 0x0, ttl 64, id 55766, offset 0, flags [DF], proto TCP (6), length 40)
    106.186.29.14.42067 > 173.194.38.96.80: Flags [.], cksum 0x5c05 (incorrect -> 0x3c72), ack 550, win 237, length 0
20:11:13.408720 IP (tos 0x0, ttl 64, id 55767, offset 0, flags [DF], proto TCP (6), length 40)
    106.186.29.14.42067 > 173.194.38.96.80: Flags [R.], cksum 0x5c05 (incorrect -> 0x3c6d), seq 87, ack 551, win 237, length ...

Dans cet exemple, le gâteau envoyé par Google était en mémoire. Si ce n'est pas le cas (la machine vient de redémarrer, par exemple), la première requête Fast Open va être une triple poignée de mains classique, les bénéfices de Fast Open ne venant qu'après :

16:53:26.120293 IP (tos 0x0, ttl 64, id 55402, offset 0, flags [DF], proto TCP (6), length 64)
    106.186.29.14.57657 > 74.125.226.86.80: Flags [S], cksum 0x07de (incorrect -> 0xc67b), seq 3854071484, win 29200, options [mss 1460,sackOK,TS val 325168854 ecr 0,nop,wscale 6,exp-tfo cookiereq], length 0
16:53:26.121734 IP (tos 0x0, ttl 57, id 16732, offset 0, flags [none], proto TCP (6), length 72)
    74.125.226.86.80 > 106.186.29.14.57657: Flags [S.], cksum 0xb913 (correct), seq 2213928284, ack 3854071485, win 42540, options [mss 1430,sackOK,TS val 2264123457 ecr 325168854,nop,wscale 7,exp-tfo cookie 234720af40598470], length 0

Ici, le client, n'ayant pas de gâteau pour 74.125.226.86, a dû envoyer une option Fast Open vide (et donc pas de données : la longueur de son paquet SYN est nulle). À la deuxième connexion, on a un gâteau, on s'en sert :

16:54:30.200055 IP (tos 0x0, ttl 64, id 351, offset 0, flags [DF], proto TCP (6), length 161)
    106.186.29.14.57659 > 74.125.226.86.80: Flags [S], cksum 0x083f (incorrect -> 0x651d), seq 1662839861:1662839950, win 29200, options [mss 1460,sackOK,TS val 325184874 ecr 0,nop,wscale 6,exp-tfo cookie 234720af40598470], length 89
16:54:30.201529 IP (tos 0x0, ttl 57, id 52873, offset 0, flags [none], proto TCP (6), length 60)
    74.125.226.86.80 > 106.186.29.14.57659: Flags [S.], cksum 0x67e3 (correct), seq 2010131453, ack 1662839951, win 42540, options [mss 1430,sackOK,TS val 2264192396 ecr 325184874,nop,wscale 7], length 0

La section 4 de notre RFC plonge ensuite dans les détails compliqués de TCP Fast Open. Le gâteau est un MAC généré par le serveur et est donc opaque au client. Ce dernier ne fait que le stocker et le renvoyer. L'option Fast Open est simple : juste le code 34, une longueur (qui peut être nulle, par exemple pour un client qui ne s'est pas encore connecté à ce serveur, et qui demande donc un gâteau), et éventuellement le gâteau. Le serveur, lors de la génération du gâteau, va typiquement devoir suivre ces règles :

  • Lier le gâteau à l'adresse IP source (pour éviter qu'un attaquant ayant espionné le réseau n'utilise le gâteau d'un autre),
  • Utiliser un algorithme de génération imprévisible de l'extérieur (par exemple un générateur aléatoire),
  • Aller vite (le but de Fast Open est de diminuer la latence : pas question de faire des heures de calcul cryptographiques compliqués),
  • Imposer une date d'expiration au gâteau (soit en changer la clé privée utilisée lors de la génération, soit en incluant une estampille temporelle dans les données qui servent à générer le gâteau).

Un exemple d'algorithme valable (mais rappelez-vous que le gâteau est opaque, le serveur peut donc utiliser l'algorithme qu'il veut) est de chiffrer avec AES l'adresse IP et de changer la clé AES de temps en temps (invalidant ainsi automatiquement les vieux gâteaux). AES étant très rapide, cet algorithme a toutes les propriétés listées plus haut. Pour vérifier un gâteau entrant, le serveur a tout simplement à refaire tourner l'algorithme et voir s'il obtient le même résultat.

Et côté client ? Comme indiqué plus haut, le client doit stocker les gâteaux reçus (sans les comprendre : ils sont opaques pour lui) et les renvoyer lors des connexions suivantes vers le même serveur. Puisqu'on mémorise le gâteau de chaque serveur, on peut en profiter pour mémoriser également le MSS, ce qui indiquera la taille des données qu'on pourra envoyer dans le prochain paquet SYN. (Rappelez-vous que le serveur indique normalement sa MSS dans le SYN + ACK, donc trop tard pour Fast Open.) Mais attention : même si le MSS ainsi mémorisé est grand (supérieur à la MTU, par exemple), ce n'est pas forcément une bonne idée d'envoyer autant de données dans le paquet SYN. Des problèmes comme la fragmentation ou comme les middleboxes ne s'attendant pas à des SYN s'étalant sur plusieurs paquets IP, risquent de diminuer les performances, voire d'empêcher TCP de marcher. Ah, et si on ne connait pas le MSS, on doit se limiter à 536 octets en IPv4 et 1240 en IPv6.

Comme toujours sur l'Internet, lorsqu'on déploie une nouvelle technique, il faut aussi tenir compte des trucs bogués. Si le serveur ne répond pas aux SYN comportant l'option Fast Open, cela peut être parce qu'une stupide middlebox a décidé de jeter ces paquets, qui passeraient sans l'option. Même chose au cas où le serveur n'accuse pas réception des données qui étaient dans le SYN : le client Fast Open doit être prêt à réessayer sans cette option, et à mémoriser que le serveur ne doit pas être utilisé avec Fast Open. (Notez, car le RFC ne le fait pas, que ces incompatibilités, étant typiquement causées par une middlebox et pas par le serveur lui-même, peuvent changer dans le temps, si le routage fait soudain passer par un autre chemin.)

Autre point important lorsqu'on met en œuvre Fast Open : le serveur doit garder une trace en mémoire du nombre de connexions qui ont demandé Fast Open mais n'ont pas encore terminé la triple poignée de mains. Et, au delà d'une certaine limite, le serveur doit refuser de nouvelles connexions Fast Open (en ne renvoyant pas d'option Fast Open dans le SYN + ACK), n'acceptant que le TCP traditionnel. Cette précaution permet de résister à certaines attaques par déni de service.

En parlant d'attaques, la section 5 du RFC se concentre sur la sécurité. L'obligation d'envoyer un gâteau authentique arrête certaines attaques triviales (envoyer paquets SYN avec des données qui vont faire travailler le serveur). Mais d'autres attaques restent possibles. Accrochez-vous, nous allons étudier ce qu'un méchant peut faire contre des serveurs TCP Fast Open.

D'abord, il peut tenter d'épuiser les ressources du serveur en utilisant des gâteaux valides. Où les obtient-il ? Cela peut être en utilisant plein de machines (un botnet). Bien sûr, vous allez me dire, on peut faire des tas d'attaques par déni de service avec un botnet mais, avec Fast Open, les zombies peuvent faire plus de dégâts pour moins cher (ils ne sont pas obligés d'écouter les réponses ni même de les attendre). D'où l'importance de la variable « nombre de connexions Fast Open pas complètement ouvertes » citée plus haut.

On ne peut pas normalement voler des gâteaux à une machine et les utiliser ensuite soi-même puisque le gâteau est (si le serveur a bien fait son boulot) lié à l'adresse IP. Mais ce vol reste possible si plusieurs machines partagent une adresse IP publique (cas du CGN par exemple). Une solution possible serait d'inclure dans le calcul du gâteau, non seulement l'adresse IP mais aussi la valeur d'une option TCP Timestamp.

Fast Open peut aussi en théorie être utilisé dans des attaques par réflexion. Par exemple (mais le RFC indique aussi d'autres méthodes), si l'attaquant contrôle une machine dans le réseau de sa victime, il peut obtenir des gâteaux valables et ensuite, lancer depuis un botnet des tas de connexions Fast Open en usurpant l'adresse IP source de sa victime. Les serveurs Fast Open vont alors renvoyer des données (potentiellement plus grosses que les requêtes, donc fournissant une amplification, chose bien utile pour une attaque par déni de service) à la victime. C'est idiot de la part de l'attaquant de s'en prendre à une machine qu'il contrôle déjà ? Non, car sa vraie victime peut être le réseau qui héberge la machine compromise. Les réponses des serveurs Fast Open arriveront peut-être à saturer la liaison utilisée par ce réseau, et cela en contrôlant juste une machine (soit par piratage, soit par location normale d'une machine chez l'hébergeur qu'on veut attaquer). La seule protection envisagée pour l'instant est de décourager les serveurs d'envoyer les réponses au-delà d'une certaine taille, tant que la triple poignée de mains n'a pas été terminée. Mais cela diminue une partie de l'intérêt de TCP Fast Open.

Bon, fini avec ces tristes questions de sécurité, revenons à la question de l'applicabilité de Fast Open. On a bien dit que Fast Open ne convient pas à tous les cas. Si je suis développeur, dans quels cas mon application a-t-elle raison d'utiliser Fast Open ? D'abord, on a vu que Fast Open fait courir le risque d'une duplication du SYN si le paquet est dupliqué et que le second arrive après que le serveur ait détruit le début de connexion. En pratique, la probabilité d'une telle malchance semble faible. Le RFC ne fournit pas de chiffres précis (voir Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J., Towsley, D., « Measurement and classification of out-of-sequence packets in a tier-1 IP backbone » dans IEEE/ACM Transactions on Networking (TON)). Dans le doute, une application qui ne pourrait pas gérer le cas de données dupliquées ne doit donc pas activer Fast Open (rappelez-vous qu'il ne doit pas non plus l'être par défaut). Comme indiqué plus haut, pour HTTP, un GET ne pose pas de problèmes (les navigateurs Web impatients causent déjà souvent des GET dupliqués, qu'on retrouve dans ses journaux) mais un POST non protégé (par exemple par les requêtes conditionnelles du RFC 7232) a davantage de chances de créer des histoires.

Autre cas où il n'y a pas de problèmes à attendre, celui de TLS. Si le client met le TLS_CLIENT_HELLO dès le SYN, cela n'entraine pas de conséquences fâcheuses si le SYN est dupliqué, et cela fait gagner un RTT sur la poignée de mains de TLS.

Ensuite, même s'il n'a pas de conséquences néfastes, TCP Fast Open n'a pas non plus d'avantages si le temps d'établissement de la connexion est négligeable devant la durée totale de la connexion. Une requête HTTP pour un fichier de petite taille peut sans doute profiter de Fast Open, mais pas le transfert d'une énorme vidéo.

On a parlé plus haut des connexions HTTP persistantes (RFC 7320). TCP Fast Open est-il utile lorsqu'on a ces connexions persistantes ? Oui, répond notre RFC. L'étude de Radhakrishnan, S., Cheng, Y., Chu, J., Jain, A. et Raghavan, B. citée plus haut, ainsi que celle d'Al-Fares, M., Elmeleegy, K., Reed, B. et Gashinsky, I., « Overclocking the Yahoo! CDN for Faster Web Page Loads » (dans Proceedings of Internet Measurement Conference , novembre 2011), montrent que le nombre moyen de transactions HTTP par connexion TCP n'est que de 2 à 4, alors même que ces connexions restent ouvertes plusieurs minutes, ce qui dépasse normalement le temps de réflexion d'un être humain. Les mesures effectuées sur Chrome (qui garde les connexions de 5 à 10 minutes) ne voyaient que 3,3 requêtes TCP par connexion. Faudrait-il allonger cette durée pendant laquelle les connexions persistent ? Cela entrainerait d'autres problèmes, par exemple avec les routeurs NAT qui, en violation du RFC 5382, coupent automatiquement les connexions bien avant la limite de deux heures demandée par le RFC (voir les études de Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P. et Kojo., M., « An Experimental Study of Home Gateway Characteristics » dans les Proceedings of Internet Measurement Conference, octobre 2010 ainsi que de Wang, Z., Qian, Z., Xu, Q., Mao, Z. et Zhang, M., « An Untold Story of Middleboxes in Cellular Networks » dans Proceedings of SIGCOMM, août 2011). Envoyer des keepalives TCP résoudrait ce problème mais serait une sérieuse source de consommation électrique pour les machines fonctionnant sur batteries. On voit même le phénomène inverse, les navigateurs Web conçus pour les équipements mobiles qui se mettent à couper les connexions HTTP persistantes plus tôt (Souders, S., « Making A Mobile Connection »).

Ce RFC sur TCP Fast Open a le statut « expérimental ». Qu'est-ce qu'on doit encore étudier et mesurer pour être sûr que Fast Open marche bien ? D'abord, quel est le pourcentage exact de chemins sur l'Internet où les paquets TCP ayant des options inconnues sont jetés ? Pas mal de middleboxes stoppent stupidement tout ce qu'elles ne comprennent pas (Medina, A., Allman, M., and S. Floyd, « Measuring Interactions Between Transport Protocols and Middleboxes » dans Proceedings of Internet Measurement Conference en octobre 2004). Une option nouvelle, comme Fast Open, pourrait donc avoir du mal à percer. Des mesures semblent indiquer que 6 % des chemins Internet seraient dans ce cas (Langley, A, « Probing the viability of TCP extensions » ou bien Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M. et Tokuda, H., « Is it Still Possible to Extend TCP? » dans Proceedings of Internet Measurement Conference en novembre 2011). TCP Fast Open réagit à ce problème en réessayant sans l'option (comme le font les résolveurs DNS quand ils n'obtiennent pas de réponse lorsque les requêtes sont envoyées avec EDNS).

Autre sujet de recherche intéressant, les liens avec la congestion. Normalement, Fast Open ne modifie pas les algorithmes qui tentent d'éviter la congestion mais il peut y avoir des cas subtils où Fast Open ne peut pas suivre ces algorithmes (données déjà envoyées avant que les pertes ne soient détectées).

TCP Fast Open impose actuellement l'usage d'un gâteau pour détecter les méchants qui tricheraient sur leur adresse IP source. Mais pour certains serveurs qui n'assurent que des tâches simples et idempotentes (le RFC prend l'exemple d'un serveur HTTP qui ne ferait que des redirections), la protection fournie par le gâteau est peut-être inutile et on pourrait faire des économies en s'en passant (l'expérience du DNS, qui est aussi requête/réponse, me rend personnellement sceptique sur ce point). Ou bien le serveur pourrait s'en passer par défaut, et basculer en Fast Open avec gâteau s'il détecte une attaque par déni de service en cours ? Bref, il y a encore des sujets ouverts.

La section 8 rappelle les travaux qui avaient précédé Fast Open. Il y a bien sûr T/TCP, déjà cité, qui avait trébuché sur les problèmes de sécurité. Une autre solution pour TCP est le TCPCT du RFC 6013. Mais il y a aussi les solutions dans les applications comme « preconnect ».

Sinon, si vous voulez de la lecture sur Fast Open, il y a une bonne explication dans Linux Weekly News, avec des détails sur son utilisation dans les programmes.

À propos de programmes, et les mises en œuvre ? TCP Fast Open existe dans le navigateur Chrome, ainsi que dans le noyau Linux, depuis la version 3.7 (3.16 seulement pour IPv6). Une Debian en version « jessie » permet donc de tester. Une API possible figure en annexe A du RFC. Du côté serveur, il faut, après avoir créé une socket : setsockopt(sfd, SOL_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen)); C'est plus compliqué sur le client (il faudrait envoyer des données dans le connect() ou bien utiliser sendto() ou encore une option de la socket). Le programme client-http-tcp-fastopen.c montre un simple client HTTP utilisant Fast Open. C'est avec lui qu'ont été obtenues les traces montrées plus haut (le pcap complet est sur pcapr ; il utilise une valeur expérimentale pour l'option et pas la valeur standard de 34).

Merci à Alexis La Goutte pour ses remarques.


Téléchargez le RFC 7413


L'article seul

RFC 7378: Trustworthy Location

Date de publication du RFC : Décembre 2014
Auteur(s) du RFC : H. Tschofenig (Independent), H. Schulzrinne (Columbia University), B. Aboba (Microsoft )
Pour information
Réalisé dans le cadre du groupe de travail IETF ecrit
Première rédaction de cet article le 18 décembre 2014


Il existe des applications de communication (de téléphonie, par exemple), qui indiquent la localisation de l'appelant, et cette localisation est cruciale lorsque il s'agit d'appels d'urgence, par exemple aux pompiers ou à la police, ou, moins dramatique, d'assistance routière (« ma voiture est en panne et je ne sais pas exactement où je suis », comme cela m'est arrivé sur la N 1 ce mois d'août). Ce nouveau RFC décrit le problème de la sécurité et de la fiabilité de la localisation, ainsi que des solutions pour améliorer cette sécurité et cette fiabilité.

Pour envoyer sa localisation à son correspondant, il y a deux sous-problèmes : 1) déterminer la localisation 2) la transmettre de manière sûre. Pour la téléphonie traditionnelle, la localisation est déterminée par le récepteur à partir du numéro de téléphone présenté. Cela veut dire notamment qu'un faux numéro peut entraîner une mauvaise localisation (cf. RFC 7340 et les autres documents du groupe STIR). Il y a plusieurs mécanismes pour s'assurer du numéro de téléphone comme le rappel (qui permet aussi de confirmer l'urgence, cf. RFC 7090). Mais quand l'appelant est mobile, même lorsqu'on est sûr du numéro de téléphone présenté, le problème n'est pas résolu. Ce RFC se focalise sur les cas où le numéro de téléphone de l'appelant est raisonnablement authentifié mais où il reste des doutes sur la localisation physique de la cible (oui, c'est comme cela qu'on désigne la personne ou l'objet dont on cherche à connaître la localisation). Le mode normal d'obtention de la localisation est de faire appel à un LIS (Location Information Server) qui, connaissant les caractéristiques du réseau utilisé, va l'indiquer à son client. Un malveillant peut faire en sorte qu'une mauvaise localisation soit indiquée de trois façons :

  • Changement d'endroit (place shifting), lorsque l'attaquant arrive à placer un faux objet PIDF-LO ( Presence Information Data Format Location Object, voir le RFC 4119). Dans certains cas, il y a une limite à la triche, par exemple l'attaquant peut indiquer une fausse position mais qui doit rester dans la zone couverte par un relais donné.
  • Changement de moment (time shifting), où l'attaquant réussit à ré-utiliser une information de localisation qui était vraie dans le passé, mais ne l'est plus.
  • Vol de localisation (location theft), lorsque on présente un objet de localisation qui est correct et valide mais concerne une autre personne.

La première façon est la plus puissante, mais n'est pas toujours accessible aux attaquants.

Pour comprendre complètement le problème, il faut aussi connaître l'architecture des services d'urgence (section 1.2) sur l'Internet. Son cadre général figure dans le RFC 6443. Les bonnes pratiques à suivre pour faire un service d'urgence qui marche sont dans le RFC 6881. Ces services d'urgence nécessitent des informations sur l'appelant (comme sa localisation, qu'il n'a pas toujours le temps ou la possibilité de donner, lorsqu'il est en situation d'urgence). Lorsqu'un service d'urgence reçoit l'appel, il doit donc déterminer la localisation, en déduire à qui transmettre l'appel (ce qu'on nomme un PSAP pour Public Safety Answering Point) et router l'appel (en SIP, transmettre un INVITE, contenant la localisation, cf. RFC 6442).

Le problème de tout service d'urgence, ce sont les faux appels. Ils existent depuis bien avant l'Internet. Comme ils détournent les services d'urgence des vrais appels, ils peuvent littéralement tuer, si quelqu'un qui avait besoin d'un secours urgent ne l'obtient pas car tous les services sont occupés à traiter des canulars. (Il est recommandé de consulter le document EENA sur les faux appels.) Parmi les faux appels, l'un est particulièrement dangereux, le swatting. Il doit son nom au SWAT états-unien et consiste à appeler les services de police en prétendant qu'il y a une situation d'extrême danger nécessitant de faire appel à la force (prise d'otages, par exemple). Cet appel amènera à un déploiement policier intense, style cow-boys, chez la victime. Le FBI a documenté ce phénomène. De telles actions étant sévèrement punies, les attaquants vont toujours essayer de cacher leur identité, par exemple en indiquant un faux numéro de téléphone, si leur fournisseur de services téléphoniques le permet. Plusieurs études ont montré que les faux appels étaient particulièrement nombreux si on ne pouvait pas authentifier l'appelant (cf. « Emergency services seek SIM-less calls block » ou « Rapper makes thousands of prank 999 emergency calls to UK police »).

Place maintenant aux menaces sur la localisation. Le RFC 6280 décrit une architecture pour des services de localisation intégrant la notion de vie privée. D'autres RFC décrivent les exigences de tout service de localisation (RFC 3693), les menaces contre eux (RFC 3694), le cas particulier des services d'urgence (RFC 5069), et l'usurpation des numéros de téléphone (RFC 7375).

Notre RFC s'attaque aux menaces en distinguant d'abord trois classes d'attaquants :

  • Les attaquants externes, ne disposant d'aucun privilège particulier,
  • Les attaquants situés dans l'infrastructure de téléphonie, et qui en contrôlent une partie, par exemple le LIS (Location Information Server),
  • Les attaquants situés sur la machine de l'utilisateur.

Évidemment, les deux dernières classes peuvent faire des dégats plus facilement.

Outre la tricherie sur son numéro de téléphone, un attaquant peut aussi tricher sur sa localisation, soit en en inventant une de toutes pièces, soit en « rejouant » une localisation authentique, mais dans le passé ou encore en « volant » une localisation authentique mais d'un autre utilisateur. Ce RFC se focalise sur ces risques liés à la localisation mais la tricherie sur l'identité n'est pas à oublier. En effet, l'auteur des faux appels cherche en général à éviter les représailles, et donc à dissimuler son identité, par exemple en appelant d'une cabine téléphonique.

Maintenant, que peut-on faire pour limiter les risques (section 3) ? Il y a trois mécanismes principaux :

  • Signer les informations de localisation (les fichiers PIDF-LO décrits dans le RFC 4119) au départ de l'appel. Aucune norme n'existe pour cela.
  • Obtention de la localisation, non pas via l'émetteur mais depuis le récepteur, via le RFC 6753, en utilisant le protocole HELD (HTTP-Enabled Location Delivery) RFC 5985. Dans ce cas, le destinataire de l'appel, le PSAP (le service d'urgence), contacte le serveur de localisation, le LIS.
  • Obtention de la localisation, non pas via l'émetteur mais via le réseau (plus exactement un mandataire dans le réseau), en utilisant le RFC 6442. Cette dernière technique, elle, impose la participation du FAI (qui connait la localisation physique de ses abonnés, même si c'est avec une précision limitée, surtout pour les mobiles).

Une fois obtenue la localisation, encore faut-il en évaluer la fiabilité. Ce niveau de fiabilité est une information cruciale pour le processus de décision. Par exemple, un appel d'urgence où la localisation est marquée comme « absolument sûre » peut être traité instantanément, alors qu'on passera un peu plus de temps à vérifier un appel depuis une localisation douteuse (section 4). La localisation dépend d'un certain nombre de partenaires, et cette fiabilité va donc varier selon la confiance qu'on accorde à ces partenaires. Par exemple, dans le deuxième mécanisme cité plus haut (le PSAP interroge le LIS), si le LIS est connu, de confiance, et qu'on l'utilise depuis longtemps avec succès, on se fiera facilement à lui. À l'inverse, dans le cas du troisième mécanisme (interrogation d'un mandataire géré par le FAI), s'il y a eu peu d'appels d'urgence depuis ce FAI et qu'on n'a jamais pu vérifier la fiabilité de ses informations, la localisation sera marquée comme douteuse.

Pour déterminer la validité des informations de localisation, on peut aussi faire des vérifications croisées. Lors d'un appel SIP, une fois qu'on a reçu une localisation physique de l'émetteur, on peut comparer avec la localisation qu'indique l'adresse IP dans les champs Via: ou Contact:, ou celle dans les paquets de données. Si les deux localisations coïncident, on est rassuré. Sinon, on note la localisation comme étant douteuse.

La section 5 résume tous les problèmes de sécurité liés à la localisation fiable. Il faut notamment se rappeler que cette fiabilité peut être en opposition avec d'autres critères de sécurité, comme la protection de la vie privée (la section 6 détaille ce problème). D'autre part, toutes les mesures envisagées ne sont guère efficaces face au problème spécifique de l'attaque par déni de service : un attaquant qui effectuerait un très grand nombre d'appels pourrait toujours perturber le PSAP (le service d'urgence), ne serait-ce que via les vérifications faites. Effectuer un tel nombre d'appels est évidemment plus facile avec la téléphonie sur IP qu'avec le téléphone traditionnel. Et cela permet plus facilement de franchir les frontières, pour attaquer les services d'urgence d'un autre pays.

Ces appels en masse peuvent être faits par des zombies mais aussi par du code non sécurisé, par exemple un malware JavaScript, chargé automatiquement par le navigateur Web, et qui ferait des appels via WebRTC. Il peut donc être prudent d'empêcher ce genre de code non sécurisé d'appeler les services d'urgence.

Pour analyser la résistance d'un service d'urgence aux attaques par déni de service, il faut séparer les cas des trois ressources finies dont disposent ces services : l'infrastructure informatique (réseaux et serveurs), les humains qui répondent à l'appel, et les services de secours eux-mêmes (police, pompiers, etc). Par exemple, si le réseau marche bien et que les preneurs d'appel répondent bien, mais qu'il n'y a plus aucun pompier disponible car tous sont partis combattre des incendies imaginaires, l'attaque par déni de service a malheureusement réussi. Les contre-mesures doivent donc veiller à traiter les cas d'abus de ces trois ressources. Par exemple, faire des vérifications automatiques poussées sur la vraisemblance de l'information de localisation va stresser la première ressource (l'infrastructure informatique) mais cela préservera les deux autres (qui sont souvent limitées : on n'a pas des ressources humaines abondantes et qualifiées).

Apparemment, il n'existe pas encore de mise en œuvre de ce système.


Téléchargez le RFC 7378


L'article seul

Un Raspberry Pi en fonctionnement permanent, ça tient ?

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


Comme le savent mes lecteurs les plus attentifs (ceux et celles qui lisent tous les articles, et plusieurs fois, afin de les retenir), j'utilise un Raspberry Pi pour superviser les machines et services Internet auxquels je tiens. Après quelques mois, la machine a-t-elle tenue ? Quelle charge peut supporter le petit Raspberry Pi ?

Mon expérience avec la fiabilité du matériel est variable. Il y a clairement des problèmes avec les cartes SD. Souvent, le problème se manifeste dès le départ : certaines cartes ont tout le temps des problèmes (on redémarre, le système de fichiers est corrompu, on fait tourner fsck, il massacre tout). D'autres tiennent le coup longtemps (c'est le cas de celle qui est située dans le Raspberry Pi « de production »). Je n'ai pas trouvé de règles simples, du genre « telle marque est pourrie ». Je teste désormais les cartes avec deux ou trois démarrages sur un Pi, et je jette immédiatement celles qui ont une défaillance. Avec ce principe, j'ai nettement moins d'ennuis.

Parfois, le problème semble lié au Pi. J'en ai un qui est nettement plus pénible que les autres, et qui corrompt son système de fichiers, quelle que soit la carte SD utilisée.

Par contre, une fois éliminés les matériels défaillants, tout peut très bien marcher. Mon Pi de supervision est allumé 24 heures sur 24, sans alimentation électrique sécurisée (les coupures sont parfois violentes, par exemple quand on débranche le Pi pour brancher l'aspirateur...) et il tourne depuis plus de deux ans sans histoires. Voici ses records d'uptime :

% uprecords 
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
     1    74 days, 17:15:35 | Linux 3.12.20-1-ARCH      Wed Jun  4 18:39:08 2014
->   2    59 days, 05:25:39 | Linux 3.12.29-1-ARCH      Sat Oct 18 16:14:03 2014
     3    47 days, 16:41:18 | Linux 3.10.25-1-ARCH      Sun Jan  5 23:05:17 2014
     4    45 days, 20:48:04 | Linux 3.10.30-1-ARCH      Sat Feb 22 15:47:14 2014
     5    45 days, 06:08:27 | Linux 3.6.11-8-ARCH+      Thu Mar 14 14:02:38 2013
     6    40 days, 20:29:03 | Linux 3.6.11-14-ARCH+     Mon Jul 22 21:46:41 2013
     7    40 days, 07:29:16 | Linux 3.6.11-12-ARCH+     Wed Jun 12 14:17:05 2013
     8    26 days, 23:52:42 | Linux 3.12.26-1-ARCH      Thu Aug 21 14:35:08 2014
     9    26 days, 18:26:10 | Linux 3.6.11-17-ARCH+     Mon Sep 23 20:18:13 2013
    10    26 days, 14:52:31 | Linux 3.6.11-11-ARCH+     Thu May 16 23:23:45 2013
----------------------------+---------------------------------------------------
no1 in    15 days, 11:49:57 | at                        Thu Jan  1 08:29:37 2015
    up   770 days, 00:12:50 | since                     Wed Oct  3 21:50:46 2012
  down    33 days, 23:36:06 | since                     Wed Oct  3 21:50:46 2012
   %up               95.773 | since                     Wed Oct  3 21:50:46 2012

Certes, il n'a jamais fonctionné six mois de suite, contrairement à d'autres machines Unix mais rappelez-vous qu'il est installé à la maison, pas dans un centre de données professionnel, et qu'il fait tourner Arch Linux, qui change le noyau Linux souvent, nécessitant un redémarrage.

Les services qui tournent dessus ? Icinga pour la surveillance et Cacti pour les statistiques d'activité, essentiellement. Cacti est très gourmand en ressources lorsqu'on affiche les graphes mais, en fonctionnement normal, la charge est très modérée (de l'ordre de 1, en moyenne), comme l'affiche xload :

Il est vrai que le travail lié à une telle activité est relativement faible. Icinga surveille 47 machines et 152 services. Les programmes exécutés pour les tests sont en C, Perl, Python, etc. Rien d'extraordinaire pour une machine Unix mais cela illustre qu'un Raspberry Pi a exactement les mêmes capacités qu'un « vrai » ordinateur. Je me connecte souvent en SSH sur cette machine, pour mesurer depuis mon réseau local, et la réactivité du shell est parfaite. Cacti affiche 6 machines, avec environ 4 graphes par machine. En bits/seconde, cela fait : Et en paquets/seconde :

Et les entrées/sorties sur la carte SD ? Voici ce qu'affiche vmstat :

% vmstat 300
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  54976  28184  10432  50084    0    0     4     1    7    8 25  4 70  0  0
 0  0  55056  33576   9892  49228    0    0     4    19  375  220 26  4 69  0  0
 0  0  55168  45464   4304  43656    0    0     6    19  385  243 27  4 68  0  0

L'article seul

RFC 7397: Report from the Smart Object Security Workshop

Date de publication du RFC : Décembre 2014
Auteur(s) du RFC : J. Gilger, H. Tschofenig
Pour information
Première rédaction de cet article le 13 décembre 2014


Le 23 mars 2012, à Paris, a eu lieu un atelier sur la sécurité des objets « intelligents ». Ce RFC résume (bien après...) ce qui s'est dit pendant cet atelier.

Cela fait plusieurs années que les organisations de la galaxie IETF travaillent sur la question de l'« Internet des Objets », son architecture, sa sécurité, etc. Ainsi, en 2011, l'IAB avait fait un atelier à Prague sur ce sujet, dont le RFC 6574 avait donné un compte-rendu. Plusieurs groupes de travail de l'IETF se sont attelés à des tâches liées à l'Internet des Objets, c'est le cas par exemple de LWIG (qui a produit le RFC 7228). L'atelier du 23 mars 2012 à Paris était plus ciblé, ne concernant que la sécurité. (« Smart Object Security » fait « SOS », au fait...)

Trente-six articles avaient été acceptés pour cet atelier, répartis en quatre catégories, « Exigences de sécurité et scénarios », « Expériences de mise en œuvre », « Autorisation » et « Fourniture des informations de créance ».

La première catégorie, « Exigences de sécurité et scénarios », découle de l'obligation de mettre, dans les RFC, une section « Security considerations » (RFC 3552 et RFC 4101), analysant les problèmes éventuels de sécurité de la technologie décrite. Mais l'idée est de généraliser cette préoccupation à un écosystème plus large, au lieu d'avoir le nez sur chaque protocole indépendamment. Quelques exemples de questions posées dans cette catégorie :

  • Quels sont les acteurs impliqués ? Dans le cas des compteurs intelligents, par exemple, cela fait beaucoup de monde, c'est un écosystème complexe (cf. RFC 6272).
  • Qui fait l'avitaillement en informations de créance (credentials) ? Le fabricant des objets ? L'utilisateur ?
  • À ce sujet, justement, qu'attend-on de l'utilisateur final ? Entrer un PIN à la première utilisation ? Appuyer sur deux boutons simultanément pour appairer deux objets ? Se connecter à l'objet via un navigateur Web pour le configurer ? Le problème est d'autant plus aigu que la sécurité trébuche en général sur les problèmes liés aux utilisateurs.

Ainsi, à l'atelier, Paul Chilton avait (cf. son article) parlé de l'éclairage : les coûts d'une ampoule sont réduits et on ne peut pas doter chaque interrupteur d'un processeur 32 bits avec puce crypto ! À bien des égards, l'éclairage représente le cas idéal pour évaluer les solutions de sécurité : si une solution est réaliste dans le cas de l'éclairage, elle le sera pour beaucoup de cas d'objets connectés. (Et cela permettra de faire des blagues sur le thème « Combien d'experts en sécurité faut-il pour changer une ampoule ? »)

Rudolf van der Berg avait, lui, parlé d'objets plus complexes, capables d'utiliser une SIM et donc d'être authentifiés par ce biais. Pour le cas où on n'utilise pas un réseau d'opéateur mobile mais, par exemple, le WiFi, on peut utiliser l'EAP-SIM du RFC 4186.

Un problème récurrent des réseaux d'objets « intelligents » est celui de l'interface utilisateur. Où va t-on taper le mot de passe, dans une ampoule ou un interrupteur ? Pour l'authentification via une SIM, on peut tout sous-traiter à l'opérateur mais, si on change d'opérateur, comment reconfigurer les SIM ?

Pour le marché grand public, on sacrifiera probablement la sécurité, pour éviter de compliquer la tâche de l'utilisateur. On n'a donc pas fini de voir des photos nues des utilisateurs, prises par leur réfrigérateur et volées ensuite par un pirate. (Après tout, tout le monde se fiche de la sécurité de M. Michu, surtout si elle diminue les ventes d'objets jugés trop complexes par le consommateur. Quelques affirmations fortes « nos objets sont sécurisés et cryptés », sous la plume du service Communication, suffiront.) Pour les déploiements d'objets en entreprise, par exemple dans une usine ou un entrepôt, les exigences de sécurité seront sans doute plus fortes, ainsi que la possibilité d'avoir du personnel formé.

Actuellement, on l'a vu, la sécurité de ces objets est faible. Il est très fréquent que, lorsqu'ils sont protégés par un mot de passe, ce mot de passe soit défini en usine, et identique pour tous les objets d'un même modèle. La grande majorité des utilisateurs ne changeant pas les mots de passe (d'autant plus que cela peut être difficile à faire), le pirate n'aura qu'à essayer le mot de passe usine pour craquer la majorité des objets. (Souvenir personnel : en 1986, les VAX/VMS de Digital, engins horriblement coûteux, étaient vendus avec un mot de passe du compte d'administration, SYSTEM, identique pour tous les systèmes - c'était manager. Mais ils étaient gérés par des professionnels qui, en général, savaient qu'il fallait changer immédiatement les mots de passe. Ce qui ne veut pas dire que tout le monde le faisait... Le RFC note que beaucoup d'images logicielles pour les Raspberry Pi ont la même faiblesse. Bien des Pi sont sans doute vulnérables...) Globalement, la sécurité des objets est restée à un stade pré-Internet. Tant qu'on ne les connecte pas, ça va à peu près.

Enfin, en analysant la sécurité des objets connectés, il ne faut pas prendre en compte seulement la sécurité d'une maison ou d'une usine mais aussi les risques plus globaux. Si tout le monde a des compteurs électriques intelligents vulnérables, un attaquant peut couper le courant chez M. Michu et M. Michu, réduit à la bougie, est alors bien embêté. Mais, si l'exploitation de la faille peut être automatisée et faite depuis l'Internet, on peut envisager des scénarios où l'attaquant couperait une ville entière (style Watch Dogs).

Les solutions ne manquent pas, bien sûr, mais elles se heurtent souvent à des problèmes concrets. Si on trouve une faille logicielle dans tous les compteurs intelligents, peut-on les mettre à jour automatiquement et à distance (cf. section 4 du RFC pour les recommandations sur ce point) ? Et cette possibilité de mise à jour ne peut-elle pas être elle-même un vecteur d'attaque ? Un objet non intelligent peut être vendu ou donné à un nouveau propriétaire. Est-ce que ce sera toujours le cas s'il est sécurisé (mot de passe changé, oublié et non resettable) ? La solution de sécurité sera-t-elle ouverte ou bien verrouillera-t-elle l'utilisateur auprès d'un fournisseur unique ? Outre les coûts du matériel pour mettre en œuvre la solution de sécurité, y aura-t-il des coûts de licence, par exemple à cause de brevets ? La sécurité ne travaille pas en isolation, elle doit tenir compte de ce genre de questions.

La deuxième catégorie, trois retours d'expérience, portait sur des points comme les résultats de la mise en œuvre de CoAP. À chaque fois, la conclusion était que le déploiement de solutions de sécurité dans des objets très contraints en ressources était faisable. Souvent, cela nécessitait une adaptation, en laissant tomber des options qui auraient été trop coûteuses. La plupart des protocoles IETF permettent cette adaptation (par exemple, pour TLS, il n'est pas nécessaire de gérer tous les algorithmes de cryptographie du monde). Les développeurs ne signalent pas de cas de protocoles IETF impossibles à ajuster aux exigences des objets connectés. L'idée de concevoir des protocoles de sécurité spécialement faits pour les objets connectés n'a pas eu beaucoup de succès : il n'y a pas de raison de croire que ces protocoles, une fois toutes les fonctions souhaitées mises en œuvre, soient moins gourmands. Mohit Sethi a remarqué que, par exemple, les opérations cryptographiques nécessaires sont à la portée d'un Arduino UNO. En fait, si on veut faire des économies, ce n'est pas la cryptographie, même asymétrique, qu'il faut viser en premier mais plutôt la transmission de données : émettre des ondes radio vide la batterie très vite.

Est-ce que la loi de Moore va aider ? Non. Comme déjà noté dans le RFC 6574, les développeurs sont d'avis que cette loi sera utilisée pour baisser les prix, pas pour augmenter les capacités des objets.

Troisième catégorie, les histoires d'autorisation. Richard Barnes a expliqué que le modèle de sécurité dominant, authentifier une entité puis lui donner tous les droits, était particulièrement peu adapté aux objets communiquants, et il propose d'utiliser plutôt des capacités, comme le permet OAuth (RFC 6749). Cela donne une meilleure granularité aux autorisations.

Enfin, la quatrième et dernière catégorie est celle de la création et de la distribution aux objets des informations de créance. Prenons un nouvel objet qui arrive dans un réseau. Il va falloir qu'il connaisse l'information par laquelle il va être accepté par les autres membres du réseau. Faut-il la mettre dans l'objet à sa fabrication ? En tout cas, la faire rentrer par l'utilisateur de l'objet n'est pas une perspective bien tentante : ces objets ont des interfaces utilisateur très limitées, vraiment pas idéales pour, par exemple, rentrer une longue phrase de passe.

Johannes Gilger (cf. son article) a fait le tour des solutions d'appairage, qui permettent d'introduire deux objets l'un à l'autre, de manière à ce qu'ils ne communiquent qu'entre eux après. Par exemple, un humain se tient à côté des deux objets, qui affichent tous les deux un code numérique, et l'humain vérifie que ces codes coïncident.

Cullen Jennings proposait de faire appel à un tiers : l'objet contacte un serveur qui va faire l'enrôlement dans le réseau (mais le RFC oublie de mentionner les graves problèmes de vie privée que cela pose).

La fin de la section 4 de notre RFC résume quelques groupes de travail IETF qui sont impliqués dans la solution des problèmes qui avaient été identifiés dans cet atelier : LWIG (conseil aux implémenteurs de TCP/IP sur des objets limités), DICE (adapter DTLS à ces objets limités), ACE (authentification et autorisation chez les objets connectés), etc.

Une liste complète des papiers présentés figure dans l'annexe C du RFC. Comme l'indique l'annexe B du RFC, les articles présentés pour l'atelier sont tous en ligne (avec une copie ici). Pour la minorité des orateurs qui ont utilisé des supports de présentation, ceux-ci sont également en ligne.


Téléchargez le RFC 7397


L'article seul

RFC 7418: An IRTF Primer for IETF Participants

Date de publication du RFC : Décembre 2014
Auteur(s) du RFC : S. Dawkins (Huawei)
Pour information
Première rédaction de cet article le 13 décembre 2014


Ce court RFC est une introduction à une entité peu connue du monde de l'Internet, l'IRTF, Internet Research Task Force. Tellement peu connue qu'elle n'a même pas de page dans le Wikipédia francophone, c'est dire. L'IRTF est censée travailler sur des projets à long terme (proches de la recherche), pendant que l'IETF travaille sur des sujets bien maîtrisés techniquement, et qu'on peut normaliser relativement rapidement. Cette introduction vise essentiellement les gens qui participent déjà à l'IETF et se demandent si leur prochain projet ne serait pas plus adapté à l'IRTF.

Disons-le franchement tout de suite, l'IRTF n'est pas toujours le truc le plus intéressant dans la vaste galaxie des entités dont le nom commence par un I. La plus grande partie de la recherche concernant l'Internet n'est pas faite là. L'IRTF, très peu connue, et vivant dans l'ombre de l'IETF, n'a pas une activité débordante.

Un des problèmes de l'IRTF, et auquel ce RFC voudrait remédier, est que beaucoup de participants potentiels à l'IRTF croient acquis que ses pratiques sont les mêmes qu'à l'IETF. Ils présentent leurs idées d'une manière qui serait appropriée à l'IETF mais qui ne marche pas pour l'IRTF. D'abord, il faut comprendre la différence entre recherche et ingéniérie. Deux citations l'illustrent, une de Fred Baker qui estime que « le résultat de la recherche, c'est la compréhension, le résultat de l'ingéniérie, c'est un produit ». Et la seconde, de Dave Clark, affirme que « si ça doit marcher à la fin du projet, ce n'est pas de la recherche, c'est de l'ingéniérie ». Le RFC résume en disant que « la recherche, c'est un voyage, l'ingéniérie, c'est une destination ». Un chercheur qui ouvre plus de questions qu'il n'en a fermé dans sa recherche peut être satisfait. Un ingénieur qui ne termine pas ne l'est pas.

Cela entraine des différences entre l'organisation de l'IETF et celle de l'IRTF (section 2 du RFC). Par exemple, les unités de base de l'IETF, les groupes de travail, sont très focalisés, avec une charte précise, des buts à atteindre, et un calendrier. Les unités de base de l'IRTF, les groupes de recherche, sont au contraire larges, traitant plusieurs sujets assez différents en même temps, et avec une charte bien plus large.

De même, les délais ne sont pas les mêmes. L'IRTF, travaillant sur des problèmes difficiles, voit typiquement à trois ou cinq ans, alors que les calendriers (très théoriques...) des groupes de travail IETF visent des échéances plus courtes.

Autre différence, alors que l'IETF est supposé arriver à un consensus (approximatif) entre les membres du groupe de travail (RFC 7282), l'IRTF n'a pas de telles obligations et peut parfaitement, par exemple, suivre plusieurs lièvres à la fois.

L'IRTF n'est pas non plus obligée de suivre les politiques de l'IETF relatives aux brevets (RFC 3979).

Et sur le résultat du groupe de recherche ? En quoi doit-il consister ? Un groupe de travail IETF produit des RFC, c'est son but. Mais un groupe de recherche IRTF ne le fait pas forcément. Il peut aussi publier par d'autres moyens (rapports, articles académiques...), voire se contenter d'Internet-Drafts qui ne deviendront pas de RFC. Le critère du succès, pour un groupe IRTF, c'est de faire avancer la science, pas de faire des RFC.

Maintenant que la section 2 a surtout expliqué ce que l'IRTF n'est pas, la section 3 donne des conseils sur ce qu'il faut faire quand on veut travailler à l'IRTF. L'actuel président de l'IRTF, Lars Eggert, le résume en disant « comportez-vous comme un groupe de recherche IRTF pendant un an, et on verra bien si vous en êtes un ». Et comment est un groupe de recherches IRTF ? Le RFC 4440 donne quelques pistes, purement indicatives :

  • Rassemblez des chercheurs, en nombre suffisant, qui veulent travailler sur ce sujet,
  • Analysez bien ce qui se fait ailleurs, en vous demandant ce que le futur groupe de recherche IRTF apporterait, par rapport à ces activités externes,
  • Organisez un premier atelier pour voir ce que cela donne,
  • Si vous estimez que cette recherche peut déboucher sur des techniques normalisables, trouvez quelques ingénieurs pour jeter un coup d'œil et voir si c'est faisable.

Si vous vous intéressez plutôt aux règles et procédures de fonctionnement de l'IRTF, plutôt qu'à la vision « haut niveau » exposée ici, voyez le RFC 2014. Si vous voulez lire mes articles sur des RFC issus de l'IRTF, demandez au moteur de recherche.


Téléchargez le RFC 7418


L'article seul

Introduction à IPv6 à Lolut/UTBM

Première rédaction de cet article le 12 décembre 2014
Dernière mise à jour le 13 décembre 2014


Le 11 décembre à l'UTBM à Belfort, j'ai eu le plaisir d'être invité par l'association libriste Lolut à parler d'IPv6. L'idée était une introduction à cette technique, avec notamment les aspects « stratégiques » (pourquoi IPv6 n'est-il pas plus déployé ? Quels sont vraiment les obstacles ?)

Le public de cette conférence était composée d'environ 50 personnes, en majorité d'étudiants en informatique de l'UTBM. C'était donc très mâle. (Mais merci à l'étudiante assez courageuse pour avoir posé des questions sur des sujets qu'elle ne comprenait pas, alors que d'autres ne comprenaient pas plus mais n'osaient pas demander.)

Voici les supports de cet exposé :

La vidéo est disponible chez Lolut (tout en bas de la page). Vous trouverez au même endroit un récit détaillé de la conférence et des difficultés à la diffuser en temps réel :-)

Et merci à Jérome Boursier pour l'idée, l'organisation et l'accueil.


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