Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

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


RFC 7680: A One-Way Loss Metric for IPPM

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : G. Almes (Texas A&M), S. Kalidindi (Ixia), M. Zekauskas (Internet2), A. Morton (AT&T Labs)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 1 février 2016


Une des tristes réalités de l'Internet d'aujourd'hui est que les paquets se perdent. Ils quittent la machine émettrice et ne sont jamais reçus par la machine réceptrice. Il y a de nombreuses causes à cela (abandon du paquet par un routeur surchargé, par exemple), mais ce RFC 7680, comme les autres documents du groupe de travail IPPM se focalise sur la mesure du phénomène, pas sur ses causes. Il définit donc une métrique « perte de paquet » permettant de comparer des mesures entre elles en sachant qu'on parle bien de la même chose. (Ce RFC remplace la première définition, qui était dans le RFC 2680.)

Comme les autres RFC décrivant des métriques, des grandeurs rigoureusement définies et qu'on va mesurer, il s'appuie sur les définitions et le vocabulaire des RFC 2330 et RFC 7312. Par ailleurs, il suit de très près le plan du RFC 2679, qui spécifiait la mesure du délai d'acheminement d'un paquet. Cette fois, ce qui est défini est une mesure binaire (un paquet est perdu ou bien ne l'est pas), Type-P-One-way-Loss, puis une statistique pour le cas où il y a plusieurs paquets, le taux de perte moyen. (Petit rappel : Type-P signifie que le rapport de mesure doit indiquer le type du paquet - protocole de transport, port, etc - car le résultat peut en dépendre. Cf. section 2.8.1.)

Pourquoi cette métrique est-elle utile ? La section 1.1 rappelle l'intérêt de connaître les pertes :

  • Certaines applications, notamment interactives, se comportent mal (ou pas du tout) si le taux de pertes dépasse un certain seuil.
  • Les applications plus ou moins temps-réel aiment encore moins les pertes de paquets que les autres applications.
  • Les protocoles de transport comme TCP compensent les pertes en réémettant les paquets mais un taux de pertes trop élevé les empêchera d'atteindre leur débit maximum.

Mais pourquoi mesurer les pertes sur un chemin aller-simple (one-way) plutôt que aller-retour (two-way) ? La célébrissime commande ping affiche en effet des pertes après un aller-retour (ici 57 %) :

% ping -c 19 198.51.100.80 
PING 198.51.100.80 (198.51.100.80) 1450(1478) bytes of data.
1458 bytes from 198.51.100.80: icmp_seq=1 ttl=46 time=168 ms
1458 bytes from 198.51.100.80: icmp_seq=5 ttl=46 time=167 ms
1458 bytes from 198.51.100.80: icmp_seq=6 ttl=46 time=167 ms
1458 bytes from 198.51.100.80: icmp_seq=9 ttl=46 time=169 ms
1458 bytes from 198.51.100.80: icmp_seq=10 ttl=46 time=167 ms
1458 bytes from 198.51.100.80: icmp_seq=13 ttl=46 time=168 ms
1458 bytes from 198.51.100.80: icmp_seq=15 ttl=46 time=168 ms
1458 bytes from 198.51.100.80: icmp_seq=18 ttl=46 time=167 ms
--- 198.51.100.80 ping statistics ---
19 packets transmitted, 8 received, 57% packet loss, time 18013ms
rtt min/avg/max/mdev = 167.407/168.034/169.066/0.639 ms

Mais les mesures aller-retour ont bien des limites :

  • Si le chemin est asymétrique, on mesure en fait les performances de deux chemins, l'aller et le retour, qui n'ont pas forcément les mêmes caractéristiques. Même si le chemin est symétrique (passage par les mêmes routeurs à l'aller et au retour), rien ne dit que les résultats soient les mêmes dans les deux sens : files d'attente différentes, QoS peut-être réglée différemment, etc.
  • Beaucoup d'applications, par exemple les transferts de fichiers, voient leurs performances dépendre essentiellement d'un seul chemin (pour un transfert de fichiers, celui que suivent les données, pas le chemin inverse par lequel ne transitent que les petits accusés de réception).

Mais les mesures aller-simple sont plus difficiles à effectuer entre autres parce qu'elles ont souvent besoin d'horloges synchronisées (section 1.2). Le principe de la mesure de notre métrique est en effet d'émettre un paquet depuis la machine source à un temps T et de l'attendre à la machine destination jusqu'au temps T + t (où t est le délai qu'on accepte d'attendre). Si les horloges des deux machines ne sont pas synchronisées, leurs mesures de T vont différer, faussant ainsi les résultats. La section 1.2 rappelle donc le vocabulaire à utiliser pour évaluer la synchronisation. Les gourous de l'horlogerie verront qu'il est différent de celui des documents UIT comme le G.810, « Definitions and terminology for synchronization networks ».

  • Synchronisation (synchronization) signifie que deux horloges sont d'accord entre elles sur l'heure qu'il est (time error pour l'UIT).
  • Correction (accuracy) désigne le degré d'accord entre une horloge et la vraie heure UTC (time error from UTC pour l'UIT). Deux horloges peuvent donc être synchronisées et néanmoins incorrectes (ce qui n'est pas un grave problème pour nos métriques aller-simple).
  • Résolution (resolution) est la précision de l'horloge. Certains vieux Unix n'avancent ainsi l'horloge que toutes les dix ms et sa résolution est donc de 10 ms (cela se voyait bien avec la commande ping, qui n'affichait que des RTT multiples de 10). L'UIT dit sampling period.
  • Décalage (skew) est le changement dans la synchronisation ou la correction. Il se produit lorsque l'horloge va plus ou moins vite qu'elle ne le devrait. L'UIT appelle cela time drift.

Une fois ces préliminaires achevés, la section 2 décrit la métrique principale de notre RFC, Type-P-One-way-Packet-Loss. Sa valeur est simplement 0 lorsque le paquet est arrivé et 1 autrement.

Il y a bien sûr davantage de choses à dire sur cette métrique. Par exemple (section 2.5), faut-il distinguer le cas où un paquet a vraiment été perdu et le cas où il est simplement arrivé en retard, après l'expiration du délai ? En théorie, on devrait attendre 255 secondes, la durée de vie maximale d'un paquet IPv4 (RFC 791, section 3.2, notez qu'IPv6 n'a aucune limite, cf. RFC 2460, section 8.2). En pratique, on attendra moins longtemps : après tout, pour beaucoup d'applications, un paquet en retard n'a aucun intérêt, on peut aussi bien le considérer comme perdu. C'est l'approche retenue ici. (Par exemple, l'outil de test DNS dig attend, par défaut, cinq secondes avant de considérer la réponse comme perdue.)

Et si le paquet arrive corrompu, le considère-t-on comme perdu ? Là encore, oui, pas de distinction. En effet, si le paquet est corrompu, on ne peut même pas être sûr qu'il était bien le paquet attendu, puisque les bits qui permettent de le reconnaître sont peut-être ceux qui ont été changés.

Même chose si le paquet est fragmenté et que certains des fragments n'arrivent pas du tout. On ne peut pas reconstituer le paquet, on le considère comme perdu. En revanche, la duplication, elle, n'est pas considérée comme une perte.

Notre RFC 7680 décrit une métrique (une grandeur définie rigoureusement), pas une méthodologie de mesure, encore moins un protocole. Toutefois, la section 2.6 donne des indications sur ce que pourrait être une telle méthodologie. Le mécanisme recommandé est de mettre une estampille temporelle dans le paquet émis, et de regarder à l'arrivée si on détecte le paquet au bout d'un temps « raisonnable ». À noter que cette méthode n'implique pas une stricte synchronisation des horloges entre les deux machines. On est loin d'un protocole complet (je n'ai pas l'impression qu'il ait jamais été mis au point) et, par exemple, on n'indique pas comment la destination sait qu'elle doit s'attendre à voir arriver un paquet.

Toute mesure implique des erreurs et des incertitudes et la section 2.7 les analyse. D'abord, si les horloges ne sont pas synchronisées du tout, un paquet peut être déclaré comme perdu à tort (si l'émetteur a une horloge qui retarde, le paquet arrivera tard et le destinataire aura pu s'impatienter et le considéré perdu). Même problème si le délai d'attente n'est pas raisonnable, si le destinataire renonce trop vite. Ces deux problèmes peuvent être évités en synchronisant à peu près les horloges (il suffit que leur écart soit petit par rapport au délai d'attente) et en choisissant bien le délai (par exemple, sur une liaison utilisant un satellite géostationnaire, la finitude de la vitesse de la lumière impose un délai d'attente minimum de 240 ms - 2 * 35 786 / 300 000).

Une troisième source d'erreur est plus subtile : le paquet peut arriver jusqu'à la machine de destination (donc le réseau fonctionne bien) mais celle-ci le rejeter car ses ressources (par exemple les tampons d'entrée/sortie) sont pleines. Pour éviter de compter à tort des paquets comme perdus, il faut s'assurer que la machine de mesure a des ressources suffisantes pour traiter tous les paquets.

La section 2.8 se penche sur la publication des résultats (voir aussi l'excellent RFC 6703). Par exemple, elle impose de publier le Type-P (comme vu plus haut, le taux de pertes peut être différent en TCP et en UDP, par exemple), le seuil de patience (« le pourcentage de paquets non arrivés au bout de 1 500 ms est de X % »), et recommande de publier, autant que possible, le chemin parcouru (entre deux machines, si le chemin change par suite de modifications de routage, le taux de perte va probablement changer).

La métrique présentée en section 2 était pour un paquet. La section 3 définit une métrique supplémentaire, Type-P-One-way-Packet-Loss-Poisson-Stream pour le cas où on utilise plusieurs paquets. Elle utilise une distribution de Poisson (ce n'est pas la seule possible mais elle est d'usage très fréquent). Et la section 4 s'en sert pour définir une statistique utile. Type-P-One-way-Packet-Loss-Ratio (section 4.1, attention, elle a changé de nom depuis le RFC 2680) est le taux de pertes moyen. Si on envoie cinq paquets et que quatre arrivent, elle vaut 0,2 (c'est ce qu'affiche ping sous l'intitulé % packet loss mais attention, ping fait une mesure aller-retour et pas aller-simple comme notre RFC).

Cette moyenne n'est pas toujours facile à évaluer. Ainsi, sur un lien Internet typique, le taux de pertes est bas (nettement moins de 1 %). Pour obtenir une valeur statistiquement significative, il faut souvent tester avec des centaines de paquets.

Comme le note la section 5, consacrée à la sécurité, un problème courant des mesures actives est qu'elles peuvent perturber le réseau qu'elle observent. Si ces mesures actives ne posent pas trop de problèmes de vie privée (on ne mesure pas le trafic existant, mais seulement celui qu'on a créé), elles peuvent par contre faire mal au réseau. Il faut donc prendre soin de ne pas injecter « trop » de paquets (cf. l'option -f de ping).

Après « les mesures qui font du mal au réseau », il y a un autre risque de sécurité, « le réseau qui fait du mal aux mesures ». Imaginons qu'on mesure les performances d'un opérateur réseau et qu'un concurrent envoie exprès un trafic intense au même moment, les résultats seront mauvais. La publication des résultats devrait donc être accompagnée d'une description des solutions utilisées qui permettent de limiter le risque de ce genre d'attaques. (Cela peut être aussi simple que de ne pas communiquer à l'avance les moments où se font les mesures.)

Le RFC mentionne aussi le risque d'une « mesure Volkswagen » : un opérateur peut reconnaître les paquets de mesure et leur donner un traitement préférentiel. Là encore, il faut indiquer les solutions choisies pour que les paquets de mesure ne soient pas favorisés (par exemple en faisant en sorte qu'ils ressemblent autant que possible à des paquets « normaux »).

La section 6 de notre RFC présente les (très faibles) différences avec la précédente norme, le RFC 2680. Le but principal du nouveau RFC (projet documenté dans le RFC 6576) était de faire avancer cette métrique sur le « chemin des normes » (cf. RFC 2026), de « proposition de norme » à « norme [tout court] ». Les tests du RFC 7290 (voir aussi le rapport sur le RFC 2680) ont montré que les métriques Internet étaient sérieuses et utilisables, justifiant cet avancement sur le chemin des normes.

Les changements dans le texte sont minimes, comme l'introduction des références au RFC sur la publication de mesures, RFC 6703 et à d'autres RFC publiés depuis (comme le RFC 4737 sur le réordonnancement des paquets), la correction de petites erreurs, l'accent plus important sur la protection de la vie privée, etc.


Téléchargez le RFC 7680


L'article seul

RFC 7679: A One-Way Delay Metric for IPPM

Date de publication du RFC : Janvier 2015
Auteur(s) du RFC : G. Almes (Texas A&M), S. Kalidindi (Ixia), M. Zekauskas (Internet2), A. Morton (AT&T Labs)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 1 février 2016


Ce RFC définit une métrique, une grandeur à mesurer, en l'occurrence le délai d'acheminement d'un paquet d'un point à un autre du réseau. Cela semble trivial, mais la définition rigoureuse de la métrique, permettant des mesures scientifiques et leur comparaison, prend vingt pages... Elle remplace l'ancienne définition, qui était normalisée dans le RFC 2679.

Comme tous les RFC du groupe de travail ippm, celui-ci s'appuie sur les définitions et le vocabulaire du RFC 2330, notamment la notion de Type-P (paquets IP ayant la même « signature », c'est-à-dire même protocole de couche 4, même numéro de port, etc, car certains équipements réseaux traitent différemment les paquets selon ces variables).

Commençons par le commencement, c'est-à-dire l'introduction, en section 1. Le RFC définit une métrique pour une mesure unique (un singleton) nommé Type-P-One-way-Delay, ainsi qu'un échantillonnage, pour le cas où la mesure est répétée, et enfin diverses statistiques agrégeant les résultats de plusieurs mesures. Pourquoi une telle métrique ? Comme le rappelle la section 1.1, celle-ci est utile dans des cas comme, par exemple :

  • Estimer le débit maximal qu'on obtiendra (avec certains protocoles comme TCP, il est limité par le RTT, cf. le RFC 7323).
  • La valeur minimale de ce délai d'acheminement nous donne une idée du délai dû uniquement à la propagation (qui est limitée par la vitesse de la lumière) et à la transmission. (Voir aussi la section 4.3.)
  • Par contre, son augmentation nous permet de détecter la présence de congestion.

Mais pourquoi un délai d'acheminement « aller-simple » et pas « aller-retour », comme le fait ping, ou bien comme le normalise le RFC 2681 ? Après tout, le délai aller-retour est bien plus simple à mesurer. Mais il a aussi des défauts :

  • Une bonne partie des routes sur l'Internet sont asymétriques. Le délai aller-retour dépend donc de deux délais aller-simple, qui peuvent être très différents.
  • Même si le chemin est symétrique, les politiques de gestion de la file d'attente par les routeurs peuvent être très différentes dans les deux sens.
  • Certains protocoles s'intéressent surtout aux performances dans une direction. C'est le cas du transfert d'un gros fichier, où la direction des données est plus importante que celle des accusés de réception.

Le RFC ne le mentionne apparemment pas, mais on peut aussi dire que la mesure d'un délai aller-retour dépend aussi du temps de réflexion par la machine distante (avec ping, si la machine visée est très chargée, la génération du paquet ICMP de réponse peut prendre un temps non négligeable ; c'est encore pire avec des protocoles applicatifs, où la réflexion n'est pas faite dans le noyau, et est donc sensible à par exemple, le swapping).

Comme avec tout système de mesure, les horloges et leurs imperfections jouent un rôle crucial. La section 2 rappelle des concepts (voir le RFC 2330) comme la synchronisation (le fait que deux horloges indiquent la même valeur) ou le décalage (le fait qu'une horloge aille plus ou moins vite qu'une autre).

Enfin, après tous ces préliminaires, le RFC en arrive à la définition de la métrique, en section 3. Type-P-One-way-Delay est définie comme une fonction de divers paramètres comme les adresses IP des deux parties et l'instant de la mesure. La mesure dépend aussi du Type-P (par exemple parce que certains ports sont favorisés par la QoS ; notez que si la QoS dépend d'une DPI, la définition du Type-P ne suffira pas). Elle est en secondes. Et sa définition (section 3.4) est « Le temps entre l'envoi du premier bit du paquet sur le câble et la réception du dernier bit du paquet depuis le câble ». Si le paquet n'arrive pas, le délai est dit « indéfini » et, en pratique, pris comme étant infini. Les programmeurs noteront donc qu'il n'est pas possible de mesurer cette valeur avec l'API Posix, qui ne donne pas accès à des détails aussi précis.

Ce n'est pas tout de définir une métrique, il faut aussi la mesurer. Dans le monde réel, cela soulève quelques problèmes, couverts par la section 3.5. Le principal étant évidemment la synchronisation des horloges. Si le paquet part à 1247389451,578306110 (en secondes depuis le 1er janvier 1970) et arrive à 1247389453,018393817, le délai a-t-il réellement été de 1,44 secondes ou bien seulement de 1,32 secondes mais les horloges différaient de 0,12 secondes ? Comme des délais peuvent être aussi bas que 100 µs, une synchronisation précise est nécessaire. Le GPS est une bonne solution pour cela, NTP une moins bonne, car sa résolution est plus faible (de l'ordre de plusieurs ms) et il dépend du réseau qu'on veut mesurer.

Il faut aussi tenir compte de problèmes comme les paquets perdus (si le délai de garde est de cinq secondes, un paquet perdu ne doit pas compter pour un délai d'acheminement de cinq secondes, ou bien des agrégats comme la moyenne seront complètement faussés) ou comme la duplication de paquets (dans ce cas, le RFC précise que c'est la première occurrence qui compte). Le délai de garde (délai d'atttente maximal avant de considérer un paquet comme perdu) ne doit pas être trop bas, sinon on risque de sur-estimer les performances du réseau, en éliminant les paquets lentement acheminés.

Enfin, pour celui qui voudrait concevoir un protocole de mesure de cette métrique, le RFC suggère une méthodologie, en section 3.6 :

  • S'assurer de la synchronisation des horloges,
  • Former le paquet et y mettre l'instant de départ sur le câble (sur une machine non temps réel, cela peut être délicat de mettre cet instant exact),
  • À la réception, mesurer l'instant et calculer la différence avec ce qui est indiqué dans le paquet,
  • Évaluer l'erreur (il y en aura forcément) et, éventuellement, corriger.

Cette question de l'analyse d'erreur fait l'objet de la section 3.7. Les deux principales sources d'erreur seront liées aux horloges (qui ne sont jamais parfaites) et à la différence entre le temps de départ ou d'arrivée mesuré et le temps réel. Sur un système d'exploitation multi-tâches et non temps réel comme Unix, le temps entre le moment où le paquet arrive dans la carte Ethernet et celui où l'application peut appeler gettimeofday() est souvent significatif (section 3.7.2) et, pire, variable et imprévisible (car on dépend de l'ordonnanceur). Parmi les mécanismes pour déterminer l'erreur, de façon à pouvoir effectuer les corrections, le RFC suggère la calibration (section 3.7.3), en répétant de nombreuses fois la mesure. Cette partie sur l'analyse des erreurs est détaillée et explique en partie la longueur du RFC : la métrologie n'est pas une science simple !

À noter que les deux horloges, à l'arrivée et au départ, ont besoin d'être synchronisées mais n'ont pas forcément besoin d'être correctes. La correction reste quand même utile, car les délais peuvent dépendre de l'heure de la journée et il faut donc indiquer celle-ci dans le rapport final.

Une fois qu'on a bien travaillé et soigneusement fait ses mesures, il est temps de les communiquer à l'utilisateur. C'est l'objet de la section 3.8. Elle insiste sur l'importance d'indiquer le Type-P, les paramètres, la méthode de calibration, etc. Si possible, le chemin suivi par les paquets dans le réseau devrait également être indiqué.

Maintenant, la métrique pour une mesure isolée, un singleton, est définie. On peut donc bâtir sur elle. C'est ce que fait la section 4, qui définit une mesure répétée, effectuée selon une distribution de Poisson, Type-P-One-way-Delay-Poisson-Stream.

Une fois cette métrique définie, on peut créer des fonctions d'agrégation des données, comme en section 5. Par exemple, la section 5.1 définit Type-P-One-way-Delay-Percentile qui définit le délai d'acheminement sous lequel se trouvent X % des mesures (les mesures indéfinies étant comptées comme de délai infini). Ainsi, le 95e percentile indique le délai pour lequel 95 % des délais seront plus courts (donc une sorte de « délai maximum en écartant les cas pathologiques »). La section 5.2 définit Type-P-One-way-Delay-Median qui est la médiane (équivalente au 50e percentile, si le nombre de mesures est impair). La moyenne, moins utile, n'apparait pas dans ce RFC.

Au moins un protocole a été défini sur la base de cette métrique, OWAMP, normalisé dans le RFC 4656 et mis en œuvre notamment dans le programme de même nom.

Le but principal du nouveau RFC (projet documenté dans le RFC 6576) était de faire avancer cette métrique sur le « chemin des normes » (cf. RFC 2026), de « proposition de norme » à « norme [tout court] ». Les tests du RFC 6808 (voir aussi le rapport sur le RFC 2679) ont montré que les métriques Internet étaient sérieuses et utilisables, justifiant cet avancement sur le chemin des normes.

La section 7 décrit les (rares) changements depuis le RFC 2679. Le RFC 6808 notait plusieurs problèmes avec le RFC 2679, problèmes qui ont été traités par ce nouveau RFC 7679. Par exemple, la métrique Type-P-One-way-Delay-Inverse-Percentile, définie dans le RFC 2679 mais jamais mise en œuvre, est abandonnée. D'autre part, une bogue a été corrigée. Les autres changements sont l'introduction des références au RFC sur la publication de mesures, RFC 6703 et à d'autres RFC publiés depuis, ainsi que l'accent plus important sur la protection de la vie privée. Notre nouveau RFC note aussi que le groupe de travail a étudié les conséquences du RFC 6921 (dont vous noterez la date de parution) et conclut que, même avec des délais de propagation négatifs, les métriques décrites ici ne nécessitaient pas de mise à jour.


Téléchargez le RFC 7679


L'article seul

RFC 7748: Elliptic Curves for Security

Date de publication du RFC : Janvier 2016
Auteur(s) du RFC : A. Langley (Google), M. Hamburg (Rambus Cryptography Research), S. Turner (IECA)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF cfrg
Première rédaction de cet article le 24 janvier 2016
Dernière mise à jour le 29 janvier 2016


Ce nouveau RFC est la description de deux courbes elliptiques largement utilisées mais qui n'avaient pas fait l'objet d'une description formelle complète : curve25519 et curve448. Maintenant que c'est fait, elles pourront être utilisées dans des normes Internet utilisant la cryptographie comme TLS ou DNSSEC.

