Mon blog

La cryptographie évoluant sans cesse, il est nécessaire, pour tous les protocoles Internet qui en dépendent, de prévoir la possibilité d'utiliser plusieurs algorithmes de cryptrographie, au fur et à mesure que les anciens craquent sous les coups de la cryptanalyse. Le format PGP, normalisé dans le RFC 4880 peut ainsi désormais utiliser l'algorithme de chiffrement symétrique Camellia.

Le RFC est très court car il n'y a pas grand'chose à dire. Camellia, un algorithme symétrique à blocs, d'origine japonaise, est décrit dans le RFC 3713. Notre RFC 5581 se contente de l'ajouter à la liste officielle des algorithmes PGP, aux côtés de protocoles comme AES et Twofish.

Ce mois d'avril marque le quarantième anniversaire du premier RFC, le RFC 1, Host software, publié le 7 avril 1969.

Le RFC 5540 célèbre cet anniversaire en notant (section 1) que les 5400 RFC publiés (il y a des trous dans la numérotation) comportent 160 000 pages. Les RFC existaient donc longtemps avant l'IETF. Leur succès est celui de l'Internet : simple, librement accessible, fondé sur des normes ouvertes. La série des RFC a donc largement mérité son succès.

Pendant vingt-neuf ans, le RFC Editor était Jon Postel. Ce rôle est désormais assuré par une équipe de l'ISI, dirigée par Bob Braden. L'ISI a récemment publié un bilan de son action, à la veille du transfert de la fonction de RFC Editor à une autre organisation, pas encore choisie.

L'auteur du RFC 1 a également écrit un excellent article résumant la signification de ce travail, How the Internet Got Its Rules, où il rappelle que le RFC 1 a été terminé dans une salle de bains mais aussi que l'Internet n'aurait jamais existé si les requins de la propriété intellectuelle avaient pu donner leur avis. Le RFC 2555 avait, pour le trentième anniversaire, rassemblé les souvenirs de nombreux pionniers.

Les HBA (Hash Based Addresse) de ce RFC sont des adresses IPv6 fondées sur un résumé cryptographique d'un certain nombre de valeurs, permettant de garantir que toutes les adresses HBA d'un groupe donné sont liées. Elles sont notamment utilisées par le protocole SHIM6 (RFC 5533). Contrairement aux adresses CGA du RFC 3972, dont elles sont proches, les HBA ne nécessitent pas de cryptographie asymétrique. Par contre, elles ne permettent pas de prouver le lien entre une machine et une adresse IP, juste de prouver que les adresses d'un groupe ont été générées par la même machine.

Quel problème essaient de résoudre les HBA (section 1 du RFC) ? Dans les protocoles conçus pour le multihoming comme SHIM6 (RFC 5533), une machine annonce à ses pairs qu'elle a plusieurs adresses IP. Qu'est-ce qui l'empêche d'annoncer des adresses qui ne sont pas « à elle », soit pour capter le trafic d'un tiers, soit pour réaliser une DoS contre ce tiers en provoquant l'envoi de nombreux paquets vers lui ? SHIM6 utilise deux mécanismes proches, les CGA et les HBA. Dans les deux cas, les adresses IP annoncées peuvent être vérifiées cryptographiquement. CGA signe les adresses avec une clé asymétrique donc le pair peut vérifier qu'une adresse « appartient » bien au pair. HBA procède différemment : une adresse HBA est composée de deux parties, un préfixe de 64 bits et un identificateur local (également de 64 bits) qui est un résumé de l'ensemble des préfixes IP de la machine (puisque HBA est fait pour les machines multihomées, il y a plus qu'un préfixe) et d'un nombre aléatoire. HBA ne permet donc pas de prouver l'appartenance d'une adresse IP à une machine, uniquement le fait que toutes les adresses HBA d'un même groupe sont liées. Une machine SHIM6 qui utilise HBA ne pourra donc pas ajouter ou retirer des adresses IP au jeu d'adresses annoncé (elle le pourrait avec CGA) et HBA ne convient donc pas à des problèmes comme la renumérotation d'un réseau ou comme la mobilité. Mais le pair pourra vérifier, lors de l'établissement de l'association SHIM6, que ces adresses sont toutes liées à la même machine et sans les calculs longs et compliqués de la cryptographie asymétrique. HBA est donc plus économe. (Voir la section 3.3 pour une discussion plus détaillée du cahier des charges de HBA.)

Autrement, HBA et CGA sont très proches, utilisent les mêmes formats et ont également en commun de ne pas nécessiter de PKI.

Les risques de sécurité que les HBA traitent sont résumés en section 3.1, suivant le RFC 4218 (et traités en détail dans la section 11). En gros, les deux attaques possibles sont le détournement (un méchant va essayer d'obtenir des paquets qui n'étaient pas normalement pour lui) et l'inondation (un méchant va essayer de noyer une victime sous un flot de paquets). HBA protège uniquement contre les premier risque, d'autres protocoles doivent gérer le second, par exemple en testant si le pair est joignable (ce que fait SHIM6).

La section 3.2 donne le principe de base de HBA : si une machine a trois préfixes IPv6, mettons A, B et C, elle choisit un nombre M au hasard puis génère trois adresses, une par préfixe. Pour A, elle concatène au préfixe le résumé cryptographique de la concaténation de M, de A et la la liste des préfixes (A, B et C). Même principe pour les autres préfixes. Étant donné une liste de préfixes (rappelez-vous que, avec HBA, elle doit être stable), un préfixe et le nombre M, on peut donc vérifier qu'une adresse fait bien partie du groupe, en recalculant le résumé.

Une particularité des HBA est qu'elles sont normalisées comme étant une variante des CGA du RFC 3972. La section 4 de notre RFC est donc dédiée à l'étude de la compatibilité exacte entre HBA et CGA. Cette compatibilité permet d'avoir des adresses qui sont à la fois HBA et CGA. On peut donc les utiliser dans des protocoles comme SEND (RFC 3971), qui impose des CGA. Il y a donc trois types d'adresses :

• Les CGA pures, normalisées dans le RFC 3972, qui n'incluent donc pas la nouvelle extension « multi-préfixe » (section 5),
• Les HBA pures qui n'utilisent pas du tout de clé publique,
• Les mixtes qui sont liées à la fois à une clé publique (CGA) et à un jeu de préfixes.

Quelle est cette extension « multi-préfixe » ? Décrite dans la section 5 de notre RFC, elle permet de représenter l'ensemble des préfixes liés par HBA. C'est cet ensemble qui servira d'entrée au hachage cryptographique.

Le mécanisme exact de génération est en section 6. Il est dérivé de celui de CGA, en section 4 du RFC 3972. La plus grande différence avec CGA est que l'adresse ne peut pas être fabriquée sans connaître les préfixes. Toutes les adresses doivent donc être générées ensemble. L'entrée des fonctions cryptographiques comporte donc l'extension multi-préfixe, qui indique les préfixes, une clé publique (si l'adresse est une mixte CGA/HBA) ou une initialisation aléatoire (nonce) - encodée comme si c'était une clé publique CGA - si l'adresse est une HBA pure et les autres paramètres de CGA.

À ce stade, on a donc un ensemble d'adresses disponible pour la machine. Si une autre machine veut vérifier ces adresses, elle doit utiliser les techniques de la section 7. Par exemple, 7.2 expose comment vérifier qu'une adresse donnée fait bien partie d'un ensemble HBA. (On vérifie que le préfixe de l'adresse est dans l'ensemble indiqué dans l'extension multi-préfixe puis on refait le hachage et on vérifie que l'identificateur local, les 64 bits les plus à droite, sont bien les mêmes.)

La publication des adresses HBA dans le DNS fait l'objet de la section 9. La recommandation est que « ça dépend ». Selon que la machine a uniquement des adresses HBA ou pas, selon que les préfixes soient des ULA ou pas, il peut être raisonnable ou pas de publier ces adresses HBA dans les DNS. Puisqu'une adresse HBA ressemble à n'importe quelle autre adresse IPv6, le client qui les trouve dans le DNS ne sait pas s'il a affaire à une HBA ou pas et il doit donc déduire cela d'un autre mécanisme.

Une mise en œuvre de HBA en C se trouve en http://ops.ietf.org/multi6/francis-hba.tar.gz.

Quelles sont les méthodes disponibles dans l'Internet d'aujourd'hui pour assurer une plus grande fiabilité à un site ? On peut payer plus cher son FAI mais cela ne garantit pas une meilleure fiabilité. Aujourd'hui, la seule méthode réaliste est d'avoir plusieurs FAI, le multihoming. Mais cela implique d'avoir ses adresses IP à soi et de faire du BGP avec ses FAI. Si on utilise en effet des adresses « appartenant » à un des FAI, la panne de celui-ci empêchera de les utiliser, même si l'autre connexion est intacte. Comme les protocoles de transport comme TCP sont liés aux adresses IP utilisées, cela veut dire que toutes les sessions TCP existantes seront cassées. Ce n'est pas forcément génant pour HTTP, aux connexions souvent courtes, mais bien plus grave pour, par exemple, SSH. Le multihoming sans BGP permet donc d'établir de nouvelles connexions, mais pas de faire vivre les anciennes.

Il faut donc faire du BGP. Mais c'est complexe et, surtout, cela impose de mettre ses adresses IP dans la table de routage globale, qui est déjà bien chargée. Shim6, objet de ce RFC, propose une autre solution, lier les connexions à un groupe d'adresses IP, pas à une seule comme actuellement. On pourrait alors changer l'adresse utilisée en couche 3 sans dommage pour la couche 4. Shim6 dispense donc d'utiliser BGP.

Ce nouveau protocole dépend d'IPv6, comme son nom l'indique, car sa sécurité et même son fonctionnement de base nécessitent des mécanismes propres à IPv6. Shim6 se situe conceptuellement entre la couche 3 et la couche 4, d'où son nom de shim (mince couche entre deux vraies couches). On peut noter que SCTP (RFC 3286) part d'une idée proche (le groupe d'adresses IP) mais fonctionne, lui, dans la couche 4. Shim6, au contraire, est accessible à tous les protocoles de transport comme, par exemple, le TCP traditionnel.

Une autre façon de s'attaquer au même problème est de séparer complètement l'identificateur du localisateur comme le fait HIP, ce qui permet de traiter des problèmes supplémentaires comme la mobilité. Cette séparation est explicitement marquée comme « non-but » dans Shim6, qui ne manipule que des « localisateurs » même si l'un d'eux, baptisé « identificateur » sans l'être vraiment, a un rôle particulier dans l'association (section 1.3, qui définit les ULID - Upper-Layer Identifier).

Il existe donc désormais un grand choix de protocoles, tous prometteurs mais tous aussi marginaux les uns que les autres.

La gestation de ce protocole a été longue et difficile. Au final, Shim6 est un protocole très complexe, avec un RFC de plus de 130 pages (sans la détection de panne, qui fait l'objet d'un document séparé, le RFC 5534).

La section 1 expose les principes de base de Shim6. Le protocole est mis en œuvre complètement dans les machines finales, il ne nécessite aucune participation des routeurs. Chaque machine a un jeu d'adresses IP possibles, a priori toutes liées à un FAI (Shim6, contrairement à BGP, n'impose pas d'utiliser des adresses PI - Provider Independant). À un moment donné, une paire d'adresses (source et destination) est utilisée pour la communication effective et les machines peuvent changer de paire par la suite (le mécanisme de détection des pannes, ou des autres raisons qui qui déclencheraient un changement de paire, sera spécifié dans un autre document). Pour assurer qu'une machine ne puisse pas prétendre être utilisatrice d'une adresse IP quelconque, des adresses HBA (Hash Based Addresses) ou CGA (signées par la cryptographie) sont utilisées.

La section 1.1 détaille le cahier des charges et la 1.2 l'anti-cahier des charges, les questions qui étaient hors-sujet pour Shim6. Dans le cahier des charges, cette section 1 insiste notamment sur le côté « opportuniste » de Shim6 : contrairement à HIP, une association Shim6 peut commencer sans échange particulier et être établie bien après la connexion TCP. D'autre part, outre la résistance aux pannes, Shim6 doit permettre la répartition de charge, selon des paires d'adresses IP différentes. Dans l'anti-cahier des charges, se trouve la question de la rénumérotation, suite à des changements de FAI. Shim6 ne la traite pas (section 1.5) : l'ensemble des adresses IP disponibles doit être fixe, ou, en tout cas, changer lentement. Shim6 ne permet donc pas le nomadisme, même si celui-ci pourra être traité dans le futur. En attendant, au début de l'association Shim6, toutes les adresses IP possibles doivent être connues.

Shim6 est un protocole de couche « 3,5 », entre la couche de réseau et la couche de transport (section 1.6). Les protocoles situés au dessus de Shim6, comme TCP ou UDP utilisent des adresses IP habituelles, les ULID (Upper-Layer Identifier, voir la section 2.1 pour une terminologie complète). En dessous d'eux, Shim6 va fabriquer des paquets IP dont les adresses sources ou destination pourront être des ULID (puisque Shim6 ne sépare pas localisateurs et identificateurs) ou bien des purs localisateurs, différents des ULID que continue à utiliser le protocole de transport. Shim6 maintient, pour chaque paire d'ULID, la liste des localisateurs possibles (les adresses IP utilisables pour la communication).

Après une section 2 de terminologie et de notations, puis une section 3 sur les pré-supposés de Shim6, voici venir le protocole lui-même en section 4. L'essentiel du fonctionnement de Shim6 peut être résumé dans les étapes suivantes :

• Une machine A en contacte une autre, B, par les moyens classiques, sans Shim6. Par exemple, elle établit une connexion TCP.
• Une des deux machines, ou les deux, décide que ce serait une bonne idée de faire du Shim6. Par exemple, plus de N paquets ont été échangés et il semble donc bien que la connexion va durer, ce qui rend intéressant de la faire résister aux pannes. Un contexte Shim6 (une association entre les deux machines) est alors mis en place.
• Les échanges continuent comme avant. À ce stade, bien que le contexte Shim6 aie été configuré, rien n'apparait dans les paquets échangés.
• Une panne survient, rendant impossible d'utiliser les localisateurs actuels (les adresses IP de A et B). C'est là que Shim6 sert à quelque chose, une nouvelle paire de localisateurs est choisie et un en-tête d'extension est ajouté désormais à chaque paquet, pour indiquer le contexte utilisé (section 4.1). Ce contexte servira à trouver les ULID (les identificateurs) utilisés. Shim6 réécrira alors les paquets avant de les transmettre à TCP... qui ne se sera rendu compte de rien, il utilisera les mêmes adresses IP tout le temps (section 12 pour les détails sur la réception des paquets).

Donc, on ne peut pas, en observant le réseau, savoir si un contexte Shim6 est disponible car les paquets ne sont modifiés (par l'ajout de l'en-tête d'extension Shim6) que si la première paire de localisateurs devient inutilisable.

Ces en-têtes d'extension sont une nouveauté d'IPv6 (RFC 2460, section 4). Leur présence dans les paquets IPv6 est rare aujourd'hui mais des techniques comme Shim6 pourrait la rendre plus fréquente (si les différents pare-feux acceptent de les laisser passer). La section 4.6 décrit le placement de l'en-tête Shim6.

Les informations mémorisées par chaque machine (ULID de la connexion, localisateurs possibles, contextes, etc) sont décrites dans la section 6.

Comme toute technique d'indirection, c'est-à-dire comme toutes les techniques qui découplent, si peu que ce soit, l'identificateur et le localisateur, Shim6 est vulnérable aux attaques portant sur la correspondance entre utilisateur et localisateur. Qu'est-ce qui empêche un méchant, par exemple, d'ajouter une adresse IP qu'il ne contrôle pas légitimement, au jeu des localisateurs, pour que son partenaire Shim6 y envoie des paquets ? La section 4.4 résume les techniques utilisées pour empêcher cela, qui tournent autour d'adresses cryptographiques (RFC 3972 et RFC 5535) et de tests de la connectivité effective (voir si le pair répond avant de le noyer sous les paquets, cf. section 5.13 pour le message Probe).

Comment se fait l'établissement du contexte Shim6 ? Par un échange de quatre paquets (comme dans HIP) et non pas de trois paquets comme avec TCP. La section 4.5 résume ces quatre paquets, I1, R1, I2 et R2, pour lesquels l'explication complète est en section 7 (et la machine à états dans la section 20). La liste des localisateurs connus est envoyée dans ces paquets mais elle peut être modifiée par la suite, Shim6 ayant d'autres messages de contrôle que ces quatre-ci (section 10).

Le format des messages sur le câble est normalisé dans la section 5. Les messages de contrôle de Shim6 ne circulent ni sur UDP, ni sur TCP mais dans son propre protocole, de numéro 140 (section 17). Le début du paquet est le même pour tous les messages Shim6 (section 5.1). Les messages de la communication en cours ont le 16ème bit à 1 et sont décrits dans la section 5.2. Les messages de contrôle ont ce 16ème bit à zéro et font l'objet de la section 5.3.

Comment se fait le premier contact ? La procédure est synthétisée dans la section 13. La méthode recommandée est d'essayer toutes les adresses disponibles, de ne pas renoncer simplement parce qu'une paire d'adresses émetteur-récepteur ne fonctionne pas. Le problème de cette méthode est que, mise en œuvre directement (boucler sur toutes les adresses de la liste de struct addrinfo renvoyée par getaddrinfo() et tenter un connect() sur chacune) va mener à de longs délais puisqu'il faudra attendre l'expiration du délai de garde. Idéalement, il faudrait donc tenter des connexions non-bloquantes simultanément.

Comment est établi un contexte Shim6 ? La section 7 fournit toutes les informations nécessaires. L'échange nécessite quatre paquets (section 7.3), ce qui permet (contrairement à l'échange à trois paquets de TCP) de ne pas garder d'état dès le premier paquet, tout en permettant l'usage d'options. Cette section couvre également la vérification des adresses utilisées (section 7.2), vérification, par la cryptographie, que le « propriétaire » d'un ULID a le « droit » d'utiliser ces localisateurs et vérification que ces localisateurs fonctionnent.

Un problème classique de toute séparation, même partielle, entre l'identificateur et le localisateur, est le traitement des erreurs envoyées par ICMP. L'émetteur de ces erreurs ne connait pas forcément Shim6 et gère simplement des adresses IP. Il faut donc, sur réception d'un message ICMP, retrouver le contexte Shim6 (section 8) et transmettre le message ICMP à la couche de transport puisque, dans la plupart des cas, c'est elle qui doit être informée des erreurs. Cela nécessite de réécrire le message pour remplacer les adresses IP par des ULID, les seules adresses que connaisse la couche 4.

Arrivé à ce point du RFC, il est temps de voir quelques contraintes d'implémentation. Elles sont regroupées dans la section 15. D'abord, si Shim6 change la paire de localisateurs utilisée, les paquets IP passeront probablement par un chemin bien différent, et Shim6 devrait donc (section 15.1) prévenir la couche de transport que la congestion sera probablement différente.

Tout nouveau protocole qu'on tente de déployer sur l'Internet doit se battre contre les middleboxes, les équipements intermédiaires qui refusent fréquemment les paquets inconnus. La section 15.2 soulève le problème. Par exemple, quoique que Shim6 soit une technique entièrement « machine », qui est gérée uniquement aux extrêmités du réseau (section 15.3), il est toujours possible qu'un pare-feu bloque les paquets Shim6. Cela apparaitra à chacune des machines comme une absence de Shim6 chez le pair. Outre cette paranoïa générale des pare-feux, Shim6 soulève des questions particulières puisque l'autorisation ou l'interdiction des paquets devraient, idéalement, prendre en compte les ULID, pas les adresses IP du paquet. Shim6 aura donc les mêmes difficultés que HIP ou SCTP à s'installer dans un Internet très ossifié.

Enfin, certaines applications passent des adresses IP à leurs pairs (par exemple les téléphones SIP) et elles devraient donc s'assurer (section 15.4) qu'elles n'envoient pas uniquement l'ULID mais un nom de domaine ou bien le jeu complet de localisateurs.

Et la sécurité ? La section 16 résume les problèmes spécifiques à Shim6 (cf. RFC 4218) et les solutions possibles. Contre le risque d'usurpation d'adresses IP, les adresses cryptographiques, HBA (RFC 5535) et CGA (RFC 3972). Contre les attaques par inondation (en redirigeant du trafic vers une machine innocente), les tests d'atteignabilité (vérifier que la machine répond positivement avant de lui transmettre des gigaoctets).

En parlant d'implémentations, quelle est la situation de Shim6 de ce côté ? Une équipe coréenne avait mis en œuvre Shim6 pour le noyau Linux. Leur travail avait été décrit dans l'Internet-Draft draft-park-shim6-implementation mais le travail semble ne pas être allé plus loin. Plus récemment, une autre équipe, belge, avait réalisé LinShim6, sur le même système et documenté dans l'Internet-Draft draft-barre-shim6-impl. Il existe aussi une autre implémentation Linux dans l'OpenHIP. Une liste à jour des tentatives se trouve sur le site « officiel ».

Terminons ce résumé du RFC 5533 avec les annexes. La section 19 décrit de possibles extensions futures du protocole. Celui-ci est déjà bien assez compliqué comme cela et beaucoup d'idées ont été laissées à de futures nouvelles versions, comme la pré-vérification d'une paire de localisateurs de secours, l'interaction avec Mobile IP ou encore la normalisation d'une API. À l'heure actuelle, il n'existe pas d'API standard pour l'application qui voudrait être consciente de Shim6 et, par exemple, forcer ou, au contraire, interdire son utilisation (section 4.3).

L'excellente section 22 intéressera les étudiants en réseaux informatiques et tous les curieux qui se demandent « mais pourquoi les choses sont-elles comme elles sont ? ». Elle est en effet consacrée aux choix alternatifs, à ce qui aurait pu être. Parmi les idées envisagées et finalement abandonnées, on trouve d'autres solutions de sécurité (section 22.4) comme l'utilisation de cookies lors de l'établissement de l'association. La connaissance du cookie prouvait qu'on était toujours le même pair. Mais le cookie aurait été vulnérable lors d'une écoute du réseau. D'où le choix final des adresses cryptographiques. Dans le cas de HBA (RFC 5535), tous les localisateurs (toutes les adresses IP) sont liées et on peut donc vérifier que deux adresses appartiennent au même ensemble HBA. Par contre, HBA ne permet pas d'ajouter ou de supprimer des localisateurs. Dans le cas de CGA (RFC 3972), l'ULID est une clé publique (plus rigoureusement, un résumé d'une clé publique) et signe les localisateurs, ce qui autorisde l'ajout de localisateurs. Mais CGA dépend donc de la cryptographie à clé publique, plus coûteuse.

La création d'un contexte Shim6 (ce que j'ai baptisé association) se fait avec quatre paquets. On aurait pu en utiliser moins (section 2.5), pour accélerer l'association mais le choix a finalement été de privilégier la protection contre les attaques DoS. Une des raisons du choix est que, de toute façon, l'établissement de l'association ne bloque pas la connexion qui utilise Shim6, puisque les premiers paquets peuvent passer avant que Shim6 ne crée son contexte. Ce n'est donc pas trop grave si l'association prend du temps.

Le courrier électronique ne fournit pas assez de garanties pour un certain nombre d'utilisations, notamment celles exigeantes en matière de sécurité. Il y a donc beaucoup de propositions pour améliorer les choses, dont ce RFC qui propose un mécanisme par lequel un message électronique peut annoncer le nom d'un certificateur, qui se portera garant (to vouch for) de son sérieux.

La section 1 résume le principe : un en-tête VBR-Info: est ajouté au message par l'émetteur, et le receveur qui veut vérifier le message va demander aux tiers certificateurs, listés dans cet en-tête, leur opinion. Il y a plusieurs points importants pour que cela améliore réellement la sécurité comme le fait que le receveur doit d'abord authentifier le domaine émetteur ou comme l'importance pour le receveur de ne consulter que des certificateurs qu'il connait et apprécie (autrement, l'émetteur pourrait toujours ne mettre que les noms de ses copains à lui dans le VBR-Info:, cf. section 8).

Vouch By Reference est donc une technique d'autorisation, pas d'authentification, et la différence est essentielle.

La section 2 explique l'utilisation de l'en-tête VBR-Info: (ou des en-têtes ; ils peuvent être plusieurs). Il contient le nom du domaine émetteur (celui qu'il faut authentifier avant de contacter les certificateurs), le type du message (un même émetteur peut avoir des messages de types différents par exemple « publicité » et « opérationnel ») et enfin la liste des certificateurs qui peuvent se porter garant, sur le thème de « Oui, nous connaissons example.com et tous ses messages de type opérationnel sont utiles ». La syntaxe formelle est en section 4 et un exemple de VBR-Info: est :

VBR-Info: md=example.com; mc=operation;
          mv=certifier.example;

où example.com est l'émetteur du message et certifier.example le certificateur qui peut se porter garant.

Le processus exact de validation d'un message entrant fait l'objet de la section 3. En gros, le récepteur :

• Extrait le nom de domaine pertinent et l'authentifie, par exemple avec DKIM (détails en section 7 du RFC),
• Sélectionne dans la liste des certificateurs ceux auxquels il fait confiance,
• Contacte les certificateurs, via une requête DNS.

C'est la section 5 qui fournit les détails sur cette requête DNS. Elle utilisera le type d'enregistrement TXT sur le nom de domaine du certificateur, préfixé par le nom de domaine à certifier et la chaîne de caractères _vouch. Ainsi, dans l'exemple ci-dessus, la requête DNS sera pour example.com._vouch.certifier.example. S'il y a une réponse, c'est que certifier.example se porte garant et le texte de la réponse contient une liste des types garantis (par exemple « operational security » garantit les messages opérationnels et de sécurité et ne dit rien sur les message de type advertisment). Les types sont décrits plus en détail en section 6. Notez bien qu'ils sont gérés par l'émetteur et ne « prouvent » donc rien, ils ne sont là que pour la traçabilité. Il existe certains types standards comme transaction (message envoyé en réponse à une action spécifique de l'utilisateur).

Enfin, la section 7 revient en détail sur l'authentification du nom de domaine de l'émetteur. Sans précaution particulière, un VBR-Info: ne vaudrait rien puisque le méchant pourrait toujours mettre un autre domaine que le sien dans le VBR-Info:. Notre RFC recommande donc de vérifier ce nom avec DKIM (RFC 4871), présenté en section 7.1 mais il permet également d'autres techniques comme SPF (RFC 4408 et section 7.3).

Contrairement à d'autres SDO, l'IETF utilise relativement peu de langages formels dans ses normes. Beaucoup de protocoles réseaux sont normalisés uniquement en langage naturel. Malgré les efforts des chercheurs qui ont développé de nombreux langages de spécification comme Lotos ou le désormais abandoné Estelle, malgré l'exemple de SDO qui dépendent de langages comme SDL/Z100, l'IETF reste fidèle aux langues humaines. Parfois, un langage formel est quand même utilisé pour une partie d'une norme. Souhaitons donc la bienvenue à RBNF (Routing Backus-Naur Form), nouveau venu dans cette famille.

Les langages formels n'étaient pas du tout utilisés au début des RFC. Petit à petit, certains sont arrivés comme ROHC-FN (RFC 4997) mais ils sont loin d'avoir pénétré partout. L'IETF n'a ainsi toujours pas de langage formel standard pour les machines à états, ni pour le format des paquets, toujours spécifiés par de l'art ASCII. Il y a plusieurs raisons à cet état de fait, l'une étant que les langages formels existants sont souvent de grosses usines à gaz assez irréalistes (l'apprentissage du langage devient une contrainte et plus une aide) et n'ont souvent même pas une seule mise en œuvre en logiciel libre.

Mais un des grands succès IETF en matière de langage formel est un langage pour écrire des grammaires, ABNF (RFC 5234). Il est utilisé pour de très nombreux RFC. Comme souvent à l'IETF, son utilisation n'est toutefois pas obligatoire et on peut constater que plusieurs RFC dans le domaine du routage ont choisi une autre forme de BNF, qui n'était pas normalisée jusque là. C'est ainsi que (section 1.2) les RFC 2205, RFC 3473, RFC 4204, RFC 5440 et bien d'autres utilisent un dialecte désormais nommé RBNF pour Routing Backus-Naur Form. Ce dialecte vient d'être normalisé dans notre RFC 5511. Son usage est conseillé pour des RFC reprenant et étendant les techniques décrites dans les RFC cités plus haut. Mais, pour des projets complètement nouveaux, il est plutôt conseillé de regarder ABNF (section 1.3).

La définition complète du langage figure en section 2. Il est plus proche de la BNF classique qu'ABNF ; par exemple, la définition d'une règle utilise ::= et pas = comme en ABNF (section 2.2.1). Les noms des règles sont systématiquement entre chevrons (section 2.1.1), par exemple (tous les exemples sont tirés du RFC 5440) <request-list> ou bien <Keepalive Message>. Les définitions terminales sont typiquement écrites en majuscules et sans espaces (section 2.1.2) comme <BANDWIDTH> ou <NO-PATH>. Les règles peuvent être combinées par des opérateurs par exemple la concaténation (section 2.2.2) notée simplement en mettant les noms des règles à la queue-leu-leu ou bien le choix (section 2.2.4) noté |. La répétition peut se faire par récursion par exemple <request-list> ::= <request> [<request-list>] (section 2.2.5).

Avec uniquement ces opérateurs, il pourrait y avoir un risque de confusion avec des règles comme celle, hypothétique, <truc> ::= <machin> | <chose> <bidule>. Est-ce que <machin> seul est légal ? Tout dépend de la précédence entre le choix et la concaténation. Les règles exactes de précédences sont normalisées dans la section 2.4 mais tous les lecteurs ne les connaissent pas forcément sur le bout des doigts et il est donc demandé de groupe explicitement les règles avec des parenthèses (section 2.2.6). La concaténation lie plus fortement que l'alternative et, donc, la bonne interprétation de la règle ci-dessus est <truc> ::= <machin> | (<chose> <bidule>).

Selon la section 3, consacrée à la validation automatique des grammaires, il n'y a malheureusement pas encore d'outil automatique pour RBNF comme il en existe pour ABNF. Un jour où j'aurai le temps, je modifierai Eustathius pour cela...

Le DNS est au cœur de la plupart des transactions sur l'Internet. Bien connu, très fiable et largement déployé, il est un service très tentant, lorsqu'on veut déployer un nouveau service d'information sur l'Internet. Bien des protocoles ont ainsi délégué la récupérations de données au DNS. Parfois, ils ne l'ont pas fait de manière optimum et ce RFC de l'IAB veut « redresser la barre » en précisant les bonnes (et les mauvaises) façons de stocker et de récupérer de l'information dans le DNS.

Dès le résumé, notre RFC pointe le problème le plus fréquent : abuser des enregistrements de type TXT (texte), le type le plus tentant pour distribuer de l'information. Par exemple, SPF à l'origine utilisait exclusivement ce type pour distribuer des politiques d'autorisation de MTA, exprimées en un mini-langage (la version finalement normalisée, dans le RFC 4408, a créé un type spécifique, nommé SPF mais, en pratique, le TXT reste le plus utilisé). La principale conclusion du RFC est donc qu'il vaut mieux, en général, créer un nouveau type d'enregistrement.

À l'origine, le DNS stockait surtout deux sortes de données : celles liées à l'infrastructure DNS elle-même comme les enregistrements SOA ou NS et celles liées à la résolution de noms en adresses IP (enregistrement A) ou inversement (PTR). Le succès du DNS, sa disponibilité universelle, ont mené à bien d'autres utilisations, soit spécifiques à une application comme les enregistrement MX, soit génériques comme les enregistrements SRV du RFC 2782. Beaucoup d'autres, plus récents, s'y sont ajoutés comme les SSHFP du RFC 4255 ou les HIP du RFC 5205. (Les sections 1 et 2 du RFC rappellent les bases du DNS, nécessaires pour comprendre la question.)

Quels sont les moyens disponibles aujourd'hui pour « étendre » le DNS, pour stocker de nouveaux types de données dans cette base ? La section 3 les liste successivement.

Il y a la possibilité (section 3.1) de stocker les données dans un enregistrement générique comme TXT ou le défunt SINK ou NAPTR et d'ajouter dans ses données un sélecteur qui indique à l'application si ce sont bien ces données. SPF fonctionne ainsi, la présence de la chaîne v=spf1 au début de l'enregistrement TXT indiquant qu'il s'agit bien de SPF. Les utilisateurs des NAPTR (RFC 3761) font souvent pareil. Cette méthode (nommée subtyping) a un gros inconvénient. Comme les requêtes DNS se font par clé (la question posée, le QNAME) et pas par valeur, il n'y a aucun moyen de ne récupérer que les enregistrements intéressants. On les obtient tous et on trie après. Ainsi, si je veux les enregistrements SPF de sources.org, je dois récupérer deux enregistrements :

% dig TXT sources.org
...
sources.org.		86400	IN	TXT	"v=spf1 mx a:uucp.bortzmeyer.org a:central.sources.org ?all"
sources.org.		86400	IN	TXT	"Sources"
...

et trier ensuite. Cela peut poser des problèmes si le nombre d'enregistrements de ce type (le RRset) est gros.

La section 3.2 propose une autre méthode : ajouter un préfixe au nom de domaine (le QNAME). C'est, par exemple, ce que fait DKIM (RFC 4871) qui utilise des enregistrements TXT mais des noms de domaine qui lui sont propres. Si je reçois un message signé par DKIM qui indique le domaine example.net et le sélecteur beta, je fais une requête DNS pour le type TXT et le nom beta._domainkey.example.net. XMPP a un mécanisme analogue.

La principale limite de cette méthode vient des jokers (wildcards). Les jokers ne peuvent apparaitre que tout à fait à gauche d'un nom de domaine. Donc, si on a un joker dans example.net, il ne sera pas facile d'en faire un pour _prefixe.*.example.net (cf. RFC 4592). Cela concerne particulièrement le courrier électronique car c'est la principale utilisation des jokers.

Continuons les méthodes possibles. Puisque le préfixe a des limites, pourquoi pas un suffixe ? (Section 3.3.) Le principal problème est alors de s'assurer que example.net et example.net._suffixe sont synchrones, alors qu'ils sont désormais dans deux sous-arbres du DNS complètement distincts.

Plus astucieuse est l'idée de jouer sur la classe. La question DNS ne comporte pas uniquement un nom de domaine (QNAME) mais aussi un type (QTYPE) et une classe (QCLASS). On a tendance à oublier cette dernière car elle vaut quasiment toujours IN (pour INternet) mais d'autres classes sont possibles et certaines sont déjà enregistrées. Mais, si certaines applications comme Hesiod (j'avais déployé Hesiod dans les salles de classe du CNAM il y a longtemps...) utilisaient ces autres classes, il parait difficile aujourd'hui de s'en servir, beaucoup de logiciels, de serveurs intermédiaires et de pare-feux n'acceptant pas les classes autres que IN. Et, du point de vue administratif, cela représente une nouvelle arborescence à mettre en place, puisque l'arbre du DNS dans une autre classe ne correspond pas forcément à celui de IN.

Alors, un nouveau type ? Je trahis le suspense mais c'est en effet la solution privilégiée par l'IAB. La section 3.5 explique les avantages de ce mécanisme mais aussi ses limites. Pour insérer des données du nouveau type, et pour pouvoir les utiliser, il faut que beaucoup d'acteurs mettent à jour quelque chose :

• les auteurs de serveurs faisant autorité (serveur primaire, qui charge les données et qui doit donc pouvoir les lire, la section 6 revient sur ce problème de l'avitaillement), et serveurs secondaires, qui les copient ; historiquement, on a déjà vu des secondaires qui ne pouvaient pas recharger une zone qu'ils avaient transféré car elle contenait des types inconnus ; normalement, c'est devenu un problème très rare, cf. RFC 3597).
• les auteurs de résolveurs (normalement, ceux-ci doivent être transparents aux divers types, voir encore le RFC 3597).
• les auteurs d'applications, qui doivent pouvoir lire ces données (toutes les bibliothèques d'accès au DNS ne le permettent pas forcément, notamment dans le monde Microsoft) et les comprendre.

En plus de ces difficultés techniques, l'enregistrement d'un nouveau type utilisable dans le DNS a toujours été un processus très long et très complexe. L'IAB le reconnait dans ce RFC (après l'avoir nié pendant longtemps) mais ce n'est que depuis la sortie du RFC 5395 en novembre 2008 que le processus est devenu raisonnable. (Obtenir un nouveau type demeure un certain travail car l'espace disponible est sur 16 bits seulement, donc pas infini et il faut justifier sa demande.)

Maintenant que les différentes solutions ont été présentées, il faut fournir les éléments permettant de choisir. Avant cela, la section 4 fait un petit détour sur un problème sur lequel les débutants en DNS se cassent souvent le nez, le fait que les frontières des zones DNS soient invisibles aux applications. En effet, le découpage d'un nom de domaine en sous-domaines qui est, lui, visible (les éléments sont séparées par des points), n'indique pas où sont les frontières de zones, encore moins quelles sont les frontières administratives et politiques. Si je vois le nom www.durand.free.fr, est-ce un nom contrôlé par Free ou bien Free a t-il délégué à M. Durand, son client ? Rien dans le DNS ne permet de le savoir et une application qui se baserait sur cette connaissance aurait de grandes chances de se tromper. Ainsi, on a vu des applications, lorsqu'elles ne trouvaient pas un nom dans un domaine, chercher dans le domaine parent. C'est très dangereux, car rien n'indique si le domaine parent est sous le contrôle des mêmes personnes (ce mécanisme, dit de tree climbing, fut la base de la faille de sécurité WPAD). La seule solution serait de connaitre la politique de tous les registres, y compris ceux qui ne sont pas des TLD comme eu.org, ce qui est évidemment irréaliste. Voir aussi le RFC 1535 sur ce point.

La section 5 synthétise tous ces points en recommandant fortement la création d'un nouveau type d'enregistrement DNS, lorsqu'on a besoin de stocker des données dans le DNS. Cette section exprime une certaine compréhension pour le développeur qui n'utilise pas le DNS pour le plaisir, mais parce qu'il a besoin de stocker ses données et d'y accéder, et qui n'est donc pas un expert DNS, et qui file donc droit vers la solution la plus évidente, les enregistrements TXT.

Mais cela ne change rien aux problèmes posés par les TXT notamment le manque de structure interne. Chaque application qui utilise les TXT doit donc définir son mini-langage, rendant ainsi difficile la cohabitation d'enregistrements TXT d'applications différentes. En pratique, le TXT est donc plutôt un enregistrement privé, dont la signification est laissé à chacun.

La cohabitation est rendue encore plus difficile par l'absence d'un sélecteur standard (le RFC 1464 avait essayé d'en définir un mais avait été un échec). Chaque application doit donc avoir son mécanisme pour « reconnaître ses petits » (comme le v=spf1 de SPF).

Les enregistrements TXT avec un préfixe spécifique dans le nom de domaine, comme ceux de DKIM, sont meilleurs mais souffrent d'autres problèmes comme la difficile cohabitation avec les jokers.

Il reste donc, et la section 6 conclut le RFC sur ce point, à lire le RFC 5395 et à remplir un dossier pour avoir un nouveau type d'enregistrement. C'était très difficile autrefois, aussi bien à obtenir qu'à déployer ensuite, mais c'est désormais plus facile.

Comment est-ce qu'une machine arrive à se connecter à Internet alors que tant de paramètres doivent être configurés, comme l'adresse IP, la longueur du préfixe de celle-ci, les résolveurs DNS à utiliser, etc ? Ces réglages qui se faisaient autrefois à la main sont maintenant souvent automatisés. Ce RFC de l'IAB explique les principes de la configuration IP et les meilleures façons de la faire.

Commençons par la section 1.2 qui explique les paramètres en jeu. Ils sont séparés en deux parties, les paramètres de couche 3 (section 1.2.1) et ceux des couches supérieures (section 1.2.2). Parmi les paramètres de la couche réseau, il y a bien sûr l'adresse IP, dont dépend tout le reste. Souvent configurée autrefois avec le protocole RARP, elle est désormais souvent fixée par DHCP sur IPv4 et par DHCPv6 et l'auto-configuration sur IPv6. Ces protocoles ont en effet en commun de fonctionner entièrement sur IP, contrairement à RARP. La configuration d'IP est donc auto-suffisante.

Les autres paramètres sont souvent configurables par DHCP, le routeur par défaut, le fichier à charger si la machine charge son système d'exploitation via le réseau, la MTU du lien, etc.

Bien sûr, on peut toujours configurer ces paramètres manuellement, ce qui est souvent fait pour des serveurs, qui changent rarement de paramètres, et n'aiment pas dépendre de mécanismes externes comme DHCP. Par exemple, sur une machine Debian, on configurera ces paramètres dans le fichier /etc/network/interfaces :

# Configurer l'interface eth0 avec une adresse fixe
iface eth0 inet static
        # Adresse IPv4
	address 80.67.170.53
        # Longueur du préfixe, ici 26 bits, sur les 32 d'une adresse v4
	netmask 255.255.255.192
        # Routeur par défaut
	gateway 80.67.170.1
        ...

Les paramètres des couches supérieures incluent les adresses des serveurs de noms (DNS la plupart du temps mais il y a aussi des mécanismes de résolution de noms comme LLMNR qui ne nécessitent pas de configuration), service de synchronisation d'horloge (typiquement NTP), etc.

Quels sont les bons principes pour la configuration de ces paramètres ? La section 2 tente de répondre à ces questions. Premier principe, posé en section 2.1 : « Tout ce qui peut être configuré peut être configuré de travers ». Notre RFC rappelle donc le RFC 1958 qui disait « Évitez les options et les paramètres autant que possible. Les options et les paramètres devraient être configurés ou négociés dynamiquement, plutôt qu'à la main ». L'idée est qu'on éviterait bien des erreurs en découvrant les paramètres automatiquement plutôt qu'en demandant à l'administrateur système de les fixer. Par exemple, la MTU peut être découverte par les techniques du RFC 4821. Tout protocole devrait donc avoir le moins de réglages possible ou, en tout cas, ceux-ci devraient pouvoir être obtenus automatiquement.

En outre, le processus de configuration devrait, même s'il est automatique, être simple. C'est ce que détaille la section 2.2 qui cite encore le RFC 1958 : « Que cela reste simple. En cas de doute lors de la conception d'un protocole, choisir la solution la plus simple. » Une des raisons de ce choix est qu'IP tourne sur un très grand nombre de machines, du téléphone portable au super-calculateur et ceux-ci ont des capacités très variables. Le code IP doit donc pouvoir tenir dans une machine de bas de gamme. Un exemple typique concerne les machines qui doivent charger le noyau de leur système d'exploitation depuis le réseau (PXE). Puisque, par définition, le système n'est pas en route lors de ce chargement, le code qui l'effectue doit pouvoir tenir dans une ROM et donc être très petit (cela exclut TCP, par exemple, et c'est une raison de plus de n'embarquer qu'IP, sans protocoles de configuration additionnels).

Et le choix des mécanismes de configuration ? La section 2.3 demande de le minimiser : un vaste ensemble de tels mécanismes augmenterait la taille du code, le temps de configuration (il faudrait essayer successivement plusieurs méthodes) et l'interopérabilité (au cas où deux machines du même réseau ne mettent pas en œuvre les mêmes mécanismes).

Moins évidente est la nécessité de ne pas dépendre des couches basses (typiquement la couche 2) pour la configuration. Ce point fait l'objet de la section 2.4. Une implémentation d'IP va typiquement tourner sur plusieurs types de réseaux et ne peut pas compter sur une technique qui serait disponible sur tous. La méthode recommandée est donc qu'IP se débrouille seul.

Il existe des contre-exemples dans la famille IP. Avec PPP, le protocole IPv4CP du RFC 1332 assurait la configuration IP et une extension à PPP (RFC 1877) configurait les serveurs de noms. Cette erreur (compréhensible à l'époque, où DHCP était très rare) a été corrigée dans son équivalent IPv6, IPv6CP (RFC 5072, mais il y a aussi d'autres mécanismes de configuration en IPv6). Le RFC 3818 a ainsi sérieusement limité la possibilité de rajouter des mécanismes de configuration dans PPP.

En outre, la couche 2, en croyant bien faire, peut en fait limiter les possibilités des machines IP. Ainsi, si l'adresse IPv6 était configurée par la couche 2, des services comme les adresses temporaires de protection de la vie privée (RFC 4941) ou comme les adresses cryptographiques du RFC 3972 ne pourraient pas être utilisées.

Enfin, la section 2 se clôt sur un point important : la configuration n'est pas le contrôle d'accès et devrait en être complètement séparée (section 2.5). De toute façon, l'administrateur d'une machine peut toujours la configurer à la main et vouloir limiter l'accès au mécanisme de configuration n'a donc guère de sens. Si on veut limiter l'accès au lien de niveau 2, il vaut mieux utiliser une technique spécifique telle que 802.1X.

Une fois ces bons principes posés, le RFC discute dans la section 3 quelques questions supplémentaires. 3.1 estime que l'ensemble des mécanismes de configuration existants suffit et qu'il n'est sans doute pas opportun d'en développer d'autres. Cette section rappelle également que l'Internet n'est pas qu'une affaire de machines mais aussi d'humains qui les gèrent et que les considérations organisationnelles doivent être prises en compte lors du choix d'un mécanisme de configuration. Ainsi, routeurs et serveur de noms sont en général sous la responsabilité de deux équipes différentes et qu'il faut veiller à ce que la configuration du routeur ne dépende pas inutilement d'une autre équipe.

La frontière est floue entre configuration et « découverte d'un service » comme le fait SLP (RFC 2608). La section 3.2 explore cette frontière et explique que les deux ont leur place, les mécanismes de découverte de service ayant des capacités plus étendues.

Cela mène le RFC à la question du « destin commun » (fate sharing, section 3.2.1). On parle de destin commun quand deux services ont intérêt à être liés (la panne de l'un entraîne celle de l'autre) car ils n'ont pas de sens séparément. Ainsi, apprendre le routeur par défaut par des RA (router advertisement, RFC 4861) émis par le routeur lui-même est un excellent exemple de destin commun. Si le routeur est en panne, il n'émettra plus de RA et les machines n'apprendront donc pas son adresse. En revanche, si le routeur est appris par DHCP, la panne du routeur ne sera pas forcément détectée par le serveur DHCP et les machines apprendront l'adresse d'un routeur inutilisable.

Le destin commun est donc en général souhaitable pour les protocoles de configuration mais il n'est pas toujours possible.

La section 4 est consacrée à la sécurité, problème toujours difficile d'autant plus qu'une machine pas encore configurée, par définition, ne sait pas encore grand'chose du réseau auquel elle est attachée et est donc très vulnérable à toutes les impostures. Si l'attaquant réussit à convaincre la machine qui se configure d'utiliser tel serveur de noms, que l'attaquant contrôle, alors presque toute l'activité Internet de cette machine est dirigée par l'attaquant. C'est encore pire si l'attaquant convainc une machine sans disque local de charger comme système d'exploitation un programme choisi par l'attaquant.

La section 4.1 explore les solutions possibles. Disons tout de suite qu'il n'y a pas de miracle : la simplicité et la souplesse de la configuration d'IP s'opposent à la sécurité. La plupart des solutions au problème de la sécurité de la configuration dépendent d'une configuration manuelle de chaque machine, ce qui ne réjouira pas l'administrateur système débordé. On peut parfois compter sur la protection apportée par les couches basses (un réseau Ethernet dont les commutateurs protègent l'accès aux différents ports, par exempe). Autrement, il existe plusieurs techniques d'authentification comme SEND (RFC 3971) mais qui, comme le note le RFC, dépend d'une configuration d'une clé sur chaque machine, ce qui n'est pas pratique, surtout lorsque la machine visite plusieurs réseaux.

Complétant la série de RFC sur l'internationalisation du courrier électronique, ce document normalise la procédure de repli (downgrade) que doivent utiliser les MTA lorsqu'ils essaient de transmettre un message RFC 5335 à un autre MTA si ce dernier ne gère pas l'extension UTF8SMTP du RFC 5336.

Écrit par des employés de JPRS, le registre du .jp, c'est un document plutôt simple malgré la complexité du sujet. En effet, lorsque les autres RFC sur l'internationalisation complète du courrier (comme les RFC 5335 ou RFC 5336) seront déployés, ils ne le seront pas instantanément sur toute la planète. Si on se fie au lent déploiement des extensions précédentes (comme la transparence aux caractères « 8 bits » du RFC 2045), on peut prévoir d'importants délais, de l'ordre de dix ans ou plus, avant que tous les MTA suivent le nouveau mécanisme. Que faire en attendant si un MTA veut transmettre un message complètement internationalisé à un MTA ancien, qui ne sait pas quoi en faire ? Tous les MTA écrits avant le RFC 5336 n'acceptent en effet que les enveloppes et les en-têtes en ASCII.

La solution choisie (introduite par le RFC 5336, sections 3.1 à 3.4, résumée en section 1 de notre RFC) est, soit de renoncer à délivrer le message, la plus simple mais évidemment pas satisfaisante, soit de mettre en œuvre le mécanisme de repli (downgrade) que normalise notre RFC 5504. Ce mécanisme consiste à convertir l'enveloppe SMTP et les en-têtes du message pour être acceptable par le vieux serveur. Elle n'est pas complètement réversible et donc aucun upgrade ne correspond à ce downgrade.

Pour permettre de se souvenir d'une partie de ce qui a été fait, des nouveaux en-têtes apparaissent, préfixés de Downgraded- et qui indiquent l'ancienne valeur. Ils sont encodés en UTF-8 et surencodés avec la méthode du RFC 2047 (Mon =?UTF-8?Q?h=C3=B4tel_et_mes_horaires?= pour « Mon hôtel et mes horaires »).

La section 3 décrit ces en-têtes Downgraded:. 3.1 couvre le repli de l'enveloppe (paramètres des commandes SMTP MAIL FROM et RCPT TO, voir aussi la section 4). Les adresses qu'elle contient se replient sur le paramètre ALT-ADDRESS s'il est présente (sinon, ce destinataire est abandonné).

3.2 et 3.3 couvrent le repli des en-têtes du message comme From:.

La section 4 revient sur le repli de l'enveloppe : celui-ci ne peut se faire que si l'adresse a un paramètre ALT-ADDRESS (cf. RFC 5336).

La section 5, elle, analyse en détail les problèmes que peuvent poser certains en-têtes lors du repli. Ainsi, Received: peut contenir des adresses de courrier :

Received: from fallback1.mel.teaser.net (fallback1.mel.teaser.net [213.162.54.52])
        by mail.bortzmeyer.org (Postfix) with ESMTP id 146B5941E4
        for <stéphane+blog@bortzmeyer.org>; Tue, 14 Oct 2008 22:29:11 +0200 (CEST)

et ces adresses doivent également se replier en ASCII.

Quant à la partie 6, elle traite le cas où le corps est structuré selon MIME (RFC 2045) et comprend donc des pseudo en-têtes comme Content-Description: qui devront peut-être également se replier. À propos de MIME, il faut noter que le repli ne considère pas le corps des messages. Si le serveur SMTP suivant, non seulement ne gère pas UTF8SMTP mais ne gère pas non plus le transport « huit bits », il faudra également modifier le corps du message pour le passer en un encodage qui tient en sept bits (cf. section 8.2).

La section obligatoire sur la sécurité (section 7) couvre notamment le fait que le repli, comme n'importe quel processus qui modifie le message en cours de route, a de fortes chances d'invalider toute signature apposée à ce message, par exemple avec DKIM (RFC 4871). Les autres méthodes de signature comme PGP (RFC 4880) peuvent également être affectées.

Voyons un exemple (non testé par manque d'implémentations), tiré de l'annexe A.1. Si le message original était :

   # Enveloppe SMTP
   MAIL FROM: <stéphane@bortzmeyer.org>
               ALT-ADDRESS=stephane@bortzmeyer.org
   RCPT TO: <françoise@example.org>
             ALT-ADDRESS=francoise@example.net
   RCPT TO: <rené@example.org>

   # Message proprement dit 
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: C'est bien de pouvoir écrire en français
   # La syntaxe ci-dessous a été introduite par le RFC 5335, section 4.4, pour 
   # représenter les ALT-ADDRESS
   From: Stéphane Bortzmeyer <stéphane@bortzmeyer.org
      <stephane@bortzmeyer.org>>
   To: Françoise Durand <françoise@example.org
      <francoise@example.net>>
   Cc: René Dupont <rené@example.org>

   # Corps du message

la version de repli sera :

   # Enveloppe SMTP
   MAIL FROM: <stephane@bortzmeyer.org>
   RCPT TO: <francoise@example.net>
   # René a disparu, il n'avait pas d'adresse de repli

   # Message proprement dit 
   Downgraded-Mail-From: =?UTF-8?Q?<st=C3=A9phane@bortzmeyer.org>_?=
    =?UTF-8?Q?<stephane@bortzmeyer.org>?=
   Downgraded-Rcpt-To: =?UTF-8?Q?<fran=C3=A7oise@example.org>_?=
    =?UTF-8?Q?<francoise@example.net>?=
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: =?UTF-8?Q?C'est bien de pouvoir =C3=A9crire en fran=C3=A7ais?=
   From: =?UTF-8?Q?St=C3=A9phane Bortzmeyer?= <stephane@bortzmeyer.org>
   Downgraded-From: =?UTF-8?Q?St=C3=A9phane Bortzmeyer_<st=C3=A9phane@bortzmeyer.org_?=
       =?UTF-8?Q?<stephane@bortzmeyer.org>>?=
   To: =?UTF-8?Q?Fran=C3=A7oise Durand?= <francoise@example.net>
   Downgraded-To: =?UTF-8?Q?_Fran=C3=A7oise Durand?=
       =?UTF-8?Q?<fran=C3=A7oise@example.org>_<francoise@example.net>>?=
   Cc: =?UTF-8?Q?Ren=C3=A9 Dupont?= Internationalized address
       =?UTF-8?Q?ren=C3=A9@example.org?= removed:;
   Downgraded-Cc: =?UTF-8?Q?Ren=C3=A9 Dupont_?=
     =?UTF-8?Q?<ren=C3=A9@example.org?>=

   # Corps du message

Cette norme modifie le protocole BGP (RFC 4271) pour ajouter une nouvelle option, qui est plutôt une méta-option, permettant de décrire des capacités optionnelles d'un pair BGP.

Sans ce système de Capabilities, deux routeurs BGP peuvent annoncer des options lors de la négociation de la session mais tous ces paramètres bien mal nommés « optionnels » sont obligatoires. Si un seul d'entre eux n'est pas reconnu par le pair, celui-ci doit refuser la session (RFC 4271, section 6.2). Cela rendrait très difficile de déployer de nouvelles options. D'où le paramètre optionnel CAPABILITIES que décrit notre RFC et qui est le seul que les routeurs doivent connaitre. Il permet de décrire des options qui sont réellement facultatives (section 1).

La section 3 explique comment utiliser ce paramètre. En gros, une capacité peut être utilisée si les deux pairs l'ont publiée dans un paramètre CAPABILITIES. Si ce paramètre lui-même n'est pas géré, notre RFC conseille de reessayer sans lui. Naturellement, un routeur BGP est toujours libre de ne pas établir de session s'il manque une capacité qu'il juge indispensable (le RFC cite l'exemple des extensions multiprotocole du RFC 4760, section 8, indispensables pour un routeur IPv6). La section 5 revient sur ce sujet en spécifiant les comportements possibles en cas d'erreur.

Et la section 4 décrit précisement le paramètre CAPABILITIES, qui porte le numéro 2 parmi les paramètres optionnels de BGP. Les capacités sont encodées en TLV par un code (1 pour les extensions multiprotocoles du RFC 4760, ou 65 pour les AS sur quatre octets du RFC 4893), une longueur et une valeur.

Ce RFC remplace son prédécesseur, le RFC 3392. Les changements, décrits dans l'annexe B, sont peu nombreux et consistent surtout en durcissement de certaines règles, maintenant que tous les routeurs BGP gèrent CAPABILITIES.

Lorsqu'un document, par exemple un Internet-Draft est publié et distribué via l'Internet, il peut être difficile de prouver qu'il est bien « authentique », qu'il a été validé et pas modifié ensuite. La technique la plus courante pour cela est la signature cryptographique et ce nouveau RFC explique comment elle s'appliquera aux Internet-Drafts.

Le mécanisme n'est pas encore en place mais le principe sera le suivant : lors de la réception d'un nouvel Internet-Draft le secrétariat de l'IETF le signera au format CMS (RFC 3852), en utilisant un certificat X.509 (qui reste apparemment à publier). La signature, détachée de l'Internet-Draft, au format PKCS#7, sera publiée avec les Internet-Drafts.

Pourquoi CMS et pas PGP tel que normalisé dans le RFC 4880 ? Je l'ignore mais c'est sans doute lié au fait que les défenseurs de X.509 sont plus bruyants, beaucoup d'argent est en jeu pour eux, avec les coûteuses CA.

Les détails, maintenant. CMS utilise ASN.1 (section 1.2) et ASN.1 a certains encodages qui permettent plusieurs représentations de la même donnée. C'est évidemment gênant pour la signature et notre RFC impose donc l'encodage DER qui n'a pas ce défaut.

Le texte de l'Internet-Draft devra être canonicalisé. Pour les Internet-Drafts au format texte seul, il faudra notamment avoir une forme unique pour les fins de lignes, la forme standard CRLF (cf. annexe B du RFC 5198, la seule norme de cette forme standard). Pour ceux en XML (section 2.3), suivant la norme XML, ce sera LF qui marquera la fin de ligne. Les autres formats seront simplement traités comme du binaire.

CMS est une norme très complexe et la section 3 est consacrée à définir un profil de CMS pour nos signatures. C'est aussi l'occasion de spécifier quelques points pratiques comme l'importance pour le secrétariat qui publie les Internet-Drafts d'avoir des ordinateurs à l'heure, piur que l'attribut Signing-Time (section 3.2.3.3) soit correct.

Enfin, comme le but de toute l'affaire est la sécurité, le RFC se termine sur des Security Considerations (sections 5 et 6) qui recommandent l'usage de HSM pour stocker la clé privée de l'IETF.

À l'heure actuelle, le processus de signature n'a pas encore commencé. Les signatures détachées porteront l'extension p7s (section 2 et cf. RFC 3851). Les signatures pourront être vérifiées avec OpenSSL (version 0.9.9 minimum car il faut la commande cms, vous pouvez taper openssl version pour tester votre version). En attendant que j'installe cette version, j'ai fait les essais suivants avec la commande smime, puisque S/MIME et CMS ont beaucoup en commun.

Si je suis un simple lecteur d'Internet-Drafts et que je veux vérifier une signature (annexe A) :

% openssl smime -verify -CAfile $CERT -content ${id} \
          -inform DER -in ${id}.p7s -out /dev/null

où id est le nom de l'Internet-Draft et CERT celui du fichier .pem contenant le certificat de l'IETF. Si tout se passe bien, OpenSSL répondra :

Verification successful

et si un seul caractère de l'Internet-Draft a été modifié :

Verification failure
14024:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:235:
14024:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature failure:pk7_doit.c:981:
14024:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:312:

Si je veux juste regarder le certificat contenu dans la signature :

% openssl pkcs7 -print_certs -inform DER -in ${id}.p7s   
subject=/C=FR/L=Paris/O=Bidon/CN=Ca essai
issuer=/C=FR/L=Paris/O=Bidon/CN=CA essai

Si je suis le secrétariat de l'IETF et que je veux signer un Internet-Draft (bien sûr, dans la réalité, cela ne sera pas fait à la main avec la ligne de commande) :

% openssl smime -sign -in $id -inkey privkey.pem -outform DER -binary \
    -signer mycacert.pem -out ${id}.p7s -noattr 

Si vous voulez faire l'essai complet, le moyen le plus rapide de créer l'infrastructure du secrétariat (les fichiers privkey.pem et mycacert.pem) est :

% openssl genrsa -out privkey.pem 1024
% openssl req -sha1 -new -x509  -key privkey.pem -out mycacert.pem -days 1095

À noter que cette technique ne s'applique qu'aux Internet-Draft, pas aux RFC eux-même (et cela sera sans doute difficile en raison de l'extrême prudence du RFC editor).

Le RFC 793, qui normalise TCP, prévoit un paramètre local user timeout qui permet de régler la « patience » de TCP. S'il n'arrive pas à échanger des données avec son partenaire avant l'expiration de ce délai, TCP renonce et coupe la connexion. Notre RFC étend l'utilité de ce paramètre, en permettant de le communiquer au partenaire, pour qu'il soit prévenu de la patience ou de l'impatience de celui avec qui il communique. On augmente ainsi les chances des connexion TCP de survivre aux longues coupures ou, au contraire, de détecter plus rapidement la coupure du réseau.

Ce paramètre user timeout peut être spécifié par l'application qui utilise TCP (ceci-dit, je ne trouve pas l'option de setsockopt qui permettrait de le faire sur tout Unix ; d'après le RFC, Solaris a une telle option). Il vaut cinq minutes par défaut (section 3.8 du RFC 793). Mais il n'était jamais connu de l'autre machine avec laquelle on est connecté en TCP. C'est ce que change notre RFC qui permet de communiquer ce paramètre.

Cette communication se fait via le mécanisme d'option de TCP, décrit dans la section 3.1 du RFC 793. La nouvelle option porte le nom d'UTO (User Timeout Option) et est strictement indicative : le TCP qui la reçoit peut parfaitement l'ignorer. S'il l'accepte, il va ajuster son propre user timeout à la valeur indiquée. Ainsi, TCP pourra, par exemple, survivre à de longues périodes de déconnexion, sans que le partenaire ne raccroche.

La section 1 fournit d'autres cas où cette option UTO est utile : pour des mobiles utilisant une technique qui conserve l'identificateur comme HIP (RFC 4423) ou Mobile-IP (RFC 3344), les périodes pendant lesquelles le mobile n'a pas de connexion risquent d'être longues. Le fait de garder l'identificateur (adresse IP ou Host Identity) constant permet en théorie de garder les sessions TCP lorsqu'on se déconnecte et se reconnecte mais, avant l'option UTO, cela ne servait à rien puisque TCP coupait la connexion qui lui semblait en panne.

De même, l'application peut dans certains cas connaître la durée d'une déconnexion et utiliser UTO pour prévenir son partenaire (le RFC cite l'exemple amusant d'une sonde spatiale qui sait, grâce aux lois de la mécanique céleste, qu'elle ne sera pas en vue de sa base pendant une longue période).

La section 3 définit rigoureusement la nouvelle option. Quatre paramètres définissent le comportement du TCP local : USER_TIMEOUT, qui existe déjà (mais n'est pas réglable sur tous les systèmes d'exploitation, cf. sections 3.1 et 5), ADV_UTO, la valeur de l'UTO communiquée au pair (typiquement identique à USER_TIMEOUT), ENABLED qui indique si le pair doit être notifié par la nouvelle option UTO et CHANGEABLE qui indique si USER_TIMEOUT doit être ajusté en fonction des notifications du pair (ou bien s'il doit être ignoré, ce qui est permis).

La section 3.1 contient une discussion détaillée des « bonnes » valeurs pour USER_TIMEOUT (notons que ce ne sera pas forcément le même pour les deux pâirs). Le RFC 1122 donnait quelques recommandations à ce sujet (par exemple, les valeurs inférieures à 100 s sont découragées). La 3.2 discute de la fiabilité de la transmisson d'UTO (inexistante, comme toutes les options TCP ; il ne faut donc pas tenir pour acquis qu'elle a été reçue par le pair). Et 3.3 décrit le format concret de l'option : numéro 28 (enregistré dans le registre IANA), un bit qui indique l'unité utilisée (minutes ou secondes) et 15 bits qui contiennent la valeur elle-même.

La section 4 passe aux problèmes pratiques que peut rencontrer le déploiement de l'option. Le RFC rappelle en section 3 que l'espace des options dans TCP est limité (40 octets) et que l'ajout d'UTO peut nécessiter de renoncer à certaines options. Il faut aussi dire que beaucoup de pare-feux bogués rejettent tout paquet TCP ayant des options (cf. Probing the viability of TCP extensions) et que celles-ci sont donc difficiles à utiliser en pratique. En théorie, une implémentation de TCP qui ne connait pas cette option devrait l'ignorer (RFC 1122) et le RFC décrète que, bien qu'il y aie quelques violations de cette règle (cf. Measuring interactions between transport protocols and middleboxes), elles ne méritent pas qu'on renonce à une option utile (section 4.1). Notez aussi qu'un pare-feu à état a typiquement ses propres délais de garde et peut donc couper une connexion sans tenir compte de l'UTO annoncée (les pare-feux futurs tiendront peut-être compte de cette option).

J'ai déjà mentionné la difficulté qu'il y a à changer la valeur de USER_TIMEOUT. La section 5 revient sur cette question de l'API mais ne fournit pas de proposition de normalisation de l'API des prises.

Bien sûr, l'UTO introduit des problèmes de sécurité nouveaux, discutés en section 6. Par exemple, un méchant pourrait spécifier de très longs délais de garde, puis s'en aller pendant que sa victime serait forcée de garder une connexion ouverte pendant de longues minutes, malgré l'absence de trafic. Notre RFC propose des mécanismes pour limiter les risques comme n'accepter les UTO qu'après authentification IP (par exemple par IPsec), ou bien seulement après que l'application aie indiqué à TCP qu'elle avait réussi une authentification à son niveau, par exemple par TLS. Sans authentification, TCP pourrait aussi mettre des limites au délai de garde total d'un pair (s'il a ouvert plusieurs connexions) et au délai de garde total (pour limiter les risques dûs aux dDoS).

Je ne trouve pas encore de trace de mises en œuvre de TCP qui incluent cette option UTO.

Le RFC 3393 normalise une métrique de variation du délai d'acheminement des paquets. Cette métrique est assez souple pour que, en pratique, plusieurs formules aient été utilisées. Ce RFC en discute deux et précise leur usage.

Souvent, le délai moyen d'acheminement d'un paquet (ce que peut mesurer, dans une certaine mesure, la commande ping) n'est pas la seule métrique de délai intéressante. Il est souvent utile de connaître la variation de ce délai d'acheminement. Les applications « temps-réel » par exemple en vidéo sont en effet très sensible à la gigue, c'est-à-dire à cette variation, par exemple parce qu'elle va nécessiter de stocker les données dans un tampon, avant de commencer leur affichage, pour garantir que celui-ci reste lisse pendant toute la session (voir le RFC 3550 et la section 3 de notre RFC 5481). Outre le RFC 3393, cette gigue fait l'objet de la norme ITU Y.1540. En anglais, le mot jitter (gigue) est souvent utilisé mais le RFC préfère « variation de délai ».

Cette variation se mesure par rapport au délai d'acheminement d'un paquet (métrique définie dans le RFC 2679). Comme le rappelle la section 1, il y a deux grandes formulations possibles pour la variation de délai :

• Variation entre paquets ou IPDV (Inter-Packet Delay Variation), où on mesure par rapport au paquet précédent. C'est celle qui est utilisée dans le RFC 3550.
• Variation par rapport à un paquet ou PDV (Packet Delay Variation), où on mesure par rapport à un paquet donné, en général celui avec le plus petit délai de voyage.

Toutes les deux sont compatibles avec le RFC 3393.

La section 3 détaille les usages qui sont raisonnables pour cette métrique. Par exemple, la section 3.2 discute des « tampons de suppression de gigue », ces structures de données où les applications audio et vidéo gardent les données, pour compenser les variations du réseau. Les formules pour calculer leur taille optimale dépendent de la variation de délai d'acheminement. Ou bien la section 3.4 explique que cette variation peut être pertinente pour comparer les offres de deux opérateurs et qu'elle peut même faire l'objet d'un SLA.

Enfin la section 4 donne les définitions exactes pour les deux formules, IPDV et PDV. IPDV est en 4.1 et se définit simplement comme la différence entre le délai d'acheminement du paquet i et celui du paquet i-1 (l'IPDV peut donc être négatif). PDV, en section 4.2, est défini comme la différence entre le délai d'acheminement du paquet i et celui du paquet au délai le plus faible. Il est donc toujours positif (ou nul). (La section 12 revient sur le calcul de ce délai minimum, par rapport auquel tout est mesuré.)

Pour les érudits, la section 5 détaille la littérature existante sur la question et les comparaisons déjà faites entre IPDV et PDV. Ces comparaisons ont utiles pour estimer la « meilleure » formule pour un problème donné.

Le point de vue des auteurs du RFC est en section 7, consacrée à l'étude de l'applicabilité de chaque formule à divers problèmes. Ainsi, la question de la taille des tampons de suppression de gigue, en section 7.1.2 est tranchée en faveur de PDV, car le tampon est calculé pour que le paquet de délai maximum n'attende pas et que le paquet de délai minimum attende pendant toute la longueur du tampon. Même chose si on est en présence de nombreuses pertes de paquets (section 7.2.3) : IPDV se comporte mal dans ce cas car chaque perte fait aussi perdre la mesure qui aurait pu être faite au paquet suivant. Par contre, si on désire utiliser la variation de délai pour mesurer des changements de route sur le réseau, IPDV est préféré, pour les raisons expliquées en section 7.2.2 (meilleure isolation des effets de chaque changement).

La section 8 couvre les problèmes pratiques que pose la mesure. Par exemple, comme notre métrique est dérivée d'une métrique uni-directionnelle, la synchronisation des horloges des machines est cruciale. C'est ce qu'explique la section 8.5, qui recommande le GPS et déconseille NTP.

Ce RFC fait partie de la série des normes produites par le groupe de travail psamp sur l'échantillonage (ou, plus exactement, la sélection) des paquets IP. Les explications générales sur ce mécanisme figurent dans le RFC 5474 et notre RFC 5475, lui, détaille les techniques de sélection des paquets.

Il est donc très recommandé de lire le RFC 5474 avant puisque ce RFC 5475 en reprend les concepts et le vocabulaire (sections 2 et 3, ainsi que la section 4, qui reprend la classification des techniques de sélection en filtrage (où on sélectionne certains paquets selon leurs propriétés, par exemple tous les paquets UDP) et échantillonage où on veut juste sélectionner un sous-ensemble représentatif des paquets. L'échantillonage peut se faire via une fonction de hachage (avec certaines de ces fonctions, cela peut faire un échantillonage quasi-aléatoire) mais, à part ce cas, le contenu du paquet n'est pas pris en compte. La même section 4 rappelle les différentes techniques de sélection, déjà présentées dans le RFC 5474 comme par exemple l'échantillonnage fondé sur le comptage des paquets ou celui fondé sur le temps.

La section 5 est consacrée à l'étude détaillée des techniques d'échantillonage. En fonction du phénomène qu'on veut étudier, on utilisera telle ou telle technique. Par exemple, l'échantillonage systématique (section 5.1) est déterministe et se décline en échantillonage systématique fondé sur le rang des paquets (on sélectionne un paquet sur N) et en échantillonage systématique fondé sur le temps (on prend tous les paquets, mais pendant une courte période).

L'échantillonage aléatoire est décrit dans la section 5.2 et lui aussi se décline en de nombreuses variantes, par exemple selon la distribution utilisée.

La section 6 parle, elle, du filtrage. Contrairement à l'échantillonage, le filtrage considère que le contenu du paquet est important, mais pas sa place dans le temps. Dans le cas du filtrage fondé sur les propriétés (section 6.1), le RFC 5475 permet d'utiliser comme critères de filtrage les attributs d'IPFIX (RFC 5102). Ces attributs (un sous-ensemble de ce qui est disponible, par exemple dans le BPF) sont combinables avec un opérateur ET (pas de OU en standard, par contre). Dans le filtrage fondé sur une fonction de hachage (section 6.2), le contenu du paquet n'est pas utilisé directement mais via cette fonction. Un des buts est, par exemple, de coordonner la sélection des mêmes paquets en différents points d'observation. Le RFC détaille ce filtrage, les différentes utilisations possibles et les propriétés souhaitables pour ls fonctions de hachage (comme la vitesse). Les programmeurs noteront avec plaisir que l'annexe A contient plusieurs mises en œuvre d'une « bonne » fonction de hachage, dont une optimisée pour IPv4, où le résultat n'a pas de lien évident avec le contenu du paquet. (Il existe aussi une étude comparative de ces fonctions dans A Comparative Experimental Study of Hash Functions Applied to Packet Sampling.)

Les différentes techniques de sélection sont résumées par un tableau synthétique dans la section 7.

Notez, hélas, que certains prétendent avoir breveté certaines de ces techniques. Il s'agit probablement de brevets futiles, comme 99,9 % des brevets logiciels mais on ne sait jamais...

L'échantillonnage est une opération qui consiste à ne sélectionner qu'une partie des objets qu'on mesure. Par exemple, lors de l'étude des paquets passant par un réseau, on ne capture qu'une partie des paquets, afin de ne pas faire exploser le disque et que le temps d'analyse reste raisonnable. Le groupe de travail PSAMP de l'IETF met au point des normes sur l'échantillonnage de paquets, afin de garantir une certaine cohérence dans les mesures. Ce RFC présente le cadre général de PSAMP.

Les travaux de PSAMP partent dans plusieurs directions, aussi bien la définition des opérations d'échantillonnage que le protocole permettant de transmettre à une autre machine les paquets capturés (de la même façon qu'IPFIX transmet des informations sur les flux). Notre RFC 5474 est le cadre général, le RFC 5475 décrit les mécanismes d'échantillonnage, le RFC 5476 normalise le protocole qui permet d'exporter le résultat de l'échantillonnage et le RFC 5477 décrit le schéma de données utilisé pour cette exportation.

Attaquons cette famille avec la section 3 du RFC, qui décrit les généralités. À un endroit du réseau (par exemple sur le port d'un routeur), on observe les paquets, un processus les sélectionne (c'est l'échantillonnage), un autre construit des données en utilisant les paquets sélectionnés et un dernier les exporte vers un point de collecte, où se fera l'analyse finale (selon un mécanisme proche de celui d'IPFIX, RFC 5101). Les paquets sélectionnés n'ont pas forcément quelque chose en commun et c'est pour cela que le RFC utilise pour l'exportation le terme de stream et pas celui de flow (RFC 3917).

Je m'intéresse particulièrement ici au processus de sélection, décrit en section 3.3. La sélection peut se faire sur divers critères, et elle peut mettre dépendre d'un état du processus du sélection (le RFC cite plusieurs exemples de tels états comme le numéro d'ordre du paquet, comme l'état d'un générateur pseudo-aléatoire, etc).

Les protocoles qui mettent en œuvre ce système obéissent à des exigences décrites en section 4. Les mécanismes de sélection (section 4.1) doivent être :

• assez simples pour être déployés facilement en des endroits où il faut aller vite. L'idée est de pouvoir traiter les paquets au rythme où ils passent (line-rate). La section 10 revient plus en détail sur cette exigence de performance et sur la complexité des opérations de sélection de paquets. La sous-section 10.2 plaira aux passionnées des couches basses, puisqu'elle décrit les implémentations possibles dans le matériel, notamment les ASIC.
• mais aussi assez riches pour couvrir tous les cas d'usage.
• et extensibles car tout n'aura pas été prévu.

Les sélecteurs obéissant à ces critères figurent en section 5 et surtout dans le RFC 5475.

Il y a aussi des exigences pour le système de mesure (capacité à indiquer que de l'information a été perdue, respect de la vie privée des utilisateurs, selon le RFC 2804, etc), et pour le système d'exportation (proches de celles d'IPFIX, cf. RFC 3917).

Les sélecteurs sont décrits en section 5. Ils sont de deux modèles, ceux qui filtrent et ceux qui échantillonent. Les premiers sélectionnent certains paquets selon les caractéristiques du paquet. Par exemple, si on dit à tcpdump, en langage BPF, tcp and dst port 443, il va filtrer selon ce critère et ne garder que les paquets TCP à destination du port 443 (HTTPS). Les seconds, ceux qui échantillonent, sont tous les autres, ceux qui n'utilisent pas uniquement le contenu du paquet mais un critère extérieur, par exemple un tirage aléatoire. Les sélecteurs qui échantillonent se divisent à leur tour en deux sous-groupes, ceux où la sélection ne dépend pas du tout du contenu du paquet et ceux où ce contenu est utilisé, par exemple pour réaliser une distribution non uniforme. Donc, si j'utilise pcapdump et que je le lance avec l'option -S, j'utilise un sélecteur qui n'est pas un filtre, et qui ne dépend pas du tout du contenu du paquet (cette option garde un paquet sur N, où N est l'argument de l'option).

La section 5.2 résume les sélecteurs importants :

• Échantillonnage fondé sur le comptage des paquets. C'est l'option -S de pcapdump mentionnée plus haut. À ma connaissance, ni tcpdump, ni Wireshark n'ont une option équivalente.
• Échantillonnage fondé sur le temps. Je ne connais pas de progiciel de capture de paquets qui aie une telle possibilité, il faut le développer soi-même avec la libpcap.
• Diverses formes d'échantillonnage aléatoire. Même remarque que ci-dessus quant à la (non-)disponibilité d'une tellee option dans l'offre logicielle actuelle.
• Filtrage sur le contenu, comme avec le langage BPF cité plus haut dont disposent tous les outils de capture sur Unix. Selon le langage disponible, on pourra utiliser plus ou moins de critères (le RFC 5102 en donne une idée).
• Filtrage selon la valeur d'une fonction de hachage du paquet. C'est une technique que les répartiteurs de charge utilisent souvent.

Les sélecteurs peuvent naturellement être combinés (section 5.5), par exemple en faisant un filtrage suivi d'un échantillonnage.

Mais, au fait, quelle est l'utilité de ce travail ? La section 11 donne des exemples d'applications de l'échantillonnage.

Enfin, l'inévitable section sur la sécurité est la numéro 12, qui pointe, entre autres, un problème général de toutes les mesures passives, le risque d'atteintes à la vie privée (section 12.2) et un risque spécifique de l'échantillonnage, celui qu'un méchant tente d'échapper à la détection en se débrouillant pour que ses paquets ne soient pas ceux sélectionnés (section 12.3).

Voici donc les RFC décrivant le protocole IPFIX, le successeur normalisé de Netflow. Ce RFC particulier décrit l'architecture d'IPFIX.

Ces RFC sont bâtis sur le travail du groupe "ipfix" de l'IETF qui avait formalisé son cahier des charges dans le RFC 3917. Il s'agissait de remplacer le protocole privé Netflow par un mécanisme ouvert et normalisé.

La section 2 du RFC décrit la terminologie utilisée. L'un des principaux termes est évidemment celui de flot (flow) et on notera la définition très large choisie : en gros, un flot est n'importe quel ensemble de paquets pour lequel il existe un critère automatique permettant de tester leur appartenance au flot. Cela peut donc être l'adresse source, l'adresse destination, ou même des données qui n'apparaissent pas dans le paquet (comme l'adresse du routeur suivant).

Les autres concepts importants sont ceux d'exporteur (exporter, nommé probe dans Netflow) et de récolteur (collector). Le premier (en général un routeur mais ce n'est pas obligé, le logiciel libre Ntop peut aussi servir d'exporteur) exporte des flots sous forme agrégée, le second les récolte et les traite.

On notera que le format des flots n'est pas complètement spécifié dans les RFC. En effet, chaque exporteur peut définir des gabarits (template) décrivant les données transmises par le flot (section 5.6 du RFC).

La déjà très longue série des RFC sur IMAP s'agrandit avec cette norme pour le nommage de filtres IMAP. On peut désormais stocker ses filtres sous un nom et les réutiliser plus tard.

Le protocole d'accès au courrier IMAP permet de filtrer le courrier selon des filtres définis dans le RFC 3501. Ces filtres devaient être stockés côté client et réenvoyés au serveur à chaque fois. Désormais, on peut leur donner un nom, les stocker de manière permanente sur le serveur IMAP et les utiliser dans des commandes IMAP comme SEARCH (section 2 du RFC pour une introduction).

Un serveur IMAP qui connait cette nouvelle extension l'annonce en réponse à la commande CAPABILITY par le mot-clé FILTERS (l'ensemble des mots-clés possibles étant dans le registre IANA). La commande SEARCH d'IMAP peut alors prendre un critère FILTER qui indique le nom du filtre (section 3.1). Par exemple :

mytag1 SEARCH FILTER mon-filtre 

Un filtre nommé peut lui-même être défini en termes d'autres filtres nommés.

Les filtres nommées étant un cas particulier des méta-données d'IMAP, créer et détruire les filtres nécessite un serveur IMAP qui comprend les méta-données (RFC 5464). On peut alors utiliser les commandes comme SETMETADATA dans l'arborescence normalisée /private/filters/values, par exemple :

mytag2 SETMETADATA "" "/private/filters/values/mon-filtre" "FROM \"moi@example.org\" "

Les noms des filtres étant restreints à US-ASCII, l'arborescence /private/filters/descriptions est réservée pour stocker des descriptions en UTF-8, donc plus présentables pour l'utilisateur.

Je ne sais pas encore quels serveurs IMAP gèrent cette extension.

Que doit faire une implémentation de TCP lorsqu'une erreur est signalée par le réseau, par exemple lorsqu'un paquet ICMP indique une route inaccessible ? La norme traditionnelle est peu respectée et ce RFC explique pourquoi et documente la réaction la plus courante des mises en œuvre de TCP.

Soit une machine qui a une connexion TCP (RFC 793) avec une autre (ou bien qui est en train de tenter d'établir cette connexion). Arrive un paquet ICMP (RFC 792) qui dit, par exemple Network unreachable. Que doit faire TCP ? Abandonner la connexion ? Ignorer le message ?

Les exigences pour les machines Internet, le RFC 1122, sont claires. Il existe deux sortes d'erreur ICMP, les « douces » (soft errors, qui sont en général temporaires, c'est le cas du type 3, Destination unreachable, pour ses codes 0, Network unreachable, 1, Host unreachable et 5 Source route failed) et les « dures » (hard errors, en général de longue durée, comme le type 3 pour le code 3, Port unreachable, dû en général à l'action délibérée d'un pare-feu). Le RFC 1122 dit que TCP ne doit pas interrompre une connexion pour une erreur douce. En effet, celles-ci étant souvent transitoires, une telle interruption immédiate empêcherait de tirer profit de la résilience de l'Internet, où le réseau se reconfigure pour contourner un problème (voir aussi la section 2.2).

Pourtant, la plupart des mises en œuvre de TCP ignorent cette règle, afin d'éviter une longue attente au cas où une machine ne soit pas joignable sur certaines adresses (cas courant, notamment avec IPv6). Notre RFC 5461, sans changer la norme officielle, documente le comportement non-officiel, explique ses raisons et indique ses limites.

D'abord, le cas couvert par ce nouveau RFC est uniquement celui de l'établissement de la connexion (quand TCP est dans l'état SYN_RECEIVED ou SYN_SENT). Celui des connexions déjà établies n'est pas traité.

Le RFC 816 séparait le traitement des pannes réseaux en deux : leur détection et leur réparation. ICMP est un outil de détection. Il permet de voir qu'il y a un problème. Mais quelle réparation utiliser ? (section 1 du RFC).

Le RFC 1122, section 4.3.2.9, dit que TCP ne doit pas couper la connexion pour les erreurs douces (et, par contre, y mettre fin en cas d'erreur dure). La section 2 de notre RFC revient sur cette règle en notant qu'elle n'est absolument pas respectée en pratique.

Pourquoi ? C'est l'objet de la section 3. En gros, si on suit le RFC 1122 au pied de la lettre, et qu'on essaie de se connecter à une machine qui a plusieurs adresses IP (ce qui est courant avec IPv6), l'algorithme typique de l'application est séquentiel : on essaie toutes les adresses l'une après l'autre. Si la réception d'une erreur ICMP n'entraine pas l'échec immédiat d'une tentative sur une adresse, il faudra attendre l'expiration du délai de garde (trois minutes, dit le RFC 1122 !) pour renoncer à cette adresse et essayer la suivante (section 3.1). Le cas fréquent d'une adresse IPv4 et d'une IPv6 sur la même machine est discuté en section 3.2.

Alors, que font les mises en œuvre actuelles de TCP ? La section 4 décrit deux stratégies courantes. Le RFC se sent obligé de rappeler que ces statégies sont, formellement, une violation de la norme mais changer celle-ci semble difficile, alors autant documenter les écarts...

La première stratégie (section 4.1), est de réagir différemment selon que l'erreur est reçue pendant la phase d'établissement de la connexion ou bien après. Le noyau Linux, depuis la version 2.0.0, renonce immédiatement à l'établissement d'une connexion TCP lorsqu'il reçoit le paquet ICMP pendant ledit établissement. L'application peut alors immédiatement passer à l'adresse suivante.

La seconde stratégie (section 4.2) est plus méfiante. Elle consiste à ne renoncer à l'établissement de la connexion qu'après N erreurs ICMP, avec N > 1 (il vaut exactement un dans la stratégie précédente). C'est la méthode utilisée par FreeBSD. (Par contre, je ne trouve pas comment régler N sur FreeBSD 7.0.)

Évidemment, violer la norme n'est pas innocent. La section 5 détaille donc les conséquences qui attendent le violeur. Par exemple, 5.1 explique qu'un problème temporaire qui affecte toutes les adresses de destination risque d'empêcher complètement la création d'une nouvelle connexion, alors qu'un TCP conforme à la norme aurait patienté et serait finalement passé. Il y a ici clairement un compromis entre l'attente, dans l'espoir de finalement réussir (parfait pour les connexions non-interactives comme un transfert de fichier nocturne avec rsync lancé par cron) et l'abandon rapide (sans doute préférable pour les applications interactives, où il ne faut pas bloquer l'utilisateur humain).

Une machine IPv6 doit évidemment avoir une adresse IP unique mais il existe une autre contrainte, c'est que les 64 bits de plus faible poids de cette adresses, l'interface identifier (RFC 4291, section 2.5.1), doivent être uniques sur le lien auquel la machine est attachée. Or, certains interface identifier sont réservés et ne doivent pas être utilisés. Lorsque l'interface identifier est attribuée manuellement par l'administrateur système, pas de problème. Mais s'il est attribué par autoconfiguration (RFC 4862) ? Ou par des une des autres méthodes citées dans l'annexe A du RFC ? Dans ce cas, le logiciel doit prendre garde à ne pas utiliser ces identificateurs notre RFC que réserve.

C'étaient plusieurs RFC qui réservaient ces identificateurs et ils n'avaient pas encore été rassemblés en un seul endroit, ce qui est désormais fait. Les identificateurs réservés seront dans le futur placés dans le registre IANA.

Notre RFC 5453 est assez court : la section 2 fait quelques rappels sur les interface identifiers, la section 3 explique toutes les horribles choses qui arriveront s'ils ne sont pas uniques (par exemple, une machine qui a pris l'interface identifier FDFF:FFFF:FFFF:FFFE va « capturer » tout le trafic normalement envoyé au Home agent des machines mobiles, décrit dans le RFC 2526).

Et la section 4 donne le contenu initial du registre, la liste des interface identifiers réservés, qui comprend 0000:0000:0000:0000 et la plage qui va de FDFF:FFFFFFFF:FF80 à FDFF:FFFF:FFFF:FFFF.

Le système de résolution de noms DNS est indispensable à la grande majorité des sessions sur l'Internet et pourtant il est très peu fiable. « Empoisonner » un résolveur DNS, lui faire avaler de fausses informations, est relativement facile, et ce problème est connu depuis longtemps (et documenté dans le RFC 3833, notamment les sections 2.2 et 2.3). Il existe une solution à long terme, DNSSEC, mais il n'est pas évident qu'elle puisse un jour être déployée suffisamment pour fournir une réelle protection. Alors, que faire en attendant ? Ce RFC documente les mesures que devrait prendre un résolveur pour ne pas se faire empoisonner.

Le résolveur DNS est le logiciel qui se charge de poser les questions, pour le compte des applications (client, pour ce RFC). Il en existe plusieurs possibles (en ne comptant que le logiciel libre et que les logiciels sérieux : BIND, Unbound et PowerDNS Recursor). Il utilise typiquement UDP pour poser la question aux serveurs DNS faisant autorité. UDP ne reposant pas sur une connexion, un attaquant qui essaie d'empoisonner le résolveur peut, juste après que la question aie été posée, envoyer une réponse fabriquée de toute pièce et, dans certains cas, la faire accepter. Bien que le DNS aie été amélioré au cours du temps (voir notamment le RFC 2181), il reste trop fragile. Pire, comme la plupart des résolveurs sont également des caches, une fausse réponse, une fois acceptée, sera resservie à chaque requête d'un client. Heureusement, le résolveur peut rendre cet empoisonnement bien plus difficile, en utilisant quelques techniques décrites par notre RFC. Celui-ci ne concerne que les résolveurs, les serveurs faisant autorité (par exemple ceux de l'AFNIC pour .fr) ne sont pas concernés. Les résolveurs sont typiquement gérés par le FAI ou les administrateurs du réseau local de l'organisation.

La publication de la faille Kaminsky en août 2008 a mis sous le feu des projecteurs cette vulnérabilité des résolveurs DNS. Mais elle était connue depuis des années, et le travail sur ce RFC avait commencé à l'IETF bien avant que la faille Kaminsky soit découverte. La première version officiellement adoptée par l'IETF date en effet de janvier 2007 et la première version tout court remonte à août 2006. Hélas, bien que plus agile que la plupart des autres organismes de normalisation, l'IETF est parfois un mammouth difficile à faire bouger. Pour diverses raisons, comme le fait que les auteurs du futur RFC (parmi lesquels Bert Hubert, le père de PowerDNS) étaient des nouveaux venus, le processus a pris plus longtemps qu'il n'aurait dû.

Oublions les retards. Que contient ce RFC ? La section 2 rappele le problème et la cible visée, les programmeurs qui écrivent les résolveurs et, dans une moindre mesure, les administrateurs de ceux-ci.

La section 3 décrit le mécanisme d'empoisonnement. L'idée, présente dans la section 5.3.3 du RFC 1034 est que, ne pouvant compter sur la protection qu'apportent les connexions TCP, les résolveurs DNS doivent se méfier des réponses UDP et vérifier que la réponse corresponde à une question actuellement en cours. Cela implique :

• Que la question (qui est rappelée dans la réponse DNS) soit une question en attente. Le truc 0x20, expliqué plus loin, pousse encore plus loin cette idée.
• Que le Query ID (RFC 1035, section 4.1.1) de la réponse soit celui de la question en cours. Notons que ce Query ID ne fait que 16 bits, ce qui est très insuffisant.
• Que la réponse soit adressée à la bonne adresse IP (si le résolveur en a plusieurs) et au bon port (c'est surtout sur la question du port que ce RFC apporte une nouveauté, voir plus loin).

Comme prévu par ce RFC (et d'autres documents antérieurs comme le RFC 3833) et comme l'a montré la faille Kaminsky, en 2008, il était trop facile, avec la plupart des résolveurs, de prévoir les informations à fournir, seul le Query ID était imprévisible et devait être essayé par force brute. Mais il n'a que 65536 valeurs possibles.

La section 4 détaille cette attaque. En effet, il existe une certaine différence entre la théorie et la pratique, et cette différence avait protégé le DNS jusqu'à présent. D'abord (section 4.1), il faut que le résolveur fasse une requête pour qu'on puisse tenter de fournir une fausse réponse. Si le résolveur est ouvert (ce qui est très dangereux, voir RFC 5358), c'est trivial. S'il ne l'est pas, l'attaque est restreinte aux clients légitimes du résolveur (c'est le cas de l'attaque Kaminsky mais ce n'est pas une grosse limitation car beaucoup d'attaquants ont déjà un zombie à leur service sur le réseau attaqué) ou à ceux qui attendent une requête spontanée. (On peut aussi indirectement provoquer une requête par exemple en envoyant un message dont la lecture déclenchera la requête DNS.) Il existe des méthodes pour prévoir le moment où se déclenchera la prochaine requête. Par exemple, certains résolveurs, sans permettre l'accès au service complet, permettent l'accès au cache (avec BIND, l'option allow-recursion <MYNETWORKS> ne suffit donc pas à protéger le résolveur, il faut aussi un allow-query-cache <MYNETWORKS>). Dans ce cas, l'attaquant peut voir le TTL et rpévoir lorsqu'il atteindra zéro, menant à une requête.

Une section est ensuite consacrée à chaque élément de la réponse, que l'attaquant doit connaître ou deviner (RFC 1035, section 7.3). La section 4.3 détaille la protection qu'offre le Query ID, un nonce de seulement 16 bits (et encore plus faible dans certaines implémentations comme le résolveur de Microsoft qui, pendant longtemps, n'utilisait que 14 bits). Si l'attaquant peut générer plusieurs requêtes simultanées (ce que permet l'attaque Kaminsky), le paradoxe de l'anniversaire lui offre de grandes chances de tomber juste. PLus loin, la section 5 détaille ce paradoxe de l'anniversaire. Il doit son nom à une observation simple. Dans un groupe de personnes (par exemple des étudiants dans un amphi), quelle doit être la taille du groupe pour avoir au moins 50 % de chances que deux aient la même date d'anniversaire ? La plupart des gens pensent au premier abord que ce nombre est de l'ordre de 180 (les 365 jours de l'année divisés par 2 puisqu'on veut une chance sur deux) alors qu'il est bien plus bas, environ 23. Appliqué au DNS, ce paradoxe veut dire que, certes, trouver un Query ID particulier est difficile mais que trouver un Query ID identique à un autre, à n'importe quel autre, est beaucoup plus facile.

La section 4.4 rappelle que l'adresse IP source de la réponse doit correspondre à celle à qui a été envoyée la question et que le succès de l'attaque dépend donc de la possibilité, pour l'attaquant, de tricher sur son adresse IP. En dépit des RFC 2827 et RFC 3704, la plupart des opérateurs permettent en effet à leurs clients d'indiquer n'importe quelle adresse IP source.

La section 4.5 étudie le rôle du port source de la requête, port où doit être renvoyé la réponse. La principale originalité de ce RFC est en effet de recommander l'utilisation des 16 bits du numéro de port comme source additionnelle d'entropie, en renfort des sources existantes comme le Query ID.

Enfin, la section 4.6 rappelle que l'attaquant n'a qu'un temps limité devant lui. Il doit répondre avant le vrai serveur soit, typiquement, en moins de 50 à 100 ms. Toutefois, l'attaquant peut améliorer ses chances en ralentissant le vrai serveur, par exemple par une attaque DoS.

Une dernière ligne de protection du résolveur (section 6) est de n'accepter que des réponses « dans la bailliage », c'est-à-dire des réponses dans le domaine de la question posée. Si un résolveur interroge les serveurs de demaziere.fr sur l'adresse IP de www.demaziere.fr, les réponses, notamment dans la section additionelle, devraient être ignorées si elles portent sur d'autres domaines. L'absence de ce test permettait l'attaque dite Kashpureff et cette vérification du bailliage est recommandée depuis le RFC 2181.

D'accord, il existe une vulnérabilité. Mais, en pratique, quel est le risque réel ? Peut-on le quantifier ? C'est l'objet des sections 7 et 8, qui vont faire un peu de mathématiques pour estimer la difficulté réelle d'empoisonnement d'un résolveur. Par exemple, si le port source est constant (ce qui était fréquent au début de la rédaction du RFC), il fallait injecter de fausses réponses au rythme de 416 Mb/s pour avoir une chance sur deux de gagner. Si le serveur réel était ralenti ou stoppé par une attaque, on pouvait se contenter de nettement moins, soit 42 Mb/s. Les calculs détaillés figurent en section 7.1 et 7.2. La conclusion est que, avec un port source fixe, l'empoisonnement est assez accessible. Avec un port variable, il faut un débit de 285 Gb/s ce qui explique que les résolveurs d'aujourd'hui sont encore protégés pour quelque temps. Augmenter le TTL favorise le défenseur, sauf si les requêtes sont pour des domaines inexistants, ce qui est le cas de l'attaque Kaminsky (discutée plus en détail en section 8.1).

Après ces calculs inquiétants, quelles sont les contre-mesures possibles, exposées en section 9 ? D'abord, le résolveur doit déjà utiliser la totalité des mesures recommandées par les RFC 1035 et RFC 2181, ce qui n'est pas encore le cas pour tous aujourd'hui. Ensuite, la plus importante contre-mesure nouvelle est l'aléatoirisation du port source (SPR pour Source Port Randomization), c'est-à-dire le fait d'utiliser peu ou prou les 65536 valeurs théoriquement possibles comme source des requêtes (section 9.2, qui recommande aussi de faire varier l'adresse IP si possible, ce qui n'est guère réaliste qu'avec IPv6). C'est cette technique qui est mise en œuvre dans BIND depuis 2008 et un peu avant dans Unbound et PowerDNS. En pratique, ces résolveurs, suivant la recommandation du RFC, utilisent les ports de 1024 à 65536.

À noter (section 10) que cette aléatoirisation du port source (voire de l'adresse) peut entrainer des problèmes avec certains routeurs NAT dont la table des flux en cours va vite déborder.

À noter aussi que la tâche de compliquer l'empoisonnement ne se termine pas avec ce RFC. Par exemple, l'IETF travaille sur un truc nommé 0x20 (voire la section 4.2 de notre RFC) qui consiste à faire varier la casse du nom de domaine dans la question pour ajouter un peu d'entropie supplémentaire.

Une autre raison importante des délais qu'a subi ce RFC est la controverse autour de DNSSEC (RFC 4033). Le raisonnement des « ultras » de DNSSEC est le suivant : comme les mesures anti-empoisonnement de notre RFC 5452 ne font que le rendre plus difficile, sans l'empêcher totalement, pourquoi perdre du temps à retarder l'attaquant lorsqu'on peut le stopper complètement avec DNSSEC ? En outre, DNSSEC protège contre d'autres attaques comme une trahison par un serveur secondaire faisant autorité. Bref, selon ce courant, très fortement représenté à l'IETF, travailler sur la résistance à l'empoisonnement est une perte de temps, voire une diversion par rapport aux seules tâches qui comptent, le déploiement de DNSSEC. Le RFC a donc eu du mal à passer face à une telle opposition (voir par exemple le compte-rendu de la réunion de Minneapolis en 2008). C'est ce qui explique le « lip service » qu'on trouve au début du RFC, avec l'affirmation que notre RFC ne décrit que des mesures temporaires, en attendant la « vraie » solution, DNSSEC. En réalité, le déploiement de DNSSEC, chez tous les acteurs (serveurs faisant autorité et distribuant des zones signées, résolveurs validant et/ou applications testant DNSSEC) va prendre de nombreuses années et ne sera peut-être jamais suffisamment effectif pour gêner réellement les empoisonneurs. Des mesures rendant leur tâche plus difficile sont donc essentielles.