La cryptographie sur les courbes elliptiques est une alternative aux algorithmes traditionnels fondés sur la décomposition en facteurs premiers, comme le classique RSA. Il est toujours bon de ne pas mettre tous ses œufs dans le même panier, car on ne sait jamais quelle sera la prochaine victime de la cryptanalyse (d'où le RFC 7696, sur l'importance de ne pas être prisonnier d'un seul algorithme). Grâce aux courbes elliptiques, si RSA est cassé complètement, on aura une solution de rechange. En outre, la cryptographie sur les courbes elliptiques a des propriétés intéressantes, comme des clés de taille plus petite. Dans les deux cas, RSA ou courbes elliptiques, je n'y connais pas grand'chose donc n'espérez pas des explications plus pointues.

Le schéma général de la cryptographie sur courbes elliptiques est décrit dans le RFC 6090 (voir aussi le cours « SEC 1: Elliptic Curve Cryptography »). Ce schéma permet l'utilisation d'une infinité de courbes elliptiques mais attention, toutes n'ont pas les propriétés requises. La plus connue est la courbe P-256 normalisée par le NIST. Comme il y a de très bonnes raisons de se méfier du NIST (leur rôle dans l'affaiblissement délibéré de Dual EC DRBG, cf. l'article de Schneier et celui de Greenemeier), et comme les raisons des choix des paramètres de P-256 n'ont jamais été rendues publiques, beaucoup de gens se méfient de P-256 (voir une bonne discussion sur StackExchange). Il est donc important, là encore, d'avoir plusieurs fers au feu, et de disposer d'autres courbes.

Les deux courbes décrites dans ce RFC sont curve25519 et curve448. Elles sont de la famille des courbes de Montgomery (et donc ont une équivalence avec une courbe d'Edwards).

Il n'est pas facile de faire des maths dans un RFC, avec leur format actuel. La section 3 décrit la notation utilisée dans le RFC, mais je ne vais pas reproduire les équations ici (je suis complètement ignorant de MathML et ce blog ne le gère pas). Des formules comme (section 4.1) :

     (u, v) = ((1+y)/(1-y), sqrt(-486664)*u/x)
     (x, y) = (sqrt(-486664)*u/v, (u-1)/(u+1))
    

sont nettement moins jolies dans le texte brut des RFC.

La section 4 du RFC décrit les deux courbes. Curve25519 doit son nom au fait qu'un des nombres premiers utilisés pour la génération des paramètres de la courbe est 2^255-19. Sa description originale est dans l'article de Bernstein « Curve25519 -- new Diffie-Hellman speed records », et son équivalent en courbe d'Edwards, ed25519 dans « High-speed high-security signatures ».

L'autre courbe, curve448, utilise le nombre premier 2^448-2^224-1. La courbe d'Edwards équivalente est nommée Goldilocks et est décrite dans « Ed448-Goldilocks, a new elliptic curve ».

La section 5 du RFC présente les fonctions X25519 et X448, utilisées pour faire du Diffie-Hellman avec ces courbes. Des vecteurs de test sont également fournis, si vous voulez vérifier votre implémentation (rappel au passage : il y a plein de pièges quand on programme de la crypto.)

En parlant de Diffie-Hellman, la section 6 est la description de l'utilisation de ces deux courbes pour un échange de clés ECDH, utilisant les deux fonctions de la section précédente.

Quelle est la sécurité de ces deux courbes (section 7) ? Le niveau de sécurité de curve25519 lors d'une attaque par force brute est d'un peu moins de 128 bits. Une attaque par force brute est normalement l'essai de toutes les clés possibles. Toutefois, le terme est souvent utilisé en cryptographie (avec un abus de langage) pour désigner des méthodes où on fait beaucoup d'essais, sans forcément tester toutes les clés (comme l'algorithme rho). D'autre part, le RFC rappelle qu'il n'est pas facile de comparer des algorithmes de cryptographie, surtout entre algorithmes symétriques et asymétriques, cf. l'article de Bernstein « Understanding brute force ».)

curve448 est normalement « meilleure », avec 224 bits de sécurité (mais plus lente : on n'a rien sans rien). Le RFC note que, pour des ordinateurs quantiques (si on en a un jour...), les deux courbes seront aussi faciles à casser l'une que l'autre. En attendant, curve25519 est parfaitement suffisant.

Notez que, si vous aimez la cryptographie quantique et les discussions sans fin, la NSA a publié en août 2015 un texte qui a stupéfié beaucoup de monde car il affirmait que, vu l'arrivée supposée proche des calculateurs quantiques, il n'était pas recommandé de faire des efforts pour migrer depuis RSA vers les courbes elliptiques. Certains en ont déduit que la NSA avait déjà des calculateurs quantiques et savaient donc que les courbes elliptiques étaient cassées ou proches de l'être, d'autres ont supposé que, si la NSA essayait de décourager les utilisateurs de se servir des courbes elliptiques, c'était au contraire une raison supplémentaire pour migrer vers ces courbes au plus vite. La polémique et l'état des informations disponibles sont très bien expliqués dans l'article « A riddle wrapped in an enigma ».

L'annexe A du RFC décrit comment les paramètres de ces deux courbes ont été générés. Des courbes comme la P-256 du NIST ou comme la courbe elliptique souveraine FRP256 de l'ANSSI ont été très critiquées car les différentes constantes utilisées sont juste annoncées, sans explication. Il n'y a pas besoin d'être excessivement paranoïaque, ou d'avoir lu les documents publiés par Snowden, pour se demander « Pourquoi ces valeurs plutôt que d'autres ? Ne serait-ce pas parce que ces constantes ont des propriétés qui facilitent leur décryptage par la NSA ou un organisme similaire ? ». Il y a consensus aujourd'hui pour dire qu'on ne doit utiliser que des courbes pour lesquelles le choix des paramètres a été fait « objectivement », selon une méthodologie expliquée et vérifiable. C'est ce que fait l'annexe A.

Notez que les paramètres des deux courbes de ces RFC n'ont pas été choisis complètement « objectivement ». Ils ont fait l'objet d'« optimisations », notamment pour des raisons de performance. Si on veut une courbe générée entièrement par un algorithme objectif et publiquement vérifiable, il faudra se tourner (elle est très récente) vers des courbes « publiquement vérifiables » comme la « courbe d'un million de dollars », qui proclame être « a procedure, more than a curve ».

Maintenant que ces courbes font l'objet d'une documentation complète, il sera plus facile de les utiliser depuis un protocole IETF (ceci dit, elles sont déjà dans au moins une norme, voir RFC 7479). Plusieurs travaux sont en cours pour cela ; il y avait un Internet-Draft pour permettre curve25519 dans TLS, draft-ietf-tls-curve25519 mais il a été remplacé par le plus général draft-ietf-tls-rfc4492bis, actuellement en cours de discussion. Un autre Internet-Draft traite le cas de DNSSEC, draft-sury-dnskey-ed25519.

Notez que les deux courbes de ce RFC sont décrites selon un formalisme qui ne permet pas de les utiliser telles quelles dans un algorithme comme ECDSA (explications sur StackOverflow). Mais on peut avec EdDSA.

OpenSSH dispose de curve25519 depuis la version 6.5. (« Add support for key exchange using elliptic-curve Diffie Hellman in Daniel Bernstein's Curve25519. This key exchange method is the default when both the client and server support it. [...] Add support for Ed25519 as a public key type. Ed25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys. »). Dans les sources d'OpenSSH, ce sont les fichiers ayant 25519 dans leur nom :

/tmp/openssh-7.1p2 %   ls *25519*
ed25519.c  fe25519.c  fe25519.h  ge25519_base.data  ge25519.c  ge25519.h  kexc25519.c  kexc25519c.c  kexc25519s.c  sc25519.c  sc25519.h  smult_curve25519_ref.c  ssh-ed25519.c

Pour générer des clés utilisant cette courbe, on utilise le classique ssh-keygen :

% ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
...
Your identification has been saved in /home/stephane/.ssh/id_ed25519.
Your public key has been saved in /home/stephane/.ssh/id_ed25519.pub.
...      
    

Par contre, ces courbes ne sont pas encore dans OpenSSL (voir la discussion #309). Autrement, on trouve des mises en œuvre de curve25519 à plein d'endroits : https://github.com/msotoodeh/curve25519, https://code.google.com/p/curve25519-donna/ et bien sûr http://cr.yp.to/ecdh.html et https://nacl.cr.yp.to/.

Merci à Patrick Mevzek pour son exploration d'OpenSSH et OpenSSL, à Émilien Gaspar pour les discussions et à Manuel Pégourié-Gonnard pour des corrections, notamment sur la force brute.


Téléchargez le RFC 7748


L'article seul

RFC 7723: Port Control Protocol (PCP) Anycast Addresses

Date de publication du RFC : Janvier 2016
Auteur(s) du RFC : S. Kiesel (University of Stuttgart), R. Penno (Cisco Systems), S. Cheshire (Apple)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF pcp
Première rédaction de cet article le 23 janvier 2016


Le protocole PCP, normalisé dans le RFC 6887, permet à une machine de signaler à la box, au routeur CPE, au pare-feu, ses désirs en terme d'ouverture de ports, d'obtention d'information sur l'adresse IP externe, etc. Mais comment l'ordinateur de M. Michu trouve t-il l'adresse du serveur PCP ? Une des solutions est celle introduite par ce RFC : une adresse anycast « bien connue », 192.0.0.9 en IPv4 et 2001:1::1 en IPv6.

Souvent, l'adresse IP du serveur PCP est évidente : c'est l'adresse du routeur par défaut. Mais il y a des cas plus compliqués, par exemple en cas de CGN (section 1 du RFC). Avant notre RFC 7723, les seules autres solutions étaient la configuration manuelle, ou une option DHCP (RFC 7291).

Ce nouveau RFC ajoute une possibilité : le client PCP écrit tout simplement à l'adresse bien connue, 192.0.0.9 ou 2001:1::1, et le serveur PCP approprié répondra. L'anycast s'occupera de router le message du client au bon serveur. Une simple diffusion n'aurait pas suffi : le serveur PCP n'est pas forcément sur le réseau local (notamment en cas de CGN). Avec l'anycast, il n'y a pas besoin d'installer quoi que ce soit de particulier dans le réseau local ou les équipements CPE. Et l'adresse bien connue étant immuable, on peut la mettre en dur dans les applications PCP, sans avoir besoin de l'obtenir du système d'exploitation. (Personnellement, je trouve cela un peu optimiste : comme cette option anycast est nouvelle, et qu'elle ne sera pas forcément déployée partout, l'application aura toujours besoin d'un « plan B » en demandant au système d'exploitation « une idée de l'adresse IP du serveur PCP ? »)

Le comportement du client et du serveur PCP est décrit dans la section 2 du RFC. La liste des serveurs PCP possibles pour le client (section 8.1, étape 2 du RFC 6887) s'enrichit des adresses anycast bien connues. Le traitement de cette liste continue à suivre la norme PCP du RFC 7488. Le serveur, lui, a juste à écouter sur les adresses anycast bien connues, en plus de ses adresses habituelles. Le RFC ne le mentionne apparemment pas, mais l'administrateur réseaux doit aussi évidemment configurer le routage pour que la route vers le serveur PCP soit annoncée partout, et appliquée.

L'anycast peut être déroutant au début pour les administrateurs réseaux et la section 3 du RFC rappelle donc quelques règles de déploiement (en plus des documents existants sur l'anycast, RFC 4786 et RFC 7094). Par exemple, si le réseau a deux connexions vers l'extérieur, chacune avec son propre serveur PCP, l'anycast ne va pas forcément aider car le message PCP du client ne sera reçu que par un seul des deux serveurs (même si tous les serveurs ont été configurés pour écouter sur l'adresse anycast).

Si le routage est toujours symétrique, ce n'est pas un problème, car le serveur PCP qui recevra le message envoyé à l'adresse anycast est également celui qui verra passer tout le trafic, et pourra donc faire ce qui lui a été demandé par le client PCP. Même si le routage change, et qu'on passe subitement par un autre lien, avec un autre serveur PCP, ce n'est pas grave (c'est l'équivalent du redémarrage d'un serveur PCP, cas qui est géré par les clients PCP).

Mais, si le routage est asymétrique... Eh bien, dans ce cas, c'est fichu, c'est une limite de PCP plus que de ces adresses anycast. La seule solution est de développer un mécanisme (qui n'existe pas encore) pour synchroniser deux serveurs PCP.

La section 4 de notre RFC rappelle les enregistrements des deux adresses à l'IANA, dans les registres d'adresses spéciales IPv4 et IPv6.

(Les fanas de sécurité peuvent lire la section 5 mais il n'y a pas grand'chose à dire d'original : les messages PCP, anycast ou pas, peuvent être attaqués comme tous les autres paquets IP, ni plus, ni moins.)

Pour l'instant (PCP est, de toute façon, très peu déployé), je ne crois pas que quiconque utilise déjà ces adresses anycast.


Téléchargez le RFC 7723


L'article seul

RFC 7745: XML Schemas for Reverse DNS Management

Date de publication du RFC : Janvier 2016
Auteur(s) du RFC : T. Manderson (ICANN)
Pour information
Première rédaction de cet article le 21 janvier 2016


Ce court RFC décrit un schéma XML qu'utilise l'ICANN pour gérer les zones DNS dans les domaines ip6.arpa et in-addr.arpa. Rien de standard, juste la documentation d'une pratique locale.

Depuis 2011, l'ICANN utilise ce système pour gérer et produire les zones DNS dont elle a la responsabilité sous .arpa (in-addr.arpa est documenté dans le RFC 1034 et ip6.arpa dans le RFC 3152). L'ICANN délègue des zones aux RIR et ceux-ci souhaitent un système le plus fiable, simple et prévisible possible.

La gestion de ces zones se faisait, il y a fort longtemps, à la main, avec un éditeur ordinaire, mais cela n'est évidemment plus possible depuis le déploiement de DNSSEC : les clés changent, les enregistrements DS (Delegation Signer) doivent être mis à jour, etc. Et la plus petite erreur casse la validation cryptographique. Bref, pour ce service comme pour d'autres, DNSSEC pousse fortement à automatiser sérieusement les processus.

Le principe de base (section 3, le gros du RFC) est que le RIR prépare sa demande sous forme d'un fichier XML conforme au schéma décrit dans ce RFC, et l'envoie à l'ICANN par une requête REST. Elle est évidemment en HTTPS et authentifiée par un certificat client (et un pour le serveur, également). L'AC est l'ICANN elle-même. Recevant le XML, l'ICANN met à jour automatiquement les zones sous .arpa.

En bonne logique REST, les requêtes HTTP sont GET, PUT et DELETE. GET sert à interroger l'état actuel de la base (et le RIR n'utilise donc que l'URI, il n'envoie pas de XML).

Voici un exemple d'une requête en XML qui pourrait être envoyée (requête PUT) pour mettre à jour la zone 10.in-addr.arpa, avec deux enregistrements DS (pour la même clé, la 33682) :


<zone xmlns="http://download.research.icann.org/rdns/1.1"
     name="10.in-addr.arpa" cust="IANA" ipversion="ipv4"
     version="1.1" modified="2012-01-18T01:00:06"
     state="active" href="https://host.example.org/ipv4/10">
     <nserver>
       <fqdn>BLACKHOLE-1.IANA.ORG.</fqdn>
     </nserver>
     <nserver>
       <fqdn>BLACKHOLE-2.IANA.ORG.</fqdn>
     </nserver>
     <ds>
       <rdata>33682 5 1 ea8afb5fce7caf381ab101039</rdata>
     </ds>
     <ds>
       <rdata>33682 5 2 7d44874f1d93aaceb793a88001739a</rdata>
     </ds>
   </zone>	       

    

Notez que la modification n'est pas forcément instantanée : il peut y avoir un système de vérification manuelle et d'approbation explicite.

Les URL utilisés par le client sont variables. Par exemple, pour mettre à jour le domaine 10.in-addr.arpa cité plus haut, l'URL serait http://icann.example/4/10.in-addr.arpa (en remplaçant icann.example par le vrai nom du serveur REST à l'ICANN). Pour avoir une liste des demandes en attente (rappelez-vous que le système n'est pas synchrone), le client ferait un GET sur http://icann.example/queuelist, etc.

Les annexes A et B du RFC donnent le schéma Relax NG complet des éléments XML possibles. Par exemple, une zone DNS se définit ainsi :

      
   # A single zone record
   zone = element zone {
     # The zone record's name, eg 10.in-addr.arpa
     attribute name { text },
     ...
     # The administrative state of the zone (optional)
     attribute state { "active" | "pending" | "error" }?,
     # The last modified timestamp in UTC (optional)
     attribute modified  { xsd:dateTime }?,
     ...
     # A zone NS RRset MUST have at least two NS records
     nserver,
     nserver+,
     # It MAY contain some DS records
     ds*
   }

    

À noter que ce schéma ne permet pas d'indiquer de la colle (adresses IP de serveurs de noms situés dans la zone elle-même) puisqu'il ne sert que pour les zones sous .arpa (on ne voit jamais de serveurs de noms nommés ainsi).

Pourquoi développer un tel système plutôt que d'utiliser la norme EPP ? Le RFC ne le dit pas mais on peut supposer que c'est parce qu'EPP est bien plus complexe.


Téléchargez le RFC 7745


L'article seul

Deux flux de syndication, avec et sans TLS

Première rédaction de cet article le 17 janvier 2016
Dernière mise à jour le 23 janvier 2016


Il y a un vieux problème sur ce blog, qui se pose depuis que j'ai activé l'accès en HTTPS : les flux de syndication ne fonctionnaient pas avec un grand nombre d'agrégateurs. J'ai contourné le problème en ayant désormais deux flux, un en HTTPS et un sans.

Quel est le problème ? Comme j'utilise une AC gratuite et automatique, CAcert, qui n'est pas dans tous les magasins de certificats, loin de là, je ne peux pas forcer l'usage de HTTPS, cela perturberait trop de lecteurs. (Pourtant, j'ai publié des enregistrements DANE mais, malheureusement, il y a encore bien des navigateurs qui, bêtement, ne les utilisent pas. Demandez aux auteurs de votre navigateur et dites-leur bien que DANE est la bonne solution à ce problème.)

Pour les flux de syndication Atom, j'avais pensé résoudre le problème en utilisant des liens « presque absolus ». Ces liens commencent par deux barres obliques, par exemple //www.bortzmeyer.org/toot.html et le logiciel client est supposé, pour le plan (http: ou https:) utiliser le même plan que celui utilisé pour récupérer le fichier où il y avait ces liens.

Avec tous les navigateurs Web, ça marche, le navigateur ajoute http: ou https: selon l'URL utilisé pour récupérer la ressource originale. J'ai malheuresement constaté que ce n'était pas le cas avec les agrégateurs de syndication. De nombreux agrégateurs ne comprennent pas ces liens, et font, par exemple, des requêtes pour une ressource //www.bortzmeyer.org/toot.html, ce qui produit une erreur 404. Le problème semble affecter, entre autres, Liferea ou spaRSS. Certains agrégateurs ont corrigé (Netvibes) mais d'autres trainent la patte.

Qui a raison ? Ce n'est pas évident. La syntaxe des URI est normalisé par le RFC 3986, qui semble autoriser ces URI relatifs commençant par deux barres obliques (section 4.2 du RFC, « A relative reference that begins with two slash characters is termed a network-path reference », et l'exemple //g en 5.4.1). Ces URI « double slash » sont également appelés « protocol-relative URIs » ou « protocol-less URIs », termes tout à fait erronés puisque le plan n'est pas forcément un protocole, « scheme-relative URIs » serait un meilleur terme. De toute façon, personnellement, je trouve le RFC peu clair sur ce point : ces URI sont légaux mais leur sémantique est mal expliquée. En attendant, le RFC sur Atom (RFC 4287) semble décourager l'usage de liens non-absolus (sections 4.2.7.1 et 4.2.6). (Pour RSS, les liens non-absolus sont clairement interdits car RSS n'a pas de notion d'« URL de base », contrairement à Atom.)

Un autre inconvénient de ces liens presques absolus étaient qu'ils ne donnent pas le résultat attendu si le flux Atom a été récupéré par un autre moyen que HTTP ou HTTPS (par exemple un fichier sur le disque local).

Plutôt que d'essayer de faire corriger tous les agrégateurs, j'ai préféré offrir le choix au lecteur, qui va donc devoir manuellement sélectionner le flux qu'il préfère.

Voici donc les quatre flux Atom. Il y a en effet le choix entre TLS ou pas (pour la sécurité et la vie privée) et article complet ou pas :

Merci à tous les signaleurs de bogue et notamment à Styx.


L'article seul

Un OS souverain, c'est quoi, et ça mène à quoi ?

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


La commission des lois de l'Assemblée Nationale a voté le 13 janvier le principe de la création d'un « OS souverain », et cet amendement a été confirmé par le vote de l'Assemblée les 20 et 21 janvier (voir l'actuel texte consolidé). Si cette initiative ni réfléchie, ni étudiée, a, à juste titre, déclenché l'hilarité de Twitter, c'est l'occasion d'expliquer ce que cela veut dire et où ça mène.

L'idée est en effet ancienne, dans tous les endroits où se promènent des Excellences et des gourous à ministres, on entend ce projet, en général jamais explicité et jamais détaillé. Comme les zombies dans les jeux vidéo, cette idée est très difficile à tuer et renait tout le temps. C'est en bonne partie parce qu'il n'y a aucun cahier des charges digne de ce nom : juste un slogan creux.

Mais imaginons qu'on cherche un peu. Qu'est-ce que pourrait être un OS souverain et pourquoi est-ce que ce serait une mauvaise idée ?

D'abord, questionnons un peu ce qu'on entend par « OS ». Le terme de « système d'exploitation » (OS = Operating System dans la langue d'Edgar Hoover) peut désigner deux choses en français :

  • Le logiciel qui parle directement au matériel et présente ensuite aux applications une vue abstraite de ce matériel. C'est ce sens qui est utilisé quand on dit « Linux est un système d'exploitation ».
  • L'ensemble des logiciels livrés ensemble, avec le noyau, les bibliothèques, un certain nombre d'applications de base, etc. C'est le sens de « système d'exploitation » dans la phrase « Windows est un système d'exploitation ».

Rappelez-vous, l'Assemblée a voté un projet sans définir ce qu'elle entendait par là. On va donc supposer que c'est le deuxième sens, celui d'un ensemble complet, permettant à des gens ordinaires de commencer à travailler.

Si c'est bien le cas, c'est une tâche colossale et, franchement, déraisonnable. Cela représente une quantité de logiciels astronomique, que ne peuvent réaliser que de très grosses entreprises comme Microsoft, ou bien les myriades de développeurs du logiciel libre. Le futur « Commissariat à la Souveraineté Numérique » n'aura certainement pas les moyens de financer un tel développement. Clamer « on va écrire un système d'exploitation » est donc une vantardise ridicule.

Peut-être qu'il y aura simplement adaptation d'un système d'exploitation existant ? Prendre un système qui existe, par exemple en logiciel libre, modifier deux ou trois choses et lui coller un drapeau tricolore sur l'écran de démarrage ? Techniquement, c'est plus raisonnable. C'est ce qu'ont fait des États soucieux de souveraineté comme la Corée du Nord avec Red Star OS, ou bien l'administration française avec CLIP (non cité à l'Assemblée : la main droite de l'État ignore ce que fait sa main gauche). Il existe plein de systèmes existants qui pourraient servir de base pour éviter de réinventer la roue (réinvention qu'adorent les députés, ainsi bien sûr que les gagneurs de marchés publics habituels). On peut citer, entre autres :

On ne peut plus alors dire « on va développer un OS souverain » mais, est-ce que, sur le fond, le résultat ne serait pas le même ?

Dans l'hypothèse où ce soit la stratégie suivie, quelles modifications pourraient être apportées au système existant ? C'est là que commencent les problèmes politiques : soucieux d'unanimité, les députés n'ont pas expliqué ce point. Pas la moindre plus petite ébauche de liste des fonctions souhaitées, dans l'amendement voté à l'Assemblée. Essayons de faire le travail des députés. Un tel système pourrait permettre :

  • De ne pas envoyer toutes les données personnelles à Google, contrairement à ce que fait Android,
  • De fournir des outils de chiffrement solides et faciles à utiliser, immédiatement disponibles,
  • D'avoir des portes dérobées permettant à l'État de lire nos communications,
  • De mettre en œuvre dans le code les lois et règlements français, par exemple en incorporant le filtrage imposé par les ayant-trop-de-droits,
  • De gérer proprement Unicode partout, afin de pouvoir écrire correctement le français et les langues de France (chose qui est difficile avec Windows).

Ce n'est qu'une liste partielle. Mes lecteurs ont certainement plein d'autres idées intéressantes. Mais le point important de cette liste est que, toute partielle qu'elle soit, elle est déjà très contradictoire. C'est en effet le problème de fond avec la souveraineté : il s'agit de la souveraineté de qui ? Du citoyen qui veut se protéger ? De l'État qui veut tout voir et tout entendre ? Le futur système d'exploitation souverain offrira-t-il du chiffrement solide de bout en bout ou bien facilitera-t-il la surveillance des utilisateurs ? Ça, c'est une vraie question politique, et c'est normalement le travail des députés. Qu'ils ne l'aient pas discuté dans leur amendement illustre bien leur manque de sérieux.

D'autant plus qu'écrire un tel « OS souverain » n'est pas tout. Encore faut-il que les gens l'utilisent. En Corée du Nord, citée plus haut, pas de problème, il suffit qu'on leur demande gentiment et tous les citoyens le font. Mais en France ? Il faudrait convaincre les citoyens et cela sera difficile si on leur dit juste « c'est un fantasme de Pierre Bellanger, installez-le, ça lui fera plaisir. » Après tout, il n'y a aucune demande des utilisateurs.

Les députés eux-mêmes seront sans doute les plus réticents : ils crient bien fort à la tribune qu'ils veulent de la souveraineté numérique, mais les rares parmi eux qui répondent aux courriers électroniques le font depuis une adresse Yahoo ou Gmail. Jamais ils ne se dégooglisent, mais ils voudraient dégoogliser les autres.

Une administration particulièrement difficile à convaincre sera l'Éducation Nationale : comme elle a signé un accord scandaleux avec Microsoft, elle n'utilisera sans doute pas l'« OS souverain » (sur lequel il y a peu de chances que Microsoft porte ses applications...).

Enfin, il faut noter que l'expérience ne sert à rien : après les sommes faramineuses englouties dans l'escroquerie nommée « cloud souverain » (alors qu'il existait déjà plusieurs acteurs français du cloud), on pourrait s'attendre à d'avantage de précautions de la part de l'État, et à une analyse du passé, avant de prétendre influencer l'avenir... Sans compter l'expérience récente de Louvois, qui laisse des doutes sur la capacité de l'État français à gérer des grands projets informatiques.

Que va donner le projet actuel ? Verrons-nous naître le « Commissariat à la Souveraineté Numérique » ? Réalisera-t-il le fameux « OS souverain » ? Je vois cinq scénarios possibles :

  • Tout cela sera oublié dans un mois. C'est juste un de ces votes habituels des politiques, pour faire un peu de buzz, sans suite dans les idées.
  • Il y aura bien un début de réalisation mais cela n'ira pas très loin, peut-être juste la production d'une image Fedora avec un logo différent (genre coq).
  • Selon un mécanisme plus proche de celui du projet « cloud souverain », beaucoup d'argent public sera dépensé, les habituelles sociétés gagnantes des marchés publics seront sélectionnées, elles remueront beaucoup d'air et, dans dix ans, il faudra constater l'échec du projet. (Mais on continuera à faire des discours, comme si rien n'était arrivé.)
  • Un « OS souverain » sera bien développé, il intégrera portes dérobées, marquage des fichiers, DRM, et son utilisation sera rendue obligatoire par la loi, en utilisant l'émotion créée par le dernier attentat terroriste en date.
  • Le Commissariat à la Souveraineté Numérique, convaincu par l'April et Framasoft, dégage de l'argent et des ressources humaines pour aider au développement de projets existants entièrement libres, comme Debian ou Replicant, systèmes qui permettent la souveraineté de l'utilisateur.

Le scénario 5 semble le moins probable, le 4 serait le pire, il en ferait même souhaiter que ce soit le scénario 3 qui soit réalisé : mieux vaut le gaspillage que la dictature.

Quelques lectures en plus :


L'article seul

RFC 7735: Tracking Reviews of Documents

Date de publication du RFC : Janvier 2016
Auteur(s) du RFC : R. Sparks (Oracle), T. Kivinen (INSIDE Secure)
Pour information
Première rédaction de cet article le 14 janvier 2016


Le processus de production des normes par l'IETF suit de nombreuses étapes, toutes se déroulant en public. Il est en effet essentiel que de nombreux yeux puissent regarder les documents en voie de devenir des RFC. Et que de nombreux examens (reviews) aient lieu. Pour suivre ces examens, il est préférable de disposer d'outils et ce sont les futurs outils à développer que décrit ce RFC.

Parmi les équipes qui effectuent des examens des Internet-Drafts en cours d'avancement figurent Gen-ART et SecDir. Mais il en existe plusieurs autres, parfois très spécialisées, et qui n'examinent que les documents relevant de leur spécialité (par exemple les MIB par les MIB doctors ou bien les schémas YANG par les YANG doctors).

Les équipes en question doivent se tenir au courant des documents en cours, leur affecter un examinateur parmi ceux qui sont enregistrés pour cette tâche, fixer une date limite et relancer l'examinateur s'il est en retard, etc. Cela serait évidemment très pénible à faire à la main et ces équipes utilisent actuellement un outil, développé il y a longtemps. Du fait de son âge, il n'est pas bien intégré avec le principal outil de travail en groupe de l'IETF, le Datatracker. Par exemple, pour obtenir certaines informations, l'outil analyse des pages HTML du Datatracker :-) .

[Au passage, notez que le Datatracker est vraiment un excellent outil, qui facilite beaucoup la vie du participant à l'IETF. On voudrait tous avoir des outils de travail en groupe équivalents au bureau.]

Une meilleure intégration avec le Datatracker permettrait de simplifier l'accès à ces informations, et à d'autres qui ne sont pas utilisées actuellement, car trop pénibles à extraire. Ce nouveau RFC est le cahier des charges du futur outil (voir aussi le système de gestion de tickets de l'outil actuel).

Pour comprendre ce cahier des charges, il est utile de revenir sur l'utilisation actuelle de l'outil des examens (section 2 du RFC). Typiquement, l'équipe a un secrétariat qui, une fois par semaine environ, dresse une liste des documents qui sont prêts à subir un examen, par exemple parce qu'ils sont en IETF Last Call (dernier appel avant approbation) ou parce qu'ils sont sur l'agenda des réunions (virtuelles) de l'IESG.

Le secrétariat prend ensuite un examinateur parmi la liste des examinateurs possibles, en tenant compte de paramètres comme le fait qu'un auteur ne doit évidemment pas être examinateur de son propre Internet-Draft. L'idée est en général de prendre un examinateur qui a un regard neuf et n'a pas été impliqué dans le développement du document.

Les différentes équipes d'examen n'ont pas toutes le même fonctionnement. Certaines, comme indiqué plus haut, s'« auto-saisissent » alors que d'autres sont plutôt en mode « on examine si on nous le demande » (c'est le cas de l'équipe du routage, par exemple).

Les examinateurs eux-même n'utilisent pas en général l'outil directement : ils communiquent par courrier avec le secrétariat. Et c'est par courrier qu'ils envoient le résultat de leur examen, après avoir rempli un « courrier-type ». Voici par exemple l'examen fait par Gen-ART pour le futur RFC sur la QNAME minimisation ou bien celui de RTG-Dir pour un futur protocole d'HomeNet.

Voici donc le fonctionnement actuel. Pour le futur outil, les exigences sont dans la section 3 de notre RFC. D'abord, ce qui intéresse le secrétariat de l'IETF (section 3.1) :

  • Le secrétariat doit pouvoir configurer une équipe,
  • Et doit pouvoir effectuer toute action à la place du secrétariat de l'équipe (en cas de défaillance de celui-ci).

Plus importantes, les exigences pour le secrétariat de l'équipe d'examen (section 3.2), entre autres :

  • Pouvoir voir quels documents sont dans un état donné (par exemple IETF Last Call),
  • Possibilité de sélectionner les documents à examiner, soit automatiquement (« tous ceux qui sont sur l'agenda de l'IESG »), soit manuellement (ajouter explicitement un document intéressant),
  • Permettre les accès concurrents à l'outil (une équipe peut avoir plusieurs secrétaires),
  • Faciliter l'envoi des courriers, par exemple en remplissant automatiquement un gabarit, puis en permettant au secrétaire de faire des modifications, avant envoi,
  • Pouvoir voir les examinateurs libres,
  • Capacité à gérer les disponibilités des examinateurs (par exemple, on doit pouvoir indiquer « Machin ne sera pas libre avant le 2 février » et il ne doit alors pas être présenté dans la liste des examinateurs potentiels),
  • Gérer automatiquement l'exclusion des examinateurs de certains documents. L'outil actuel utilise une expression rationnelle. M. Michu, examinateur qui est très investi dans le groupe de travail DPRIVE, aura une expression d'exclusion pour les documents nommés ^draft-(michu|ietf-dprive).*, l'excluant de ses drafts et de ceux de DPRIVE,
  • Permettre le suivi des examens (certains examinateurs sont très occupés, peuvent « oublier » leur tâche, etc),
  • Par la même occasion, l'outil doit permettre de suivre les « performances » des examinateurs (afficher le retard moyen...) de manière à détecter les « maillons faibles »,
  • Autoriser le changement d'examinateur, l'ajout d'un examinateur...

Et pour l'examinateur lui-même, que doit savoir faire l'outil (section 3.3) ? Par exemple :

  • Il doit permettre à l'examinateur d'indiquer ses disponibilités, à la fois en dates (« en vacances tout le mois d'août ») et en fréquence (« pas plus d'un examen de document par trimestre »), avec notification du secrétariat par courrier,
  • L'examinateur doit avoir accès aux documents qui lui sont affectés, avec leur état, pour suivre son propre travail,
  • Possibilité de rejeter une affectation, avec explication optionnelle (et, là aussi, notification du secrétariat),
  • De même, l'examinateur doit pouvoir indiquer explicitement qu'il accepte une affectation,
  • Rappels automatiques (« il te reste 24 h pour ton examen du draft draft-ietf-cuterabbit-security-analysis-09.txt »),
  • Et bien sûr, puisque c'est le but de l'examen, l'examinateur doit pouvoir soumettre facilement le texte final, par un formulaire Web ou en téléversant un fichier, le texte étant alors automatiquement envoyé aux auteurs et au groupe de travail concerné,
  • Et cette soumission doit aussi être possible par courrier, pour les examinateurs qui sont allergiques au Web (c'est possible avec les bons outils de gestion de tâche, comme RT).

Comme tout le monde aime les statistiques, et qu'il est bon de pouvoir évaluer si une équipe d'examen marche bien ou pas, l'outil devra également fournir des chiffres (section 3.5) :

  • Pour une période donnée, indiquer combien d'examens ont été faits, combien sont en cours, combien ont été en retard et de combien, le temps moyen d'examen,
  • Mêmes résultats, mais pour un examinateur donné,
  • Ces chiffres doivent pouvoir être pondérés par des caractéristiques du document (notamment sa taille, mesurée en nombre de signes),
  • Et, autant que possible, ces statistiques, par exemple le nombre d'examens faits par un examinateur par an devraient pouvoir tenir compte des périodes d'indisponibilité,
  • Et si l'outil pouvait faire des jolis graphes avec les séries temporelles, ce serait encore mieux,
  • L'accès à ces chiffres doit être limité : le secrétariat d'une équipe peut tout voir pour son équipe, un examinateur peut voir ses résultats, ou bien les résultats globaux de son équipe,

Les outils actuels de l'IETF sont écrits en Django. Pour rendre ce cahier des charges plus concret, l'annexe A fournit un modèle Django tout prêt. Par exemple, l'état d'un examen peut être :

 class ReviewRequestStateName(NameModel):
     """ Requested, Accepted, Rejected, Withdrawn, Overtaken By Events,
         No Response , Completed  """
      

Un examinateur est ainsi modélisé :

class Reviewer(models.Model):
     """
     These records associate reviewers with review team, and keeps track
     of admin data associated with the reviewer in the particular team.
     There will be one record for each combination of reviewer and team.
     """
     role        = models.ForeignKey(Role)
     frequency   = models.IntegerField(help_text=
                                   "Can review every N days")
     available   = models.DateTimeField(blank=True,null=True, help_text=
                         "When will this reviewer be available again")
     filter_re   = models.CharField(blank=True)
     skip_next   = models.IntegerField(help_text=
                          "Skip the next N review assignments")
      

Et une demande d'examen est :

 class ReviewRequest(models.Model):
     """
     There should be one ReviewRequest entered for each combination of
     document, rev, and reviewer.
     """
     # Fields filled in on the initial record creation:
     time          = models.DateTimeField(auto_now_add=True)
     type          = models.ReviewTypeName()
     doc           = models.ForeignKey(Document,
                            related_name='review_request_set')
     team          = models.ForeignKey(Group)
     deadline      = models.DateTimeField()
     requested_rev = models.CharField(verbose_name="requested_revision",
                             max_length=16, blank=True)
     state         = models.ForeignKey(ReviewRequestStateName)
     # Fields filled in as reviewer is assigned, and as the review
     # is uploaded
     reviewer      = models.ForeignKey(Reviewer, null=True, blank=True)
     review        = models.OneToOneField(Document, null=True,
                                                    blank=True)
     reviewed_rev  = models.CharField(verbose_name="reviewed_revision",
                                      max_length=16, blank=True)
     result        = models.ForeignKey(ReviewResultName)
      

Vous avez envie de réaliser cet outil ? L'annonce a été publiée le 28 décembre 2015 et vous avez jusqu'au 18 janvier 2016 pour proposer vos services.


Téléchargez le RFC 7735


L'article seul

RFC 7713: Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements

Date de publication du RFC : Janvier 2016
Auteur(s) du RFC : M. Mathis (Google), B. Briscoe (BT)
Pour information
Réalisé dans le cadre du groupe de travail IETF conex
Première rédaction de cet article le 6 janvier 2016


Le projet ConEx de l'IETF vise à développer des mécanismes permettant à l'émetteur de paquets IP de prévenir le réseau situé en aval que ce flot de données rencontre de la congestion. Les routeurs pourront alors éventuellement prendre des décisions concernant ce flot. Ce nouveau RFC expose le mécanisme abstrait de signalisation (le mécanisme concret, dans des protocoles comme TCP, sera normalisé plus tard).

La spécification se fait donc en trois temps, décrire le problème et les scénarios d'utilisation (RFC 6789), décrire un mécanisme de signalisation de la congestion abstrait, sans se soucier des détails techniques (ce RFC 7713), puis enfin normaliser le protocole concret (travail en cours), avec les inévitables compromis que cela impliquera.

Aujourd'hui, les équipements réseau comme les routeurs signalent la congestion vers l'aval, en utilisant ECN (RFC 3168), en retardant les paquets (car les files d'attente mettent du temps à se vider) ou, tout simplement, en laissant tomber des paquets. Ce signalement arrive au récepteur qui peut alors informer l'émetteur, par exemple en réduisant la fenêtre, dans TCP. Cette boucle de rétroaction préserve l'Internet de la congestion (RFC 5681). (De ces trois signaux, le temps d'acheminement est le moins utilisé, car il n'est pas un indicateur univoque de la congestion.)

Mais ce signalement n'est pas visible de tous les équipements réseau traversés par ce flot de paquets. Ceux situés en amont du premier routeur qui détecte la congestion ne sont pas prévenus, alors qu'ils auraient pu jouer un rôle. Le rôle de ConEx est justement que tout le monde soit informé. Le principe de base est que l'émetteur, une fois prévenu de la congestion, mette dans les paquets qu'il envoie un indicateur que ce flot rencontre de la congestion quelque part sur le trajet.

Pour que ConEx soit déployé, il faudra que les gens y trouvent un avantage, surtout au début où le déploiement sera limité. Ce problème est commun à tous les nouveaux protocoles mais il sera encore plus crucial pour un protocole qui permettra de signaler les gros consommateurs... Ceux-ci pourraient se retrouver pénalisés (« vos flots signalent tous de la congestion, vous devriez ne les lancer qu'aux heures creuses ») ou poussés à utiliser des protocoles moins gourmands comme LEDBAT (RFC 6817).

ConEx semblait moins nécessaire autrefois car les protocoles comme TCP étaient conçus pour limiter la congestion, en se calmant dès qu'ils la détectaient. Un problème jamais résolu était celui de machines qui ignorent délibérement cet objectif et, par exemple, utilisent des protocoles de transport qui maximisent le débit individuel et tant pis pour le reste de l'Internet. Difficile de lutter contre cet égoïsme. Il pourrait être contagieux puisque les bons citoyens se trouveraient alors défavorisés, et seraient donc tentés de suivre la voie égoïste à leur tour, poussant les gros consommateurs à faire des protocoles encore plus agressifs, etc. L'IETF a toujours découragé ces pratiques (comme celle d'ouvrir plusieurs connexions TCP simultanées pour avoir une plus grosse part du gâteau) avec un succès variable.

ConEx est une approche complémentaire : les gens peuvent consommer de la capacité réseau mais ils doivent le signaler.

Comme une des conséquences de ce signalement pourrait être un traitement différencié du flot en question (« il encombre le réseau, je le limite »), une partie importante du projet ConEx est de s'assurer qu'il n'y aura pas de triche (par exemple d'émetteur « négligeant » d'informer le réseau des problèmes qu'il pose). Les signaux ConEx doivent donc être auditables, pour détecter les tricheurs. (Voir Briscoe, « Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork »).

Une dernière chose avant d'attaquer le cahier des charges exact de ConEx, le vocabulaire :

  • Transport qui ne peut pas faire du ConEx (Not-ConEx) : un mécanisme de transport des données qui ne connait pas du tout ConEx, ce qui est le cas de la totalité des mécanismes actuels.
  • Transport qui peut faire du ConEx (ConEx-capable) : les futurs mécanismes de transport qui sauront faire du ConEx.
  • Signal ConEx : quelque chose dans un paquet (transporté par un mécanisme capable de faire du ConEx) qui indique soit une perte de paquets (signal Re-Echo-Loss), soit une marque ECN (signal Re-Echo-ECN), soit que l'émetteur s'attend à déclencher de la congestion bientôt, par exemple parce qu'il démarre et teste la capacité du réseau (signal Credit), soit qu'il n'a rien à signaler, à part qu'il sait faire du ConEx (signal ConEx-Not-Marked).

La section 3 de notre RFC décrit les exigences précises de ConEx. D'abord, pour les signaux :

  • Le signal ConEx doit être visible par les éléments intermédiaires du réseau comme les routeurs. Il doit donc être mis dans l'en-tête IP, pas enfoui au fin fond du paquet. Il ne doit pas être modifié par ces éléments intermédiaires, l'émetteur met le signal, le reste du réseau ne fait que regarder.
  • Comme le déploiement ne sera pas instantané (et qu'il est très probable, quand on voit le déploiement très limité d'ECN, qu'il ne sera jamais complet), il est important que ConEx soit utilisable, et ait des bénéfices, même en cas de déploiement partiel.
  • Le signal doit être rapidement émis, pour bien rendre compte de la situation actuelle. Le RFC reconnait qu'il faudra évidemment au moins un RTT avant l'émission du signal (et davantage avec RTP, cf. RFC 3550 et RFC 6679).
  • Le signal doit être exact (évidemment...) et auditable, ce qui veut dire qu'un observateur extérieur doit pouvoir le vérifier, afin de détecter d'éventuels tricheurs.

Ces exigences sont parfois contradictoires et le RFC note qu'il faudra sans doute, en passant de ces abstractions à un protocole concret, accepter quelques compromis.

J'ai parlé de l'importance d'auditer les signaux ConEx. La fonction d'audition n'est pas normalisée dans ce RFC mais il pose des exigences qu'elle doit suivre, notamment :

  • Le moins de faux positifs possibles (flots honnêtes notés à tort comme tricheurs).
  • Le moins de faux négatifs possibles (tricheurs non détectés). Je note personnellement que ces deux premières exigences sont souvent en conflit...
  • Des sanctions suffisantes pour être dissuasives mais proportionnelle à la triche : en raison des faux positifs, des sanctions excessives n'encourageront pas à déployer le protocole (et pourraient représenter un vecteur d'attaque par déni de service).

Ce RFC décrit des mécanismes abstraits. Le futur travail du groupe de travail ConEx devra en faire un ensemble de mécanismes concrets, traitant entre autres de ces points :

  • L'encodage des signaux.
  • Les mécanismes d'authentification et d'intégrité.
  • Les techniques de coexistence entre des machines ConEx et non-ConEx.
  • L'extensibilité du protocole.

Là encore, il ne sera sans doute pas possible de tout satisfaire. Les futurs RFC ConEx devront donc noter quelles exigences ont été délibérement affaiblies, voire abandonnées.

Place à l'encodage, maintenant, pour satisfaire mes lecteurs qui préfèrent savoir à quoi vont ressembler les bits sur le câble. Je rappelle que le protocole précis n'est pas encore normalisé, cette section 4 du RFC ne fait que pointer les problèmes liés à l'encodage des signaux. Prenons en effet un encodage naïf : on décide d'un bit dans l'en-tête IP qu'on met à 1 dès qu'il y a eu une retransmission TCP (des données sans accusé de réception, qu'il a fallu réémettre), ou dès qu'on a réduit la fenêtre TCP en réponse à ECN. Cet encodage semble satisfaire les premières exigences de ConEx : il est trivial à réaliser (sans doute une seule ligne de code dans la plupart des mises en œuvre de TCP/IP), il est compatible avec les matériels et logiciels existants (les non-ConEx ignoreront tout simplement ce bit), tout routeur ConEx sur le trajet peut lire ce bit et agir en fonction de sa valeur.

Mais cet encodage trop simple a des défauts : comme dans le cas du RFC 3514, il ne permet pas un audit. On n'a aucun moyen de vérifier si l'émetteur triche ou pas. Bon, ne soyons pas trop critique : un tel encodage est utile pour aider à comprendre ConEx et à se représenter à quoi cela peut bien ressembler. Dans des environnements fermés où tout le monde est honnête, il peut suffire.

D'autres encodages sont imaginables. Par exemple, on pourrait ne rien encoder du tout et dire aux routeurs ConEx de regarder les flots TCP et d'en déduire s'il y a eu rencontre avec la congestion en aval ; en effet, si on voit des retransmissions, ou la fenêtre TCP se réduire, on peut en déduire que l'émetteur a vu de la congestion et a réagi. Cela implique que les routeurs analysent TCP (ce qu'ils ne font normalement pas) et gardent un état (au moins un RTT de données), ce qui serait coûteux. Mais cela dispenserait de toute modification des émetteurs. Et cela ne permet pas de triche.

Dans un routeur implémenté en logiciel, en bordure du réseau, cela pourrait être réaliste (dans un routeur de cœur traitant des milliards de paquets à la seconde, cela le serait moins). À noter que des protocoles de sécurité comme TLS ou SSH ne masquent pas TCP et ne seraient donc pas un problème pour une analyse ConEx (contrairement à IPsec avec ESP, mais qui est beaucoup moins répandu). Mais si ConEx était ainsi déployé, cela pourrait motiver certains pour tout faire passer dans un VPN qui empêcherait cette observation.

Et encoder avec ECN ? Il existe une proposition (Internet-Drafts draft-briscoe-conex-re-ecn-tcp et draft-briscoe-conex-re-ecn-motiv) d'intégration d'ECN avec ConEx, qui a l'avantage d'empêcher la triche.

L'inconvénient de l'approche précédente est de nécessiter ECN, que n'ont pas tous les récepteurs. Une approche purement ConEx à l'encodage serait d'avoir des bits dédiés à ConEx dans l'en-tête IP (ou dans un en-tête d'extension en IPv6). On peut utiliser un bit par signal ConEx (ConEx, Re-Echo-Loss, Re-Echo-ECN et Credit), ou bien essayer de profiter du fait que certains sont mutuellement exclusifs pour condenser un peu.

Un sous-problème intéressant est celui de savoir si on compte la congestion en bits ou bien en paquets ? Est-ce que la perte d'un paquet de 1 500 octets vaut celle d'un paquet de 64 octets ? La perte d'un gros paquet est-elle due à sa taille ou bien un petit paquet aurait-il été également jeté ? Certaines parties du réseau sont limitées en nombre de bits (c'est typiquement le cas des tuyaux), d'autres en nombre de paquets (c'est partiellement le cas des équipements actifs). Le RFC 7141 recommande d'utiliser plutôt les bits, le RFC 6789 suggère la même chose, au moins dans l'Internet actuel.

La section 5 du RFC décrit les composants du réseau qui auront un rôle à jouer dans ConEx (voir aussi la section 6). Les équipements intermédiaires (notamment les routeurs) d'aujourd'hui ignorent les signaux ConEx et passent les paquets tels quels (espérons qu'aucun pare-feu trop zélé ne se permettra de les bloquer). Ceux qui seront modifiés ConEx, soit des routeurs, soit des engins spécialisés (congestion policer ?) liront les signaux ConEx, les vérifieront (cf. la partie sur l'audit) et pourront agir, par exemple en shapant les émetteurs qui déclenchent de la congestion.

Les émetteurs, typiquement des machines terminales, devront voir leur code TCP/IP modifié pour émettre des signaux ConEx. A priori, ceux qui n'ont même pas encore ECN n'utiliseront pas ConEx non plus, mais ceux qui ont ECN trouveront peut-être l'ajout de ConEx intéressant.

Les récepteurs, typiquement des machines terminales, n'ont pas à être modifiés.

L'audit des signaux ConEx, pour détecter les tricheurs (pensez au RFC 3514) est évidemment essentiel (section 5.5). Si des équipements réseaux limitent le trafic des émetteurs qui déclenchent de la congestion, afin d'épargner le réseau aval, ces émetteurs auront évidemment un bon mobile pour tricher. Ils risquent de ne pas mettre les signaux ConEx. (Voir aussi la section 8, sur la sécurité.)

Comment détecter les tricheurs ? Une solution possible est de détecter les pertes de paquets et de voir si l'émetteur envoie bien des Re-Echo-Loss. Mais attention : rien ne dit que l'auditeur voit tous les paquets d'un flot. Si le trafic passe par deux liens différents, l'auditeur situé sur un des liens risque de ne pas voir certains paquets et croire à tort qu'ils sont perdus.

Les signaux ECN peuvent aussi servir à l'audit. Pour être sûr de les voir, il faut être en aval des points où il y a congestion.

Une autre solution est d'utiliser les retransmissions de TCP. Si l'émetteur réémet, c'est que que paquets ont été perdus. Là, il vaut mieux être proche de l'émetteur (donc le plus en amont possible), pour être sûr de voir tous ses paquets, même en cas de chemins multiples dans le réseau.

Le routeur qui doit jeter des paquets (ou les marquer avec ECN) car il n'arrive plus à tout transmettre est aussi un bon endroit pour faire de l'audit : il peut directement comparer ce qu'il fait (jeter les paquets d'un flot donné) avec l'apparition, un RTT plus tard, des signaux ConEx.

La thèse de B. Briscoe (un des auteurs du RFC), « Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork » contient une analyse détaillée de toutes les techniques de triche, et d'audit, connues.


Téléchargez le RFC 7713


L'article seul

FreeBSD sur un Raspberry Pi

Première rédaction de cet article le 3 janvier 2016


Je viens d'installer FreeBSD sur un Raspberry Pi. Rien d'extraordinaire, je voulais juste expliquer pourquoi je ne garderai pas ce système en production.

Il y a désormais des images officielles pour le Raspberry Pi chez FreeBSD : ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.2/ (« ...arm-armv6-RPI-B... »). On télécharge, on décomprime, on copie sur un carte SD avec dd et on démarre le Pi dessus :

wget ftp://ftp.freebsd.org/pub/FreeBSD/releases/arm/armv6/ISO-IMAGES/10.2/FreeBSD-10.2-RELEASE-arm-armv6-RPI-B.img.xz
unxz FreeBSD-10.2-RELEASE-arm-armv6-RPI-B.img.xz
sudo dd if=FreeBSD-10.2-RELEASE-arm-armv6-RPI-B.img of=/dev/sdb bs=1M conv=sync
[Démarrage du Pi ; il faut être patient la première fois, cela prend
plusieurs minutes pour générer les clés SSH.]
    

Ensuite, on peut se connecter au Pi en SSH (login/mot de passe freebsd/freebsd). On crée des comptes, on change les mot de passe, tout va bien :

amour% uname -a
FreeBSD amour 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Thu Aug 13 03:16:22 UTC 2015     root@releng1.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B  arm
amour% uptime
 1:59PM  up 39 mins, 2 users, load averages: 1.67, 1.83, 1.66

(Les messages de démarrage du noyau sont disponibles ici.)

C'est ensuite que les ennuis commencent. Le programme bsdinstall censé permettre de configurer la machine facilement ne marche pas, la liste des miroirs n'étant pas adapté au processeur ARM : la plupart des miroirs n'ont pas ARM et on n'a aucun moyen de le savoir à l'avance. bsdinstall quitte donc rapidement. Il faut donc faire les réglages à la main. Par exemple, pour la date et le fuseau horaire :

ln -s  /usr/share/zoneinfo/Europe/Paris /etc/localtime
ntpdate  ntp.nic.fr

Et pour le clavier :

% kbdmap
kbdcontrol: getting keymap: Inappropriate ioctl for device
You are not on a virtual console - expect certain strange side-effects
lang_default = en
dialect = en
lang_abk = en
keymap="fr.kbd"

Mais le plus gênant concerne les paquetages. Dans la terminologie FreeBSD, le port est le source et le paquetage le binaire (pré-compilé, donc). Quand on a démarré sur l'image officielle, on n'a que le système de base. Pour des raisons historiques (enfin, plutôt, pré-historiques), FreeBSD maintient une division des anciens Unix, entre un système de base et les applications. La distinction est assez arbitraire (le système « de base » contient un compilateur, par exemple, alors que l'écrasante majorité des machines n'en ont pas besoin). Pour installer des applications utiles, il existe plusieurs mécanismes (et qui changent tout le temps, donc les vieux articles récupérés sur le Web ne vous aideront pas). Un peu au hasard, j'ai testé avec pkg :

# pkg update
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:10:armv6/quarterly, please wait...
pkg: Error fetching http://pkg.FreeBSD.org/FreeBSD:10:armv6/quarterly/Latest/pkg.txz: No address record
A pre-built version of pkg could not be found for your system.
Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'.
    

Le message « No address record » est erroné. Le site existe bien, mais n'a rien pour les processeurs ARM. En fait, le fond du problème est qu'il n'y a pas de paquetages (donc de binaires) pour le Raspberry Pi ; il parait qu'ils apparaitront dans la prochaine version de FreeBSD (je rappelle que les mises à jour du système sont très complexes avec FreeBSD, rien à voir avec ce que permet un système comme Debian, donc je n'envisage pas de passer dans les systèmes ultérieurs).

Il faut donc tout compiler soi-même ce qui, sur le Raspberry Pi, prend des siècles (et use la carte SD). J'ai utilisé portsnap pour extraire les ports (les sources, ou plutôt les références aux sources) comme suggéré par Johnson D :

portsnap fetch
portsnap extract
   

puis, cd /usr/ports/CATEGORY/SOFTWARE et make install. C'est horriblement lent et je ne rêve même pas d'arriver à installer emacs ainsi. Donc, pas utilisable « en vrai ».

Autre problème, j'ai eu du mal à activer IPv6 (qui ne l'est pas par défaut, ce qui est incroyable en 2016). Il existe d'innombrables variables IPv6 pour le /etc/rc.conf et les explications sur leur interaction sont confuses. Mon réseau utilise SLAAC pour la configuration IPv6. Un peu au hasard, j'ai mis :

ipv6_enable="YES"
ipv6_activate_all_interfaces="YES"
ipv6_privacy="YES"
ifconfig_ue0_ipv6="inet6 accept_rtadv"

ue0 est le nom de l'interface Ethernet du Pi. Avec un peu de patience ensuite, cela marche.

Quelques documentations et articles :

Des alternatives possibles :


L'article seul

Le journal d'Anne Frank monte dans le domaine public

Première rédaction de cet article le 1 janvier 2016


À l'heure où le fanatisme religieux est à l'offensive dans le monde, il faut lire et relire le journal d'Anne Frank. C'est plus facile désormais qu'il est monté dans le domaine public, ce premier janvier.

La famille d'Anne Frank, jeune juive allemande, réfugiée, déchue de sa nationalité, s'est installée à Amsterdam en 1934. C'est à Amsterdam qu'elle a écrit son journal intime, notamment pendant la période où sa famille était cachée, pendant l'occupation allemande. Elle a été arrêtée et assassinée par les nazis.

Ce journal monte dans le domaine public aujourd'hui. Malheureusement, un groupe de professionnels de l'appropriation intellectuelle prétend que le journal d'Anne Frank lui appartient, et menace ceux qui le publieraient. Il est donc crucial que le plus d'internautes possibles relayent cette publication, à l'image de Olivier Ertzscheid et d'Isabelle Attard, que je félicite chaleureusement au passage.

Voici donc le texte original, en néerlandais. Point juridique : la montée dans le domaine public se fait en général 70 ans après la mort de l'auteur (une durée incroyablement et anormalement longue). Mais cela ne vaut que pour le texte original, toute traduction (en français, par exemple), remet le compteur à zéro. Voici pourquoi il n'y a « que » le texte original.


L'article seul

RFC 7719: DNS Terminology

Date de publication du RFC : Décembre 2015
Auteur(s) du RFC : P. Hoffman (ICANN), A. Sullivan (Dyn), K. Fujiwara (JPRS)
Pour information
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 19 décembre 2015


Comme beaucoup de protocoles très utilisés sur l'Internet, le DNS est ancien. Très ancien (la première norme, le RFC 882, date de 1983). Les normes techniques vieillissent, avec l'expérience, on comprend mieux, on change les points de vue et donc, pour la plupart des protocoles, on se lance de temps en temps dans une révision de la norme. Mais le DNS est une exception : la norme actuelle reste fondée sur des textes de 1987, les RFC 1034 et RFC 1035. Ces documents ne sont plus à jour, modifiés qu'ils ont été par des dizaines d'autres RFC. Bref, aujourd'hui, pour comprendre le DNS, il faut s'apprêter à lire de nombreux documents. En attendant qu'un courageux et charismatique participant à l'IETF se lance dans la tâche herculéenne de faire un jeu de documents propre et à jour, ce nouveau RFC 7719 se limite à une ambition plus modeste : fixer la terminologie du DNS.

En effet, chacun peut constater que les discussions portant sur le DNS sont difficiles : on manque de terminologie standard, et celle des RFC officielles ne suffit pas, loin de là. Souvent, le DNS a tellement changé que le RFC officiel est même trompeur : les mots ne veulent plus dire la même chose. D'autres protocoles ont connu des mises à jour de la norme. Cela a été le cas de SMTP, passé successivement du RFC 772 à l'actuel RFC 5321, en passant par plusieurs révisions successives. Ou de XMPP, qui a vu sa norme originale mise à jour dans le RFC 6120. Et bien sûr de HTTP, qui a connu récemment un toilettage complet. Mais personne n'a encore osé faire pareil pour le DNS. Au moins, ce nouveau RFC 7719 traite l'un des problèmes les plus criants, celui du vocabulaire. Le RFC est évidemment en anglais, les traductions proposées dans cet article, et qui n'ont pas de valeur « officielle » sont de moi seul.

Notre RFC 7719 rassemble donc des définitions pour des termes qui étaient parfois précisément définis dans d'autres RFC (et il fournit alors un lien vers ce RFC original), mais aussi qui n'étaient définis qu'approximativement ou parfois qui n'étaient pas définis du tout (et ce RFC fournit alors cette définition). Du fait du flou de certains RFC anciens, et des changements qui ont eu lieu depuis, certaines définitions sont différentes de l'original. Le document a fait l'objet d'un consensus relatif auprès des experts DNS mais quelques termes restent délicats. Notez aussi que d'autres organisations définissent des termes liés au DNS par exemple le W3C a sa propre définition de « domaine ».

Ironiquement, un des termes les plus difficiles à définir est « DNS » lui-même. D'accord, c'est le sigle de Domain Name System mais ça veut dire quoi ? « DNS » peut désigner le schéma de nommage (les noms de domaine comme signal.eu.org, leur syntaxe, leurs contraintes), la base de données répartie (et faiblement cohérente) qui associe à ces noms des informations (comme des certificats, des adresses IP, etc), ou le protocole requête/réponse (utilisant le port 53) qui permet d'interroger cette base. Parfois, « DNS » désigne uniquement le protocole, parfois, c'est une combinaison des trois éléments indiqués plus haut (personnellement, quand j'utilise « DNS », cela désigne uniquement le protocole).

Bon, et ces définitions rigoureuses et qui vont mettre fin aux discussions, ça vient ? Chaque section du RFC correspond à une catégorie particulière. D'abord, en section 2, les noms eux-même, ces fameux noms de domaine :

  • Nom de domaine (domain name) : on reprend la définition du RFC 1034, section 3.1, dans une structure arborescente, le nom est une suite de composants (labels), la racine de l'arbre étant à la fin. Aucune restriction n'est imposée dans ces composants (tant pis pour la légende comme quoi le DNS serait limité à ASCII). Comme on peut représenter les noms de domaine sous forme d'un arbre, ou bien sous forme texte (www.madmoizelle.com), le vocabulaire s'en ressent. Par exemple, on va dire que com est « au-dessus de madmoizelle.com » (vision arborescente) ou bien « à la fin de www.madmoizelle.com » (vision texte). Notez aussi que la représentation des noms de domaine dans les paquets IP n'a rien à voir avec leur représentation texte (par exemple, les points n'apparaissent pas).
  • FQDN (Fully Qualified Domain Name, nom de domaine complet) : apparu dans le RFC 819, ce terme désigne un nom de domaine où tous les composants sont cités (par exemple, ldap.potamochère.fr. est un FQDN alors que ldap tout court ne l'est pas). En toute rigueur, un FQDN devrait toujours s'écrire avec un point à la fin (pour représenter la racine) mais ce n'est pas toujours le cas.
  • Composant (label) : un nœud de l'arbre des noms de domaine, dans la chaîne qui compose un FQDN. Dans www.laquadrature.net, il y a trois composants, www, laquadrature et net.
  • Nom de machine (host name) : ce n'est pas la même chose qu'un nom de domaine. Utilisé dans de nombreux RFC (par exemple RFC 952) mais jamais défini, un nom de machine est un nom de domaine avec une syntaxe plus restrictive : uniquement des lettres, chiffres, points et le tiret. Ainsi, brienne.tarth.got.example peut être un nom de machine mais www.&#$%?.example ne peut pas l'être. Le terme de « nom de machine » est parfois aussi utilisé pour parler du premier composant d'un nom de domaine (brienne dans brienne.tarth.got.example).
  • TLD (Top Level Domain, domaine de premier niveau ou domaine de tête) : le dernier composant d'un nom de domaine, celui juste avant (ou juste en dessous) de la racine. Ainsi, fr ou name sont des TLD. N'utilisez surtout pas le terme erroné d'« extension ».
  • IDN (Internationalized Domain Name, nom de domaine internationalisé) : un nom de domaine en Unicode, normalisé dans le RFC 5890.
  • Sous-domaine (subdomain) : domaine situé sous un autre, dans l'arbre des noms de domaines. Sous forme texte, un domaine est sous-domaine d'un autre si cet autre est un suffixe. Ainsi, www.cl.cam.ac.uk est un sous-domaine de cl.cam.ac.uk, qui est un sous-domaine de cam.ac.uk et ainsi de suite, jusqu'à la racine, le seul domaine à n'être sous-domaine de personne.
  • Alias (alias) : attention, il y a un piège. Le DNS permet à un nom d'être un alias d'un autre, avec le type d'enregistrement CNAME (voir la définition suivante). L'alias est le terme de gauche de l'enregistrement CNAME. Ainsi, si on met dans un fichier de zone vader IN CNAME anakin, l'alias est vader (et c'est une erreur de dire que c'est « le CNAME »).
  • CNAME (Canonical Name, nom canonique, le « vrai » nom) : le membre droit dans l'enregistrement CNAME. Dans l'exemple de la définition précédente, anakin est le CNAME, le « nom canonique ».
  • Suffixe public (public suffix) : ce terme pas très officiel est parfois utilisé pour désigner un suffixe de noms de domaine qui est contrôlé par un registre public (au sens où il accepte des enregistrements du public). Le terme est ancien mais est apparu pour la première fois dans un RFC avec le RFC 6265, section 5.3. com, co.uk et eu.org sont des suffixes publics. Rien dans la syntaxe du nom n'indique qu'un nom de domaine est un suffixe public, puisque ce statut ne dépend que d'une politique d'enregistrement (qui peut changer).

Fini avec les noms, passons à l'en-tête des messages DNS et aux codes qu'il peut contenir. Cet en-tête est défini dans le RFC 1035, section 4.1. Il donne des noms aux champs mais pas forcément aux codes. Ainsi, le code de réponse 3 indiquant qu'un domaine demandé n'existe pas est juste décrit comme name error et n'a reçu son mnémonique de NXDOMAIN (No Such Domain) que plus tard. Notre RFC définit également :

  • NODATA : un mnémonique pour une réponse où le nom de domaine demandé existe bien mais ne contient aucun enregistrement du type souhaité. Le code de retour est 0, NOERROR, et le nombre de réponses (ANCOUNT pour Answer Count) est nul.
  • Réponse négative (negative answer) : le terme recouvre deux choses, une réponse disant que le nom de domaine demandé n'existe pas, ou bien une réponse indiquant que le serveur ne peut pas répondre (code de retour SERVFAIL ou REFUSED). Voir le RFC 2308.
  • Renvoi (referral) : le DNS étant décentralisé, il arrive qu'on pose une question à un serveur qui ne fait pas autorité pour le domaine demandé, mais qui sait vous renvoyer à un serveur plus proche. Ces renvois sont indiqués dans la section Authority d'une réponse.

Voici un renvoi depuis la racine vers .fr :


% dig @l.root-servers.net A blog.imirhil.fr 
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16572
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 11
...
;; AUTHORITY SECTION:
fr.			172800 IN NS d.ext.nic.fr.
fr.			172800 IN NS d.nic.fr.
fr.			172800 IN NS e.ext.nic.fr.
fr.			172800 IN NS f.ext.nic.fr.
fr.			172800 IN NS g.ext.nic.fr.

    

Passons maintenant aux enregistrements DNS, stockés dans cette base de données répartie (section 4 du RFC) :

  • RR (Resource Record, un enregistrement DNS).
  • Ensemble d'enregistrements (RRset pour Resource Record set) : un ensemble d'enregistrements ayant le même nom (la même clé d'accès à la base), la même classe, le même type et le même TTL. Cette notion avait été introduite par le RFC 2181. Notez que la définition originale, reprise par notre RFC, parle malheureusement de label dans un sens incorrect. La terminologie du DNS est vraiment compliquée !
  • EDNS (Extension for DNS, également appelé EDNS0) : normalisé dans le RFC 6891, EDNS permet d'étendre l'en-tête du DNS, en spécifiant de nouvelles options, en faisant sauter l'antique limitation de taille de réponses à 512 octets, etc.
  • OPT (pour Option) : une astuce d'EDNS pour encoder les informations de l'en-tête étendu. C'est un enregistrement DNS un peu spécial, défini dans le RFC 6891, section 6.1.1.
  • Propriétaire (owner ou owner name) : le nom de domaine d'un enregistrement. Ce terme est très rarement utilisé, même par les experts.
  • Champs du SOA (SOA field names) : ces noms des enregistrements SOA (comme MNAME ou RNAME) sont peu connus et peu utilisés (RFC 1035, section 3.3.13). Notez que la sémantique du champ MINIMUM a complètement changé avec le RFC 2308.
  • TTL (Time To Live) : la durée de vie maximale d'un enregistrement dans les caches des résolveurs. C'est un entier non signé (même si le RFC 1035 dit le contraire), en secondes.

Voici un ensemble d'enregistrements (RRset), comptant ici deux enregistrements :


rue89.com.		600 IN MX 50 mx2.typhon.net.
rue89.com.		600 IN MX 10 mx1.typhon.net.	       
	       
    

Et voici un pseudo-enregistrement OPT, tel qu'affiché par dig, avec une indication de la taille maximale et l'option client subnet (RFC pas encore publié) :

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; CLIENT-SUBNET: 13.176.144.0/24/0
    

Ensuite, un sujet chaud où le vocabulaire est particulièrement peu défini, et très mal utilisé (voir les forums grand public sur le DNS où les discussions prennent un temps fou car les gens utilisent mal les mots) : les différents types de serveurs et clients DNS (section 5) :

  • Résolveur (resolver) : un client DNS qui va produire une réponse finale (pas juste un renvoi, pas juste une information ponctuelle comme le fait dig). Il existe plusieurs types de résolveurs (voir ci-dessous) et, en pratique, quand on dit « résolveur » tout court, c'est en général un « résolveur complet ».
  • Résolveur minimum (stub resolver) : un résolveur qui ne sait pas suivre les renvois et qui dépend donc d'un ou de plusieurs résolveurs complets pour faire son travail. Ce type est défini dans la section 6.1.3.1 du RFC 1123. C'est ce résolveur minimum qu'appelent les applications lorsqu'elles font un getaddrinfo() ou getnameinfo(). Sur Unix, le résolveur minimum fait en général partie de la libc et trouve l'adresse du ou des résolveurs complets dans /etc/resolv.conf.
  • Résolveur complet (full resolver) : un résolveur qui sait suivre les renvois et donc fournir un service de résolution complet. Des logiciels comme Unbound ou PowerDNS Resolver assurent cette fonction. Le résolveur complet est en général situé chez le FAI ou dans le réseau local de l'organisation où on travaille, mais il peut aussi être sur la machine locale. On le nomme aussi « résolveur récursif ».
  • Serveur faisant autorité (authoritative server et traduire ce terme par « serveur autoritaire » montre une grande ignorance de l'anglais, un adjudant est autoritaire, un serveur DNS fait autorité) : un serveur DNS qui connait une partie des données du DNS (il « fait autorité » pour une ou plusieurs zones) et peut donc y répondre (RFC 2182, section 2). Ainsi, au moment de l'écriture de cet article, f.root-servers.net fait autorité pour la racine, d.nic.fr fait autorité pour pm, etc. Des logiciels comme NSD ou Knot assurent cette fonction. Les serveurs faisant autorité sont gérés par divers acteurs, les registres, les hébergeurs DNS (qui sont souvent en même temps bureaux d'enregistrement), mais aussi par M. Michu. La commande dig NS $ZONE vous donnera la liste des serveurs faisant autorité pour la zone $ZONE.
  • Serveur mixte : ce terme n'est pas dans ce RFC. Autrefois, il était courant que des serveurs DNS fassent à la fois résolveur et serveur faisant autorité. Cette pratique est fortement déconseillée depuis de nombreuses années (entre autres parce qu'elle complique sérieusement le déboguage, mais aussi pour des raisons de sécurité parce qu'elle mène à du code plus complexe) et n'est donc pas dans ce RFC.
  • Initialisation (priming) : le processus par lequel un résolveur complet vérifie l'information sur les serveurs de la racine. Au démarrage, le résolveur ne sait rien. Pour pouvoir commencer la résolution de noms, il doit demander aux serveurs de la racine. Il a donc dans sa configuration leur liste. Mais ces configurations ne sont pas forcément mises à jour souvent. La liste peut donc être trop vieille. La première chose que fait un résolveur est donc d'envoyer une requête « NS . » à un des serveurs de sa liste. Ainsi, tant qu'un moins un des serveurs de la vieille liste répond, le résolveur est sûr d'apprendre la liste actuelle.
  • Mémorisation des négations (negative caching, ou « cache négatif ») : mémoriser le fait qu'il n'y a pas eu de réponse, ou bien une réponse disant qu'un nom de domaine n'existe pas.
  • Serveur primaire (primary server mais on dit aussi master server) : un serveur faisant autorité qui a accès à la source des données (fichier de zone, base de données, etc). Attention, il peut y avoir plusieurs serveurs primaires (autrefois, ce n'était pas clair et beaucoup de gens croient qu'il y a un serveur primaire, et qu'il est indiqué dans l'enregistrement SOA). Attention bis, le terme ne s'applique qu'à des serveurs faisant autorité, l'utiliser pour les résolveurs (« on met en premier dans /etc/resolv.conf le serveur primaire ») n'a pas de sens.
  • Serveur secondaire (secondary server mais on dit aussi « serveur esclave », slave server) : un serveur faisant autorité qui n'est pas la source des données, qui les a prises d'un serveur primaire (dit aussi serveur maître), via un transfert de zone (RFC 5936).
  • Serveur furtif (stealth server) : un serveur faisant autorité mais qui n'apparait pas dans l'ensemble des enregistrements NS. (Définition du RFC 1996, section 2.1.)
  • Maître caché (hidden master) : un serveur primaire qui n'est pas annoncé publiquement (et n'est donc accessible qu'aux secondaires). C'est notamment utile avec DNSSEC : s'il signe, et donc a une copie de la clé privée, il vaut mieux qu'il ne soit pas accessible de tout l'Internet (RFC 6781, section 3.4.3).
  • Transmission (forwarding) : le fait, pour un résolveur, de faire suivre les requêtes à un autre résolveur (probablement mieux connecté et ayant un cache partagé plus grand). On distingue parfois (mais ce n'est pas forcément clair, même dans le RFC 5625) la transmission, où on émet une nouvelle requête, du simple relayage de requêtes sans modification.
  • Transmetteur (forwarder) : le terme est confus (et a suscité plein de débats dans le groupe de travail DNSOP lors de la mise au point de ce RFC). Il désigne parfois la machine qui transmet une requête et parfois celle vers laquelle on transmet (c'est dans ce sens qu'il est utilisé dans la configuration de BIND, avec la directive forwarders).
  • Résolveur politique (policy-implementing resolver) : un résolveur qui modifie les réponses reçues, selon sa politique. On dit aussi, moins diplomatiquement, un « résolveur menteur ». C'est ce que permet, par exemple, le système RPZ. Sur l'utilisation de ces « résolveurs politiques » pour mettre en œuvre la censure, voir entre autres mon article aux RIPE Labs. Notez que le résolveur politique a pu être choisi librement par l'utilisateur (par exemple comme élément d'une solution de blocage des publicités) ou bien qu'il lui a été imposé.
  • Résolveur ouvert (open resolver) : un résolveur qui accepte des requêtes DNS depuis tout l'Internet. C'est une mauvaise pratique (cf. RFC 5358) et la plupart de ces résolveurs ouverts sont des erreurs de configuration. Quand ils sont délibérement ouverts, comme Google Public DNS, on parle plutôt de résolveurs publics.
  • Collecte DNS passive (passive DNS) : désigne les systèmes qui écoutent le trafic DNS, et stockent tout ou partie des messages DNS échangés. Le cas le plus courant est celui où le système de collecte ne garde que les réponses (ignorant donc les adresses IP des clients et serveurs), afin de constituer une base historique du contenu du DNS (c'est ce que font DNSDB ou le système de PassiveDNS.cn).
  • Anycast : le fait d'avoir un service en plusieurs sites physiques, chacun annonçant la même adresse IP de service (RFC 4786). Cela résiste mieux à la charge, et permet davantage de résilience en cas d'attaque par déni de service. Les serveurs de la racine, ceux des « grands » TLD, et ceux des importants hébergeurs DNS sont ainsi « anycastés ».

Voici, vu par tcpdump, un exemple d'initialisation d'un résolveur BIND utilisant la racineYeti :

15:07:36.736031 IP6 2a01:e35:8bd9:8bb0:21e:8cff:fe76:29b6.35721 > 2001:6d0:6d06::53.53: \
       21476% [1au] NS? . (28)
15:07:36.801982 IP6 2001:6d0:6d06::53.53 > 2a01:e35:8bd9:8bb0:21e:8cff:fe76:29b6.35721: \
       21476*- 16/0/1 NS yeti-ns.tisf.net., NS yeti-ns.lab.nic.cl., NS yeti-ns.wide.ad.jp., NS yeti.ipv6.ernet.in., NS yeti-ns.as59715.net., NS ns-yeti.bondis.org., NS yeti-dns01.dnsworkshop.org., NS dahu2.yeti.eu.org., NS dahu1.yeti.eu.org., NS yeti-ns.switch.ch., NS bii.dns-lab.net., NS yeti.bofh.priv.at., NS yeti-ns.conit.co., NS yeti.aquaray.com., NS yeti-ns.ix.ru., RRSIG (619)
    

La question était « NS . » (quels sont les serveurs de la racine) et la réponse contenait les noms des seize serveurs racine.

Voici aussi des exemples de résultats avec un résolveur ou bien avec un serveur faisant autorité. Si je demande à un serveur faisant autorité (ici, un serveur racine), avec mon client DNS qui, par défaut, demande un service récursif (flag RD, Recursion Desired) :


% dig @2001:620:0:ff::29 AAAA www.iab.org 
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54197
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 13
;; WARNING: recursion requested but not available
...
;; AUTHORITY SECTION:
org.			172800 IN NS b0.org.afilias-nst.org.	       
...
	       
    

C'est pour cela que dig affiche WARNING: recursion requested but not available. Notez aussi que le serveur, ne faisant autorité que pour la racine, n'a pas donné la réponse mais juste un renvoi aux serveurs d'Afilias. Maintenant, interrogeons un serveur récursif (le service de résolveur public Yandex DNS) :


% dig @2a02:6b8::feed:0ff AAAA www.iab.org           
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63304
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
...
;; ANSWER SECTION:
www.iab.org.		1800 IN	AAAA 2001:1900:3001:11::2c
	       
    

Cette fois, j'ai obtenu une réponse, et avec le flag RA, Recursion Available. Si je pose une question sans le flag RD (Recursion Desired, avec l'option +norecurse de dig) :


% dig +norecurse @2a02:6b8::feed:0ff AAAA www.gq.com  
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59438
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
...
;; ANSWER SECTION:
www.gq.com.		293 IN CNAME condenast.map.fastly.net.
	       
    

J'ai obtenu ici une réponse car l'information était déjà dans le cache (la mémoire) de Yandex DNS (on le voit au TTL, qui n'est pas un chiffre rond, il a été décrémenté du temps passé dans le cache). Si l'information n'est pas dans le cache :

    
% dig +norecurse @2a02:6b8::feed:0ff AAAA blog.keltia.net
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19893
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
...
	       
    

Je n'obtiens alors pas de réponse (ANSWER: 0). Si je demande au serveur faisant autorité pour cette zone :


% dig +norecurse @2a01:e0d:1:3:58bf:fa61:0:1 AAAA blog.keltia.net  
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62908
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 15
...
;; ANSWER SECTION:
blog.keltia.net.	86400 IN AAAA 2a01:240:fe5c:1::2
...
	       
    

J'ai évidemment une réponse et, comme il s'agit d'un serveur faisant autorité, elle porte le flag AA (Authoritative Answer, qu'un résolveur ne mettrait pas). Notez aussi le TTL qui est un chiffre rond (et qui ne change pas si on rejoue la commande).

Passons maintenant à un concept relativement peu connu, celui de zones, et le vocabulaire associé :

  • Zone : un groupe de domaines contigus et gérés ensemble, par le même ensemble de serveurs de noms (ma définition, celle du RFC étant très abstraite). Beaucoup de gens croient que tout domaine est une zone, mais c'est faux. Ainsi, au moment de la publication de ce RFC, gouv.fr n'est pas une zone séparée, il est dans la même zone que fr (cela se teste facilement : gouv.fr n'a pas d'enregistrement NS ou de SOA).
  • Parent : le domaine « du dessus ». Ainsi, le parent de wikipedia.org est org.
  • Apex : le sommet d'une zone, là ù on trouve les enregistrements NS et SOA. Si la zone ne comprend qu'un domaine, l'apex est ce domaine. Si la zone est plus complexe, l'apex est le domaine le plus court.
  • Coupure de zone (zone cut) : l'endoit où on passe d'une zone à l'autre. Au-dessus de la coupure, la zone parente, en dessous, la zone fille.
  • Délégation (delegation) : un concept évidemment central dans le DNS, qui est un système décentralisé. En ajoutant un ensemble d'enregistrements NS pointant vers les serveurs de la zone fille, une zone parente délègue une partie de l'arbre des noms de domaine à une aure entité. L'endroit où se fait la délégation est donc une coupure de zone.
  • Colle (glue records) : lorsqu'une zone est déléguée à des serveurs dont le nom est dans la zone fille, la résolution DNS se heurte à un problème d'œuf et de poule. Pour trouver l'adresse de ns1.mazone.example, le résolveur doit passer par les serveurs de mazone.example, qui est déléguée à ns1.mazone.example et ainsi de suite... On rompt ce cercle vicieux en ajoutant, dans la zone parente, des données qui ne font pas autorité sur les adresses de ces serveurs (RFC 1034, section 4.2.1). Il faut donc bien veiller à les garder synchrones avec la zone fille. (Tanguy Ortolo me suggère d'utiliser « enregistrement de raccord » plutôt que « colle ». Cela décrit bien leur rôle, en effet.)
  • Dans le bailliage (in bailiwick) : terme absent des textes DNS originaux et qui peut désigner plusieurs choses. Il est (très rarement, selon mon expérience) parfois utilisé pour parler d'un serveur de noms dont le nom est dans la zone servie (et qui nécessite donc de la colle, voir la définition précédente), mais le sens le plus courant désigne des données pour lesquelles le serveur qui a répondu, soit fait autorité pour la zone, soit pour un ancêtre de cette zone. L'idée est qu'il est normal dans la réponse d'un serveur de trouver des données situées dans la bailliage et, par contre, que les données hors-bailliages sont suspectes (elles peuvent être là suite à une tentative d'empoisonnement DNS). Un résolveur DNS prudent ignorera donc les données hors-bailliage.
  • ENT (Empty Non-Terminal pour nœud non-feuille mais vide) : un domaine qui n'a pas d'enregistrements mais a des sous-domaines. C'est fréquent, par exemple, sous ip6.arpa ou sous les domaines très longs de certains CDN.
  • Zone de délégation (delegation-centric zone) : zone composée essentiellement de délégations vers d'autres zones. C'est typiquement le cas des TLD et autres suffixes publics.
  • Joker (wildcard) : une source de confusion considérable depuis les débuts du DNS. Si on pouvait refaire le DNS en partant de zéro, ces jokers seraient la première chose à supprimer. Pour les résumer, le nom * dans une zone déclenche la synthèse automatique de réponses pour les noms qui n'existent pas dans la zone. Si la zone foo.example contient bar.foo.example et *.foo.example, une requête pour thing.foo.example renverra le contenu de l'enregistrement avec le joker, une requête pour bar.foo.example donnera les données de bar.foo.example.
  • Changement rapide (fast flux) : une technique notamment utilisée par les botnets pour mettre leur centre de commande à l'abri des filtrages ou destructions. Elle consiste à avoir des enregistrements d'adresses IP avec des TTL très courts et à en changer fréquemment.

Voyons ici la colle retournée par un serveur faisant autorité (en l'occurrence un serveur de .net) :


% dig @a.gtld-servers.net AAAA labs.ripe.net 
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18272
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
...
;; AUTHORITY SECTION:
ripe.net.		172800 IN NS ns3.nic.fr.
ripe.net.		172800 IN NS sec1.apnic.net.
ripe.net.		172800 IN NS sec3.apnic.net.
ripe.net.		172800 IN NS tinnie.arin.net.
ripe.net.		172800 IN NS sns-pb.isc.org.
ripe.net.		172800 IN NS pri.authdns.ripe.net.
...
;; ADDITIONAL SECTION:
sec1.apnic.net.		172800 IN AAAA 2001:dc0:2001:a:4608::59
sec1.apnic.net.		172800 IN A 202.12.29.59
sec3.apnic.net.		172800 IN AAAA 2001:dc0:1:0:4777::140
sec3.apnic.net.		172800 IN A 202.12.28.140
tinnie.arin.net.	172800 IN A 199.212.0.53
tinnie.arin.net.	172800 IN AAAA 2001:500:13::c7d4:35
pri.authdns.ripe.net.	172800 IN A 193.0.9.5
pri.authdns.ripe.net.	172800 IN AAAA 2001:67c:e0::5
	     
    

On notera :

  • La section ANSWER est vide, c'est un renvoi.
  • Le serveur indique la colle pour pri.authdns.ripe.net : ce serveur étant dans la zone qu'il sert, sans son adresse IP, on ne pourrait jamais le joindre.
  • Le serveur envoie également les adresses IP d'autres machines comme sec1.apnic.net. Ce n'est pas strictement indispensable (on pourrait l'obtenir par une nouvelle requête), juste une optimisation.
  • Les adresses de ns3.nic.fr et sns-pb.isc.org ne sont pas renvoyées. Le serveur ne les connait probablement pas et, de toute façon, elles seraient hors-bailliage.

Voyons maintenant, un ENT, gouv.fr :

   
% dig @d.nic.fr ANY gouv.fr 
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42219
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

    

Le serveur fait bien autorité pour ce domaine (flag AA dans la réponse), le domaine existe (autrement, le status aurait été NXDOMAIN, pas NOERROR) mais il n'y a aucun enregistrement (ANSWER: 0).

Allez courage, ne faiblissons pas, il reste encore la question de l'enregistrement des noms de domaine (section 7) :

  • Registre (registry) : l'organisation ou la personne qui gère les délégations d'une zone. Le terme est parfois employé uniquement pour les gérants de grandes zones de délégation, mais ce n'est pas obligatoire. Je suis à moi tout seul le registre de bortzmeyer.org :-) C'est le registre qui décide de la politique d'enregistrement, qui peut être très variable selon les zones (sauf dans celles contrôlées par l'ICANN, où une certaine uniformité est imposée). Mes lecteurs français noteront que, comme le terme « registre » est court et largement utilisé, le gouvernement a inventé un nouveau mot, plus long et jamais vu auparavant, « office d'enregistrement ».
  • Titulaire (registrant, parfois holder) : la personne ou l'organisation qui a enregistré un nom de domaine.
  • Bureau d'enregistrement (registrar) : dans le modèle RRR (Registry-Registrar-Registrant, mais ce modèle n'est pas obligatoire et pas universel), c'est un intermédiaire entre le titulaire et le registre.
  • Hébergeur DNS (DNS operator) : la personne ou l'organisation qui gère les serveurs DNS. Cela peut être le titulaire, son bureau d'enregistrement, ou encore un acteur spécialisé dans cette gestion.
  • EPP (Extensible Provisioning Protocol) : normalisé dans le RFC 5730, c'est le protocole standard entre bureau d'enregistrement et registre. Ce protocole n'a pas de lien avec le DNS, et tous les registres ne l'utilisent pas.
  • Whois (nommé d'après la question Who Is?) : un protocole réseau, sans lien avec le DNS, normalisé dans le RFC 3912. Il permet d'interroger les bases de données du registre pour trouver les informations qui ne sont pas dans le DNS (comme le nom du titulaire, et des moyens de le contacter). Les termes de « base Whois » ou de « données Whois » sont parfois utilisés mais ils sont erronés puisque les mêmes bases peuvent être interrogées par d'autres protocoles que Whois, comme RDAP (voir définition suivante).
  • RDAP (Registration Data Access Protocol) : un protocole concurrent de Whois, mais plus moderne.

Enfin, pour terminer, la section 8 de notre RFC couvre DNSSEC. Pas grand'chose de nouveau ici, DNSSEC étant plus récent et donc mieux défini.


Téléchargez le RFC 7719


L'article seul

RFC 7700: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames

Date de publication du RFC : Décembre 2015
Auteur(s) du RFC : P. Saint-Andre (&yet)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF precis
Première rédaction de cet article le 15 décembre 2015


Bien des protocoles Internet manipulent des noms qui doivent être parlants pour les utilisateurs et donc, de nos jours, doivent pouvoir être en Unicode. Les noms purement ASCII appartiennent à un passé révolu. Le groupe de travail PRECIS de l'IETF établit des règles pour ces noms, de manière à éviter que chaque protocole, chaque application, ne soit obligé de définir ses propres règles. Ce nouveau RFC contient les règles pour un sous-ensemble de ces noms : les noms qui visent plutôt à communiquer avec un utilisateur humain (par opposition aux noms qui sont indispensables aux protocoles réseaux, traités dans le RFC 7613).

Ces noms « humains » sont typiquement ceux qui sont présentés aux utilisateurs. Ils doivent donc avant tout être « parlants » et il faut donc qu'ils puissent utiliser la plus grande part du jeu de caractères Unicode, sans restrictions arbitraires (contrairement aux identificateurs formels du RFC 7613, pour lesquels on accepte des limites du genre « pas d'espaces »).

Le terme utilisé par le RFC pour ces noms « humains » est nicknames, terme qui vient du monde de la messagerie instantanée. Il n'y a pas de terme standard pour les désigner, certains protocoles (comme le courrier) parlent de display names (par opposition au login name ou account name), d'autres utilisent encore d'autres termes (l'article « An Introduction to Petname Systems » peut vous intéresser). Par exemple, dans un message électronique, on pourrait voir :

From: Valérie Pécresse <vp@les-républicains.fr>
    

Et, dans cet exemple, vp serait le nom formel (mailbox name dans le courrier, login name pour se connecter), alors que Valérie Pécresse est le nickname, le nom montrable aux humains. (Le concept de display name dans le courrier est normalisé dans la section 3.4.1 du RFC 5322, son exact équivalent XMPP, le nickname, est dans XEP-0172.)

Comme l'illustre l'exemple ci-dessus, on veut évidemment que le nom puisse être en Unicode, sauf pour la petite minorité des habitants de la planète qui utilisent une langue qui peut s'écrire uniquement en ASCII.

Ces noms « parlants », ces nicknames, ne servent pas qu'à désigner des humains, ils peuvent aussi être utilisés pour des machines, des sites Web (dans les signets), etc.

On pourrait penser qu'il n'y a rien à spécifier pour permettre leur internationalisation. On remplace juste ASCII par Unicode comme jeu de caractères autorisé et vas-y, poupoule. Mais Unicode recèle quelques surprises et, pour que les nicknames fonctionnent d'une manière qui paraitra raisonnable à la plupart des utilisateurs, il faut limiter légèrement leur syntaxe.

Ces limites sont exposées dans la section 2 de notre RFC, qui définit un profil de PRECIS. PRECIS, Preparation, Enforcement, and Comparison of Internationalized Strings est le sigle qui désigne le projet « Unicode dans tous les identificateurs » et le groupe de travail IETF qui réalise ce projet. PRECIS définit (RFC 7564) plusieurs classes d'identificateurs et les nicknames sont un cas particulier de la classe FreeformClass, la moins restrictive (celle qui permet le plus de caractères).

Outre les restrictions de FreeformClass (qui n'est pas complètement laxiste : par exemple, cette classe ne permet pas les caractères de contrôle), le profil Nickname :

  • Convertit tous les caractères Unicode de type « espace » (la catégorie Zs) en l'espace ASCII (U+0020),
  • Supprime les espaces en début et en fin du nickname, ce qui fait que " Thérèse" et "Thérèse" sont le même nom,
  • Fusionne toutes les suites d'espaces en un seul espace,
  • Met tout en minuscules (donc les nicknames sont insensibles à la casse),
  • Normalise en NFKC, plus violent que NFC, et réduisant donc les possibilités que deux nicknames identiques visuellement soient considérés comme distincts (cf. section 6, qui prétend à tort que ce serait un problème de sécurité ; comme souvent à l'IETF, le groupe de travail a passé beaucoup de temps sur un faux problème de « confusabilité », cf. UTS#39).

À noter qu'un nickname doit avoir une taille non nulle, après l'application des ces règles (autrement, un nickname de trois espaces serait réduit à... zéro).

Une fois ce filtrage et cette canonicalisation faite, les nicknames sont encodés en UTF-8 et peuvent être comparés par une simple égalité bit à bit.

La section 3 de notre RFC fournit quelques exemples amusants et instructifs de nicknames :

  • "Foo" et "foo" sont acceptables, mais sont le même nom (en application de la régle d'insensibilité à la casse),
  • "Foo Bar" est permis (les espaces sont autorisés, avec les quelques restrictions indiquées plus haut),
  • "Échec au roi ♚" est permis, rien n'interdit les symboles comme cette pièce du jeu d'échecs, le caractère Unicode U+265A,
  • "Henri Ⅳ" est permis (ouvrez l'œil : c'est le chiffre romain à la fin, U+2163) mais la normalisation NFKC (précédée du passage en minuscules) va faire que ce nom est équivalent à "henri iv" (avec, cette fois, deux caractères à la fin).

Comme le rappelle la section 4 de notre RFC, les applications doivent maintenant définir l'utilisation de ces noms parlants, où peut-on les utiliser, etc. L'application peut donc avoir des règles supplémentaires, comme une longueur maximale pour ces nicknames, ou des caractères interdits car ils sont spéciaux pour l'application.

L'application ou le protocole applicatif a également toute latitude pour gérer des cas comme les duplicatas : j'ai écrit plus haut que "Foo Bar" et "foo bar" étaient considérés comme le même nickname mais cela ne veut pas dire que leur coexistence soit interdite : certaines applications permettent à deux utilisateurs distincts d'avoir le même nickname. Même chose avec d'autres règles « métier » comme la possibilité d'interdire certains noms (par exemple parce qu'ils sont grossiers).

Le profil Nickname est désormais ajouté au registre IANA (section 5 du RFC).


Téléchargez le RFC 7700


L'article seul

RFC 7687: Report from the Strengthening the Internet (STRINT) workshop

Date de publication du RFC : Décembre 2015
Auteur(s) du RFC : S. Farrell (Trinity College, Dublin), R. Wenning, B. Bos (W3C), M. Blanchet (Viagenie), H. Tschofenig (ARM)
Pour information
Première rédaction de cet article le 15 décembre 2015


Depuis les révélations d'Edward Snowden, les initiatives se multiplient pour « durcir l'Internet », c'est-à-dire le rendre plus résistant à la surveillance généralisée, telle que pratiquée par plusieurs pays (par exemple la France, où les politiques profitent cyniquement des attentats islamistes pour faire passer de plus en plus de lois liberticides). Début 2014, à Londres, s'est ainsi tenu l'atelier STRINT, qui a rassemblé une centaine de participants pour réfléchir à la meilleure façon de renforcer l'Internet contre cet espionnage. Ce RFC est le compte-rendu (très tardif) de cet atelier. Il résume les principales interventions, et les suggestions faites à cette occasion.

L'engagement de l'IETF à lutter contre la surveilance généralisée date de sa réunion de Vancouver, et a été formalisé dans le RFC 7258. C'est à la suite de cette réunion canadienne qu'a été tenu l'atelier STRINT, coorganisé par le projet STREWS, l'IAB et le W3C. STRINT signifie « Strengthening the Internet Against Pervasive Monitoring » et l'atelier s'est tenu juste avant la réunion IETF 89 à Londres.

L'atelier a été un succès. Prévu pour un petit nombre de participants (cent maximum : le but était de travailler, pas de faire des discours devant une immense salle), il a été rempli en peu de temps. (Outre les 100 participants physiques, jusqu'à 165 personnes ont suivi l'atelier à distance.) 67 articles avaient été soumis.

La section 2 du RFC résume les conclusions de l'atelier :

  • La cryptographie bien faite est une protection efficace contre la surveillance massive et son usage plus intense est souhaitable.
  • L'analyse de trafic est une menace réelle, et la cryptographie est ici moins efficace. Mais le problème reste insuffisamment connu et mérite d'avantage d'études.
  • La surveillance massive est quelque chose de relativement nouveau et mérite des analyses du modèle de menace plus détaillées (le travail était en cours à l'époque, et cela a mené, entre autres, au RFC 7624).
  • Cette surveillance massive mérite qu'on s'attaque à une mise à jour du RFC 3552.
  • Le terme de « opportunistic security » a été brandi plusieurs fois pendant l'atelier. Il faut savoir que ce terme n'a pas de définition rigoureuse et est utilisé dans le monde de la sécurité pour désigner des tas de choses différentes. Depuis, l'IETF a publié sa définition, dans le RFC 7435.
  • Un effort d'explication auprès des décideurs reste nécessaire, pour expliquer les problèmes techniques que pose la surveillance massive. (Belle naïveté de techniciens honnêtes qui croient que les politiques prennent des mauvaises décisions parce qu'ils ne sont pas bien informés.)
  • La question des interfaces utilisateur est très importante et très difficile. Il existe désormais un net consensus chez les gens de la sécurité que l'utilisateur est un maillon crucial (et souvent fragile) de la chaîne de sécurité. Il reste à tirer des conséquences pratiques de ce consensus de principe. Par exemple, faut-il arrêter de présenter à l'utilisateur des choix dangereux, comme « le certificat n'a pas le bon nom, voulez-vous continuer ? » Si on répond « il ne faut pas proposer de tels choix », une coordination entre les auteurs de logiciels est nécessaire autrement ceux qui respectent le plus la sécurité risquent d'être considérés comme moins bon que ceux de leurs concurrents (comme on l'a déjà vu avec DNSSEC). Globalement, ce problème des interfaces utilisateur reste un champ de recherche ouvert.
  • Développer des exemples de configurations sûres à copier/coller pour mettre dans son logiciel aiderait certainement (regardez par exemple la documentation de l'ANSSI sur HTTPS, section 2.1). Ce n'est pas un travail de normalisation et cela ne concerne donc pas directement l'IETF ou le W3C mais c'est certainement important.
  • Plus directement de la responsabilité de ces SDO : faire un effort pour que les protocoles soient sûrs par défaut (un contre-exemple est SMTP, qui est en clair par défaut.)
  • Apparemment plus anecdotique, mais néanmoins crucial vu leur vaste déploiement, résoudre le problème des portails captifs aiderait : aujourd'hui, ces portails utilisent les mêmes techniques que des attaquants et sont donc indistinguables d'une attaque.

La section 3 de notre RFC revient sur les buts de l'atelier. Une fois qu'on a décidé que la surveillance généralisée était une attaque, et qu'il fallait la combattre (RFC 7258), que faire de plus ?

  • Se mettre d'accord sur des concepts comme celui de « sécurité opportuniste »,
  • Mieux comprendre les compromis à faire (la sécurité n'est pas gratuite),
  • Identifier les « maillons faibles » de la sécurité du Web,
  • Et surtout, identifier les tâches concrètes qui relèvent des organismes de normalisation comme l'IETF ou le W3C et celles qui, sans relever directement de ces organismes, les aideraient dans leur tâche.

Pour atteindre ces buts, l'atelier était structuré pour maximiser les discussions (section 4 du RFC). Les papiers acceptés n'étaient pas présentés (les participants étaient supposés les avoir lus avant).

Quels furent les sujets couverts dans les sessions de l'atelier (section 5 du RFC) ? La session d'ouverture a discuté de questions plutôt « méta » comme la quantité minimale de métadonnées qui est vraiment nécessaire aux protocoles IETF pour faire leur travail, comme la recherche de « fruits à portée de main » (des solutions qui pourraient être déployées très rapidement), ou comme le niveau de sécurité considéré comme « suffisant » (il ne faut pas espérer atteindre une sécurité parfaite, quand l'attaquant a les moyens de la NSA).

La première session portait (section 5.2) sur les menaces. Pas de sécurité sérieuse sans une étude détaillée des menaces. Ce n'est pas la même chose de se protéger contre la DGSE ou le FSB et de se protéger contre le lycéen boutonneux dans son garage. La surveillance généralisée met en cause un modèle traditionnel de menaces, fondé sur une étude coût/bénéfice de la défense (ou de l'attaque d'ailleurs). Dans ce modèle traditionnel, on regardait ce que valait l'objectif à défendre et on calculait les dépenses de sécurité réalistes en fonction de cela. (L'attaquant faisait un calcul similaire, et pouvait migrer vers un autre objectif, si le premier envisagé était trop coûteux.) Mais, avec la surveillance généralisée, il n'y a plus de décisions d'attaquer tel ou tel objectif : on attaque tout le monde. Et l'attaquant étant en général un État, il ne fait pas de calcul de ROI (certaines bureaucraties étatiques sont même contentes quand c'est cher, cela permet de se « construire un empire » en réclamant des budgets toujours plus élevés).

Est-ce que la surveillance généralisée est plus facile s'il y a un petit nombre de silos très protégés (les GAFA, Google, Facebook, etc) ou s'il y a une multitude de petits sites, chacun avec son CozyCloud ou son YunoHost, chacun moins bien protégé que les grosses entreprises professionnelles, mais bénéficiant de la dispersion des données ? Si Facebook est certainement, pour un attaquant, un objectif plus difficile à craquer que le VPS de M. Michu, c'est également un objectif beaucoup plus intéressant : si on le craque, on a les données de centaines de millions de M. Michu. Le RFC suggère donc qu'il vaut mieux ne pas tout mettre chez les GAFA et disperser les objectifs. (Gentiment, il oublie de rappeler que certains attaquants n'ont pas besoin de pirater les GAFA : ils ont PRISM pour cela.)

La session a aussi mis en évidence l'importance d'utiliser un vocabulaire rigoureux quand on parle des menaces et des solutions techniques, surtout quand on s'adresse à un public non-spécialiste. Ainsi, les solutions contre les attaques de l'Homme du Milieu ne « protègent » pas contre ces attaques : elles les rendent simplement visibles. C'est la réaction aux alertes qui déterminera si on est protégé ou pas (pensez au traditionnel avertissement des navigateurs Web : « voulez-vous continuer malgré ce certificat mal fichu ? »).

Une autre session portait sur l'usage des outils de sécurité (section 5.3). Ce n'est pas tout de concevoir des outils géniaux, il faut encore qu'ils soient utilisés. Aujourd'hui, on constate que ce n'est pas assez le cas. Combien de messages circulent en clair quand ils devraient être chiffrés avec PGP ? Combien de SMS envoyés de manière à être lisibles par tous alors qu'il faudrait utiliser Signal (ex-TextSecure) ? Combien de webmestres renoncent à activer HTTPS parce qu'ils ne veulent pas payer une AC et subir ses procédures et son interface Web mal faite ?

Le RFC note que, dans ce dernier cas, ils ont raison, vu la faille fondamentale de ce système des AC : n'importe quelle AC peut émettre un certificat pour n'importe quel domaine. Donc, il suffit qu'une seule des centaines d'AC reconnues par le logiciel soit compromise pour faire s'effondrer tout l'édifice. Des solutions techniques existent (cf. RFC 6962 ou le RFC 6698, curieusement oublié ici).

Un des problèmes à l'usage des outils de sécurité peut être le modèle de confiance utilisé. Dans X.509, c'est « toutes les AC ont raison ». C'est très dangereux pour la sécurité. PGP a un modèle « réseau de confiance » qui a l'inconvénient de ne bien marcher que pour des petites communautés (il n'est pas réellement transitif). Un modèle longtemps méprisé par les experts en sécurité (ceux avec qui, si on les écoute, on ne déploie jamais aucune solution de sécurité, car aucune n'est parfaite) est le TOFU, utilisé par SSH ou Signal. Il a l'avantage d'être beaucoup plus facile pour les utilisateurs, mais l'attaque de l'Homme du Milieu reste possible pour la première connexion. La technique de l'« épinglage des clés » (RFC 7469) est une variante de TOFU.

Et pour SIP ? La constatation de l'atelier était que les fonctions de cryptographie dans SIP, pourtant bien normalisées, étaient peu utilisées. L'argument des opérateurs SIP est que les mises en œuvre de ce protocole sont peu interopérables et que la seule solution pour que ça marche est de modifier les échanges en cours de route, rajoutant ou enlevant des en-têtes SIP pour s'adapter à chaque logiciel. (S'ils ont raison, cela signifie que les RFC sur SIP n'étaient pas clairs, ou bien que les programmeurs ne les ont pas lus.)

Peut-être que WebRTC en tirera les leçons. Après tout, WebRTC est mis en œuvre par les auteurs de navigateurs et ceux-ci n'ont pas les mêmes intérêts que les opérateurs SIP (les intermédiaires adorent modifier les données et détestent la sécurité de bout en bout).

Et pour XMPP (RFC 6120), pourquoi les techniques de sécurité existantes ne sont-elles pas plus fréquemment utilisées ? XMPP a de l'authentification et du chiffrement du canal, grâce à TLS, et de l'authentification et du chiffrement de bout en bout, grâce à OTR (qui a par contre le gros défaut d'être mal intégré au protocole XMPP). Mais le problème identifié pendant la session est plutôt que XMPP est peu utilisé. Contrairement au courrier électronique, où tout le monde utilise les solutions standard (SMTP et IMF), pour la messagerie instantanée, M. Michu fait une confiance aveugle à des systèmes fermés et privatifs comme Skype, dont la sécurité est inconnue ou inexistante.

Il y avait bien sûr une session consacrée aux questions non techniques (section 5.4) car on sait bien maintenant que « la sécurité n'est pas un produit, c'est un processus ». Installer un outil technique ne suffit pas. Il faut aussi traiter les questions d'éducation des utilisateurs, les questions politiques, les questions juridiques... Ainsi, l'excuse du terrorisme est largement utilisée par les États pour justifier des politiques répressives, tellement répressives qu'elles auraient été largement considérées comme inacceptables il y a seulement quelques années (voir par exemple ce qui se fait en France en ce moment avec l'état d'urgence). Il y aussi, note le RFC, le problème des traités internationaux pro-commerce (comme TTIP) qui contiennent souvent des mesures anti-vie privée.

On note que, d'une façon générale, ces problèmes non techniques étaient traditionnellement peu pris en compte par les organisations comme l'IETF, ou par les informaticiens en général. Cela fait très longtemps que les chercheurs en médecine, par exemple, ont des comités d'éthique qui se penchent sur les conséquences de leur travail. Faudrait-il faire la même chose pour les SDO ? Pour l'instant, les normes qui ont reçu une évaluation extérieure sur les questions de vie privée (comme l'API de géolocalisation) l'ont été ponctuellement, sans démarche systématique.

Cela n'interdit pas d'améliorer les outils et une session était consacrée à cette activité (section 5.5 du RFC). D'abord, l'atelier a discuté de la sécurité opportuniste (au sens de « essayer de chiffrer autant que possible, même sans authentification, ce serait mieux que rien »), en considérant qu'elle n'avait pas été assez utilisée jusqu'à présent. L'une des difficultés de cet opportunisme est de ne pas donner de faux sentiments de sécurité à l'utilisateur. Par exemple, il y avait un consensus dans l'atelier que, si un logiciel tente TLS et y réussit, mais sans authentification, il ne doit pas présenter à l'utilisateur des signes rassurants, genre petit cadenas. Le chiffrement ainsi obtenu est un progrès mais il ne faut pas donner l'impression qu'on s'arrête là.

Un aspect délicat à l'heure actuelle est de l'attitude à avoir lorsqu'on ne peut pas chiffrer : est-ce parce que le pair ne sait effectivement pas ou bien parce qu'un Homme du Milieu a réussi à empêcher le chiffrement ? Pour des sessions qu'on veut sécurisées (https://... vers sa banque), il faut évidemment s'arrêter là. Mais pour les autres, il serait intéressant, plutôt que de se rabattre sur de la communication en clair, ce qui est souvent le choix, de se souvenir des communications précédentes avec ce pair et de décider en fonction du passé si ce problème de chiffrement est normal (une forme de TOFU).

Là aussi, la terminologie est importante. Les descriptions des connexions utilisant le « chiffrement, si possible » (sécurité opportuniste) parlent souvent d'« échec » si la session chiffrée n'a pu être établie alors qu'un tel échec n'est pas pire que si on n'avait même pas essayé. Il faudrait plutôt parler d'« amélioration » quand on a réussi à lancer le chiffrement (et ne rien dire si on n'y est pas arrivé). Là aussi, le fait que les concepteurs de protocoles, les experts en sécurité et les programmeurs ne soient pas des spécialistes de l'interface utilisateur va jouer : il n'est pas évident de communiquer des informations sur le niveau de sécurité à l'utilisateur.

Autre point sur lequel il faudrait améliorer les outils, le fait de chiffrer systématiquement, sans action explicite de l'utilisateur. Sinon, il y a un risque que l'utilisateur ne chiffre que les documents sensibles, ce qui facilite la tâche des espions, en leur indiquant quels sont les documents importants. (C'est un des problèmes de PGP, je trouve.)

Il serait également intéressant d'améliorer TOFU. Un des gros problèmes de ce modèle, tel qu'il est utilisé dans SSH, est qu'il n'existe pas de mécanisme propre pour changer la clé d'un serveur (par exemple parce qu'on a mis à jour le logiciel). Idem si on utilise Signal : si votre correspondant a perdu son téléphone et en a acquis un nouveau, il faut manuellement vérifier la nouvelle identité (TOFU ne peut pas savoir si c'est un changement de clé légitime ou bien une attaque de l'Homme du Milieu).

Un sujet qui fait l'objet de nombreuses discussions dès qu'on parle de vie privée et de surveillance est celui des métadonnées (section 5.6). Chiffrer protège en effet très bien le contenu. Malgré quelques rumeurs, il est peu probable que même les plus puissants attaquants arrivent aujourd'hui à craquer le chiffrement bien fait (attention : bien chiffrer est beaucoup plus dur que ce n'en a l'air). Pour un attaquant rationnel, voler les clés, acheter ou menacer un destinataire légitime, ou encore corrompre le logiciel de chiffrement est bien plus aisé que de casser le chiffrement lui-même (c'est d'ailleurs pour cela que les discussions de détail sur la longueur des clés sont assez ridicules). Mais ce chiffrement n'aide pas si les métadonnées sont, elles accessibles. Pour prendre un exemple classique, imaginons deux personnes qui se téléphonent et chiffrent la communication. Le fait qu'ils se téléphonent est lui-même une information, qui peut être suffisante pour un espion, même s'il n'a pas accès au contenu des communications. C'est encore plus vrai si on a accès à plusieurs communications : si, à chaque fois que A appelle B au téléphone, B, immédiatement après avoir raccroché, appelle C, D et E, on en déduira facilement qu'on a identifié une chaîne de commandement, même si on n'a pas le contenu de leurs conversations. Cet exemple illustre bien le danger des métadonnées. Parfois, même la taille des messages donne des indications (si vingt fichiers de taille différente sont sur un serveur, l'observation du trafic, même chiffré, permet de savoir quel fichier a été récupéré).

Or, ces métadonnées sont partout, soit qu'elle soient absolument indispensables au fonctionnement des protocoles (comme l'adresse IP de destination dans les paquets IP), soit que leur potentiel d'indiscrétion n'ait pas été perçu tout de suite. Les supprimer n'est pas évident : un routeur a bien besoin de l'adresse de destination pour router !

Il y a trois techniques pour lutter contre l'espionnage par les métadonnées : l'agrégation, le détour (contraflow), et la dispersion (multipath). L'agrégation consiste à regrouper des conversations différentes dans un même flux de données. Par exemple, si votre résolution DNS passe par un gros résolveur partagé, les serveurs qu'interroge ce résolveur auront du mal à identifier vos requêtes, toutes passant par le résolveur. Idem en HTTP si on utilise un relais partagé, sauf évidemment si celui-ci laisse passer, ou, pire, ajoute, des informations discriminantes comme le User-Agent:. Même chose côté serveur : si vos pages « sensibles » sont hébergées sur un serveur mutualisé, un observateur aura du mal à dire ce qui était demandé (là encore, tout est dans les détails : par exemple, SNI peut trahir la communication).

Le détour consiste à passer délibérement par des chemins supplémentaires. C'est ce que fait un VPN ou, en encore mieux, Tor. Un espion qui voudrait identifier votre trafic devrait observer l'Internet en de nombreux points, et corréler ce qu'il voit.

Quant à la dispersion, elle consiste à envoyer les données par des moyens différents. Si vous commencez une conversation XMPP via de la 4G et que vous continuez en Wifi, l'attaquant aura davantage de mal que si toute la communication passe par un seul canal.

L'analyse de trafic donne souvent des résultats surprenants d'efficacité, dont les concepteurs de protocole ne se rendent pas compte. (Voir la bibliographie de FreeHaven, par exemple.) Il existe des méthodes pour la contrarier, comme d'ajouter des messages vides (padding, voir par exemple le RFC 7540, sections 6.1 et 10.7) mais elles ont un coût (par exemple en terme de débit) et ne sont pas faciles à utiliser.

Notez que les protections de bas niveau (couche 3) ne sont pas très utiles si les applications elle-même font fuiter des données. Un navigateur Web est particulièrement terrible sur ce point, voir le Panopticlick. C'est pour cela que Tor recommande l'usage du Tor Browser qui ne se contente pas de router les données via Tor, mais qui s'assure aussi que le navigateur ne vous trahit pas, et n'envoie qu'un minimum de données.

Un problème fréquent pour tous les systèmes de sécurité est celui des middleboxes, ces équipements intermédiaires qui se permettent de filtrer les messages, voire de les modifier. Beaucoup de protocoles de sécurité de l'Internet sont conçus pour une connexion de bout en bout : c'est le cas de TLS, par exemple. La middlebox viole cette supposition. On voit, par exemple, des middleboxes qui terminent la session TLS, analysent le trafic, puis re-chiffrent de l'autre côté. Pour passer l'authentification TLS, elles imposent en général de mettre le certificat d'une AC complice sur les ordinateurs clients. À noter que, dans la configuration TLS typique, le client authentifie le serveur mais pas le contraire. Ce qui veut dire qu'un serveur, même ultra-paranoïaque, n'a aucun moyen, contrairement au client, de détecter qu'une middlebox est présente.

Un autre exemple typique de middlebox courante est le portail captif (cf. RFC 6585 mais aussi le RFC 7710, issu des réflexions de cet atelier). Certains systèmes d'exploitation utilisent diverses heuristiques pour détecter la présence d'un portail captif afin, par exemple, de permettre une connexion automatisée. Mais ces heuristiques ne marchent évidemment pas toujours. (D'autant plus qu'il semble que certains points d'accès font tout pour empêcher ces heuristiques de marcher, afin d'empêcher les connexions automatisées.)

Idéalement, il faudrait un protocole nouveau permettant aux portails captifs de se signaler, sans avoir à jouer les Hommes du Milieu. Mais, même si un tel protocole était nnormalisé demain, il faut se rappeler que la plupart des points d'accès ne sont jamais mis à jour... (Un hôtel, par exemple, se moque pas mal de si son portail captif marche bien ou pas.)

L'atelier STRINT a ensuite vu les participants se répartir en petits groupes (break-outs) pour discuter en profondeur certains sujets. Par exemple, l'un de ces groupes s'attaquait à l'analyse des clients. Si certains ignorants ne considèrent que les navigateurs Web, les participants à l'atelier savaient bien, eux, qu'il existe une grande variété de logiciels clients. L'un des problèmes de ces clients est « que faire lorsqu'un certificat pose un problème ? » Certains administrateurs système disent simplement aux utilisateurs « continuez, ne vous inquiétez pas de cet avertissement », conseil qu'il sera difficile de faire désapprendre aux utilisateurs ensuite. Peut-être faudrait-il que les logiciels clients ne fournissent plus d'option pour passer outre un problème de certificat. Mais un tel changement devrait être fait plus ou moins simultanément par tous les auteurs de logiciels de cette catégorie. Autrement, il y a un risque que l'utilisateur croit que les logiciels les plus sûrs sont en tort, en l'empêchant de se connecter à son serveur.

Autre problème d'interaction entre la sécurité informatique et les facteurs humains, le cas des certificats auto-signés. Si un tel certificat est évidemment inacceptable pour une banque ou pour GitHub, pour un site personnel, il peut être tout à fait valable et en tout cas meilleur qu'une communication en clair. Un des aspects délirants de l'usage de HTTPS aujourd'hui est que bien des gérants de serveurs personnels n'activent pas HTTPS car obtenir un certificat est cher et compliqué, et utiliser un certificat auto-signé provoquerait des avertissements de sécurité injustifiés. Résultat : on reste en clair...

Un autre groupe travaillait sur l'activation par défaut des meilleurs choix de sécurité. Quant l'IETF dit que tous les programmes DOIVENT (MUST, cf. RFC 2119) mettre en œuvre tel protocole ou tel algorithme, cela veut dire qu'il doit être présent dans le code (MTI ou Mandatory To Implement, cf. RFC 3365). Mais cela ne signifie pas qu'il sera utilisé, s'il faut une action explicite de l'utilisateur ou de l'administrateur système pour l'activer. La très grande majorité des utilisateurs, et la plupart des administrateurs système, ne changent pas les réglages par défaut. Si on veut vraiment combattre la surveillance généralisée, il ne suffit pas d'avoir 2 ou 3 % des utilisateurs qui sont protégés. Il faut que presque tous le soient, donc passer du MTI au MTU (Mandatory To Use).

Enfin, un autre groupe break-out a planché sur la notion de « sécurité opportuniste » (opportunistic security). Le terme est très utilisé dans les milieux de la sécurité informatique mais n'a pas de définition précise. Plusieurs auteurs ont essayé d'en donner une définition (voir par exemple le RFC 4322) mais ces définitions sont très différentes les unes des autres. Depuis, l'IETF a publié la sienne, dans le RFC 7435.

On l'a dit, ce RFC arrive bien tard après l'atelier. Depuis, du travail a été fait. Juste après l'atelier, la réunion IETF de Londres a logiquement beaucoup couvert ces questions de protection contre l'espionnage. Ce fut par exemple la « DNSE BoF », première réunion physique du projet « DNS et vie privée », qui a depuis débouché sur le RFC 7626.

La totalité des articles présentés est en ligne.


Téléchargez le RFC 7687


L'article seul

RFC 7710: Captive-Portal Identification Using DHCP or Router Advertisements (RAs)

Date de publication du RFC : Décembre 2015
Auteur(s) du RFC : W. Kumari (Google), O. Gudmundsson (CloudFlare), P. Ebersman (Comcast), S. Sheng (ICANN)
Chemin des normes
Première rédaction de cet article le 14 décembre 2015


Les portails captifs sont une des plaies de l'accès à l'Internet. À défaut de pouvoir les supprimer, ce nouveau RFC propose des options aux protocoles DHCP et RA pour permettre de signaler la présence d'un portail captif, au lieu que la malheureuse machine doive le détecter elle-même.

On trouve de tels portails captifs en de nombreux endroits où de l'accès Internet est fourni, par exemple dans des hôtels ou des cafés. Tant que l'utilisateur ne s'est pas authentifié auprès du portail captif, ses capacités d'accès à l'Internet sont très limitées. Quels sont les problèmes que pose un portail captif ?

  • Le plus important est qu'il détourne le trafic normal : en cela, le portail captif est une attaque de l'Homme du Milieu et a donc de graves conséquences en terme de sécurité. Il éduque les utilisateurs à trouver normal le fait de ne pas arriver sur l'objectif désiré, et facilite donc le hameçonnage.
  • Le portail captif ne marche pas ou mal si la première connexion est en HTTPS, ce qui est de plus en plus fréquent. Là encore, il éduque les utilisateurs à trouver normaux les avertissements de sécurité (« mauvais certificat, voulez-vous continuer ? »).
  • Le portail captif n'est pas authentifié, lui, et l'utilisateur est donc invité à donner ses informations de créance à un inconnu.
  • En Wifi, comme l'accès n'est pas protégé par WPA, le trafic peut être espionné par les autres utilisateurs.
  • Spécifique au Web, le portail captif ne marche pas avec les activités non-Web (comme XMPP). Même les clients HTTP non-interactifs (comme une mise à jour du logiciel via HTTP) sont affectés.

Pourquoi est-ce que ces hôtels et cafés s'obstinent à imposer le passage par un portail captif ? On lit parfois que c'est pour authentifier l'utilisateur mais c'est faux. D'abord, certains portails captifs ne demandent pas d'authentification, juste une acceptation des conditions d'utilisation. Ensuite, il existe une bien meilleure solution pour authentifier, qui n'a pas les défauts indiqués plus haut. C'est 802.1X, utilisé entre autres dans eduroam (voir RFC 7593). La vraie raison est plutôt une combinaison d'ignorance (les autres possibilités comme 802.1X ne sont pas connues) et de désir de contrôle (« je veux qu'ils voient mes publicités et mes CGU »).

L'IETF travaille à développer un jour un protocole complet d'interaction avec les portails captifs, pour limiter leurs conséquences. En attendant, ce RFC propose une option qui permet au moins au réseau local de signaler « attention, un portail captif est là, ne lance pas de tâches - comme Windows Update - avant l'authentification ». Cette option peut être annoncée par le serveur DHCP (RFC 2131 et RFC 3315) ou par le routeur qui envoie des RA (RFC 4861).

Cette option (section 2 du RFC) annonce au client qu'il est derrière un portail captif et lui fournit l'URI de la page d'authentification (ce qui évite d'être détourné, ce qui est grave quand on utilise HTTPS). Dans cet URI, le serveur HTTP doit être désigné par son adresse IP, pour éviter d'avoir à faire du mensonge DNS.

Les sections 2.1, 2.2 et 2.3 de notre RFC donnent le format de l'option en DHCP v4, DHCP v6 et en RA. Le code DHCP v4 est 160, le DHCP v6 est 103 et le type RA est 37.

La section 4 de notre RFC étudie les conséquences de cette option pour la sécurité. Elle rappelle que DHCP et RA ne sont pas sécurisés, de toute façon. Donc, un méchant peut envoyer une fausse option « il y a un portail captif, allez à cet URI pour vous authentifier » mais le même méchant peut aussi bien annoncer un faux routeur...

Il est même possible que cette option nouvelle améliore la sécurité, en n'encourageant pas les utilisateurs à couper les mécanismes de validation comme la vérification des certificats, contrairement à ce que font les portails captifs actuels.

Pour DHCP, la plupart des serveurs permettent de servir une option quelconque, en mettant ses valeurs manuellement et une future mise à jour ne servira donc qu'à rendre l'usage de cette option plus simple. Autrement, il n'existe pas encore de mise en œuvre côté clients DHCP ou RA.


Téléchargez le RFC 7710


L'article seul

RFC 7720: DNS Root Name Service Protocol and Deployment Requirements

Date de publication du RFC : Décembre 2015
Auteur(s) du RFC : M. Blanchet (Viagenie), L-J. Liman (Netnod)
Première rédaction de cet article le 13 décembre 2015


L'Internet repose en grande partie sur le DNS (si ce dernier est en panne, presque plus rien ne fonctionne) et le DNS doit à sa nature arborescente de dépendre de sa racine ou plus exactement de ses serveurs racine. La gestion de ces derniers est donc une question cruciale, même si les débats sur la gouvernance de l'Internet se focalisent plutôt sur des sujets moins concrets comme la création (ou non) du TLD .vin. Ce très court RFC précise les obligations des serveurs racine en terme de protocoles réseau à suivre. D'autres documents décrivent les exigences opérationnelles. (Voir notamment le RSSAC 001: Service Expectation of Root Servers.)

Avant, ces obligations étaient dans un seul RFC, le RFC 2870. Il contenait des recommandations concernant les protocoles, donc plutôt du ressort de l'IETF, et d'autres concernant les règles quotidiennes des opérations d'un serveur racine, considérées aujourd'hui comme relevant plutôt du RSSAC (Root Server System Advisory Committee, qui publie ses propres recommandations dans le document nommé RSSAC-001). Ce RFC est donc encore plus court que son prédécesseur, désormais document historique.

À noter que les serveurs racine ne servent pas que la racine, mais aussi root-servers.net, domaine dans lequel ils sont nommés. Certains d'entre eux servent également .arpa.

Le cœur de notre RFC est la section 2 qui exige que les serveurs racine :

  • Suivent le protocole DNS (encore heureux...),
  • Soient capables de répondre en IPv4 et IPv6 (en octobre 2015, deux serveurs, E et G, n'avaient toujours pas d'IPv6),
  • Soient capables de répondre en UDP et en TCP,
  • Doivent gérer les sommes de contrôle UDP,
  • Doivent évidemment gérer DNSSEC, pour pouvoir servir la racine, qui est signée,
  • Doivent gérer EDNS (RFC 6891).

La plupart de ces règles vont de soi mais, en 2015, on rencontre hélas encore des serveurs DNS qui n'ont pas EDNS ou bien qui n'ont pas TCP (sans même parler d'IPv6...)

Moins liées aux protocoles, il y a deux autres exigences dans la section 3 :

  • Répondre à tous les clients (c'est un principe de neutralité du réseau, qui a d'amusantes conséquences de gouvernance, par exemple les serveurs gérés par l'armée US doivent répondre aux requêtes venant d'Iran...),
  • Servir l'unique racine « officielle », cf. RFC 2826 et pas une éventuelle racine alternative. Évidemment, cela implique de ne pas la modifier : les serveurs racine sont des imprimeurs, pas des éditeurs.

Merci à Lancelot et Atlal (et Opale), qui savent pourquoi...


Téléchargez le RFC 7720


L'article seul

RFC 7682: IRR & Routing Policy Configuration Considerations

Date de publication du RFC : Décembre 2015
Auteur(s) du RFC : D. McPherson (Verisign), S. Amante (Apple), E. Osterweil (Verisign), L. Blunk (Merit Network), D. Mitchell (Singularity Networks)
Pour information
Réalisé dans le cadre du groupe de travail IETF grow
Première rédaction de cet article le 13 décembre 2015


On le sait, il n'y a pas de chef de l'Internet. Personne ne reste dans un bureau toute la journée avec pour mission l'envoi de règles qui seront immédiatement appliquées par tous les acteurs de l'Internet. C'est même le cas des fonctions les plus essentielles de l'Internet comme l'échange des tables de routage. Tout l'Internet ne tient que parce que les opérateurs sont d'accord entre eux pour s'échanger l'information qui se retrouvera dans ces tables « pour joindre le préfixe 2001:db8:fe2::/48, passez par moi, je connais un chemin que j'ai appris des AS 64499 puis 429496613 ». Cet accord de principe se double d'un accord technique sur le protocole à utiliser : BGP, normalisé dans le RFC 4271. Et au-delà, rien, aucun accord : chaque opérateur est libre de sa politique et notament de ce qu'il accepte ou refuse. Un opérateur peut refuser les préfixes plus spécifiques que /32, par exemple. Chacun est maître chez soi. En pratique, bien des opérateurs refusent les préfixes qui ne sont pas dans un IRR. C'est quoi, un IRR ? Qui les gère ? Qui décide de ce qu'on met dans un IRR ?. Ce nouveau RFC explore la question.

Un IRR (Internet Routing Registry) est une base de données stockant des préfixes d'adresses IP et des informations de politique associées comme, par exemple, le ou les AS qui sont autorisés à annoncer ce préfixe en BGP ou bien les communautés BGP (RFC 1997) utilisées. Le RFC 1787, dans sa section 7, décrit l'importance de partager l'information entre les opérateurs. Certes, chacun est maître chez lui, mais tout serait plus simple si chacun partageait avec les autres, pour limiter le risque de décisions malencontreuses.

Mais les IRR ont des problèmes et des limites (introduction en section 3). Première catégorie de problèmes, l'exactitude et l'intégrité des données stockées (section 4). Comme tous les registres utilisés sur l'Internet, les IRR sont plein de données fausses ou dépassées. Les personnes qui mettent ces données dans les registres n'ont guère de motivations pour mettre des données correctes et encore moins pour les mettre à jour. Les données sont donc souvent erronées.

En outre, il n'existe pas de moyen largement déployé de vérifier ces données dès le départ. Si Pakistan Telecom met dans un IRR qu'ils sont autorisés à annoncer le préfixe de YouTube, comment vérifier qu'ils ont le droit de le faire ? Le langage utilisé pour les IRR, RPSL (normalisé dans le RFC 2622) le permet techniquement mais en l'absence d'un mécanisme de signature cryptographique entre le préfixe et l'AS, cela ne permet pas de s'assurer de l'authenticité du contenu de l'IRR. Le RFC note à juste titre que cette absence de mécanisme de signature vient en partie d'un manque d'intérêt de la communauté des opérateurs : tout le monde se plaint des détournements BGP mais personne n'est prêt à faire les considérables efforts qu'il faudrait pour tout certifier.

Bien sûr, certains IRR ont des mesures de sécurité (par exemple, dans la base RIPE, seul le titulaire d'un préfixe peut ajouter des routes pour ce préfixe, cf. RFC 2725 et c'est une obligation contractuelle, cf. ripe-637) mais cela ne s'étend pas aux autres IRR, qui ne peuvent pas vérifier que cette sécurité a été respectée. Difficile donc de savoir quelle politique de sécurité a été utilisée par un IRR donné.

Même quand les données sont correctes, en l'absence de mécanismes de vérification fondés sur la cryptographie, on peut parfois se retrouver avec des données fausses alors qu'elles étaient justes au départ.

Il existe de nombreuses propositions pour créer de tels systèmes de vérification et de certification (TASRS, HotNets-X et bien sûr la RPKI) mais aucune n'a encore un déploiement suffisant.

Comme indiqué plus haut, une partie du problème est le manque de motivation : le titulaire d'une ressource Internet (un préfixe IP, par exemple) peut avoir un intérêt direct à ajouter une information dans un IRR (par exemple parce que son transitaire est strict, et lui impose cet ajout, avant d'accepter l'annonce BGP du titulaire) mais il a rarement de raison objective de le maintenir à jour ou, surtout, de le détruire quand il n'est plus utilisé. Certains acteurs bâtissent leurs filtres d'annonces BGP à partir des IRR, ce qui fait qu'une information manquante se paie d'un manque de visibilité BGP. Mais il n'y a aucune pénalité à avoir de l'information en trop. Si un client, titulaire d'un préfixe IP, passe d'un transitaire strict, qui lui imposait une entrée dans un IRR (par exemple un objet route dans la base RIPE-NCC) vers un transitaire laxiste qui n'impose rien, le client n'a aucune motivation (à part la pureté de l'IRR, qui n'intéresse qu'une poignée de barbus fanatiques utilisant OpenBSD) à changer l'ancienne entrée. Il la laissera probablement telle quelle. Le nouveau transitaire, qui ignore l'IRR, n'en tiendra pas compte.

Une des rares motivations concrètes qui pourrait mener à un nettoyage des IRR est le manque de mémoire dans les routeurs : les filtres pourraient devenir trop gros, si personne ne nettoie jamais. Heureusement pour les utilisateurs des routeurs, mais malheureusement pour la pureté de l'IRR, les routeurs PE modernes ont en général assez de mémoire dans leur module de routage (control plane) pour que cela ne soit plus un problème.

Autre problème avec les IRR, le fait que leur modèle de sécurité soit en général basé sur « le titulaire peut tout, les autres ne peuvent rien ». Si une information est dépassée, un tiers qui s'en aperçoit ne peut rien faire, seul le titulaire est autorisé à la modifier. Pas moyen de nettoyer pour compenser la négligence d'un titulaire. C'est pour cela que le RFC 2725 avait prévu le mécanisme auth-override, qui semble n'avoir jamais été mis en œuvre.

Pour accéder aux données des IRR, on utilise souvent whois. Un exemple (une liste des IRR existe en ligne) :

%  whois -h whois.radb.net 192.134.5.10  
route:          192.134.5.0/24
descr:          NIC-FR-SITE-TH3
origin:         AS2485
mnt-by:         FR-NIC-MNT
mnt-lower:      FR-NIC-MNT
mnt-routes:     FR-NIC-MNT
changed:        jean-philippe.pick@nic.fr 20110214
remarks:        Peering:   peering@nic.fr
remarks:        NOC:       noc@nic.fr
remarks:        Info:      http://www.nic.fr/
source:         RIPE
remarks:        ****************************
remarks:        * THIS OBJECT IS MODIFIED
remarks:        * Please note that all data that is generally regarded as personal
remarks:        * data has been removed from this object.
remarks:        * To view the original object, please query the RIPE Database at:
remarks:        * http://www.ripe.net/whois
remarks:        ****************************
    

On y voit que seul l'AS 2485 est autorisé à être l'origine d'une annonce pour le préfixe 192.134.5.0/24.

Un plaisir des IRR existants est qu'on n'a pas de moyen simple, étant donné une ressource Internet (par exemple un préfixe IP), de savoir quel IRR utiliser. Les clients logiciels existants doivent utiliser diverses heuristiques. Par exemple GNU whois utilise un fichier de configuration local - /etc/whois.conf, des règles incluses dans le client - fichier ip_del_list dans le source, et compte sur le serveur whois de l'ARIN pour le rediriger, pour les ressources inconnues (cette fonction de redirection étant une extension absente du protocole officiel whois, normalisé dans le RFC 3912).

À noter que whois ne fournit aucune confidentialité : le protocole est du simple TCP en clair sur le port 43. (Le protocole RDAP, lui, fournit un mécanisme de chiffrement via TLS.)

La section 5 de notre RFC se penche sur le fonctionnement interne des IRR et notamment sur leur synchronisation. Il est fréquent en effet que les IRR copient les données gérées par d'autres IRR. Cela se fait en général avec le protocole NRTM (protocole ressemblant à whois, et qui est peu ou pas documenté). Ce protocole n'a aucun mécanisme de sécurité (en pratique, la seule protection est la limitation d'accès à certaines adresses IP) et est peu robuste (des erreurs de synchronisation ont déjà eu lieu). Il fonctionne en mode pull et il n'y a pas de mécanisme de notification pour indiquer la présence de données récentes. Une autre façon de synchroniser des IRR est de télécharger un fichier plat, par exemple en FTP, qu'on applique ensuite à la copie locale (ce qui facilite l'application de modifications locales). Ce téléchargement et cette synchronisation sont typiquement faits toutes les 24 heures (une période qui date de l'époque où les réseaux étaient plus lents qu'aujourd'hui, et qui n'a pas toujours été réévaluée depuis), ce qui fait que les données ne sont pas forcément de la première fraicheur. On notera que le logiciel irrd synchronise toutes les dix minutes, par défaut.

Un standard existe pour cette réplication d'IRR, le RFC 2769, mais il ne semble pas avoir jamais eu le moindre succès, peut-être parce qu'il dépend du standard de sécurité RFC 2725, également peu ou pas répandu.

Les filtres effectivement utilisés par les routeurs de l'opérateur sont créés à partir d'un IRR, et cette création implique une autre étape (et les délais associés). Typiquement, l'opérateur utilise un logiciel comme IRRtoolset, qui va traduire les objets trouvés dans l'IRR en règles pour un type de routeur donné. Ce logiciel ne tourne pas en permanence. Conséquence pratique : un changement dans l'IRR a intérêt à ne pas être urgent ! Il n'y a aucun moyen de forcer les opérateurs à télécharger tout de suite les nouvelles données, et à faire tourner la « moulinette » qui va produire les règles pour les routeurs. Si on est un client payant de l'opérateur, on peut parfois les appeler et obtenir que cette opération soit faite de suite, mais ce n'est pas toujours le cas.

Idéalement, lorsqu'une politique change (par exemple un AS annonce un nouveau préfixe), il « suffit » de changer l'IRR, d'attendre les copies dans les autres IRR, puis l'exportation des données depuis les IRR vers les routeurs. Mais le protocole BGP ne permettait pas forcément de changer les caractéristiques d'une session en vol (section 6 de notre RFC) et exigeait une opération de réinitialisation, pour que le routeur accepte les nouvelles routes. Pendant cette opération, tout ou partie du travail normal du routeur était mis en attente... Résultat, cette opération (clear ip bgp neighbor... sur les Cisco...) ne pouvait se faire que pendant les périodes de maintenance. C'est un bon exemple d'un cas où les « bonnes pratiques » (n'accepter que les préfixes décrits dans les IRR) sont irréalisables dans un environnement de production (cf. section 8). Le yakafokon ne marche pas bien dans le monde des réseaux.

Heureusement, ce problème spécifique appartient largement au passé : les extensions à BGP des RFC 2918 et RFC 7313 ont largement supprimé ces obligations.

Il y a aussi les limites inhérentes à certaines mises en œuvre de BGP (section 7 du RFC). Par exemple, au milieu des années 1990, la plupart des routeurs ne permettaient pas de modifier les listes de préfixes acceptés de manière incrémentale : il fallait effacer la liste, puis installer une nouvelle liste, créant ainsi une fenêtre de vulnérabilité pendant laquelle des routes pouvaient fuir. Là aussi, ce problème a largement disparu avec les progrès des routeurs (voir aussi les sections 1 et 8, qui expliquent bien que certains problèmes historiques d'utilisation des IRR sont désormais du passé).

Rien n'est gratuit en informatique : le stockage des listes de préfixes IP acceptés nécessite de la mémoire et, pendant longtemps, les routeurs disposaient de trop peu de mémoire (une NVRAM bien limitée, et très lente en écriture). Les routeurs modernes ont des mémoires flash ou SSD, voire des disques durs et ont donc une bien meilleure capacité. D'un autre côté, les exigences ont crû et la taille de certaines configurations peut toujours poser des défis aux mémoires des routeurs (voir « NTT BGP Configuration Size and Scope »).

Dernier problème, l'envoi aux routeurs des changements. Autrefois, il n'y avait aucun standard en ce sens. Chaque routeur avait son CLI et il fallait générer depuis l'IRR les quelques lignes de commandes qui allaient changer la configuration du routeur, lui faisant accepter de nouveaux préfixes, ou bien refuser ceux qui étaient acceptés. Le routeur recevait ensuite en telnet, puis SSH, l'ordre de charger ces quelques lignes en TFTP ou FTP, puis, plus tard, en SCP. On pouvait alors activer la nouvelle configuration.

De nos jours, il existe une norme pour cela, NETCONF (RFC 6241). On génère toujours des données depuis l'IRR, puis on utilise NETCONF pour les charger. Les données issues de la RPKI peuvent, elles, être envoyées en RTR (RFC 6810) mais cela ne concerne pas tout le reste de la configuration du routeur.

Un petit mot de sécurité pour finir (section 9 du RFC). Le but des IRR étant d'influencer le routage à distance, ces IRR sont donc des ressources sensibles : si quelqu'un peut pirater un IRR et y injecter de fausses données, il peut perturber le routage Internet. Si ce problème est trop fréquent, les opérateurs pourraient en arriver à ne plus utiliser les IRR. Une gestion rigoureuse de leur sécurité est donc cruciale.

Voilà, si vous voulez en savoir davantage sur les IRR, il y a bien sûr l'incontournable site http://www.irr.net/.


Téléchargez le RFC 7682


L'article seul

RFC 7704: An IETF with Much Diversity and Professional Conduct

Date de publication du RFC : Novembre 2015
Auteur(s) du RFC : D. Crocker (Brandenburg InternetWorking), N. Clark (Pavonis Consulting)
Pour information
Première rédaction de cet article le 12 décembre 2015


La question de la diversité dans les organisations qui contribuent d'une manière ou d'une autre au bon fonctionnement de l'Internet a souvent été discutée. Un simple coup d'œil à une réunion IETF permet de voir de nets déséquilibres (peu de femmes, peu de gens originaires d'Afrique ou d'Amérique Latine...). Comme le dit le résumé de ce nouveau RFC : « a small group of well-funded, American, white, male technicians ». Même si ce résumé est exagéré, et si le mécanisme ouvert de l'IETF a largement prouvé son efficacité, il n'est pas interdit de creuser la question « comment accroitre la diversité ? », dans l'espoir d'augmenter encore cette efficacité. (Un tel document suscitera forcément des controverses. Par exemple, personnellement, il me semble que la diversité est plutôt une question de justice - faire sauter les éventuelles discriminations - que d'une supposée meilleure efficacité.)

L'état actuel d'une organisation dépend évidemment de son histoire (section 1 du RFC). L'IETF est née d'un effort commencé à la fin des années 1960, et financé par l'ARPA. Au début, il n'y avait donc que des États-Uniens. La participation s'est ensuite étendue à d'autres milieux aux États-Unis, comme ceux financés par la NSF et non plus l'ARPA. À la création formelle de l'IETF, à la fin des années 1980, le projet a été complètement ouvert. Tout le monde peut participer, sans distinction de genre, de nationalité ou de couleur de peau, au moins en théorie.

L'IETF est à juste titre fière du résultat : le processus ouvert s'est avéré particulièrement efficace, permettant aux protocoles TCP/IP d'être très largement déployés, à la place des protocoles conçus par des SDO traditionnelles et fermées. Mais rien n'est éternel et on ne peut évidemment pas garantir que l'IETF gardera éternellement cette ouverture. Une « vigilance citoyenne » permanente est donc nécessaire.

La culture spécifique de l'IETF est née. Elle se caractérise par une grande franchise dans les discussions, loin de l'hypocrisie de beaucoup d'organisations, où on n'affiche jamais ouvertement les désaccords. Comme toute chose peut être vue de deux façons différentes, le RFC parle non pas de franchise mais de « singularly aggressive behavior, including singularly hostile tone and content ». Il ajoute que ce style n'est pas « professionnel », un terme très curieux, comme si l'aggressivité était le privilège des amateurs... Ce qui est sûr, c'est que ce style, qui allait bien aux participants du début, peut être un problème pour la diversité. Un comportement qui serait considéré « un peu trop direct » aux Pays-Bas peut être vu comme « très impoli » au Japon. (Le RFC parle de « more polite cultures », qui peuvent se sentir mal à l'aise face au style franc et direct de l'IETF.)

La section 2 du RFC décrit ensuite pourquoi le manque de diversité est un problème. D'abord, précisons que tous les attributs sont concernés, le genre, la nationalité, la religion, l'orientation sexuelle, etc. Cette section reprend l'idée que des groupes divers prennent des meilleures décisions (en citant, c'est amusant, uniquement des études états-uniennes, et presque toutes limitées au monde du management capitaliste, comme « Better Decisions Through Diversity: Heterogeneity can boost group performance »).

La question de la diversité étant ancienne, il n'est pas étonnant que le débat sur les solutions le soit aussi, et que de nombreuses techniques aient déjà été proposées, et expérimentées. Par exemple, le RFC note que des mesures purement statistiques, comme des quotas, peuvent être difficile à mettre en œuvre dans des groupes restreints. S'il y a deux Area Directors pour la Routing Area de l'IETF, ils ou elles ne peuvent pas représenter à eux deux toute la diversité souhaitée. En outre, le but est la diversité, pas juste des nombres appliqués aveuglément (avoir X % de membres de tel groupe ne sert à rien si ces X % sont silencieux et ne participent pas).

Quels sont les mécanismes qui peuvent, en pratique, limiter la diversité dans l'IETF (puisque, en théorie, tout le monde peut participer) ? Il y a plein d'exemples :

  • En théorie, la participation à l'IETF peut se faire à distance, par le biais des listes de diffusion et des différents outils de travail en groupe. En pratique, les réunions physiques sont difficiles à ignorer. La participation à ces réunions coûte de l'argent (inscription, voyage, hôtel) et cela limite la diversité en favorisant les riches. La participation à distance ne résout pas tout (par exemple en raison du décalage horaire). Accroitre l'importance des réunions par rapport aux listes de diffusion serait donc un problème pour la diversité.
  • Les participants à l'IETF sont évidemment (et heureusement) des passionnés. Cela peut mener à affirmer un peu trop vigoureusement ses préférences, d'une manière qui peut intimider certains participants, et donc limiter la diversité, en excluant les groupes qui sont traditionnellement exclus de la prise de parole publique.
  • L'IETF travaille sur la technique. Il est parfaitement normal de privilégier l'opinion de ceux et celles qui sont techniquement plus compétents. Mais même une organisation technique comme l'IETF a des activités non techniques (comme le choix des personnes qui assumeront des responsabilités) et, là, il n'y a aucune raison de n'écouter que les gens très forts en technique.
  • D'ailleurs, une partie du travail de l'IETF est de produire des documents (les RFC) qui ne doivent pas seulement être techniquement corrects, mais aussi être lisibles et compréhensibles, et pas seulement par les participants à l'IETF et pas non plus uniquement par des experts. Là encore, les compétences pour ce travail d'éducation ne sont pas forcément les mêmes que pour la technique pure et ne devraient donc pas être sous-estimées.

Mais il y a aussi des comportements anti-diversité plus directs et plus actifs comme le harcèlement ou l'intimidation. Ils peuvent être dirigés contre toutes les personnes appartenant (ou supposées appartenir) à tel ou tel groupe (comme « les femmes » ou « les homosexuels ») ou bien dirigés contre des individus spécifiques (comme l'abominable GamerGate). Aucun cas précis n'a été dénoncé à l'IETF, contrairement à ce qui arrive dans d'autres organisations, mais cela ne veut pas dire que cela n'arrivera jamais, ni même que cela n'est pas déjà arrivé : tous les cas ne sont pas publics, par exemple parce que les victimes peuvent hésiter à se plaindre, en raison du risque de représailles. Un futur RFC décrira la politique de l'IETF au sujet du harcèlement.

Malheureusement, ce RFC 7704 continue à décrire un environnement sans harcèlement comme « professional » comme si des actions aussi graves que celles du GamerGate étaient juste un manque de professionnalisme !

La section 3 du RFC s'occupe plutôt de propositions constructives : comment faire pour que tout le monde se sente bienvenu, de manière à augmenter la diversité ? Par exemple, le RFC recommande aux anglophones (la langue de travail de l'IETF est l'anglais) de parler lentement et clairement, et d'éviter les idiosyncrasies locales, ou les références culturelles trop locales (ah, ces allusions agaçantes à des émissions télé US que les non-États-Uniens n'ont pas vu...) Ainsi, la participation des non-anglophones pourra augmenter. Je note personnellement que, lorsqu'une réunion de l'IETF se tient aux États-Unis, les participants parlent bien plus vite et font moins attention à la diversité linguistique.

On peut aussi :

  • Encourager les timides à participer,
  • Avoir une attitude chaleureuse envers les nouveaux,
  • Ne pas laisser les plus expérimentés monopoliser la parole.

Tout cela n'est pas facile car il faut aussi tenir compte des exigences du travail : le but n'est pas juste d'être gentil mais surtout de créer les nouvelles normes techniques. Un exemple où il est difficile d'atteindre un bon équilibre est celui des réunions physiques des groupes de travail. L'IETF privilégie normalement l'efficacité : on saute directement dans le sujet, on ne passe pas son temps à expliquer, de toute façon, tout le monde est censé avoir travaillé avant, lisant les drafts et les discussions sur la liste de diffusion. Mais cette excellente façon de faire peut décourager les nouveaux, qui n'ont pas compris tous les tenants et aboutissants de la discussion.

Enfin, que faut-il faire contre les gens qui se comportent d'une manière qui peut faire fuir certain·e·s (section 4 du RFC) ? On peut les ignorer si ce n'est pas trop grave mais, au-delà d'un certain niveau de perturbation, il faut faire appel aux autorités (présidents du groupe de travail, ombudsperson, et président de l'IETF si nécessaire.

Quelques ressources supplémentaires sur l'activité de l'IETF à ce sujet :


Téléchargez le RFC 7704


L'article seul

RFC 7706: Decreasing Access Time to Root Servers by Running One on Loopback

Date de publication du RFC : Novembre 2015
Auteur(s) du RFC : W. Kumari (Google), P. Hoffman (ICANN)
Pour information
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 26 novembre 2015


Toute résolution DNS commence par la racine (de l'arbre des noms de domaine). Bien sûr, la mémorisation (la mise en cache) des réponses fait qu'on n'a pas besoin tout le temps de contacter un serveur racine. Mais c'est quand même fréquent et les performances de la racine sont donc cruciales. L'idée documentée dans ce RFC est donc d'avoir en local un serveur esclave de la racine, copiant celle-ci et permettant donc de répondre localement aux requêtes.

Le problème est particulièrement important pour les noms qui n'existent pas. Si les TLD existants comme .com ou .fr vont vite se retrouver dans la mémoire (le cache) du résolveur DNS, les fautes de frappe ou autres cas où un TLD n'existe pas vont nécessiter la plupart du temps un aller-retour jusqu'au serveur racine le plus proche. Les réponses négatives seront également mémorisées mais 1) il y a davantage de noms non existants que de noms existants 2) le TTL est plus court (actuellement deux fois plus court). Ces noms non existants représentent ainsi la majorité du trafic de la racine.

Bien qu'il existe aujourd'hui des centaines de sites dans le monde où se trouve une instance d'un serveur racine, ce nombre reste faible par rapport au nombre total de réseaux connectés à l'Internet. Dans certains endroits de la planète, le serveur racine le plus proche est assez lointain. Voici les RTT en millisecondes avec les serveurs racine observés depuis un réseau tunisien (notez les deux serveurs qui répondent bien plus vite que les autres, car ils ont une instance à Tunis) :

% check-soa -4 -i .
a.root-servers.net.
	198.41.0.4: OK: 2015112501 (54 ms)
b.root-servers.net.
	192.228.79.201: OK: 2015112501 (236 ms)
c.root-servers.net.
	192.33.4.12: OK: 2015112501 (62 ms)
d.root-servers.net.
	199.7.91.13: OK: 2015112501 (23 ms)
e.root-servers.net.
	192.203.230.10: OK: 2015112501 (18 ms)
f.root-servers.net.
	192.5.5.241: OK: 2015112501 (69 ms)
g.root-servers.net.
	192.112.36.4: OK: 2015112501 (62 ms)
h.root-servers.net.
	128.63.2.53: OK: 2015112501 (153 ms)
i.root-servers.net.
	192.36.148.17: OK: 2015112501 (67 ms)
j.root-servers.net.
	192.58.128.30: OK: 2015112501 (55 ms)
k.root-servers.net.
	193.0.14.129: OK: 2015112501 (72 ms)
l.root-servers.net.
	199.7.83.42: ERROR: Timeout
m.root-servers.net.
	202.12.27.33: OK: 2015112501 (79 ms)
    

Ces délais peuvent sembler courts mais ils ne forment qu'une partie du travail de résolution, il est donc légitime de vouloir les réduire encore.

En outre, ces requêtes à la racine peuvent être observées, que ce soit par les opérateurs de serveurs racine, ou par des tiers sur le projet, ce qui n'est pas forcément souhaitable, question vie privée (cf. RFC 7626).

Donc, l'idée de base de ce RFC est de :

  • Mettre un serveur esclave de la racine sur sa machine, écoutant sur l'adresse locale (loopback),
  • Configurer le résolveur pour interroger d'abord ce serveur.

Cette idée est documentée dans ce RFC mais n'est pas encouragée (c'est un très vieux débat, dont j'avais déjà parlé). En effet, cela ajoute un composant à la résolution (le serveur local faisant autorité pour la racine), composant peu ou pas géré et qui peut défaillir, entrainant ainsi des problèmes graves et difficiles à déboguer. Mais pourquoi documenter une idée qui n'est pas une bonne idée ? Parce que des gens le font déjà et qu'il vaut mieux documenter cette pratique, et en limiter les plus mauvais effets. C'est pour cela, par exemple, que notre RFC demande que le serveur local n'écoute que sur les adresses locales, pour limiter les conséquences d'une éventuelle défaillance à une seule machine.

Dans tous les cas, le RFC recommande que la configuration décrite ici ne soit pas celle par défaut : l'utilisateur doit l'activer explicitement (et en supporter les conséquences).

Pas découragé ? Vous voulez encore le faire ? Alors, les détails pratiques. D'abord (section 2 du RFC), les pré-requis. DNSSEC est indispensable (pour éviter de se faire refiler un faux fichier de zone par de faux serveurs racine). Ensuite (section 3), vous mettez un serveur faisant autorité (par exemple NSD ou Knot) qui écoute sur une des adresses locales (en 127.0.0.0/8, IPv6 est moins pratique car il ne fournit paradoxalement qu'une seule adresse locale à la machine) et qui est esclave des serveurs racine. À noter que votre serveur, n'étant pas connu des serveurs racine, ne recevra pas les notifications (RFC 1996) et sera donc parfois un peu en retard sur la vraie racine (ce qui n'est pas très grave, elle bouge peu).

Il est important de lister plusieurs serveurs maîtres dans sa configuration. En effet, si la mise à jour de la racine dans votre serveur esclave échoue, ce sera catastrophique (signatures DNSSEC expirées, etc) et cette configuration locale, contrairement à la « vraie » racine, n'a aucune redondance. (Une autre raison pour laquelle ce n'est pas une idée géniale.) Quels serveurs maîtres indiquer ? Certains serveurs racine permettent le transfert de zone (RFC 5936) mais ce n'est jamais officiel, ils peuvent cesser à tout moment (l'annexe A du RFC donne une liste et discute de ce choix). Une raison de plus de se méfier.

Il est donc important d'avoir un mécanisme de supervision, pour être prévenu si quelque chose échoue. On peut par exemple interroger le numéro de série dans l'enregistrement SOA de la racine et vérifier qu'il change.

Ensuite, une fois ce serveur faisant autorité configuré, il ne reste qu'à indiquer à un résolveur (comme Unbound) de l'utiliser (section 4 du RFC).

Voici un exemple, pris dans l'annexe B du RFC et testé. J'ai choisi l'exemple avec NSD et Unbound mais il y en a d'autres dans le RFC. D'abord, la configuration de NSD (notez la longue liste de maîtres, pour maximiser les chances que l'un d'eux fonctionne ; notez aussi l'adresse loopback choisie, 127.12.12.12) :

# RFC 7706
server:
       ip-address: 127.12.12.12
zone:
       name: "."
       request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
       request-xfr: 192.33.4.12 NOKEY    # c.root-servers.net
       request-xfr: 192.5.5.241 NOKEY    # f.root-servers.net
       request-xfr: 192.112.36.4 NOKEY   # g.root-servers.net
       request-xfr: 193.0.14.129 NOKEY   # k.root-servers.net
       request-xfr: 192.0.47.132 NOKEY   # xfr.cjr.dns.icann.org
       request-xfr: 192.0.32.132 NOKEY   # xfr.lax.dns.icann.org
       request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
       request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
       request-xfr: 2001:7fd::1 NOKEY    # k.root-servers.net
       request-xfr: 2620:0:2830:202::132 NOKEY  # xfr.cjr.dns.icann.org
       request-xfr: 2620:0:2d0:202::132 NOKEY  # xfr.lax.dns.icann.org  

Le démarrage de NSD (notez qu'il faut patienter un peu la première fois, le temps que le premier transfert de zone se passe) :

Nov 25 19:50:43 machine-locale nsd[2154]: [2015-11-25 19:50:43.791] nsd[2175]: notice: nsd started (NSD 4.1.2), pid 2154
Nov 25 19:50:56 machine-locale nsd[2154]: zone . serial 0 is updated to 2015112501.
Nov 25 19:50:56 machine-locale nsd[2154]: [2015-11-25 19:50:56.166] nsd[2154]: info: zone . serial 0 is updated to 2015112501.

C'est bon, on a transféré la zone. Testons (notez le bit AA - Authoritative Answer - dans la réponse) :


% dig  @127.12.12.12 SOA . 
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61984
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 25
...
;; ANSWER SECTION:
.			86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. (
				2015112501 ; serial
... 

C'est bon.

Maintenant, la configuration d'Unbound (prise dans le RFC) :

server:
    # RFC 7706
    do-not-query-localhost: no
    
# RFC 7706
# Requires a slave auth. running (normally, nsd)
stub-zone:
       name: "."
       stub-prime: no
       stub-addr: 127.12.12.12

Et le test :


% dig www.cnam.fr
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23562
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
...
;; ANSWER SECTION:
www.cnam.fr.		0 IN CNAME sarek.cnam.fr.
sarek.cnam.fr.		86400 IN A 163.173.128.52

Ça a marché. Avec tcpdump, on voit le trafic (faible, en raison du cache) vers le serveur racine local :

08:37:24.869569 IP (tos 0x0, ttl 64, id 7734, offset 0, flags [none], proto UDP (17), length 76)
    127.0.0.1.10908 > 127.12.12.12.53: 42633% [1au] A? www.tunisair.com.tn. (48)
08:37:24.869671 IP (tos 0x0, ttl 64, id 12657, offset 0, flags [none], proto UDP (17), length 685)
    127.12.12.12.53 > 127.0.0.1.10908: 42633- 0/8/13 (657)
08:38:04.734565 IP (tos 0x0, ttl 64, id 12887, offset 0, flags [none], proto UDP (17), length 71)
    127.0.0.1.45221 > 127.12.12.12.53: 25787% [1au] A? www.edreams.es. (43)
08:38:04.734645 IP (tos 0x0, ttl 64, id 19270, offset 0, flags [none], proto UDP (17), length 749)
    127.12.12.12.53 > 127.0.0.1.45221: 25787- 0/10/14 (721)
08:38:04.734867 IP (tos 0x0, ttl 64, id 12888, offset 0, flags [none], proto UDP (17), length 70)
    127.0.0.1.40575 > 127.12.12.12.53: 61589% [1au] AAAA? ns-ext.nic.cl. (42)
08:38:04.734932 IP (tos 0x0, ttl 64, id 19271, offset 0, flags [none], proto UDP (17), length 622)
    127.12.12.12.53 > 127.0.0.1.40575: 61589- 0/8/11 (594)
08:44:00.366698 IP (tos 0x0, ttl 64, id 27563, offset 0, flags [none], proto UDP (17), length 62)
    127.0.0.1.22009 > 127.12.12.12.53: 30565% [1au] A? po.st. (34)
08:44:00.389126 IP (tos 0x0, ttl 64, id 34039, offset 0, flags [none], proto UDP (17), length 404)
    127.12.12.12.53 > 127.0.0.1.22009: 30565- 0/6/5 (376)
08:44:01.229635 IP (tos 0x0, ttl 64, id 27693, offset 0, flags [none], proto UDP (17), length 69)
    127.0.0.1.65173 > 127.12.12.12.53: 32911% [1au] AAAA? ns3.perf1.eu. (41)
08:44:01.229705 IP (tos 0x0, ttl 64, id 34207, offset 0, flags [none], proto UDP (17), length 560)
    127.12.12.12.53 > 127.0.0.1.65173: 32911- 0/8/10 (532)

À noter qu'il existe un brevet futile (comme tous les brevets...) de Verisign sur cette technique : déclaration #2539 à l'IETF.


Téléchargez le RFC 7706


L'article seul

RFC 7695: Distributed Prefix Assignment Algorithm

Date de publication du RFC : Novembre 2015
Auteur(s) du RFC : P. Pfister, B. Paterson (Cisco Systems), J. Arkko (Ericsson)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF homenet
Première rédaction de cet article le 25 novembre 2015


Le projet Homenet, qui vise à relier en un réseau local autonome tous les objets électroniques de la maison, avance (cf. RFC 7368). Parmi les briques indispensables à l'édification de ce réseau de la maison, il fallait un mécanisme d'allocation des adresses IP. Un réseau Homenet devant fonctionner sans administration système, ce mécanisme devait être entièrement automatique. C'est ce que propose ce RFC.

Contrairement au traditionnel réseau domotique actuel, le réseau Homenet peut être constitué de plusieurs réseaux (au sens IP du terme), avec chacun son préfixe IPv6. Si la maison a un préfixe IPv6 délégué, il faut le découper et affecter les sous-préfixes à chaque réseau de la maison. Normalement, c'est le travail de l'administrateur réseaux, qui centralise l'information puis la distribue. Mais, à la maison, il n'y a personne qui puisse ou veuille faire ce travail, il faut donc l'automatiser. Et ce doit être un algorithme réparti car un réseau Homenet n'a pas de machine « chef ».

Cet algorithme prend en entrée une liste de préfixes (le ou les préfixes délégués à la maison), et répartit les sous-préfixes à chaque lien de façon à ce que chaque lien reçoive au plus un sous-préfixe de chacun des préfixes délégués, qu'il n'y ait pas de recouvrement entre les préfixes, et que le tout soit stable, tant que la topologie du réseau ne change pas (cf. section 3 sur les conditions d'usage de cet algorithme).

Le principe (section 4) est que chaque routeur (je simplifie : ce n'est pas forcément un routeur qui choisit le préfixe) va, pour chaque lien, tirer au hasard (pour minimiser le risque de collision), un préfixe plus spécifique que le préfixe délégué et le transmettre ensuite à tout le réseau, via un algorithme d'inondation. Notez bien que c'est une présentation simplifiée : par exemple, le préfixe initial n'est pas forcément tiré au hasard (cf. section 5).

Cet algorithme dépend donc de l'existence d'un algorithme d'inondation, qui n'est pas spécifié dans ce RFC, plusieurs sont envisageables (comme ceux de OSPF - cf. RFC 7503 - ou de HNCP - Home Networking Control Protocol). Il dépend aussi de l'existence d'un identificateur unique par nœud (rappelez-vous que ce RFC n'est qu'une seule des briques d'Homenet, il n'est pas utilisable seul, par exemple il ne dit pas comment cet identificateur est attribué), et que ces identificateurs ont un ordre. Cela servira au cas où plusieurs routeurs veulent le même préfixe, avec la même priorité (celui qui a l'identificateur le plus grand gagne).

Parmi les nombreuses options de l'algorithme, notez qu'il gère également le cas où le lien a déjà eu un préfixe alloué et souhaite le réutiliser. (Une telle stabilité est souhaitable.)

Enfin, la section 8, sur la sécurité, rappelle que ce protocole n'a pas de protection contre un acteur malveillant. Par exemple, un routeur gourmand qui se prend le préfixe entier pour l'un de ses liens empêche les autres de le réclamer. Un méchant peut aussi annoncer quelque chose tout le temps pour empêcher la convergence, réalisant ainsi une attaque par déni de service. En outre, cet algorithme dépend de la sécurité de l'algorithme d'inondation et de celle du mécanisme de sélection de l'identificateur.

Une mise en œuvre de HNCP en logiciel libre existe, hnetd. Elle contient cet algorithme (cf. fichiers src/pa_core*, « pa » signifiant prefix assignment).


Téléchargez le RFC 7695


L'article seul

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

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