Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Les RFC (Request For Comments) sont les documents de référence de l'Internet. Produits par l'IETF pour la plupart, ils spécifient des normes, documentent des expériences, exposent des projets...

Leur gratuité et leur libre distribution ont joué un grand rôle dans le succès de l'Internet, notamment par rapport aux protocoles OSI de l'ISO organisation très fermée et dont les normes coûtent cher.

Je ne tente pas ici de traduire les RFC en français (un projet pour cela existe mais je n'y participe pas, considérant que c'est une mauvaise idée), mais simplement, grâce à une courte introduction en français, de donner envie de lire ces excellents documents. (Au passage, si vous les voulez présentés en italien...)

Le public visé n'est pas le gourou mais l'honnête ingénieur ou l'étudiant.


RFC 4998: Evidence Record Syntax (ERS)

Date de publication du RFC : Août 2007
Auteur(s) du RFC : T. Gondrom (Open Text Corporation), R. Brandner (InterComponentWare), U. Pordesch (Fraunhofer Gesellschaft)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ltans
Première rédaction de cet article le 11 octobre 2007


Ce RFC spécifie un format pour signer, sur le très long terme, des enregistrements. L'exigence de durée est un gros problème pour la cryptographie car les algorithmes de signature peuvent être cassés avec le temps.

Conçu dans le cadre du groupe de travail IETF ltans, ce RFC propose une méthode simple. Chaque signature est accompagnée d'une date et les dates sont elles-même signées (et resignées si un algorithme s'avère à l'usage trop simple, donc une application peut avoir à suivre une chaîne de signatures, ce que décrit la section 5). Le RFC 4810 qui donnait le cahier des charges du groupe de travail précisait déjà la nécessité de prouver l'intégrité d'un document après des dizaines d'années, malgré les progrès qu'avait fait la cryptographie pendant ce temps.

Notre RFC spécifie également d'autres techniques pour résister au passage du temps, comme le fait de mettre autant que possible au moins deux signatures, avec des algorithmes différents, pour augmenter les chances qu'un d'eux résiste (section 7).

Le format est spécifié en utilisant le langage ASN.1.


Téléchargez le RFC 4998


L'article seul

RFC 4997: Formal Notation for Robust Header Compression (ROHC-FN)

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : R. Finking (Siemens/Roke Manor Research), G. Pelletier (Ericsson)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF rohc
Première rédaction de cet article le 31 juillet 2007


Ce RFC décrit un langage formel pour spécifier les en-têtes d'un paquet et, surtout, pour indiquer le mécanisme de compression utilisé.

Tous les réseaux ne disposent pas d'un excès de bande passante. Même aujourd'hui, les vieux modems restent en service (y compris dans un pays riche, mais étendu, comme les États-Unis) et certaines technologies récentes offrent une bande passante limitée (par exemple sur les téléphones mobiles). Il est donc utile de pouvoir comprimer les données et aussi les en-têtes des paquets émis, qui sont souvent très redondants, ouvrant ainsi de bonnes perspectives pour la compression. Le premier grand travail dans ce domaine avait été la compression des en-têtes TCP par Van Jacobson en 1990 (RFC 1144). Par la suite, plusieurs mécanismes de compression ont été inventés et le projet ROHC (Robust Header Compression) a été créé pour mettre de l'ordre dans ces mécanismes, en développant un cadre commun, spécifié dans le RFC 3095 et dans plusieurs autres (ROHC est désormais normalisé dans le RFC 5795).

Il manquait à tous ces RFC un langage formel, toutes les descriptions étant en langue naturelle. C'est désormais fait avec notre RFC et ce langage, ROHC-FN, rejoint donc ABNF (RFC 5234) et MIB (RFC 2578) comme langage formel pour aider à la normalisation. La première utilisation de ROHC-FN a été dans le RFC 5225.

On notera que ROHC-FN permet également la description formelle des en-têtes des paquets, description qui était traditionnellement faite dans les RFC par des ASCII box. Voici un en-tête (imaginaire) en ASCII box :

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |version| type  |    flow_id    |
   +---+---+---+---+---+---+---+---+
   |  sequence_no  |   flag_bits   |
   +---+---+---+---+---+---+---+---+

et le même décrit en ROHC-FN :

     eg_header
     {
       UNCOMPRESSED {
         version_no   [ 2 ];
         type         [ 2 ];
         flow_id      [ 4 ];
         sequence_no  [ 4 ];
         flag_bits    [ 4 ];
       }

Si on intègre la compression, ce qui est le but principal de ROHC-FN, on peut avoir :

       COMPRESSED obvious {
         version_no    =:= uncompressed_value(2, 1);
         type          =:= irregular(2);
         flow_id       =:= static;
         sequence_no   =:= lsb(0, -3);
         abc_flag_bits =:= irregular(3);
         reserved_flag =:= uncompressed_value(1, 0);
       }

ce qui exprime le fait que version_no a toujours la même valeur (1), que type n'est pas comprimable, ou que sequence_no ne l'est pas dans un paquet mais qu'une compression inter-paquets est possible (le numéro de séquence s'incrémentant légèrement à chaque paquet).

Ces différentes méthodes (uncompressed_value, lsb, etc) sont décrites dans la section 4.11 de notre RFC.

On notera qu'il existe d'autres langages pour la description de structures binaires comme les en-têtes mais qu'apparemment aucun ne convenait pour l'IETF.


Téléchargez le RFC 4997


L'article seul

RFC 4995: The RObust Header Compression (ROHC) Framework

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : L-E. Jonsson (Optand), G. Pelletier (Ericsson), K. Sandlund (Ericsson)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF rohc
Première rédaction de cet article le 22 décembre 2008
Dernière mise à jour le 30 mars 2010


Quels que soient les progrès des technologies, il n'y a jamais assez de capacité. Même aujourd'hui, les vieux modems restent en service (y compris dans un pays riche, mais étendu, comme les États-Unis) et certaines technologies récentes offrent une capacité limitée (par exemple sur les téléphones mobiles). Il est donc utile de pouvoir comprimer les données et aussi les en-têtes des paquets émis, qui sont souvent très redondants, ouvrant ainsi de bonnes perspectives pour la compression. Plusieurs mécanismes de compression ont été inventés et le projet ROHC (Robust Header Compression) a été créé pour mettre de l'ordre dans ces mécanismes, en développant un cadre commun. Ce RFC spécifie ce cadre.

La section 1 du RFC, l'introduction, donne quelques chiffres sur les gains qu'on peut tirer de la compression. Par exemple, si on utilise RTP (RFC 3550) pour transporter de la voix sur IP, il faudra transporter les 40 octets de l'en-tête (en IPv6), les 12 octets de l'en-tête UDP et les 8 octets de l'en-tête RTP (sans compter les en-têtes de la couche liaison). Ainsi, un paquet de données de 20 octets (une taille courante en voix sur IP) pourrait nécessiter 60 octets d'en-têtes TCP/IP.

Le RFC originel sur ROHC était le RFC 3095 qui incluait à la fois le cadre général et les profils de compression pour certains protocoles (un profil est un protocole de compression donné, adapté à un certain protocole). Une réforme générale de ROHC a eu lieu et il est désormais normalisé dans plusieurs RFC, notre RFC 4995, à l'origine, pour le cadre général, les RFC 4996 et RFC 5225 pour des profils pour, respectivement, TCP et les protocoles sans connexion comme IP ou UDP, le RFC 4997 pour le langage formel de définition des compressions, etc. (Le RFC 3095 n'est pas officiellement abandonné puisque le protocole est le même, il est juste mieux décrit.) Depuis, le RFC 5795 est sorti, remplaçant notre RFC 4995 en corrigeant quelques bogues.

La section 3 du RFC décrit les bases de la compression. Le principe est que le compresseur ne transmette pas certaines informations, car elles n'ont pas changé, ou bien peuvent être déduites automatiquement. Cela implique que le décompresseur puisse se souvenir de l'état de la compression, ce que ROHC nomme le contexte (la section 2.2 décrit toute la terminologie). Le maintien de ce contexte, même en présence de perturbations sur le réseau, est le principal défi de la compression. Sur des liens de mauvaise qualité (par exemple avec beaucoup de pertes), les mécanismes de compression pré-ROHC se comportaient plutôt mal (voir aussi la section 1).

Naturellement, rien n'est gratuit : le gain en capacité du réseau sera obtenu au détriment de la puissance de calcul, puisque compression et décompression nécessitent des calculs. La vitesse des processeurs des téléphones portables augmentant plus vite que leur capacité réseau, le choix de la compression semble raisonnable.

La section 3.2 rappelle l'histoire de la compression. Le premier grand travail dans le monde TCP/IP avait été la compression des en-têtes TCP par Van Jacobson en 1990 (RFC 1144), dont tous les utilisateurs de SLIP dans les années 1980 et 90 se souviennent (« Tu es sûr d'avoir activé la compression VJ ? »).

La section 4 décrit de manière relativement informelle le fonctionnement de ROHC, notamment (section 4.1), les différentes classes de changement dans les en-têtes, qui permettent leur prédiction par le décompresseur. Ainsi, la classe STATIC décrit les informations qui ne changent pas pendant la durée du flux de données (le numéro de version IP par exemple), la classe INFERRED étant composée des en-têtes qui peuvent se déduire ou se calculer à partir d'autres informations (comme la taille du paquet).

La vraie définition de ROHC est en section 5. C'est là qu'on trouve, par exemple, la description du mécanisme de rétroaction (section 5.2.4) qui permet au décompresseur de tenir le compresseur au courant du succès (ou de l'échec) de son travail. Autre exemple (section 5.1.2), chaque canal de communication ROHC a, parmi ses paramètres, un identificateur du profil utilisé (la liste des identificateurs possibles est dans un registre IANA, voir également la section 8). La section 5.4 normalise ainsi le profil d'identificateur 0x0000, le profil qui ne fait rien (en oubliant une partie, ce qui a été corrigé dans le RFC 5795), les profils « actifs » étant définis dans d'autres RFC.

Des déploiements de ROHC sont déjà faits dans les téléphones portables. Il existe une implémentation libre, RObust Header Compression (ROHC) library (merci à Didier Barvaux pour cela), tirée d'une plus ancienne bibliothèque. La section 6 du RFC 3095 contient une excellent section sur les problèmes concrets de mise en œuvre de ROHC (section qui ne semble pas avoir été reprises dans les RFC plus récents).


Téléchargez le RFC 4995


L'article seul

RFC 4993: A Lightweight UDP Transfer Protocol for the Internet Registry Information Service

Date de publication du RFC : Août 2007
Auteur(s) du RFC : A. Newton (Verisign)
Chemin des normes
Première rédaction de cet article le 21 septembre 2007


Un court RFC pour ajouter un nouveau transport au protocole IRIS. Désormais, IRIS peut utiliser UDP, un peu comme le DNS.

IRIS, spécifié dans le RFC 3981, est un protocole d'interrogation de registres Internet. Il fonctionne typiquement au dessus de TCP mais il existe une demande pour un transport plus léger, purement requête/réponse, avec un seul paquet pour chacune. Ce transport, LWZ (Lightweight using Compression aujourd'hui mais il avait une autre signification, sans que le sigle ait changé), est normalisé dans ce RFC.

LWZ est simple : la question est un élément XML IRIS classique, précédé de quelques octets (section 3 du RFC) indiquant notamment l'identificateur de la transaction (afin de permettre de mettre en correspondance les questions et les réponses) et la longueur maximale de réponse acceptable. Même chose pour le paquet de réponse.

Il n'existe à ma connaissance que deux implémentations, dans les logiciels Irisserv et FlowerBed de Verisign. Ces deux logiciels sont peu maintenus, mais ont un support de LWZ (surtout sur Flowerbed).

À ma connaissance, il n'existe pas de serveurs IRIS publics, que ce soit avec LWZ ou pas.

La sécurité de LWZ est très faible et, notamment, il présente les mêmes failles que le DNS : identificateur de transaction trop petit, donc vulnérable aux tentatives d'usurpation, taille du paquet réponse très supérieure à la taille du paquet question, donc risque que les serveurs IRIS servent à des attaques avec amplification, etc. La section 8, sur la sécurité, semble bien faible par rapport à ces risques.


Téléchargez le RFC 4993


L'article seul

RFC 4987: TCP SYN Flooding Attacks and Common Mitigations

Date de publication du RFC : Août 2007
Auteur(s) du RFC : W. Eddy (Verizon)
Pour information
Réalisé dans le cadre du groupe de travail IETF tcpm
Première rédaction de cet article le 1 septembre 2007


Curieusement, malgré le nombre d'attaques ayant visé le protocole TCP, aucun RFC n'avait documenté lesdites attaques et les solutions couramment utilisées comme les SYN cookies.

TCP (RFC 793) est de très loin le plus utilisé des protocoles de transport sur Internet. Même les applications qui font passer l'essentiel de leur trafic en UDP comme la téléphonie, dépendent de TCP pour l'établissement et la coupure de la liaison. Une attaque sur TCP a donc typiquement des effets dévastateurs et la première à avoir été largement médiatisée, l'attaque par SYN flooding contre Panix en 1996, a provoqué une prise de conscience. De nombreuses défenses contre les différentes attaques ont été développées dans les années qui ont suivi et ce RFC est le premier à les documenter.

La section 2 de notre RFC décrit en détail le SYN flooding qui consiste à envoyer des paquets de demande d'ouverture de connexion (des paquets SYN) sans jamais répondre aux accusés de réception (packets ACK). Les mises en œuvre typiques de TCP ont un tableau de taille fixe pour leurs connexions TCP et le seul paquet SYN suffit à réserver une case de ce tableau, jusqu'à l'expiration d'un délai qui est typiquement de plusieurs minutes.

Sans avoir besoin de révéler son adresse IP, avec un trafic relativement faible, un attaquant peut donc empêcher la machine cible d'accepter des nouvelles connexions TCP, empêchant ainsi tout service.

Un outil comme hping permet d'automatiser cette attaque, sans que l'attaquant aie même à savoir programmer (non, je ne donnerai pas les détails gratuitement).

La section 3 du RFC s'attaque ensuite aux mesures de défense comme les SYN cookies, qui consiste à ne pas allouer du tout d'état à la réception du paquet SYN, mais à encoder les informations contenues dans ce paquet dans le numéro de séquence TCP initial. La réception du paquet ACK, le deuxième paquet envoyé par le client, permettra de vérifier qu'un SYN avait bien été envoyé et que l'ACK du serveur avait bien été reçu. Cette idée, mise au point par Dan Bernstein, est conforme au principe « ne pas allouer d'état sans authentification » posé dans la section 4.1.1 du RFC 4732.

Les SYN cookies posent quelques problèmes à TCP (décrits dans la section 3.6 du RFC ou, par exemple, dans le manuel sur FreeBSD). C'est pour cela qu'ils ne sont typiquement pas activés par défaut. Par exemple, sur une Debian, il faut les configurer à yes dans le fichier /etc/network/options (qui indique au script de démarrage qu'il doit mettre à jour la variable Linux /proc/sys/net/ipv4/tcp_syncookies).

Aussi, d'autres solutions existent comme le SYN cache, qui alloue un état, mais de petite taille ou comme l'abandon, lorsque la table des connexions en cours est pleine, des connexions non actives les plus anciennes.


Téléchargez le RFC 4987


L'article seul

RFC 4984: Report from the IAB Workshop on Routing and Addressing

Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : D. Meyer, L. Zhang, K. Fall
Pour information
Première rédaction de cet article le 28 septembre 2007


En octobre 2006, l'IAB a tenu un séminaire à Amsterdam, consacré aux questions fondamentales de routage et d'adressage sur Internet. Ce RFC est le compte-rendu de ce séminaire.

Cela fait très longtemps que l'avenir du routage et de l'adressage, les deux bases de la sécurité et de la stabilité de l'Internet, suscitent des inquiétudes. Par exemple, la rapide consommation d'adresses IPv4 a mené au début des années 90 à la création d'IPv6. Mais le problème n'a pas cessé, l'inquiétude principale portant désormais sur le routage. Les routeurs de la DFZ (Default-Free Zone, l'ensemble des routeurs qui n'ont pas de route par défaut et doivent donc avoir une entrée dans leur table de routage pour chaque réseau indépendant) consomment de plus en plus de mémoire et d'autres ressources, pour stocker les (aujourd'hui) 230 000 routes de l'Internet. Est-ce que la croissance actuelle pourra se poursuivre ?

Le séminaire a donc étudié le problème actuel et les capacités des routeurs à supporter encore quelques années (cinq ? dix ?) de croissance (la passionnante section 4 décrit en détail les problèmes de matériel des routeurs, prenant en compte jusqu'à la question du refroidissement). Il s'est aussi penché sur les phénomènes à l'origine de cette croissance. Bien sûr, il y a le nombre de personnes connectées à l'Internet. Mais il y a aussi des causes nouvelles, comme la montée de la mobilité, ou comme les demandes des utilisateurs pour le multihoming, c'est-à-dire être connecté par plusieurs FAI.

Le problème est très difficile à résoudre car, à son cœur, se trouve une contradiction entre les demandes des opérateurs, qui préféreraient des adresses fortement agrégées en gros préfixes (de façon à limiter le nombre de ces derniers) et les utilisateurs qui préféreraient pouvoir router à volonté « leurs » adresses. Une des pistes pour trancher ce nœud gordien est la séparation de l'identificateur et du localisateur, actuellement fusionnés dans l'adresse IP. Ce point est détaillé dans les sections 2.2, 6 et 7.2 de notre RFC.

Le RFC se termine par un ensemble d'exigences que devra satisfaire la solution proposée et par des recommandations que le problème, bien que non immédiat, soit traité sérieusement. Conscient de la contradiction entre les intérêts des différentes parties prenantes, l'IAB recommande également que les futurs séminaires ou forums ne comprennent pas que des fabricants de routeurs et des opérateurs...

La publication du RFC, bien tardive, a été retardée par des désaccords sur certains des conclusions. Alors que le RFC aurait dû être un compte-rendu factuel de ce qui s'était dit à Amsterdam, il a failli être compris comme un plan d'action stratégique, devant donc faire l'objet d'un relatif consensus. La discussion lancée par ce séminaire se poursuit aujourd'hui sur la liste RAM.


Téléchargez le RFC 4984


L'article seul

RFC 4981: Survey of Research towards Robust Peer-to-Peer Networks: Search Methods

Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : J. Risson, T. Moors (University of New South Wales)
Pour information
Première rédaction de cet article le 21 septembre 2007


Les techniques pair-à-pair ont une place de plus en plus importantes sur Internet aujourd'hui mais aucune ne semble formellement normalisée. Ce RFC est donc le premier RFC à parler du pair-à-pair, via une étude de la littérature existante.

S'il n'existe pas de RFC, ni d'ailleurs d'autres texte normatifs, sur aucun des fameux protocoles de pair-à-pair, il y a en revanche une abondante littérature scientifique sur ce sujet. Tellement abondante qu'il est parfois difficile de s'y retrouver. Notre RFC entreprend donc un tour général de cette littérature, et s'appuie sur une bibliographie d'une taille très inhabituelle pour un RFC, avec plus de 380 références.

Le résultat est utile, mais pas forcément très digeste. Et il souligne l'absence de l'IETF dans le champ des techniques pair-à-pair, bien qu'elles représentent aujourd'hui probablement la majorité du trafic de l'Internet.

Notre RFC décrit donc les différents types d'index, du centralisé de Napster au distribué de Freenet, puis les index « sans sémantique », c'est-à-dire où l'identificateur d'une ressource est complètement opaque (et qui se prêtent donc bien à une mise en œuvre via des DHT comme Pastry ou Chord) et enfin les index « à sémantique », plus faciles pour la recherche floue, lorsqu'on ne sait pas bien ce qu'on veut, mais moins efficaces.

Peut-être les changements sont-ils encore trop rapides, dans cette technique assez jeune ? Ou peut-être la diabolisation du pair-à-pair pratiquée par certains gros intérêts financiers effraie t-elle les SDO ? En tout cas, le pair-à-pair reste pour l'instant complètement hors du champ de la normalisation.


Téléchargez le RFC 4981


L'article seul

RFC 4960: Stream Control Transmission Protocol

Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : R. Stewart
Chemin des normes
Première rédaction de cet article le 22 septembre 2007
Dernière mise à jour le 26 septembre 2007


Une des particularités du protocole IP est que vous avez plusieurs protocoles de transport disponibles. TCP et UDP sont les plus connus mais SCTP, normalisé dans notre RFC, est également intéressant. (Il a depuis été remplacé par le RFC 9260.)

SCTP ressemble plutôt à TCP, notamment par le fait qu'il fournit un transport fiable. Mais il a plusieurs différences :

  • il ne gère pas un flot d'octets continu mais une série de messages, bien séparés (comme le fait BEEP),
  • il gère plusieurs flux de données séparés, qui partagent le même contrôle de congestion mais gèrent à part les pertes et retransmissions,
  • il gère le cas où la machine a plusieurs adresses IP, ce qui lui fournit normalement plus de redondance, si on est connecté à plusieurs réseaux.

Cette dernière possibilité le rapproche des protocoles qui séparent l'identificateur et le localisateur et lui permet de gérer proprement le multihoming.

Cela se fait en indiquant, au début du contact, toutes les adresses IP (et même les noms de domaines, cf. la section 3.3.2.1) de la machine.

SCTP tient également compte de l'expérience acquise avec TCP. par exemple, l'établissement d'une connexion (que SCTP nomme association) se fait avec un échange de quatre paquets (et non pas trois comme avec TCP), pour offrir une meilleure protection contre les dénis de service. Les SYN cookies, un ajout plus ou moins bancal en TCP, sont ici partie intégrante du protocole.

SCTP est surtout issu des demandes du monde de la téléphonie sur IP, qui avait besoin d'un tel protocole pour la signalisation mais il peut être aussi utilisé dans d'autres domaines.

Le premier RFC à avoir normalisé SCTP était le RFC 2960. Les changements qu'introduit ce nouveau RFC ne modifient pas en profondeur le protocole mais corrigent les nombreux problèmes survenus pendant ses premières années d'utilisation. Le RFC 4460 donne la liste complète des problèmes corrigés. Depuis, le RFC 9260 a également légèrement révisé la norme.

Un bon tutoriel existe, SCTP for beginners et un excellent article du Linux Journal.

SCTP est depuis longtemps mis en œuvre dans Linux et, depuis peu également dans FreeBSD. De même, des programmes de débogage comme Wireshark sont capables de décoder et d'afficher le SCTP. Le support de SCTP est parfois limité, voici un exemple de ce que racontait tcpdump, lors d'une ouverture de connexion, sur une machine Ubuntu de 2007 :

09:06:07.896605 IP 192.0.2.33.32769 > 192.0.2.34.7: sctp[|sctp]

et ce qu'il indique, pour la même activité en TCP. C'est bien plus détaillé :

09:06:58.441737 IP 192.0.2.33.49874 > 192.0.2.34.7: S 2577209510:2577209510(0) win 32792 >mss 16396,sackOK,timestamp 243393 0,nop,wscale 7<

Ceci dit, avec une Ubuntu plus récente, en 2010, on a enfin l'association SCTP complète :

 
14:25:18.931093 IP 192.168.2.1.6666 > 192.168.2.25.8888: sctp (1) [INIT] [init tag: 4133424833] [rwnd: 55808] [OS: 10] [MIS: 65535] [init TSN: 1604754740] 
14:25:18.931236 IP 192.168.2.25.8888 > 192.168.2.1.6666: sctp[|sctp]
14:25:18.937771 IP 192.168.2.1.6666 > 192.168.2.25.8888: sctp[|sctp]
14:25:18.937882 IP 192.168.2.25.8888 > 192.168.2.1.6666: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 1604754740] [a_rwnd 56314] [#gap acks 0] [#dup tsns 0] 

Des exemples de programmes de tests SCTP se trouvent dans mon article sur le RFC 3286.

On pourra consulter une étude comparée des différents protocoles de transport concurrents de TCP dans l'article A Survey of Transport Protocols other than Standard TCP.

Il n'est pas sûr que les coupe-feux laissent passer SCTP de si tôt... L'Internet s'ossifiant de plus en plus, il devient très difficile de déployer un nouveau protocole de transport.

Un bon résumé de l'histoire et des avantages de SCTP se trouve dans Why is SCTP needed given TCP and UDP are widely available?.


Téléchargez le RFC 4960


L'article seul

RFC 4957: Link-layer Event Notifications for Detecting Network Attachments

Date de publication du RFC : Août 2007
Auteur(s) du RFC : S. Krishnan (Ericsson Research), N. Montavont (LSIIT - University Louis Pasteur), E. Njedjou (France Telecom), S. Veerepalli (Qualcomm), A. Yegin (Samsung AIT)
Pour information
Réalisé dans le cadre du groupe de travail IETF dna
Première rédaction de cet article le 8 août 2007


Un court RFC pour expliquer comment une pile IP peut tirer parti des indications envoyées par la couche 2 pour déterminer si un changement de réseau physique vient d'avoir lieu.

Il est fréquent qu'une machine puisse changer de réseau physique sans redémarrer : cela peut arriver en Wi-Fi, bien sûr, mais aussi avec les technologies issues de la téléphonie mobile comme 3GPP et même avec Ethernet lorsqu'on débranche et rebranche un câble.

Les paramètres de la connexion IP dépendent souvent du réseau physique sous-jacent. IP doit donc être prêt à changer ces paramètres lorsque la machine change de réseau. Il reste à détecter automatiquement ce changement et notre RFC explique, pour chaque technique de couche 2, les méthodes possibles et leurs problèmes éventuels.

Pour 3GPP/GPRS par exemple, notre RFC explique dans sa section 3.1 que c'est l'établissement du contexte PDP (Packet Data Protocol) qui signale que IP est disponible et qui doit donc être utilisé comme évenement déclencheur de la (re)configuration IP.

Pour Ethernet, c'est plus compliqué. La présence de ponts exécutant le protocole spanning tree fait que la connexion physique au lien ne signifie pas que les trames passent déjà. Et rien n'indique aux stations connectées que le protocole a terminé et que les trames peuvent désormais passer. Le RFC expose ce problème mais ne propose pas de solution simple.


Téléchargez le RFC 4957


L'article seul

RFC 4954: SMTP Service Extension for Authentication

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : R. Siemborski (Google), A. Melnikov (Isode Limited)
Chemin des normes
Première rédaction de cet article le 17 septembre 2007


Le courrier électronique, tel que spécifié à l'origine, reposait entièrement sur la confiance aveugle des acteurs entre eux. N'importe quel serveur de messagerie pouvait demander n'importe quoi à n'importe quel autre et les expéditeurs de courrier pouvaient indiquer ce qu'ils voulaient dans le courrier. Aujourd'hui, les demandes de sécurité sont plus fortes, d'où ce RFC.

Il y a deux questions importantes, la sécurité du message (s'assurer qu'un message est authentique, quelles que soient les étapes traversées) et la sécurité du canal (s'assurer que le serveur à l'autre bout est le bon). Si cette dernière ne permet pas, à elle seule, d'authentifier un message (il faut pour cela utiliser des techniques comme PGP, spécifié dans le RFC 4880), elle est toutefois intéressante lorsqu'un serveur de messagerie veut n'autoriser certaines fonctions qu'à certains partenaires, dûment authentifiés.

Un exemple typique est le fait de relayer du courrier. On parle de « relais » lorsqu'un MTA transmet à un autre MTA un courrier dont le serveur destinataire n'est pas le destinataire final. Il devra donc relayer ce courrier. Autrefois, tous les serveurs relayaient. La montée du spam a mis fin à ces relais ouverts et, aujourd'hui, un serveur bien géré ne relaie que pour des clients autorisés et authentifiés.

Cette extension d'authentification utilise le cadre SASL, spécifié dans le RFC 4422. À l'intérieur de ce cadre sont spécifiées plusieurs méthodes d'authentification comme un mot de passe transmis en clair (RFC 4616).

Le serveur capable d'authentifier annonce cette possibilité en réponse à la requête EHLO :

% telnet mail.bortzmeyer.org smtp 
...
220 mail.bortzmeyer.org ESMTP Postfix (Debian/GNU)
EHLO mail.example.org
250-mail.bortzmeyer.org
...
250-AUTH DIGEST-MD5 CRAM-MD5

Ici, le serveur SMTP annonce, entre autres choses, sa capacité à gérer l'authentification.

Cette extension est mise en œuvre, par exemple, dans le serveur de messagerie Postfix.

Bien sûr, transmettre un mot de passe en clair sur Internet est le plus sûr moyen de se faire sniffer. Alors, notre RFC impose, pour tout mécanisme d'authentification à mot de passe en clair, d'utiliser TLS, spécifié dans le RFC 3207 et également disponible dans Postfix.

Ce RFC met à jour le RFC 2554, qui avait introduit cette extension. Il n'apporte pas de changements fondamentaux. Notons par exemple l'arrivée de SASLprep (RFC 4013, pour gérer des noms d'utilisateurs en Unicode).


Téléchargez le RFC 4954


L'article seul

RFC 4952: Overview and Framework for Internationalized Email

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : J. Klensin, Y. Ko (ICU)
Pour information
Réalisé dans le cadre du groupe de travail IETF eai
Première rédaction de cet article le 25 juillet 2007
Dernière mise à jour le 7 septembre 2008


Parmi les protocoles utilisés sur Internet, presque tous sont internationalisés depuis longtemps. Le dernier gros manque concernait les adresses de courrier électronique, obligées de s'en tenir à stephane@internet-en-cooperation.fr alors qu'on voudrait pouvoir écrire à stéphane@internet-en-coopération.fr. Désormais, nous avons une solution, Internationalized Email Addresses. Expérimentale à l'époque de la parution de ce RFC, cette solution est devenue une norme complète par la suite avec le RFC 6530, qui a remplacé ce RFC.

Bien sûr, pour l'exemple ci-dessus, le gain n'est pas évident. Mais il l'est beaucoup plus si vous voulez écrire votre adresse avec l'écriture arabe ou chinoise.

Le contenu des courriers était internationalisé depuis longtemps, au moins depuis MIME (RFC 1341 à l'origine, en juin 1992). Mais les adresses ne l'étaient pas encore. Notre RFC décrit le cadre général de l'internationalisation des adresses de courrier.

Il y a deux parties à l'adresse (décrites dans le RFC 2822) : la partie locale, à gauche du @ et le nom de domaine à droite. Si ce nom de domaine, depuis la sortie du RFC 3490, en mars 2003, peut s'écrire en Unicode (norme IDN), le courrier exigeait toujours un nom de domaine en ASCII donc un message de non-délivrance, par exemple, allait affichait la forme Punycode du nom. Ce n'était pas une vraie internationalisation.

Le cadre d'internationalisation du courrier couvre plusieurs aspects, couverts chacun par un RFC. Ce premier RFC expose l'architecture générale.

SMTP est modifié pour permettre une nouvelle extension, indiquant le support du courrier internationalisé (RFC 5336).

Le format des messages (RFC 2822) est modifié pour permettre d'inclure de l'Unicode, encodé en UTF-8, directement dans les en-têtes, comme le champ To: (RFC 5335).

Un mécanisme de repli (downgrading) était prévu pour le cas où un émetteur internationalisé rencontrerait un récepteur qui ne l'est pas, nécessitant une modification des adresses en ASCII (RFC 5504). En effet, contrairement à HTTP, le courrier ne fonctionne pas de bout en bout et le message est relayé par plusieurs serveurs, qu'on ne connait pas forcément a priori. Ce mécanisme s'est révélé bien compliqué pour pas grand'chose et a finalement été abandonné avec le RFC 6530.

De même, les protocoles POP et IMAP doivent être modifiés pour que le courrier ainsi internationalisé puisse être récupéré... et lu.

Le repli est certainement la partie la plus complexe et fera l'objet d'un RFC propre : modifier un message est toujours une opération délicate, notamment en présence de signatures cryptographiques, que le repli ne doit pas invalider !

Notons (section 6.3 du RFC) que les adresses de courrier sont utilisés en de nombreux endroits, par exemple comme identificateurs sur certains sites Web de commerce électronique, comme Amazon et que ces utilisateurs vont également devoir s'adapter. Quant on voit le nombre de sites, supposés professionnels, qui continuent à interdire des adresses de courrier légales, on mesure l'ampleur du travail. La sortie en février 2012 de la norme RFC 6530, qui remplace notre RFC, accélérera-t-elle les choses ?


Téléchargez le RFC 4952


L'article seul

RFC 4950: ICMP Extensions for MultiProtocol Label Switching

Date de publication du RFC : Août 2007
Auteur(s) du RFC : R. Bonica (Juniper), D. Gan, D. Tappan, C. Pignataro (Cisco)
Chemin des normes
Première rédaction de cet article le 6 août 2007


Ce RFC documente une simple extension à ICMP pour distribuer de l'information spécifique à MPLS.

De nombreux outils existent pour traiter les informations envoyées par le protocole de signalement ICMP, notamment le fameux traceroute. Notre RFC spécifie donc un moyen de permettre à un routeur MPLS de mettre des informations spécifiques à MPLS dans le paquet ICMP émis en cas de problème.

Depuis le RFC 4884, ICMP peut inclure des messages structurés, comme MIME le permet pour le courrier électronique. C'est cette possibilité qu'utilise notre RFC pour transmettre un message MPLS Label Stack qui inclue les valeurs des labels MPLS utilisés.

Si les LSR, les routeurs MPLS sont configurés pour signaler ces labels (tous les opérateurs ne le font pas), un programme comme traceroute pourra les afficher. Un patch est par exemple intégré dans Gentoo ou dans le traceroute de NANOG. Voici le résultat :

...
 5  p5-2-0-2.rar2.chicago-il.us.xo.net (65.106.6.161)  6.771 ms  15.769 ms  6.651 ms
 6  p1-0.IR1.Chicago2-IL.us.xo.net (65.106.6.138)  8.008 ms  6.910 ms  7.489 ms
 7  206.111.2.54.ptr.us.xo.net (206.111.2.54)  8.812 ms  7.224 ms  7.022 ms
 8  if-1-0.core2.CT8-Chicago.teleglobe.net (66.110.14.177)  6.955 ms  8.744 ms  7.288 ms
     MPLS Label=391 CoS=0 TTL=0 S=1
 9  if-0-1-0.core2.NTO-NewYork.teleglobe.net (66.110.14.22)  33.647 ms  33.673 ms  33.791 ms
     MPLS Label=106 CoS=0 TTL=0 S=1
10  if-4-0.core1.PG1-Paris.teleglobe.net (80.231.72.113)  104.626 ms  104.966 ms  107.155 ms
     MPLS Label=96 CoS=0 TTL=0 S=1
11  if-0-0.core2.PG1-Paris.teleglobe.net (80.231.72.34)  104.865 ms 111.197 ms  104.696 ms

Téléchargez le RFC 4950


L'article seul

RFC 4948: Report from the IAB workshop on Unwanted Traffic March 9-10, 2006

Date de publication du RFC : Août 2007
Auteur(s) du RFC : L. Andersson (Acreo AB), E. Davies (Folly Consulting), L. Zhang (UCLA)
Pour information
Première rédaction de cet article le 15 septembre 2007


La sécurité sur Internet est un problème très fréquemment mentionné. Rien d'étonnant donc à ce que l'IAB, organisme chargé entre autres de superviser les développements de l'architecture de l'Internet, aie décidé de réunir un certain nombre d'experts pour un séminaire sur « le trafic Internet non désiré ». Ce RFC est le compte-rendu de ce séminaire.

Le séminaire s'est tenu à Marina del Rey en mars 2006 et on peut déplorer l'extrême lenteur que met toujours l'IAB à publier les compte-rendus de ses intéressants séminaires.

De quoi a t-on parlé pendant ce séminaire ? D'abord, la définition de « trafic non désiré » s'est concentrée sur deux phénomènes spécifiques, le spam et les DoS. Ensuite l'IAB note qu'un des messages les plus importants à faire passer est que le trafic non désiré n'est pas seulement produit par quelques adolescents perturbés mais est majoritairement l'œuvre d'entreprises criminelles bien organisées au sein de ce que l'IAB appelle (section 2 et notamment 2.1 du RFC) l'économie souterraine. (Je prends mes distances face à ce terme car je ne suis pas sûr qu'elle soit si souterraine que cela, ni si distincte de l'économie légale. L'utilisation de paradis fiscaux ou de la fraude fiscale n'est pas spécifique à la Mafia. Mais revenons à la sécurité de l'Internet.)

Bref, au revoir l'image du boutonneux qui s'attaque aux serveurs du Pentagone pour impressionner ses copains. Place aux professionnels, qui agissent pour l'argent.

Cette économie souterraine fait que des ressources humaines, financières et techniques importantes sont dédiées aux utilisations illégales de l'Internet. Dans un réseau ouvert, ces utilisations peuvent faire beaucoup de dégâts, d'autant plus que beaucoup d'utilisateurs ne sont pas conscients de l'ampleur des dangers que courent leurs machines. Outre son caractère ouverte et l'absence de traçabilité construite dans le réseau lui-même, l'Internet doit une partie de sa vulnérabilité à son caractère international. On ne peut pas compter sur la police russe pour traquer ceux qui ont attaqué les réseaux informatiques en Estonie puisque ces attaquants agissaient sous la bienveillance de leur propre gouvernement.

Quelles sont les machines participant aux attaques ? Aujourd'hui, ce ne sont que rarement celles appartenant à l'attaquant (section 2.3). Celui-ci se sert plutôt de zombies, des machines piratées et asservies. Le RFC note que la grande majorité des machines connectées à Internet est vulnérable. En partie à cause des faiblesses de Microsoft Windows (que l'IAB minimise par souci du « politiquement correct ») mais aussi parce que ces machines ne sont pas gérées par des professionnels responsables. Même prévenu, il est rare que l'utilisateur d'une machine zombie la nettoie. Les problèmes sont pour les autres, pas pour lui et l'absence de responsabilité crée un terrain favorable pour les recruteurs de zombies.

Notons que le séminaire n'avait pas pour but de trouver une solution magique mais d'étudier le problème. Le compte-rendu est donc souvent balancé, car il n'y a pas de solution parfaite, uniquement des compromis. C'est ainsi que la section 2.4 rappelle que, si on change le réseau pour augmenter la traçabilité, ces nouvelles possibilités de surveillance vont certainement attirer des gens peu recommandables, qui seraient ravis d'utiliser ces nouvelles possibilités pour surveiller les citoyens.

La section 3 est ensuite consacrée à une étude de l'ampleur du problème, pour les différents acteurs, et aux stratégies qu'ils utilisent pour se défendre. C'est là par exemple que l'IAB rappelle que le RFC 2827 (alias BCP 38), qui permettrait de sérieusement limiter l'usurpation d'adresse IP, n'est pratiquement pas déployé aujourd'hui, par suite du manque d'intérêt financier à le faire (la section 4.2.1 détaille également ce problème, où le marché est incapable de déployer une solution qui bénéficierait à tous mais coûterait un peu à chacun).

La section 3.4 concerne les fournisseurs de services DNS. Sa principale recommandation est le déploiement rapide de l'anycast sur les serveurs importants. Notre RFC étant consacré aux trafic non désiré et notamment aux DoS, il n'est pas étonnant que les conseils qu'il donne n'aille pas dans le même sens que ceux des RFC qui se penchent surtout sur l'intégrité des données. Ainsi, DNSSEC est présenté comme un risque plutôt que comme une solution (la section 4.3.2 exprime également une certaine méfiance par rapport à la cryptographie).

La section 4 commence à s'attaquer aux solutions. On notera que plusieurs participants au séminaire ont estimé qu'on avait déjà toutes les solutions techniques nécessaires, le défi était de les déployer. Si le déploiement doit se faire sur les réseaux des grands opérateurs commerciaux, il est freiné par l'absence de retour sur investissement. Si le déploiement doit se faire sur les machines des utilisateurs, il est freiné par la difficulté d'éducation.

Compte-tenu de l'ampleur du problème, ne faut-il pas adopter des mesures drastiques, qui changeraient radicalement le modèle de l'Internet ? C'est par exemple ce que propose le projet « table rase » de l'université de Stanford, qui se propose de refaire complètement l'Internet, autour d'un modèle bien plus fermé où tout devrait être autorisé préalablement. Les sections 4.3.4 et surtout 5.1 sont consacrées à l'examen de telles solutions, qui évoquent le médecin assassinant le malade pour le guérir...

Les présentations faites lors du séminaire sont en partie en ligne, à l'exception de celles qui sont trop sensibles. Un compte-rendu du séminaire, plus court et plus vivant que le RFC, a été fait dans le numéro 70 de l'IETF Journal.


Téléchargez le RFC 4948


L'article seul

RFC 4946: Atom License Extension

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : J. Snell
Expérimental
Première rédaction de cet article le 21 juillet 2007


Cette extension au format de syndication Atom permet de spécifier la licence utilisée par l'auteur et autorise donc les lecteurs / agrégateurs / transformateurs de flux de syndication à prendre des décisions en toute connaissance de cause.

Atom, normalisé dans le RFC 4287 est un format de syndication bâti sur XML. L'un des buts de la syndication est de permettre à des logiciels de traiter automatiquement ces flux, pour les agréger avec d'autres, sélectionner certaines entrées, etc. Mais est-ce légal ? Cela dépend de la licence sous laquelle l'auteur des flux les distribue. La norme Atom fournissait déjà un élément <atom:rights> pour indiquer cette licence mais son contenu était prévu pour être lu par des humains, pas par des logiciels.

Atom est extensible, mais il n'a pas été nécssaire d'utiliser le mécanisme d'extension, cette fois. Notre RFC comble la faille en utilisant l'élément <atom:link>. Celui-ci sert à référencer toutes sortes de ressources, la nature de cette référence étant donnée par son attribut rel qui prend une valeur choisie dans le registre des relations.

Par exemple, ce blog, qui est distribué sous licence GFDL contient désormais dans son flux de syndication :


<link rel="license" type="text/html" title="GFDL in HTML format" href="http://www.gnu.org/copyleft/fdl.html"/>
<!--  draft-walsh-app-docbook-xml, not yet registered -->
<link rel="license" type="application/docbook+xml" title="GFDL in Docbook format" href="http://www.gnu.org/licenses/fdl.xml"/>
<link rel="license" type="text/plain" title="GFDL in plain text" href="http://www.gnu.org/licenses/fdl.txt"/>

ce qui permet à un lecteur de flux Atom de retrouver facilement la licence utilisée.

Cela ne veut pas dire qu'il saura a traiter, le RFC ne va pas jusqu'à spécifier un langage formel pour exprimer les licences, comme l'avait tenté (avec peu de succès) P3P.


Téléchargez le RFC 4946


L'article seul

RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : T. Narten (IBM), R. Draves (Microsoft), S. Krishnan (Ericsson)
Chemin des normes
Première rédaction de cet article le 26 août 2008
Dernière mise à jour le 18 décembre 2008


Une des particularités d'IPv6 est de disposer d'un mécanisme, l'autoconfiguration sans état qui permet à une machine de se fabriquer une adresse IP globale sans serveur DHCP. Ce mécanisme crée typiquement l'adresse IP à partir de l'adresse MAC de la machine et une même machine a donc toujours le même identifiant (les 64 bits les plus à droite de l'adresse IPv6), même si elle change de réseau et donc de préfixe. Il est donc possible de « suivre à la trace » une machine, ce qui peut poser des problèmes de protection de la vie privée. Notre RFC fournit une solution, sous forme d'un mécanisme de création d'adresses temporaires, partiellement aléatoires. (Elle a depuis été assez sérieusement révisée et améliorée dans le RFC 8981.)

L'autoconfiguration sans état, normalisée dans le RFC 4862 est souvent présentée comme un des gros avantages d'IPv6. Sans nécessiter de serveur central (contrairement à DHCP), ce mécanisme permet à chaque machine d'obtenir une adresse globale (IPv4, via le protocole du RFC 3927, ne permet que des adresses purement locales) et unique. Cela se fait en concaténant un préfixe (par exemple 2001:db8:32:aa12::), annoncé par le routeur, à un identifiant d'interface (par exemple 213:e8ff:fe69:590d, l'identifiant de mon PC portable - les machines individuelles, non partagées, comme les PDA sont particulièrement sensibles puisque la connaissance de la machine implique celle de son maître), typiquement dérivé de l'adresse MAC.

Partir de l'adresse MAC présente des avantages (quasiment toute machine en a une, et, comme elle est unique, l'unicité de l'adresse IPv6 est obtenue facilement) mais aussi un inconvénient : comme l'identifiant d'interface est toujours le même, cela permet de reconnaître une machine, même lorsqu'elle change de réseau. Dès qu'on voit une machine XXXX:213:e8ff:fe69:590d (où XXXX est le préfixe), on sait que c'est mon PC.

La solution initiale de ce problème avait été introduite par le RFC 3041, que notre RFC 4941 met à jour.

Les sections 1.2 et 2 du RFC décrivent le problème plus en détail. Elles notent entre autre que le problème n'est pas aussi crucial que l'avaient prétendu certains (une véritable campagne anti-IPv6 avait été montée à une époque par des gens mal informés). En effet, il existe bien d'autres façons, parfois plus faciles, de suivre une machine à la trace, par exemple par les fameux petits gâteaux de HTTP mais aussi par des moyens de plus haute technologie comme les caractéristiques matérielles de l'ordinateur, que l'on peut observer sur le réseau. Parmi les autres méthodes, notons aussi que si on utilise les adresses temporaires de notre RFC 4941 mais qu'on configure sa machine pour mettre dynamiquement à jour un serveur DNS avec cette adresse, le nom de domaine suffirait alors à suivre l'utilisateur à la trace !

La section 2.2, consacrée à la situation actuelle avec IPv4, fait d'ailleurs remarquer que la situation n'est pas parfaite avec IPv4 non plus, et que certains articles qui sonnaient l'alarme contre les dangers de IPv6 étaient donc vraiment peu informés. Aujourd'hui, en pratique, beaucoup de machines ont une adresse IPv4 qui change peu ou pas et elles sont donc plus vulnérables au « pistage » (sauf si elles changent de réseau souvent) que les machines IPv6 utilisant ce RFC 4941.

La section 2.4 commence à discuter des solutions possibles. DHCPv6 (RFC 3315, notamment la section 12) serait évidemment une solution, mais qui nécessite l'administration d'un serveur. L'idéal serait une solution qui permette, puisque IPv6 facilite l'existence de plusieurs adresses IP par machine, d'avoir une adresse stable pour les connexions entrantes et une adresse temporaire, non liée à l'adresse MAC, pour les connexions sortantes, celles qui « trahissent » la machine. C'est ce que propose notre RFC, en générant les adresses temporaires selon un mécanisme pseudo-aléatoire.

Enfin, la section 3 décrit le mécanisme de protection lui-même. Il y a deux cas, celui où on dispose d'un mécanisme de stockage des données, par exemple une mémoire Flash et celui où l'appareil, trop simple, n'a pas un tel mécanisme.

Le premier cas est détaillé dans la section 3.2.1 : on stocke une « valeur historique » à chaque génération d'une adresse. On utilise la valeur précédente, on la concatène à l'identifiant d'interface et on passe le tout à travers MD5. Les 64 premiers bits du résumé MD5 formeront le suffixe de l'adresse IPv6. La faiblesse cryptographique de MD5 n'est pas un problème, on ne cherche pas ici à résister à une attaque, juste à condenser un nombre aléatoire. Il n'est pas nécessaire que toutes les machines utilisent la même fonction de hachage et l'usage d'autres algorithmes que MD5 est donc autorisé.

La section 3.2.2 traite des cas où un dispositif de stockage n'existe pas et recommande alors l'usage d'une source réellement aléatoire, selon le RFC 4086.

Une fois l'adresse temporaire générée (les détails sont dans la section 3.3), il faut la renouveler de temps en temps (sections 3.4 et 3.5, cette dernière expliquant pourquoi renouveler une fois par jour est plus que suffisant). L'ancienne adresse peut rester active pour les connexions en cours mais plus pour de nouvelles connexions.

Maintenant que l'algorithme est spécifié, la section 4 du RFC reprend de la hauteur et examine les conséquences de l'utilisation des adresses temporaires. C'est l'occasion de rappeler un principe de base de la sécurité : il n'y a pas de solution idéale, seulement des compromis. Si les adresses temporaires protègent davantage contre le « flicage », elles ont aussi des inconvénients comme de rendre le débogage des réseaux plus difficile. Par exemple, si on note un comportement bizarre associé à certaines adresses IP, il sera plus difficile de savoir s'il s'agit d'une seule machine ou de plusieurs.

L'utilisation des adresses temporaires peut également poser des problèmes avec certaines pratiques prétendument de sécurité comme le fait, pour un serveur, de refuser les connexions depuis une machine sans enregistrement DNS inverse (un nom correspondant à l'adresse, via un enregistrement PTR). Cette technique est assez ridicule mais néanmoins largement utilisée.

Un autre conflit se produira, note la section 7, si des mécanismes de validation des adresses IP source sont en place dans le réseau. Il peut en effet être difficile de distinguer une machine qui génère des adresses IP temporaires pour se protéger contre les indiscrets d'une machine qui se fabrique de fausses adresses IP source pour mener une attaque.

Quelles sont les différences entre le RFC originel, le RFC 3041 et celui-ci ? Peu importantes, elles sont résumées dans la section 8. Les principales sont des demandes plus fortes sur la configurabilité de l'usage des adresses temporaires, l'acceptation explicite d'autres fonctions de hachage que MD5 et surtout le fait que le réglage standard par défaut doit désormais être de couper l'usage des adresses IP temporaires. En revanche, les changements ont été davantage prononcés avec la mise à jour suivante de cette technique, dans le RFC 8981.

Sur MS-Windows, ce mécanisme semble avoir été implémenté depuis Vista.

Sur Linux, notre RFC est mis en œuvre depuis longtemps (c'est l'option CONFIG_IPV6_PRIVACY de compilation du noyau), mais désactivé par défaut, comme demandé par le RFC (section 3.6). Le paramètre sysctl qui contrôle ce protocole est net.ipv6.conf.XXX.use_tempaddr où XXX est le nom de l'interface réseau, par exemple eth0. En mettant dans le fichier /etc/sysctl.conf :

# Adresses temporaires du RFC 4941
net.ipv6.conf.default.use_tempaddr = 2

On met en service les adresses temporaires, non « pistables » pour toutes les interfaces (c'est le sens de la valeur default). Il y a plusieurs pièges, très bien expliqués par Pascal Hambourg : au moment où le sysctl.conf est lu, le module noyau ipv6 n'est pas forcément chargé. Et certaines interfaces ont pu être configurées avant, alors que default ne s'applique qu'aux futures interfaces. Pour s'assurer que les réglages soient bien pris en compte, il vaut mieux faire en sorte que le module ipv6 soit chargé tout de suite (sur Debian, le mettre dans /etc/modules) et que les interfaces fixes aient leur propre réglage. Par exemple, sur Debian, on peut mettre dans /etc/network/interfaces :

iface eth2 inet dhcp
   pre-up sysctl -w net.ipv6.conf.eth2.use_tempaddr=2

Ou alors il faut nommer explicitement ses interfaces :

net.ipv6.conf.eth0.use_tempaddr = 2

Le comportement du noyau Linux face à ces options est souvent surprenant. Voir par exemple la bogue #11655. Notez aussi qu'ifconfig n'affiche pas quelles adresses sont les temporaires (mais ip addr show le fait).

Notons que l'adresse « pistable » est toujours présente mais vient s'y ajouter une adresse temporaire choisie au hasard. Selon les règles du RFC 6724, rappelées dans la section 3.1 de notre RFC, c'est cette adresse temporaire qui sera choisie, en théorie, pour les connexions sortantes. Avec Linux, il faut pour cela que use_tempaddr vale plus que un (sinon, l'adresse temporaire est bien configurée mais pas utilisée par défaut). ifconfig affichera donc :

wlan0     Link encap:Ethernet  HWaddr 00:13:e8:69:59:0d  
...
          inet6 addr: 2001:db8:32:aa12:615a:c7ba:73fb:e2b7/64 Scope:Global
          inet6 addr: 2001:db8:32:aa12:213:e8ff:fe69:590d/64 Scope:Global

puis, au démarrage suivant, l'adresse temporaire (la première ci-dessus) changera :

wlan0     Link encap:Ethernet  HWaddr 00:13:e8:69:59:0d
...
          inet6 addr: 2001:db8:32:aa12:48a9:bf44:5167:463e/64 Scope:Global
          inet6 addr: 2001:db8:32:aa12:213:e8ff:fe69:590d/64 Scope:Global

Sur NetBSD, il n'y a qu'une seule variable syscvtl pour toutes les interfaces. Il suffit donc de mettre dans /etc/sysctl.conf :

net.inet6.ip6.use_tempaddr=1

Par contre, je n'ai pas trouvé comment faire que l'adresse temporaire soit utilisée par défaut. Sur FreeBSD, je n'ai pas essayé, mais je suppose que les variables sysctl au nom bien parlant net.inet6.ip6.use_tempaddr et net.inet6.ip6.prefer_tempaddr sont là pour cela.

Ceux qui veulent configurer ce service sur une machine Linux peuvent aussi lire Stateless Network Auto Configuration With IPv6 ou IPv6 privacy extensions on Linux. Sur les autres systèms, je suggère Enabling Privacy Enhanced Addresses for IPv6.


Téléchargez le RFC 4941


L'article seul

RFC 4934: Extensible Provisioning Protocol (EPP) Transport Over TCP

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 1 avril 2008
Dernière mise à jour le 7 mai 2008


Ce court RFC spécifiait comment utiliser le protocole d'avitaillement EPP au dessus d'une simple connexion TCP. Il a été remplacé depuis par le RFC 5734.

EPP, décrit dans le RFC 4930 est à sa base uniquement un format XML pour les requêtes d'avitaillement (création, mise à jour et destruction d'objets) et leurs réponses. Ces éléments XML peuvent être transmis de différence façon (au dessus de HTTP, de BEEP, par courrier électronique, etc), et notre RFC normalise la plus commune aujourd'hui, une simple connexion TCP. Il remplace le RFC 3734, avec uniquement des modifications de détail, portant notamment sur la sécurité (section 8).

Le RFC est court car il n'y a pas grand'chose à dire, juste l'utilisation des primitives de TCP (ouverture et fermeture de connexion, section 2 du RFC), l'ordre des messages (section 3) et le fait que chaque élément EPP soit précédé d'un entier qui indique sa taille (section 4). Sans cet entier (qui joue le même rôle que l'en-tête Content-Length de HTTP), il faudrait, avec la plupart des implémentations, lire les données octet par octet (sans compter que la plupart des analyseurs XML ne savent pas analyser de manière incrémentale, il leur faut tout l'élément). En outre, sa présence permet de s'assurer que toutes les données ont été reçues (voir l'excellent article The ultimate SO_LINGER page, or: why is my tcp not reliable).

L'entier en question est fixé à 32 bits. Si on programme un client EPP en Python, l'utilisation brutale du module struct ne suffit pas forcément. En effet :

struct.pack("I", length)

force un entier (int) mais pas forcément un entier de 32 bits. Pour forcer la taille, il faut utiliser également, comme précisé dans la documentation, les opérateurs < et >, qui servent aussi à forcer la boutianité (merci à Kim-Minh Kaplan pour son aide sur ce point). Voici une démonstration (un "l" standard fait 4 octets alors que le type long de C peut faire 4 ou 8 octets) :

# Machine 32 bits :

Python 2.4.4 (#2, Apr  5 2007, 20:11:18) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
4
>>> print struct.calcsize(">l")
4
# Machine 64 bits :

Python 2.4.5 (#2, Mar 11 2008, 23:38:15) 
[GCC 4.2.3 (Debian 4.2.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
8
>>> print struct.calcsize(">l")
4

Si on a quand même un doute, on peut tester la taille obtenue mais ce code est probablement inutile (merci à David Douard pour son aide ici) :


# Get the size of C integers. We need 32 bits unsigned.
format_32 = ">I"
if struct.calcsize(format_32) < 4:
    format_32 = ">L"              
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
elif struct.calcsize(format_32) > 4:
    format_32 = ">H"                
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
else:
    pass
...
def int_from_net(data):
    return struct.unpack(format_32, data)[0]

def int_to_net(value):
    return struct.pack(format_32, value)

L'algorithme complet d'envoi est :

epp_as_string = ElementTree.tostring(epp, encoding="UTF-8")
# +4 for the length field itself (section 4 mandates that)
# +2 for the CRLF at the end
length = int_to_net(len(epp_as_string) + 4 + 2)
self._socket.send(length)
self._socket.send(epp_as_string + "\r\n")

et la lecture :

data = self._socket.recv(4) # RFC 4934, section 4, the length 
                            # field is 4 bytes long
length = int_from_net(data) 
data = self._socket.recv(length-4)
epp = ElementTree.fromstring(data)
if epp.tag != "{%s}epp" % EPP.NS:
     raise EPP_Exception("Not an EPP instance: %s" % epp.tag)
xml = epp[0]

Le code Python complet (qui ne met en œuvre qu'une petite partie de EPP, le but était juste de tester ce RFC 4934), utilisant la bibliothèque ElementTree, est disponible en ligne.


Téléchargez le RFC 4934


L'article seul

RFC 4933: Extensible Provisioning Protocol (EPP) Contact Mapping

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : S. Hollenbeck
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF provreg
Première rédaction de cet article le 6 août 2007


Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux contacts, c'est-à-dire aux personnes physiques ou morales responsables d'un objet de la base et qui peuvent être contactées à son sujet. (L'objet étant typiquement un nom de domaine ou bien un préfixe IP.)

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 4930, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping) pour les contacts. Il n'est plus d'actualité, ayant été remplacé par le RFC 5733.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

Un contact est donc composé d'un identificateur (type clIDType du RFC 4930). Cet identificateur (on l'appelait traditionnellement le handle) est, par exemple, SB68-GANDI.

Les contacts ont aussi évidemment des moyens d'être contactés, via numéro de téléphone, adresse postale, etc.

Les contacts pouvant être des personnes physiques, pour protéger leur vie privée, la section 2.9 du RFC décrit aussi un format pour spécifier si ces informations doivent être publiées ou pas. Insuffisant pour tous les cas, ce format est en général remplacé, chez les registres européens, par un mapping spécifique (par exemple, EPP parameters for .pl ccTLD pour les polonais qui utilisent un élément <individual> pour indiquer si le contact est une personne physique, et a donc droit à la protection des lois européennes sur les données personnelles).

À titre d'exemple, voici la réponse d'un serveur EPP à une requête <epp:info> pour le contact SB68-GANDI :


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:infData
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>SB68-GANDI</contact:id>
        <contact:roid>SH8013-REP</contact:roid>
        <contact:status s="clientDeleteProhibited"/>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Exemple SA</contact:org>
          <contact:addr>
            <contact:street>123 rue de l'Exemple</contact:street>
            <contact:city>Trifouillis-les-Oies</contact:city>
            <contact:cc>FR</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+33.7035555555</contact:voice>
        <contact:fax>+33.7035555556</contact:fax>
        <contact:email>jdoe@example.com</contact:email>
        <contact:crDate>1997-04-03T22:00:00.0Z</contact:crDate>
        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
        <contact:disclose flag="0">
          <contact:voice/>
          <contact:email/>
        </contact:disclose>
      </contact:infData>
    </resData>
  </response>
</epp>

Ce RFC remplace son prédécesseur, le RFC 3733 mais ce ne sont que des modifications de détail. Lui-même a ensuite été remplacé par le RFC 5733, avec, là encore, peu de modifications.


Téléchargez le RFC 4933


L'article seul

RFC 4931: Extensible Provisioning Protocol (EPP) Domain Name Mapping

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 17 juin 2007


Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre (remplacé depuis par le RFC 5731), consacré aux noms de domaine.

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 4930, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping) pour les noms de domaine.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

On note que ce schéma, se voulant adaptable à de nombreux registres différents, ne colle parfaitement à la politique d'aucun. Par exemple, <infData> est spécifié ainsi :


    <sequence>
      <element name="registrant" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="contact" type="domain:contactType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="ns" type="domain:nsType"
       minOccurs="0"/>

ce qui veut dire que des « règles métier » très courantes comme « un titulaire et un seul » ou bien « au moins deux serveurs de noms » ne sont pas respectés avec le schéma EPP seul.

Ce RFC remplace son prédécesseur, le RFC 3731 mais ce ne sont que des modifications de détail. Lui-même a ensuite été remplacé par le RFC 5731.

Voici un exemple d'une réponse à une requête <epp:info> pour le domaine example.com :


<response>
  <result code="1000">
    <msg>Command completed successfully</msg>
  </result>
  <resData>
    <domain:infData
     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:name>example.com</domain:name>
      <domain:roid>EXAMPLE1-REP</domain:roid>
      <domain:status s="ok"/>
      <domain:registrant>jd1234</domain:registrant>
      <domain:contact type="admin">sh8013</domain:contact>
      <domain:contact type="tech">sh8013</domain:contact>
      <domain:ns>
        <domain:hostObj>ns1.example.com</domain:hostObj>
        <domain:hostObj>ns1.example.net</domain:hostObj>
      </domain:ns>
      <domain:host>ns1.example.com</domain:host>
      <domain:host>ns2.example.com</domain:host>
      <domain:clID>ClientX</domain:clID>
      <domain:crID>ClientY</domain:crID>
      <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
      <domain:upID>ClientX</domain:upID>
      <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
      <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
      <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
      <domain:authInfo>
        <domain:pw>2fooBAR</domain:pw>
      </domain:authInfo>
    </domain:infData>
  </resData>
...

On y voit les serveurs de noms du domaine, ns1.example.com et ns1.example.net, son titulaire, identifié par un code, ici jd1234, sa date de création, le 3 avril 1999, etc.

De même, pour créer un domaine, on appele <epp:create> avec des éléments de l'espace de nom urn:ietf:params:xml:ns:domain-1.0, par exemple :


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">2</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.com</domain:hostObj>
          <domain:hostObj>ns1.example.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>jd1234</domain:registrant>
...


Téléchargez le RFC 4931


L'article seul

RFC 4930: Extensible Provisioning Protocol (EPP)

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 17 juin 2007


Les registres, par exemple les registres de noms de domaine fonctionnent parfois sur un modèle registry/registrar c'est-à-dire, où le client final doit passer par un intermédiaire, le registrar pour enregistrer son nom de domaine. Le registrar souhaite en général avoir un protocole de communication avec le registre afin d'automatiser ses opérations, dans son langage de programmation favori. EPP, décrit dans ce RFC, est un de ces protocoles d'avitaillement (provisioning, et merci à Olivier Perret pour la traduction). (EPP n'emploie pas le terme de registrar mais celui de sponsoring client, plus neutre. EPP peut donc en théorie être utilisé en cas de vente directe.)

Notre RFC remplace le premier RFC sur EPP, le RFC 3730, mais les changements sont mineurs, essentiellement des bogues qui se produisent assez rarement dans la pratique, même si le registre du .eu a réussi à violer la norme XML en câblant en dur le préfixe d'espace de noms epp dans leur code, ce qui a nécessité une modification dans la section 2 de notre RFC pour rappeler que c'était interdit.

À son tour, notre RFC 4930 a été remplacé, par le RFC 5730, là encore avec peu de modifications.

EPP a été réalisé sur la base du cahier des charges dans le RFC 3375. Au lieu de s'appuyer sur les protocoles classiques de communication comme XML-RPC ou SOAP, ou même sur l'architecture REST, EPP crée un protocole tout nouveau, consistant en l'établissement d'une connexion (authentifiée) puis sur l'échange d'éléments XML, spécifiés dans le langage W3C Schemas.

Par exemple, l'ouverture de la connexion se fait en envoyant l'élément XML <login> :


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <login>
      <clID>ClientX</clID>
      <pw>foo-BAR2</pw>
      <newPW>bar-FOO2</newPW>
      <options>
        <version>1.0</version>
        <lang>fr-CA</lang>
      </options>
      <svcs>
        <objURI>urn:ietf:params:xml:ns:obj1</objURI>
        <objURI>urn:ietf:params:xml:ns:obj2</objURI>
        <objURI>urn:ietf:params:xml:ns:obj3</objURI>
      </svcs>
    </login>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Un des points délicats de la conception d'un tel protocole est que chaque registre a sa propre politique d'enregistrement et ses propres règles. Quoi que dise ou fasse l'ICANN, cette variété va persister. Par exemple, l'expiration automatique d'un domaine existe dans .com mais pas dans .eu ou .fr. Le protocole EPP ne prévoit donc pas d'éléments pour gérer telle ou telle catégorie d'objets (les domaines mais aussi les serveurs de noms ou les contacts). Il doit être complété par des mappings, des schémas dont certains sont spécifiés pas l'IETF comme le domain mapping (gestion des domaines) dans le RFC 4931. Plusieurs registres utilisent des mappings non-standard, pour s'adapter à leurs propres règles d'enregistrement, ce qui limite la portabilité des programmes EPP. C'est ce qu'ont fait les brésiliens ou les polonais.

Complexe, EPP n'a guère eu de succès chez les registres existants, sauf ceux qui refaisaient complètement leur logiciel comme .be. On notera que certains gros TLD comme .de n'utilisent pas EPP (Denic utilise son protocole MRI/RRI). Il existe d'autres protocoles d'avitaillement comme :

et beaucoup d'autres qui ne semblent pas forcément documentés publiquement.

Il existe plusieurs mises en œuvres d'EPP en logiciel libre par exemple le serveur EPP OpenReg de l'ISC, le logiciel Fred du registre de .cz ou bien le client EPP Net::DRI de Patrick Mevzek.


Téléchargez le RFC 4930


L'article seul

RFC 4925: Softwire Problem Statement

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : X. Li (Cernet), S. Dawkins (Huawei), D. Ward (Cisco), A. Durand (Comcast)
Pour information
Réalisé dans le cadre du groupe de travail IETF softwire
Première rédaction de cet article le 11 juin 2008


Les réseaux informatiques typiques d'il y a vingt ans étaient multi-protocoles et ces protocoles coexistaient plus ou moins harmonieusement. Pour connecter deux réseaux via un troisième, parlant un protocole différent, on utilisait souvent des tunnels. C'est ainsi que, par exemple, IP a servi à connecter beaucoup de réseaux AppleTalk. Puis IP a tout remplacé et les réseaux sont devenus mono-protocole. Maintenant, avec l'épuisement des adresses IPv4 qui se rapproche, avec le déploiement d'îlots IPv6 qu'il faut relier entre eux, les tunnels reviennent, et avec eux beaucoup de complexité. Un groupe de travail de l'IETF, softwire (« câbles virtuels ») travaille donc à une meilleure spécification de ces tunnels. Ce RFC est la première étape publiée de leur travail.

Les idées derrière le système des « câbles virtuels » (soft wires) sont très anciennes. Par exemple, le système de « courtier en tunnels » (tunnel broker) du RFC 3053, en janvier 2001, était déjà un câble virtuel, même si le mot n'existait pas encore. Mais pourquoi avoir remplacé les tunnels par des « câbles virtuels » ? La raison principale est cosmétique : les tunnels souffrent d'une mauvais réputation, lents, compliqués, peu fiables, posant des problèmes de MTU. Comme les balayeurs sont devenus techniciens de surface, comme le surveillant général est devenu conseiller d'éducation, les tunnels sont devenus des soft wires (la section 1.1 détaille le vocabulaire et définit le câble virtuel comme un tunnel, créé sous le contrôle d'un protocole, ce qui exclut donc les tunnels manuels).

Ce premier RFC ne fait que définir le problème. D'autres documents, en cours d'élaboration à l'IETF, s'occuperont des protocoles effectifs. La section 1 introduit le problème, spécifier des câbles virtuels qui pourront être établis rapidement, mais durer longtemps, afin de connecter des réseaux IP entre eux (typiquement, des réseaux IPv6 via un réseau IPv4). Cette section introduit également la grande distinction entre les topologies « Centraliser et redistribuer  » (Hubs and Spokes) et « Maillage » (Mesh). Dans le premier cas, le réseau est organisé autour de points proéminents (les hubs) qui concentrent le trafic et le redistribuent. Dans le second, tout le monde est au même niveau.

La section 2 est consacrée au « Centraliser et redistribuer  ». Les tunnels du RFC 4213 sont un exemple typique de cette approche. Voici, extrait de cette section, un cas où une machine double pile (v4 et v6) se trouve sur un réseau local où le CPE est purement v4 (la section 2.2 décrit plus finement ce cas), et qui est connecté à un FAI purement v4. Elle va donc établir un câble virtuel avec un concentrateur de câbles virtuel (le « hub ») qui va ensuite la connecter aux réseaux v6. Seul IPv6 circulera sur ce câble virtuel. softwire-fig3 Comme précisé dans la section 2.4, le protocole du câble virtuel doit permettre la délégation d'un préfixe IPv6 fixe, même si l'adresse IPv4 du CPE change. On peut utiliser pour cela le RFC 3633. Cette exigence fait que 6to4 ne permet pas de créer de véritables câbles virtuels, puisque l'adresse IPv6 change en même temps que la v4.

Dans le mode « Centraliser et redistribuer », c'est toujours la machine double pile qui crée le câble virtuel, en se connectant au concentrateur. Elle est nommée l'initiateur (section 2.5). Le concentrateur est typiquement un routeur double pile (section 2.6). Le RFC impose que le protocole permette « des millions » d'initiateurs. Le protocole de découverte du concentrateur n'est pas spécifié. Enfin, la section 2.11 détaille les exigences de sécurité, comme la possibilité d'authentifier les initiateurs.

La section 3, elle, parle de l'architecture maillée. Dans cette architecture, un réseau uniquement IPv4 connecte des clients IPv6 entre eux en fournissant des AFBR (Address Family Border Routers) qui parlent les deux protocoles et peuvent créer des câbles virtuels entre eux. Cela ressemble donc beaucoup aux VPN, par exemple dans le RFC 4364, mais sans l'exigence de gérer plusieurs espaces d'adressage distincts.

Les câbles virtuels, en pratique, vont nécessiter d'encapsuler les paquets d'un protocole (en général IPv6) dans un autre (en général IPv4). Les sections 2.13 et 3.5 discutent de l'encapsulation en notant que toutes les techniques existantes doivent pouvoir être utilisées. Cela implique GRE (RFC 2784), MPLS (RFC 3031) ou L2TP (RFC 3931).


Téléchargez le RFC 4925


L'article seul

RFC 4924: Reflections on Internet Transparency

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : B. Aboba (IAB), E. Davies (IAB)
Pour information
Première rédaction de cet article le 1 août 2007


Ce RFC nommé « Réflexions sur la neutralité de l'Internet » est essentiellement consacré à un rappel de l'importance qu'il y a à ne pas préjuger des usages et des applications. L'Internet doit rester transparent c'est-à-dire traiter de la même façon tous les paquets IP, sans privilégier certaines applications. C'est cette transparence qui a permis le développement spectaculaire de nouvelles applications et qui est aujourd'hui menacée.

Aujourd'hui, cette transparence est sérieusement menacée. Par exemples, certains opérateurs voudraient traiter de manière privilégiée certaines applications, ou au contraire contrarier certaines, comme la téléphonie sur IP, qui s'attaque à leur marché le plus rentable. C'est contre cette tendance que s'est développé le courant qui défend la neutralité du réseau.

Mais il y a d'autres menaces, par exemple, le déploiement de plus en plus fréquent de mécanismes qui empêchent la connexion de bout en bout, que ce soit :

  • le NAT pour pallier le manque d'adresses IPv4,
  • les coupe-feux mis au nom de la sécurité,
  • ou, pire, certains FAI qui redirigent discrètement les paquets, bloquent certains ports comme le 25 (SMTP) ou modifient les réponses DNS dans les récurseurs qu'ils offrent à leurs clients.

Notre RFC est donc consacré à l'analyse de ces problèmes et à un rappel de leur caractère négatif. En effet, le fait que l'Internet soit un réseau neutre, un oblivious transport (terme utilisé dans le rapport New Arch, que cite notre RFC), un simple transporteur de paquets, qui ne se permet pas de les examiner ou de les modifier, est l'un des points les plus importants de l'architecture de ce réseau. C'est ce point qui permet le développement d'applications nouvelles et non planifiées dès l'origine. L'exemple archétypal est bien sûr le Web, non prévu à l'origine de l'Internet et qui a pu être déployé progressivement ; sur un réseau transparent, il suffit que deux machines soit d'accord et elles peuvent tout de suite commencer à utiliser le nouveau protocole.

À l'opposé des réseaux transparents se trouvent des réseaux ossifiés comme les réseaux des opérateurs téléphoniques, liés à une seule application et ne permettant donc pas l'innovation, puisque tout changement doit être approuvé et mis en œuvre par l'opérateur.

L'Internet, traditionnellement transparent, devient de plus en plus ossifié. C'est ainsi que les routeurs NAT et les coupe-feux qui examinent le contenu des paquets ne laissent guère de chance à des nouveaux protocoles de transport comme SCTP (RFC 3286) d'être déployés. De même, les nouvelles applications sont souvent obligées de « tricher » en passant au dessus de HTTP, de façon à franchir les coupe-feux.

Il est temps de réagir. Ce RFC n'est pas le premier document sur la question, le pionnier avait été le RFC 2775 et notre nouveau RFC se consacre surtout aux nouveautés. Il décrit les facteurs qui s'opposent à la transparence comme le filtrage (section 2.1), d'autant plus problématique que très rares sont les FAI qui publient leur règle de filtrage, malgré le RFC 4084, certaines utilisations de la QoS (section 2.2), les passerelles applicatives (ALG, section 2.3), puisqu'elles doivent être mises à jour pour tout changement du protocole applicatif, mais aussi la manipulation des réponses DNS (section 2.5.2).

Certains FAI (apparemment, aujourd'hui, en France, Noos, Club-Internet et Tiscali) modifient les réponses DNS reçues par les serveurs faisant autorité. Typiquement, ils remplacent les réponses NXDOMAIN (No Such Domain, ce nom de domaine n'existe pas) par une adresse IP prédéterminée où un serveur Web leur propose moteur de recherche et publicités. Le RFC note que, outre leur incompatibilité avec DNSSEC, ces manipulations cassent le modèle de référence du DNS (qui est que le gérant d'une zone est l'autorité suprême sur le contenu de la zone).


Téléchargez le RFC 4924


L'article seul

RFC 4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals

Date de publication du RFC : Août 2007
Auteur(s) du RFC : N. Kushalnagar (Intel), G. Montenegro (Microsoft), C. Schumacher (Danfoss)
Pour information
Réalisé dans le cadre du groupe de travail IETF 6lowpan
Première rédaction de cet article le 8 janvier 2010


La norme IEEE 802.15.4 standardise un protocole de communication radio conçu pour des équipements légers, ayant peu de ressources (que ce soit des ressources de calcul ou bien en électricité). Le groupe de travail 6lowpan de l'IETF travaille à adapter IP à ces objets légers et à ce protocole radio. La réussite de 6lowpan permettrait le développement d'un véritable Internet des objets, connectant des engins qui ne sont en général pas classés parmi les ordinateurs.

Qu'est-ce qu'un « Low-Power Wireless Personal Area Networks » (LowPAN) ? Comme résumé par la section 1 du RFC, c'est un réseau de machines communiquant sans fil, à faible distance, avec IEEE 802.15.4. Et ces machines ont presque toujours peu de puissance électrique, un coût faible (donc peu de mémoire et peu de CPU) et le réseau ne va pas vite. Typiquement, les membres d'un « LowPAN » sont des capteurs et autres dispositifs de surveillance et de détection. Quel protocole de couche 3 (et au-dessus) faire tourner sur 802.15.4 ? Il existe un protocole privé, qui bénéficie d'un marketing virulent, Zigbee. Il est donc stratégiquement important qu'il soit remplacé par un protocole ouvert, c'est le but du groupe de travail 6lowpan. Ce RFC 4919 en est le premier document, qui décrit le problème à résoudre, en partant de l'hypothèse que les LowPAN utiliseront IPv6 (d'où le chiffre six au début du nom du groupe). Le second RFC publié a été le RFC 4944, contenant les détails pratiques d'utilisation d'IP sur 802.15.4.

La section 2 reprend l'ensemble des caractéristiques d'un LowPAN et permet d'imaginer les problèmes qu'elles peuvent poser à un déploiement d'IP traditionnel. Entre autres :

  • paquets de petite taille, le maximum de 802.15.4 étant de 127 octets. Avec les différents en-têtes obligatoires (notamment de chiffrement), il n'y a parfois plus que 81 octets libres pour IP.
  • Les adresses des machines d'un LowPAN peuvent être des adresses IEEE de 64 bits mais aussi des adresses abrégées de seulement 16 bits.
  • Capacité très faible : à 868 Mhz (une des fréquences normalisées), il n'y a que 20 kb/s.
  • Les machines d'un LowPAN peuvent s'organiser en étoile ou bien dans un réseau maillé.
  • Grand nombre de machines connectées, bien plus élevé que le nombre d'ordinateurs.
  • Machines peu fiables, souvent en panne, déplacées, à la batterie qui se vide...
  • Connectivité d'une machine souvent interrompue par ses périodes de sommeil (pour économiser le courant).

On le voit, ces caractéristiques sont très différentes de celles des Vax sur lesquels avait été programmée l'implémentation de TCP/IP à Berkeley !

Dans ce cadre, plutôt difficile, sur quoi peut compter le concepteur de protocoles pour 6lowpan ? La section 3 liste ces suppositions de base, sachant que certaines pourront évoluer dans le temps (après tout, la loi de Moore s'applique ici aussi et peut améliorer la situation) :

  • Il y aura une séparation entre les machines les plus « bêtes » (RFD, Reduced Function Devices) et des machines plus évoluées (FFD, Full Function Devices), qui pourront prendre à leur charge certaines des activités, notamment de coordination.
  • Le réseau devra utiliser IP, système déjà déployé, connu, et pour lequel il existe d'innombrables applications et plein d'outils de gestion du réseau.
  • Contrairement aux concurrents comme Zigbee, IP est ouvert, et accessible à tous. Il n'enferme pas chez un vendeur ou un cartel de vendeurs.
  • Le fait d'utiliser IP permet des interconnexions relativement faciles avec le reste de l'Internet.

Mais il y a aussi des problèmes concrets à résoudre, qui font l'objet de la section 4.

  • Vu le nombre d'objets attendus dans un LowPAN, il faut disposer de beaucoup d'adresses, ce qui impose IPv6, avec son immense espace d'adressage.
  • Comme il n'est pas question de gérer tous ces objets à la main, il faut un système d'auto-configuration. Là encore, IPv6 a tout ce qu'il faut.
  • La faible capacité du lien va nécessiter la compression des en-têtes (curieusement, ROHCRFC 5795 - n'est pas cité).
  • Le protocole de routage (section 4.2) devra à la fois gérer des topologies variées et ne pas être trop bavard, pour économiser la capacité du réseau. Il devra également tenir compte de l'exigence d'économie d'énergie (les protocoles existants ont été conçus pour des systèmes très différents de ceux d'un LowPAN).
  • Les équipements du LowPAN doivent autant que possible se configurer tout seuls : en effet, ils seront très nombreux (trop pour être configurés à la main un par un), avec des moyens d'entrée/sortie très limités, et souvent planqués dans des endroits difficiles d'accès.
  • Ce genre d'exigences ne va pas en général dans le sens de la sécurité. 802.15.4 impose un chiffrement (avec AES) mais ne dit rien de la gestion des clés (comment communiquer les clés à l'objet ?), de la sécurité dans les couches hautes. La section 4.4 insiste donc sur l'importance de développer des mécanismes de sécurité (voir aussi la section 6).

Bref, il va y avoir du travail. La section 5 donne les buts à atteindre :

  • Comme IP impose une taille minimale de paquets à sa couche 2, que cette taille est de 1280 octets en IPv6 (section 5 du RFC 2460), bien au delà des 81 octets libres, dans le pire cas, avec 802.15.4, il va falloir développer un mécanisme de fragmentation et réassemblage au niveau 2.
  • Comme l'en-tête IPv6 fait au minimum 40 octets, que l'en-tête TCP atteint 20 octets, il ne resterait que 21 octets pour les données ! Il est donc impératif de spécifier un mécanisme de compression des en-têtes.
  • Pour l'auto-configuration IPv6, il faut définir une correspondance entre les adresses IEEE 802.15.4 et les identificateurs d'interface utilisés par IP. Ces deux premiers points ont été traités dans le RFC 4944.
  • Un protocole de routage pour le réseau maillé doit être créé. Il existe des expériences diverses (RFC 3561, RFC 3626, RFC 3684), mais souvent pour des réseaux avec moins de contraintes que les LowPAN. (Voir un autre travail sur ce sujet dans le RFC 5826.)
  • Une des raisons de l'utilisation d'IP est la disponibilité de nombreux protocoles et outils, par exemple SNMP pour la gestion. Mais un agent SNMP est un logiciel complexe, peut-être trop pour l'objet LowPAN typique. Peut-être faudra t-il créer un profil simplifié de SNMP.
  • Même au niveau application, certains ajustements seront peut-être nécessaires. Par exemple, une usine à gaz comme SOAP est sans doute trop consommatrice de ressources. (À noter qu'il existe déjà une liste de diffusion sur les problèmes spécifiques aux applications, 6lowapp, qui évoluera peut-être en un groupe de travail.)

Où en sont les mises en œuvre de 6LowPAN ? Un exemple avec le source disponible est apparemment celle de NXP, JenNet-IP.


Téléchargez le RFC 4919


L'article seul

RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)

Date de publication du RFC : Juin 2007
Auteur(s) du RFC : L. Dusseault (Commerce.net)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF webdav
Première rédaction de cet article le 2 juillet 2007


Ce RFC spécifie une nouvelle version du protocole WebDAV (Web Distributed Authoring and Versioning), initialement décrit dans le RFC 2518. Les changements sont peu nombreux.

WebDAV étend le protocole HTTP pour faciliter le travail en groupe sur les ressources distribuées via le Web. HTTP offrait déjà des moyens de modifier une ressource (une ressource est en général un document) par les commandes PUT et DELETE, en plus des commandes permettant d'y accéder (GET), mais elles étaient peu utilisées en dehors de certaines applications REST. WebDAV étend les possibilités de ces commandes, notamment par le concept de collection (un groupe de ressources) et par celui de versions, décrit dans le RFC 3253, dit Delta-V. En outre, il ajoute des nouvelles commandes comme :

  • PROPFIND pour récupérer la liste des propriétés (métadonnées) d'une ressource,
  • LOCK et UNLOCK pour mettre et retirer des verrous sur les ressources, afin d'éviter qu'un auteur ne marche sur les pieds d'un autre.

Les réponses à ces nouvelles commandes sont formulées en XML et, comme dans la plupart des RFC récents, notre RFC recommande dans l'appendice A.2 d'être très prudent avec le traditionnel principe Be liberal in what you accept and conservative in what you send, principe qui, sur le Web, a fait plus de mal que de bien.

WebDAV est un protocole complexe (notre RFC est plutôt gros et il faut déjà connaitre HTTP pour le lire) et qui n'est qu'un succès mitigé. En pratique, il semble que la plupart des gens qui maintiennent un site Web chargent leur fichier en FTP ou bien directement en TTW, Through The Web, c'est-à-dire via leur navigateur et un formulaire, comme on peut le faire avec la plupart des CMS.

L'un des utilisateurs le plus connus de WebDAV est Subversion dont c'est le principal protocole d'accès au dépôt. Un serveur Subversion est donc un serveur WebDAV étendu (car WebDAV ne suffisait pas, tout gros qu'il soit), en général un Apache avec les modules dav et dav_svn. Voici par exemple une configuration typique d'Apache pour Subversion :


LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so

<VirtualHost *:443>
        ServerAdmin webmaster@example.net
        ServerName svn.example.net

        SSLEngine on 
        SSLCertificateFile /etc/apache2/apache.pem

        <Location />
              DAV svn
             
              SVNPath /home/Subversion-Repository

             AuthType Basic
             AuthName "Subversion Repository"
             require valid-user
        </Location>

</VirtualHost>

On voit alors dans le journal du serveur les requêtes spécifiques à WebDAV, ici un PROPFIND lors d'un svn update :

192.0.2.69 - bortzmeyer [29/Mar/2007:12:05:35 +0200] "PROPFIND / HTTP/1.1" 207 629 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net

Et ici la séquence d'ajout d'un nouveau fichier (par svn commit) qui se fait en déposant un fichier temporaire avec PUT, puis en le déplaçant avec MERGE - commande qui vient du RFC 3253 - avant de détruire le fichier temporaire avec DELETE :

192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "PUT /!svn/wrk/9c36d042-47ac-41d6-a455-b8a6091f6a3c/README HTTP/1.1" 201 225 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net
192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "MERGE / HTTP/1.1" 200 933 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net
192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "DELETE /!svn/act/9c36d042-47ac-41d6-a455-b8a6091f6a3c HTTP/1.1" 204 - "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net

Il semble y avoir peu de logiciels qui gèrent WebDAV, le principal sur Unix étant cadaver. Voici un exemple d'utilisation de cadaver pour envoyer des fichiers sur un serveur DAV :

% cadaver http://tmp.example.org:9701/tests_perf
Authentication required for Tests de performance on server `tmp.example.org':
Username: tester
Password: 

dav:/tests_perf/>   mput *
[Matching... 4 matches.]
Uploading AFNIC-2-Renater-Paris.pcap.gz to `/tests_perf/AFNIC-2-Renater-Paris.pcap.gz':
Progress: [=============================>] 100.0% of 289 bytes succeeded.
Uploading AFNIC-2-INRIA-Montbonnot.pcap.gz to `/tests_perf/AFNIC-2-INRIA-Montbonnot.pcap.gz':
Progress: [=============================>] 100.0% of 292 bytes succeeded.
Uploading Nerim-2-Renater-Paris.pcap.gz to `/tests_perf/Nerim-2-Renater-Paris.pcap.gz':
Progress: [=============================>] 100.0% of 289 bytes succeeded.
Uploading Nerim-2-INRIA-Montbonnot.pcap.gz to `/tests_perf/Nerim-2-INRIA-Montbonnot.pcap.gz':
Progress: [=============================>] 100.0% of 292 bytes succeeded.

dav:/tests_perf/> quit
Connection to `tmp.example.org' closed.

Mais on trouve du WebDAV en plusieurs endroits, par exemple comme protocole d'accès pour des serveurs de fichiers.

Le groupe de travail WebDAV de l'IETF a eu un parcours assez difficile et vient seulement d'être dissous, après dix ans d'existence, ce qui est extrêmement long pour l'IETF. Finalement, cette mise à jour du RFC 2518 n'apporte que des changements de détails, qui sont décrits dans l'appendice F.


Téléchargez le RFC 4918


L'article seul

RFC 4912: Abstract Syntax Notation X (ASN.X)

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : S. Legg (eB2Bcom)
Expérimental
Première rédaction de cet article le 25 juillet 2007


Voici un RFC expérimental (et dont mon pronostic est qu'il le restera) sur l'encodage de schémas ASN.1 en XML.

ASN.1 est un langage très utilisé dans les RFC pour décrire les données échangées entre deux systèmes. Il est notamment à la base du langage de description des MIB, les bases de données des agents SNMP. ASN.1 est probablement le langage formel le plus courant dans les RFC, même devant ABNF.

Ce n'est pas en raison de ses qualités propres, pourtant. Normalisé par l'ISO, il hérite les défauts habituels des normes ISO : diffusion payante et restreinte, documents très complexes et abstraits, écrits sans aucun souci pour les problèmes des implémenteurs.

C'est un de ces problème que traite ce RFC : ASN.1 est difficile à analyser en raison des multiples ambiguïtés de sa grammaire (section 1 du RFC). Changer la grammaire actuelle pour XML, en gardant la sémantique semble donc une idée tentante.

Le résultat est un RFC de 165 pages, un des plus longs car il a fallu reprendre toute la sémantique d'ASN.1. ASN.X est en effet décrit sous la forme d'une transformation d'une grammaire en ASN.1 en XML.

Par exemple, en appliquant ces règles de transformation, l'ASN.1 suivant :

SEQUENCE {
          one    INTEGER,
          two    BOOLEAN OPTIONAL,
          three   PrintableString DEFAULT "third"
      }

deviendra en XML :


<type>
       <sequence>
        <element name="one" type="asnx:INTEGER"/>
        <optional>
         <attribute name="two" type="asnx:BOOLEAN"/>
        </optional>
        <optional>
         <element name="three" type="asnx:PrintableString"/>
         <default literalValue="third"/>
        </optional>
       </sequence>
</type>

Le résultat semble aussi complexe que l'original et ne résout qu'un seul problème, celui de la syntaxe. Je ne lui prédis donc pas beaucoup d'avenir.


Téléchargez le RFC 4912


L'article seul

RFC 4907: Architectural Implications of Link Indications

Date de publication du RFC : Juin 2007
Auteur(s) du RFC : B. Aboba (IAB)
Pour information
Première rédaction de cet article le 25 juin 2007


Un RFC de l'IAB pour décrire l'usage que peuvent faire les protocoles Internet des indications envoyées par la couche Liaison (couche 2) du réseau.

Dans le traditionnel modèle en couches, que notre RFC rappelle dans sa jolie figure 1, la couche 2 ou couche de liaison (Link layer) peut donner aux couches supérieurs des indications utiles, par exemple que le lien fonctionne (Link Up) ou bien justement qu'il ne fonctionne pas (Link Down). Mais la réalité est bien plus complexe et ce RFC la détaille.

Ces indications sont typiquement transitoires (un lien, surtout les liens radio, qui sont le principal exemple donné dans le RFC, tombe en panne, remarche, etc). La section 1.4 est toute entière consacrée aux nombreuses méthodes existantes pour utiliser les indications de la couche 2. Il y en a beaucoup car aucune n'est idéale. Par exemple, sur un Ethernet 100base-T, il peut être tentant d'utiliser les indications données par le commutateur pour déterminer si le lien fonctionne ou pas. Mais un commutateur défaillant peut établir le signal, sans pour autant commuter les paquets. L'information de lien doit donc être utilisée avec prudence, les protocoles doivent toujours faire leurs propres tests (par exemple, OSPF (RFC 2328) ne se fie qu'à ses paquets Hello). Et c'est pire pour les liens radio, où la qualité du signal peut varier énormément. Bref, une machine qui se fierait aveuglément aux indications de la couche 2 pourrait avoir des faux positifs (le lien semble marcher mais les paquets ne passent pas) et des faux négatifs (le lien est tombé mais c'est transitoire, il ne faut pas interrompre les sessions TCP pour si peu). Ces problèmes sont également décrits dans le RFC 4436 qui propose une méthode pour savoir si la liaison réseau fonctionne, sans compter sur la couche 2 pour le dire.

La section 2 du RFC décrit en détail les règles qui doivent suivre les protocoles qui veulent utiliser les indications de la couche liaison. Par exemple, ceux-ci doivent résister à des indications erronnées de la couche 2.

La section 4 est consacrée aux questions de sécurité car les messages de la couche liaison sont en général non authentifiés et un atatquant peut donc relativement facilement simuler des évenements comme Link Down.

Enfin, une longue et détaillée annexe A passe en revue l'abondante littérature sur le sujet, notamment sur les protocoles sans fil, littérature qui montre que l'état d'un lien n'est pas aussi binaire (Up/Down) qu'on pourrait le penser.


Téléchargez le RFC 4907


L'article seul

RFC 4893: BGP Support for Four-octet AS Number Space

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : Q. Vohra (Juniper), E. Chen (Cisco)
Chemin des normes
Première rédaction de cet article le 22 mai 2007


Un des nombres trop petits de l'Internet était la taille des numéros de système autonome. Elle passe, avec ce RFC, de deux à quatre octets. (Il a depuis été remplacé par le RFC 6793.)

Il est assez courant dans l'Internet que des nombres prévus très larges au début s'avèrent ridiculement petits avec la croissance du réseau. C'est bien sûr le cas des adresses IPv4, dont les 32 bits sont bien trop peu pour le nombre de machines connectées aujourd'hui, mais c'est aussi vrai pour les numéros de système autonome (AS pour autonomous system). Chacun de ces numéros identifie un système autonome de routage, au sein duquel une politique de routage cohérente peut s'appliquer. En gros, chaque opérateur a un numéro de système autonome, les plus gros en ayant plusieurs (surtout en cas de fusion ou d'acquisition).

Ces numéros sont notamment utilisés par le protocole de routage BGP (normalisé dans le RFC 4271), pour indiquer le chemin à suivre pour joindre un réseau. La petite fonction shell bgproute permet d'interroger les serveurs de Route Views et affiche les numéros de système autonomes traversés :

% bgproute 80.67.162.1
AS path: 3257 3356 20766 20766
Route: 80.67.160.0/19

On voit que le serveur de Route Views a reçu l'annonce de la part du système autonome 3257 qui l'avait lui même reçu du système autonome 3356.

Ces numéros étaient stockés sur seulement 16 bits, ce qui ne permettait que 65 535 systèmes en tout, bien trop peu pour l'Internet d'aujourd'hui, qui va des villes chinoises aux hébergeurs brésiliens. Si certains conservateurs, méprisants et élitistes, ont regretté le fait que « n'importe qui, avec une armoire et deux PC avec Quagga » veuille faire du BGP, le fait est que l'Internet touche bien plus de monde et que la population des opérateurs a augmenté. D'où notre RFC, qui fait passer la taille des numéros d'AS à 32 bits, soit quatre milliards d'opérateurs possibles.

Ces nouveaux AS s'écriront en notation ASPLAIN, en écrivant directement le nombre, par exemple 112617 (RFC 5396).

Le changement lui-même est assez trivial mais, comme souvent sur Internet, le gros du travail (et qui prend la plus grande partie de notre RFC) était la gestion de la transition. Notre RFC explique avec beaucoup de soin comment un routeur BGP récent va pouvoir parler à un routeur de l'ancienne génération et comment les chemins d'AS 4-octets pourront être transmis même à travers des « vieux » routeurs, utilisant un mécanisme de tunnel (l'article de Geoff Huston l'explique très bien).

Pour cette transition, le nouveau BGP utilise un numéro d'AS spécial, le 23456, qui sert à représenter tous les AS 4-octets pour les anciens routeurs. Si vous voyez apparaitre ce système autonome, par exemple en tapant un show ip bgp sur un Cisco, c'est que votre logiciel est trop vieux.

La publication de notre RFC ne fait qu'entériner un changement déjà bien entamé ; cela fait plusieurs mois que les RIR allouaient des numéros sur quatre octets (voir par exemple la politique du RIPE-NCC). Depuis, la norme technique a été mise à jour dans le RFC 6793.

Ainsi, le système autonome 196613 est utilisé depuis plusieurs mois pour des tests. Le routeur de Route Views étant de la vieille génération, le préfixe 145.125.0.0/20, annoncé par l'AS 196613, est vu comme émanant du célèbre 23456 :

% bgproute 145.125.0.1   
AS path: 14608 19029 3356 3549 1103 1125 23456
Route: 145.125.0.0/20

Un petit regret personnel : l'encodage des paquets BGP étant insuffisamment robuste, rien n'indique à un programme qui analyse une session BGP (par exemple Wireshark) que la session utilise des numéros à quatre octets et on ne peut donc pas analyser une session si on n'a pas vu l'échange initial, où s'est décidé de coder les numéros d'AS sur deux ou quatre octets. Comme les sessions BGP durent souvent des semaines, cela peut être un problème gênant.


Téléchargez le RFC 4893


L'article seul

RFC 4892: Requirements for a Mechanism Identifying a Name Server Instance

Date de publication du RFC : Juin 2007
Auteur(s) du RFC : S. Woolf (ISC), D. Conrad (ICANN)
Pour information
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 22 juin 2007


Autrefois, tout était plus simple, les serveurs de noms DNS étaient simplement identifiables par leur adresse IP et on savait donc toujours à quel serveur on s'adressait. Mais un certain nombre d'innovations techniques assez récentes comme l'anycast ont rendu le débogage plus difficile. D'où l'importance d'un nouveau mécanisme pour trouver à quel serveur on parle.

A priori, si je pose une question à 192.93.0.4, une et une seule machine peut répondre à la question posée, non ? Eh bien non, en raison de l'anycast (voir le RFC 4786) et des répartiteurs de charge. Plusieurs machines peuvent désormais se « cacher » derrière une même adresse. Normalement, on ne s'en aperçoit même pas mais, s'il y a un problème, par exemple si elles se désynchronisent, il est nécessaire de pouvoir déterminer à quelle machine physique on parle.

La méthode traditionnelle, popularisée par le logiciel BIND était d'utiliser une requête de la classe CH (pour CHAOS), classe inutilisée et donc disponible. Essayons sur f.root-servers.net, qui est anycasté :


% dig @f.root-servers.net CH TXT hostname.bind   
...
;; ANSWER SECTION:
hostname.bind.          0       CH      TXT     "cdg1b.f.root-servers.org"

On voit qu'on est tombé sur l'instance parisienne de cette machine (l'ISC identifiant ses machines par le code à trois lettres de l'aéroport international le plus proche, ici Roissy / CDG).

Mais cette méthode, qui n'avait jamais été normalisée ou documentée a ses limites, que décrit notre RFC :

  • Elle est spécifique, y compris dans son nom, à BIND (mais son concurrent NSD la met également en œuvre, vous pouvez tester avec k.root-servers.net, également anycasté et utilisant NSD).
  • Et, surtout, elle nécessite une requête séparée, qui n'arrivera pas forcément au même serveur de noms que la requête originale (le routage ayant pu changer pendant ce temps).

Notre RFC pose donc le cahier des charges pour un remplaçant. Celui-ci devra :

  • Garder une excellente propriété de la solution actuelle, le fait qu'elle fonctionne sur le DNS et ne nécessite donc pas d'ouvrir un nouveau port dans le coupe-feu ou d'installer un logiciel supplémentaire,
  • Mais faire en sorte que l'identification du serveur passe désormais dans la même session.

Un projet existe déjà pour ce nouveau système, utilisant EDNS (RFC 6891). Adopté par l'IESG, il n'est pas encore publié en RFC.


Téléchargez le RFC 4892


L'article seul

RFC 4886: Network Mobility Support Goals and Requirements

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : T. Ernst (INRIA)
Pour information
Première rédaction de cet article le 21 juillet 2007


Voici le cahier des charges du groupe de travail IETF NEMO qui vise à normaliser les techniques permettant la mobilité d'un réseau entier, pas seulement d'une machine.

La mobilité est un domaine riche et complexe et il est préférable de lire d'abord les RFC de terminologie comme le RFC 3753 et RFC 4885. Les principaux termes utilisés dans notre RFC sont MR (Mobile Router) pour le routeur du réseau mobile, MNN (Mobile Network Nodes) pour les machines ordinaires du réseau mobile et CN (Correspondent Node) pour la machine (par exemple, un serveur Web) avec laquelle le MNN veut communiquer.

La section 2 décrit les scénarios d'usage, du cadre survolté moderne bardé de gadgets électroniques, comme un soldat US en Irak, et qui est un réseau mobile à lui tout seul, tous ses gadgets communiquant entre eux par Bluetooth, à un groupe d'étudiants qui travaillent sur leurs ordinateurs portables dans le train et qui ont besoin de connectivité entre eux aussi bien qu'avec l'Internet.

La section 3 du RFC expose ensuite les buts de NEMO : permettre aux MNN d'ignorer qu'ils sont mobiles, ne pas charger la table de routage globale en vain (section 3.12), permettre de protéger la vie privée des MNN (le CN ne doit pas savoir où se trouve son client), etc.

Le groupe de travail NEMO a bien avancé. Ce RFC de cahier des charges est publié deux ans (!) après la première spécification, le RFC 3963 et en même temps que plusieurs autres normes comme les RFC 4887 et RFC 4889.

J'ai commencé cet article dans un avion et je note que NEMO n'est pas encore déployé partout, nous n'avions pas de connectivité Internet (même si des essais ont été tentés).


Téléchargez le RFC 4886


L'article seul

RFC 4884: Extended ICMP to Support Multi-Part Messages

Date de publication du RFC : Avril 2007
Auteur(s) du RFC : R. Bonica (Juniper), D. Gan, D. Tappan, C. Pignataro (Cisco)
Chemin des normes
Première rédaction de cet article le 16 juin 2007


Le protocole ICMP permet d'inclure une partie du datagramme qui a déclenché l'émission du paquet ICMP. Avec ce RFC, cette partie est désormais dotée d'une structure, permettant son analyse et sa transformation.

ICMP (RFC 792) sert à beaucoup de choses mais une de ses utilisations les plus connues est l'émission d'un paquet ICMP par un routeur lorsqu'un datagramme ne peut pas être transmis par ce routeur, par exemple lorsqu'il n'existe pas de route vers la destination ou bien lorsque le nombre maximal de routeurs à franchir a été dépassé (cette dernière fonction est à la base de traceroute).

Pour aider à l'analyse du paquet ICMP (quel datagramme a déclenché le problème ? à qui était-il destiné ? que contenait-il ?), ICMP prévoit depuis la début la possibilité d'inclure le début du datagramme « fautif » dans le paquet ICMP. Mais ce bout de datagramme n'avait pas de structure précise, même pas d'indication de sa longueur, et son analyse était donc parfois délicate.

Notre RFC introduit donc un nouveau concept, le message ICMP en plusieurs parties, un peu comme ce que MIME avait fait pour le courrier électronique. Certains messages ICMP peuvent donc désormais contenir plusieurs objets, chaque objet ayant un en-tête et contenant des données structurées.

Comme souvent dans l'Internet, la compatibilité avec la version précédente du protocole était le principal problème. Que va faire une application moderne qui traite l'ICMP si un vieux routeur lui envoie des paquets ICMP de l'ancienne norme ? Et dans le cas inverse ? Notre RFC consacre donc une longue section 5 à ce problème et en conclut que peu d'inconvénients devraient être visibles.

Ces types d'objets sont enregistrés dans un registre IANA, https://www.iana.org/assignments/icmp-parameters. Le premier RFC à utiliser cette extension est le RFC 4950 sur MPLS, le second a été le RFC 5837 sur les informations d'interface, mais plusieurs autres RFC en préparation créent de tels objets.


Téléchargez le RFC 4884


L'article seul

RFC 4882: IP Address Location Privacy and Mobile IPv6: Problem Statement

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : R. Koodli (Nokia Siemens)
Pour information
Première rédaction de cet article le 29 juin 2007


La protection de la vie privée sur Internet suscite de plus en plus d'intérêt à l'IETF, d'autant plus que certaines techniques comme la mobilité peuvent aggraver la diffusion d'informations confidentielles. Notre RFC explique le problème.

Lorsqu'une machine A correspond avec une machine B, celle-ci apprend l'adresse IP de A, c'est inévitable. B apprend aussi beaucoup d'autres choses (par exemple via les cookies Web) qui, mises ensemble, peuvent représenter une sérieuse menace pour la vie privée. Dès qu'on cherche un peu, on est étonné du nombre de moyens qu'il existe pour détecter des choses que le correspondant voulait cacher. Par exemple, l'analyse du temps de réponse du correspondant peut donner une idée de la distance, et donc permettre de savoir quand un portable a quitté son « port d'attache ».

En effet, dans le cas de la mobilité IP, de nouvelles vulnérabilités apparaissent. La mobilité « traditionnelle » où la machine en déplacement (on parle de MN pour Mobile Node) acquiert une nouvelle adresse IP à chaque réseau visité, typiquement par DHCP, avait déjà ses propres dangers. Si le correspondant du MN, le CN (Corresponding Node), peut découvrir un invariant du MN (par exemple un cookie Web envoyé ou, de manière plus sophistiquée, une signature du comportement de l'horloge de la machine, le CN peut littéralement suivre à la trace le MN et déterminer sa position approximative, comme si votre téléphone GSM révélait à vos correspondants votre position !

La mobilité IPv6, décrite dans le RFC 3775, a deux modes de fonctionnement, le mode « normal » (reverse tunneling) où tout le trafic passe par un routeur sur le réseau principal du MN (et où le CN ne voit donc pas l'actuelle adresse IP du MN, la « care-of address ») et un mode « optimisé » où le passage par le routeur « de la maison » (Home Agent) n'est plus obligatoire et qui retrouve donc le même inconvénient qu'avec DHCP pur. Chacun de ses deux modes a ses propres défauts pour la protection de la vie privée et notre RFC les détaille. La section 4 est particulièrement vivante dans son exposé des risques qui guettent le malheureux utilisateur d'un PC portable.

Notre RFC ne propose pas de solution, il explique les problèmes à résoudre et donne une idée des compromis qu'il faudra sans doute faire.


Téléchargez le RFC 4882


L'article seul

RFC 4880: OpenPGP Message Format

Date de publication du RFC : Novembre 2007
Auteur(s) du RFC : J. Callas (PGP Corporation), L. Donnerhacke (IKS), H. Finney (PGP Corporation), D. Shaw, R. Thayer
Chemin des normes
Première rédaction de cet article le 22 novembre 2007


Le logiciel PGP est synonyme de cryptographie pour beaucoup de gens. Un des plus anciens et des plus utilisés pour les fonctions de confidentialité mais aussi d'authentification, PGP est très célèbre mais on sait peu que ses messages sont normalisés, dans ce RFC.

PGP a vu son format de données normalisé pour la première fois en août 1996, dans le RFC 1991. Cette norme a été révisée par la suite, dans le RFC 2440 et notre RFC est la dernière version.

Cette normalisation permet à diverses mises en œuvre de PGP d'interopérer. La plus connue aujourd'hui est la seule libre, GNU Privacy Guard (qui n'existait pas encore au moment de la publication du premier RFC). Il ne faut donc plus confondre le logiciel PGP, écrit à l'origine par Phil Zimmermann, et qui est non-libre, avec le format PGP que décrit notre RFC et que des logiciels autres que PGP peuvent lire ét écrire.

Le principe du chiffrement avec PGP est simple. Une clé de session (le terme est impropre puisqu'il n'y a pas de session au sens de TLS mais c'est celui utilisé par le RFC) est créée pour chaque destinataire, elle sert à chiffrer le message et cette clé est chiffrée avec la clé publique du destinataire (section 2.1 du RFC).

Pour l'authentification, c'est aussi simple conceptuellement. Le message est résumé et le résumé est chiffré avec la clé privée de l'émetteur (section 2.2 du RFC).

Le format PGP permet également la compression (qui améliore la sécurité en supprimant les redondances) et l'encodage en Base64 (RFC 4648), baptisé ASCII armor, pour passer à travers des logiciels qui n'aiment pas le binaire (la section 6 détaille cet encodage).

La section 3 explique les éléments de base utilisés par le format PGP. L'un des plus importants est le concept d'entier de grande précision (MPI pour Multi-Precision Integers), qui permet de représenter des entiers de très grande taille, indispensables à la cryptographie, sous forme d'un doublet longueur + valeur.

Enfin les sections 4 et 5 expliquent le format lui-même. Un message PGP est constitué de paquets (rien à voir avec les paquets réseau). Chaque paquet a un type, une longueur et un contenu. Par exemple, un paquet de type 1 est une clé de session chiffrée, un paquet de type 2 une signature, un paquet de type 9 du contenu chiffré, etc.

La section 7 du RFC décrit un type de message un peu particulier, qui n'obéit pas à la syntaxe ci-dessus, les messages en clair mais signés. Ces messages ont l'avantage de pouvoir être lus sans avoir de logiciel PGP. Ils nécessitent donc des règles spéciales.

On notera que gpg permet d'afficher les paquets présents dans un message PGP, ce qui est pratique pour l'apprentissage ou le débogage. Voyons un exemple avec un fichier test.txt de 35 octets, signé mais non chiffré :

% gpg --list-packets test.gpg 
:compressed packet: algo=1
:onepass_sig packet: keyid 4136479797D6D246
        version 3, sigclass 00, digest 2, pubkey 17, last=1
:literal data packet:
        mode b (62), created 1191502517, name="test.txt",
        raw data: 35 bytes
:signature packet: algo 17, keyid 4136479797D6D246
        version 3, created 1191502517, md5len 5, sigclass 00
        digest algo 2, begin of digest 0d e4
        data: [159 bits]
        data: [158 bits]

Malheuresement, gpg n'affiche pas les valeurs numériques des types, telles que listées par le RFC. Mais les noms qu'il utilise sont les mêmes que dans le RFC, on peut donc facilement trouver la section qui explique ce qu'est un "onepass_sig packet".

Avec un message chiffré, on obtient :

% gpg --list-packets test.txt.gpg
:pubkey enc packet: version 3, algo 16, keyid F3A0253D6C2A95F9
        data: [1022 bits]
        data: [1023 bits]
:pubkey enc packet: version 3, algo 16, keyid C0FE90B0F08F74D7
        data: [2044 bits]
        data: [2048 bits]

You need a passphrase to unlock the secret key for
user: "Stephane Bortzmeyer (Personl address) <stephane@bortzmeyer.org>"
2048-bit ELG-E key, ID F08F74D7, created 2000-03-31 (main key ID 97D6D246)

:encrypted data packet:
        length: 102
        mdc_method: 2
gpg: encrypted with 1024-bit ELG-E key, ID 6C2A95F9, created 2005-02-18
      "Kim Minh Kaplan <kaplan@kim-minh.com>"
gpg: encrypted with 2048-bit ELG-E key, ID F08F74D7, created 2000-03-31
      "Stephane Bortzmeyer (Personl address) <stephane@bortzmeyer.org>"
:compressed packet: algo=2
:literal data packet:
        mode b (62), created 1191502765, name="test.txt",
        raw data: 35 bytes

On notera que c'est après l'affichage des premiers paquets que gpg demande la phrase de passe pour lire la clé privée. En effet, les premiers paquets ne sont pas chiffrés, puisqu'ils indiquent la clé à utiliser pour déchiffrer le reste (PGP a une option pour masquer ces paquets, cf. section 5.1).

Malheureusement, notre RFC n'indique pas clairement les changements par rapport à la version précédente, le RFC 2440. Mais les changements ne sont pas radicaux, la version reste la même. Les principaux ajouts sont les suivants :

  • Le précédent RFC contenait une note de l'IESG expliquant qu'il n'y avait pas de mécanisme d'extension, par exemple pour ajouter de nouveaux types ou sous-types de paquets. Ce n'est plus le cas et la section 10 détaille comment demander à l'IANA d'ajouter de nouveaux paramètres.
  • Il y a moins de support des vieilles versions de PGP (l'obligation de les accepter est passée de MUST à SHOULD, cf. RFC 2119.)
  • Il y a de nouveaux types de paquet comme le paquet User Attributes, plus riche que le paquet User ID, avec notamment la possibilité d'ajouter des images.
  • Un nouveau format de compression est ajouté, bzip2.
  • La section 14 (analyse de sécurité) est bien plus détaillée, avec description des attaques possibles.
  • Parmi les nouvelles options, les signatures peuvent désormais être marquées comme confirmées par un tiers de confiance, via les Third-Party Confirmation signature.

Téléchargez le RFC 4880


L'article seul

RFC 4871: DomainKeys Identified Mail (DKIM) Signatures

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : E. Allman (Sendmail), J. Callas (PGP Corporation), M. Delany (Yahoo), M. Libbey (Yahoo), J. Fenton (Cisco), M. Thomas (Cisco)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dkim
Première rédaction de cet article le 24 mai 2007


Le courrier électronique, on le sait, n'offre, en natif, aucun mécanisme d'authentification des utilisateurs. Il est donc assez facile d'envoyer un courrier prétendant venir de Bill.Gates@microsoft.com. DKIM, spécifié à l'origine dans notre RFC, est la dernière tentative de combler ce manque. Ce RFC a ensuite été remplacé par le RFC 6376.

Notons d'abord que, si le courrier électronique, tel que décrit dans les RFC 5321 ou RFC 5322, ou bien leurs prédécesseurs, n'offre pas d'authentification des utilisateurs, ce n'est pas parce que leurs concepteurs étaient imprévoyants ou trop confiants dans la nature humaine. C'est tout simplement parce que le problème est très complexe, ne serait-ce que parce qu'il n'existe pas de fournisseur d'identité unique sur Internet, qui pourrait jouer le rôle que joue l'État avec les papiers d'identité.

Mais l'absence d'authentification devient de plus en plus regrettable, d'autant plus qu'elle est activement exploitée par les spammeurs et les phisheurs pour leurs entreprises malhonnêtes. Non seulement il est difficile de retrouver le véritable envoyeur d'un message, mais une personne tout à fait innocente peut voir son identité usurpée. Ces problèmes de sécurité sont documentés dans le RFC 4686.

De nombreuses tentatives ont eu lieu pour tenter de traiter ce problème. Certaines ont connu un déploiement non négligeable comme PGP (normalisé dans le RFC 4880), surtout connu pour ses services de chiffrement mais qui peut aussi servir à l'authentification.

PGP est surtout utilisé dans des environnements à forte composante technique, au sein de groupes d'experts qui se connaissent. D'autres protocoles ont tenté de traiter le problème de l'authentification de la masse d'utilisateurs de Hotmail ou de Wanadoo.

SPF (normalisé dans le RFC 4408) a été condamné par l'hostilité de la plupart des gros acteurs.

DKIM, successeur de DomainKeys de Yahoo, après sa fusion avec l'IIM de Cisco, vient d'atteindre le statut de norme à l'IETF après de nombreux rebondissements. Comme SPF, il vise surtout à authentifier le domaine dans l'adresse électronique, en d'autres termes à garantir que le courrier vient bien de microsoft.com, laissant à Microsoft le soin de dire si la partie gauche (Bill.Gates) est authentique ou pas.

Mais, contrairement à SPF, il ne procède pas par énumération des adresses IP des MTA autorisés à émettre du courrier pour le compte d'un domaine mais par signature cryptographique.

Le principe de DKIM est le suivant (les exemples sont tirés de l'excellente annexe A du RFC). Un message émis ressemble à :

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

DKIM (qui peut être installé dans le MUA mais sera en général plutôt dans le MSA) le signe et ajoute un en-tête DKIM-Signature :

   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
         c=simple/simple; q=dns/txt; i=joe@football.example.com;
         h=Received : From : To : Subject : Date : Message-ID;
         bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
         b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
           4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
           KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
           4bmp/YzhwvcubU4=;
   Received: from client1.football.example.com  [192.0.2.1]
         by submitserver.example.com with SUBMISSION;
         Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

L'en-tête en question spécifie l'algorithme de chiffrement utilisé (ici SHA-256 et RSA), le domaine signant (ici example.com), un sélecteur (ici brisbane) qui servira à sélectionner la bonne clé, les en-têtes effectivement signés (ici Received : From : To : Subject : Date : Message-ID), la signature elle-même et l'identité de l'émetteur (ici joe@football.example.com). (La différence entre le domaine, identifié par d= et l'« identité » indiquée par i= est subtile et a dû faire l'objet d'une mise à jour, dans le RFC 5672, mise à jour qui a depuis été intégrée dans la nouvelle norme DKIM, le RFC 6376.)

L'identité est indiquée dans la signature pour éviter les longs débats sur l'identité la plus pertinente parmi toutes celles présentes dans un message (cf. le RFC 4407 pour un des exemples d'algorithme qui croit naïvement qu'il existe une et une seule bonne identité). Notre RFC note que le MUA doit en tenir compte et doit afficher l'adresse qui est authentifiée, pas seulement celle qui se trouve dans le champ From et qui peut être différente.

Le programme qui veut vérifier la signature (en général un MTA mais cela peut être le MUA) va devoir récupérer la clé de signature. DKIM ne souhaitant pas dépendre des lourdes et chères autorités de certification, la clé est récupérée via le DNS (d'autres méthodes sont en cours de normalisation). Pour le message ci-dessus, la requête DNS sera brisbane._domainkey.example.com et un enregistrement DNS de type TXT contiendra la clé. Pour voir une clé réelle, vous pouvez taper dig TXT beta._domainkey.gmail.com..

Un des problèmes difficiles en cryptographie est que les messages sont souvent modifiés en cours de route. Par exemple, un logiciel imposé par le direction de l'entreprise va ajouter automatiquement un stupide message pseudo-légal comme « Ce message e-mail et les pièces jointes sont transmis à l'intention exclusive de ses destinataires et sont confidentiels et/ou soumis au secret professionnel. Si vous recevez ce message par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur par téléphone ou par mail. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation. L'intégrité de ce message n'étant pas assurée sur Internet, nous ne pouvons être tenu responsables de son contenu. » (notons que le dernier point devient faux avec DKIM). Ou bien une liste de diffusion va mettre des instructions de désabonnement. DKIM traite ces problèmes avec deux méthodes : une canonicalisation (section 3.4 du RFC) du message (plusieurs algorithmes sont disponibles) pour limiter les risques qu'une modification triviale ne fausse le calcul de la signature et l'option l= qui permet d'indiquer sur quelle distance le message est signé. Si on indique l=1000, seuls les mille premiers octets seront signés et une liste pourra ajouter un message automatiquement à la fin, cela n'invalidera pas la signature.

Malheureusement, DKIM encourage également (section 5.3) à remplacer les caractères codés sur 8 bits (comme l'UTF-8 ou le Latin-1) par des horreurs comme le Quoted-Printable, pour limiter les risques qu'une conversion automatique en Quoted-Printable, comme le font certains MTA, n'invalide la signature. Des années d'efforts pour faire passer les caractères 8-bits dans le courrier sont ainsi négligés.

Parmi les limites de DKIM (qui sont celles de beaucoup de solutions de sécurité, un domaine complexe où il faut faire beaucoup de compromis), il faut aussi se rappeler qu'un attaquant actif peut tout simplement retirer complètement une signature. Tant que les domaines ne publient pas leur politique de sécurité (en suivant le RFC 5617) et donc annoncent « Nous signons toujours », cette attaque passera inaperçue.

Aujourd'hui, tous les messages sortant de Gmail sont signés avec DKIM et des implémentations de DKIM existent pour plusieurs logiciels (comme le DKIM milter de sendmail). Mais peu de domaines vérifient les signatures.

Enfin, notons que DKIM est une technologie d'authentification, pas d'autorisation. Cette distinction est cruciale. DKIM peut prouver que le message vient bien de Nicolas.Sarkozy@elysee.fr, il ne peut pas dire si la personne en question est digne de confiance ou si elle va réellement se préoccuper de « la France qui se lève tôt ».


Téléchargez le RFC 4871


L'article seul

RFC 4865: SMTP Submission Service Extension for Future Message Release

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : G. White, G. Vaudreuil (Alcatel-Lucent)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF lemonade
Première rédaction de cet article le 1 juin 2007


Depuis que le protocole de transport de courrier SMTP permet des extensions annoncées par le serveur (voir le RFC 2821), beaucoup de telles extensions, plus ou moins utiles, ont été normalisées. Celle-ci permet à un client SMTP d'indiquer qu'il veut retarder la délivrance d'un message jusqu'à un moment qu'il indique.

Il est fréquent qu'on souhaite voir un message délivré plus tard : parce qu'il est lié à un évenement futur (anniversaire, par exemple) ou bien parce qu'on souhaite avoir un rappel d'une tâche à assurer. Il est trivial de programmer cela sur sa machine (par exemple, sur Unix, avec at). Mais certains machines n'ont pas forcément les ressources nécessaires et préféreraient confier cette tâche au serveur de messagerie. C'est ce que normalise notre RFC. Le travail a été mené au sein du groupe Lemonade de l'IETF, qui normalise les extensions groupware à SMTP.

On peut donc, si le serveur l'accepte, lui demander de délivrer le message à une date précise, ou bien au bout d'une durée précise (les deux choix existent car certains clients SMTP n'ont pas forcément d'horloge fiable et complète).

La section Sécurité de notre RFC vaut le détour, notamment à propos des risques qu'un client malveillant n'utilise le serveur comme espace de stockage gratuit, ou bien à expliquer pourquoi on ne peut pas complètement dissimuler la vraie date d'envoi (et donc pas faire croire qu'on a pensé à l'anniversaire juste au jour J).

À l'heure actuelle, à ma connaissance, aucun logiciel SMTP ne met en œuvre cette extension.


Téléchargez le RFC 4865


L'article seul

RFC 4862: IPv6 Stateless Address Autoconfiguration

Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : S. Thomson (Cisco), T. Narten (IBM), T. Jinmei (Toshiba)
Chemin des normes
Première rédaction de cet article le 20 octobre 2007


Ce RFC met à jour un protocole qui a souvent été présenté comme un des gros avantages d'IPv6, la possibilité d'acquérir une adresse globale par autoconfiguration.

Le principe de SLAAC (StateLess Address AutoConfiguration) est simple : la machine IPv6 écoute sur le réseau et détecte les RA (Router Advertisement) envoyés par le routeur (notre RFC ne s'applique en effet qu'aux machines « terminales », pas aux routeurs). Ces RA l'informent de la valeur du préfixe réseau utilisé. La machine concatène ce préfixe à un identificateur d'interface, obtenant ainsi une adresse (section 5 du RFC, notamment 5.5).

L'identificateur d'interface est décrit dans le RFC 4291, qui indique comment les fabriquer à partir d'éléments comme les adresses MAC. (Notez que la méthode recommandée est désormais de ne plus utiliser l'adresse MAC, cf. RFC 8064.)

Voici, vu par tcpdump, un de ces RA :

17:49:23.935654 IP6 fe80::20c:6eff:fe6e:e5d4 > ff02::1: ICMP6, router advertisement, length 56

Si le préfixe annoncé est 2001:660:f108::/64 et que le RA est reçu par la machine dont l'identificateur d'interface est 20c:6eff:fe6e:e73a, l'adresse IPv6 fabriquée sera 2001:660:f108:0:20c:6eff:fe6e:e73a.

Si IPv4 a désormais une possibilité analogue grâce au RFC 3927, IPv6 garde un gros avantage, la notion de préfixe publié, qui fait que ces adresses autoconfigurées sont globales, elles peuvent être utilisées sur tout l'Internet.

Cette méthode d'autoconfiguration, dite sans état, est concurrente de DHCP (RFC 8415).

Notons qu'on n'est pas obligé d'attendre le Router Advertisement du routeur, on peut le solliciter avec un Router Solicitation.

La section 5.4 de notre RFC décrit la procédure DAD (Duplicate Address Detection), qui permet de s'assurer que l'adresse obtenue est bien unique en envoyant un Neighbor Solicitation (RFC 4861).

Toujours vue avec tcpdump, voici toute la procédure, envoi d'un RS, réception du RA et DAD :

18:13:32.046584 IP6 fe80::20c:6eff:fe6e:e73a > ff02::2: ICMP6, router solicitation, length 16
18:13:32.046861 IP6 fe80::20c:6eff:fe6e:e5d4 > ff02::1: ICMP6, router advertisement, length 56
18:13:32.578592 IP6 :: > ff02::1:ff6e:e73a: ICMP6, neighbor solicitation, who has 2001:660:f108:0:20c:6eff:fe6e:e73a, length 24

tcpdump n'affiche pas tous les détails, il ne montre pas le préfixe, ni la durée du bail (l'annonce RA est valable pour un certain bail, de durée limitée).

Parmi les limites du protocole, la section 6 du RFC note qu'il n'offre aucune sécurité. Une machine peut envoyer des faux RA, peut répondre aux DAD qui ne sont pas pour elle, etc.

Notre RFC remplace le RFC 2462. Il s'agit de changements mineurs, qui ne devraient pas toucher l'interopérabilité (mais qui peuvent affecter les implémentations, comme l'obligation d'un délai aléatoire avant de tester la duplication d'adresse).


Téléchargez le RFC 4862


L'article seul

RFC 4861: Neighbor Discovery for IP version 6

Date de publication du RFC : Septembre 2007
Auteur(s) du RFC : T. Narten (IBM), E. Nordmark (Sun Microsystems), W. Simpson (Daydreamer), H. Soliman (Elevate Technologies)
Chemin des normes
Première rédaction de cet article le 25 septembre 2007
Dernière mise à jour le 24 novembre 2008


Voici une nouvelle version du protocole ND (Neighbor Discovery) qui permet à une machine IPv6 de trouver l'adresse MAC d'une autre machine qui se trouve sur le même réseau local.

Lorsqu'une machine veut écrire à une autre machine située sur le même lien et qu'elle ne connait que son adresse IP, son adresse de couche 3, comment fait-elle pour avoir l'adresse MAC, l'adresse de couche 2 qu'il faut mettre, par exemple, dans l'en-tête de la trame Ethernet ?

IPv4 utilisait ARP, spécifié dans le RFC 826. Ce protocole avait plusieurs limites, notamment le fait qu'il n'utilisait pas IP, requérant des machines qu'elles mettent donc en œuvre un autre protocole. IPv6 a donc un mécanisme assez différent, ND, qui fonctionne au dessus d'ICMP v6 et donc d'IP.

ND permet aux machines de trouver les routeurs, aux routeurs de s'annoncer, et aux machines de trouver leurs voisines. Voici quelques paquets vus avec tcpdump -n ip6. D'abord, un routeur se signale en écrivant à l'adresse multicast ff02::1:, « toutes les machines » :

15:20:02.032894 fe80::201:96ff:fe96:dc60 > ff02::1: icmp6: router advertisement           [class 0xe0]

(Cette fonction de ND n'était pas en IPv4 gérée par ARP mais par Router Discovery, RFC 1256.) Maintenant, on a le même routeur qui cherche à joindre 2001:660:3003:3::1:3 et qui diffuse donc une demande de voisin (neighbor solicitation) :

15:19:37.981830 fe80::201:96ff:fe96:dc60 > ff02::1:ff01:3: icmp6: neighbor solicitation:  who has 2001:660:3003:3::1:3 [class 0xe0]

Ici, la machine n'avait jamais répondu. Ici, un cas où la machine sollicitée, 2001:660:3003:3::1:1, répond :

15:30:44.416346 fe80::211:43ff:fee7:bcde > 2001:660:3003:3::1: icmp6: neighbor sol: who has 2001:660:3003:3::1
15:30:44.417438 2001:660:3003:3::1 > fe80::211:43ff:fee7:bcde: icmp6: neighbor adv: tgt is 2001:660:3003:3::1 [class 0xe0]

On note que le solliciteur écrit toujours depuis son adresse « lien local » (link-local).

Naturellement, les résultats d'une découverte du voisin sont gardés dans un cache, qu'on peut afficher. Sur Linux :

% ip neigh show                         
fe80::210:dbff:feb8:e5ed dev eth0 lladdr 00:10:db:b8:e5:ed router REACHABLE
2001:660:3003:3::1 dev eth0 lladdr 00:10:db:b8:e5:ed router REACHABLE
fe80::219:b9ff:fee4:2987 dev eth0 lladdr 00:19:b9:e4:29:87 router REACHABLE

Sur FreeBSD :

% ndp -na
Neighbor                             Linklayer Address  Netif Expire    S Flags
2001:470:1f15:121:223:12ff:fe56:b34d 0:23:12:56:b3:4d    sis1 20h24m25s S
...

La section 6.2.1 du RFC précise qu'un routeur doit fournir un moyen de configurer les paramètres qui sont utilisés dans la découverte de voisin qu'il effectue et dans les annonces du RFC 4862. Avec le logiciel radvd, cela se fait dans /etc/radvd.conf qui peut ressembler à (radvd utilise pour ses options exactement les noms suggérés par le RFC) :

...
   prefix 2001:DB8:49::/64
   { 
     AdvOnLink on; 
     AdvPreferredLifetime 1800;

Et on voit alors avec un tcpdump -vvv le paramètre « durée de vie » (ltime pour life time) :

18:25:59.264392 fe80::204:75ff:fece:efbe > ff02::1: icmp6: router advertisement(chlim=64, pref=medium, router_ltime=1800, reachable_time=0, retrans_time=0)[ndp opt] (len 64, hlim 255)

Peu de changements par rapport au RFC 2461 et ils portent essentiellement sur la sécurité. L'ancien RFC ne la mentionnait guère, sauf pour expliquer que le protocole était peu sûr (les risques sont détaillés dans les RFC 3756 et RFC 6104). Désormais, la section Sécurité est plus détaillée et cite des solutions possibles comme le protocole SEND, spécifié dans le RFC 3971. Depuis, une autre est apparue, les gardes, dans le RFC 6105.


Téléchargez le RFC 4861


L'article seul

RFC 4848: Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)

Date de publication du RFC : Avril 2007
Auteur(s) du RFC : L. Daigle (Cisco)
Chemin des normes
Première rédaction de cet article le 2 mai 2007


Les RFC 3401 et RFC 3403 décrivent un mécanisme riche et compliqué, le DDDS pour trouver les URI de services à partir de noms cherchés dans le DNS. Ce RFC spécifie une application de DDDS.

DDDS, reposant sur les compliqués enregistrements NAPTR (normalisés dans le RFC 3403), n'a pas été un grand succès. Il y a quand même eu plusieurs applications normalisées comme les S-NAPTR, du RFC 3958. Notre RFC étend légèrement les possibilités des S-NAPTR en créant les U-NAPTR.

Les enregistrements S-NAPTR ne permettaient pas d'utiliser les expressions rationnelles alors que les U-NAPTR de notre RFC les autorisent.

Par exemple, pour trouver un serveur LDAP, le S-NAPTR pouvait ressembler à :

  IN NAPTR 100   20   "s"   "WP:ldap"         ( ; service
                             ""                  ; regexp
                            _ldap._tcp.myldap.example.com. ; replacement
                                               )

alors qu'un U-NAPTR peut utiliser en plus l'option "u" (expressions rationnelles), par exemple :

   IN NAPTR 200   10   "u"    "EM:protA"        ( ; service
                             "!.*!prota://someisp.example.com!" ; regexp
                             ""                  ; replacement
                                               )

Le DNS peut donc ainsi servir de véritable annuaire, pas juste de table de correspondance entre noms et adresses.


Téléchargez le RFC 4848


L'article seul

RFC 4846: Independent Submissions to the RFC Editor

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : J. Klensin, D. Thaler
Pour information
Première rédaction de cet article le 25 juillet 2007


Ce RFC décrit la voie "indépendante" pour soumettre un RFC au RFC editor sans passer par l'IETF.

On l'oublie souvent mais tous les RFC n'ont pas été développés à l'IETF. Certains ont emprunté la "voie indépendante" qui fait l'objet de notre RFC. Compagnon du RFC 4844, ce RFC décrit cette voie.

A l'origine, tous les RFC étaient de tels "indépendants" puisque les RFC existaient bien avant l'IETF. Aujourd'hui que les normes techniques de l'Internet sont dévelopées à l'IETF et publiés comme RFC après leur approbation par l'IESG, la voie indépendante sert pour :

  • Documenter des protocoles privés,
  • Proposer des protocoles alternatifs à ceux approuvés par l'IETF,
  • Publier des normes qui n'ont pas réussi sur la voie normale e à qui la voie indépendante offre un rattrapage.

Ces futurs RFC sont donc soumis directement au RFC editor. Si celui-ci vérifie avec l'IESG la possibilité d'un conflit avec une norme IETF (section 5 du RFC), le RFC editor n'en est pas moins le seul décideur pour leur publication ou non. (Depuis la parution de ce RFC, un nouvel acteur a été ajouté, l'ISE - Independent Submission Editor, cf. RFC 8730 - et d'autres changements ont eu lieu, par exemple dans le RFC 8726.)


Téléchargez le RFC 4846


L'article seul

RFC 4844: The RFC Series and RFC Editor

Date de publication du RFC : Juillet 2007
Auteur(s) du RFC : L. Daigle (for the Internet Architecture Board)
Pour information
Première rédaction de cet article le 24 juillet 2007


Les RFC, qui incluent notamment les normes techniques de l'Internet, sont en général réalisés par l'IETF mais sont publiés par un organisme séparé, le RFC editor dont le rôle n'avait pas encore été mis par écrit, ce que fait notre RFC, qui a depuis été remplacé par le RFC 8729.

Comme pour beaucoup de choses dans l'Internet, la définition exacte des rôles des différents acteurs n'avait pas été formalisée car personne n'en ressentait le besoin. Au fur et à mesure que l'Internet devient une infrastructure essentielle, cette absence de formalisation est mal ressentie et la tendance, depuis plusieurs années, est de mettre par écrit tout ce qui était implicite auparavant.

C'est le cas du rôle du RFC editor. Autrefois le titre d'une seule personne, Jon Postel, ce nom désigne désormais une petite structure, choisie et financée par l'ISOC, hébergée à l'ISI, qui assure le travail d'éditeur. Relire les RFC avant publication, leur donner un numéro et assurer leur distribution, tels sont les principaux rôles du RFC editor.

Notre RFC décrit en détail le rôle de cet éditeur, sa place dans le processus de publication et les fonctions qu'il doit assurer (le cahier des charges de l'IETF avait été publié dans le RFC 4714).

Il faut noter (section 5 du RFC) que le RFC editor reçoit des textes candidats par plusieurs voies. Si la plus connue est celle de l'IETF, il peut aussi publier des RFC d'autres origines notamment ceux ici des soumissions indépendantes (RFC 4846).

Le RFC editor a une mission difficile puisqu'il doit agir avec prudence, voire avec conservatisme, pour assurer la qualité et la disponibilité des RFC pendant de très longues périodes.

Il remplit cette mission sans faire d'excès de zèle. Ce n'est pas chez le RFC editor qu'il faudrait chercher les derniers gadgets comme un flux de syndication. Les erreurs signalées mettent fort longtemps à être publiées, les RFC ne sont pas signés (malgré la section 6 du RFC qui demande que des mesures soient prises pour assurer l'intégrité des documents), et le manque de poids politique du RFC editor fait qu'il n'a jamais été possible d'adopter un autre format de publication que le texte brut...


Téléchargez le RFC 4844


L'article seul

RFC 4843: An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)

Date de publication du RFC : Avril 2007
Auteur(s) du RFC : P. Nikander (Ericsson), J. Laganier (DoCoMo), F. Dupont (CELAR)
Chemin des normes
Première rédaction de cet article le 23 juin 2007


Une nouvelle pierre dans la construction d'une éventuelle future architecture Internet séparant identificateur et localisateur, depuis remplacée par le RFC 7343.

Les ORCHID sont des identificateurs dont la forme est celle d'une adresse IPv6 (afin de pouvoir être utilisés dans les API qui attendent des adresses IP). Ils sont typiquement utilisés dans le cadre de protocoles comme HIP (RFC 9063). Pour les distinguer, notre RFC réservait le préfixe 2001:10::/28 (rendu depuis, suite au RFC 7343). Si vous voyez une telle « adresse IP », ne vous attendez pas à pouvoir la « pinguer », elle n'a pas vocation à être routable, c'est un pur identificateur.

Comme les adresses CGA (RFC 3972), les ORCHID sont signées cryptographiquement, la section 2 de notre RFC détaillant le mécanisme de construction d'une ORCHID.


Téléchargez le RFC 4843


L'article seul

RFC 4838: Delay-Tolerant Networking Architecture

Date de publication du RFC : Avril 2007
Auteur(s) du RFC : V. Cerf (Google / JPL), S. Burleigh (JPL), A. Hooke (JPL), L. Torgerson (JPL), R. Durst (MITRE), K. Scott (MITRE), K. Fall (Intel), H. Weiss (Sparta)
Pour information
Première rédaction de cet article le 13 avril 2007


Tous les RFC ne spécifient pas une norme pour l'Internet existant. Certains sont plus futuristes et, par exemple, voici la description d'une architecture de réseau qui pourrait convenir, entre autres, aux communications interplanétaires.

Si ce thème spectaculaire garantit évidemment un gros intérêt médiatique pour ces travaux, si la NASA a activement participé à ceux-ci, il faut noter que le titre de notre RFC est plus général : « Une architecture pour les réseaux à forte latence ». En effet, plusieurs types de réseaux, pas seulement ceux utilisés par les sondes interplanétaires ont des caractéristiques similaires :

  • Très forte latence, parfois de plusieurs heures pour les communications avec les planètes lointaines ; c'est la principale caractéristique de ces réseaux,
  • Nœuds du réseau souvent injoignables (cas des satellites en orbite basse, qui ne sont visibles que pendant une partie de leur orbite),
  • Variété des protocoles sous-jacents.

Par exemple, un réseau de machines au sol éloignées les unes des autres, connectées par radio est souvent dans une situation similaire : les liaisons y sont intermittentes.

Les protocoles utilisés sur Internet comme TCP ne sont pas adaptés à de tels réseaux. Par exemple, TCP nécessite trois voyages pour simplement ouvrir une connexion, avant même que l'échange de données commence. Sur un réseau à forte latence, TCP serait inutilisable, l'essentiel du temps écoulé serait passé à attendre les données. D'autre part, TCP, comme les autres protocoles de l'Internet, est bâti autour de l'idée que la liaison est la règle et l'absence de liaison l'exception. Notre RFC prend le parti opposé.

Il existe donc depuis de nombreuses années un programme de recherche à l'IRTF, au sein du Delay-Tolerant Networking Research Group, programme qui a produit beaucoup de documents. Citons notamment le bon tutoriel Delay-Tolerant Networks (DTNs): a tutorial.

Notre RFC, issu des travaux de ce groupe, spécifie donc une architecture de réseau qui n'a rien à voir avec l'Internet. Les protocoles IP et TCP ne sont pas conservés. La nouvelle architecture ressemble plutôt (et c'est mentionné dans le RFC) à celle de la Poste ou, pour prendre un exemple plus informatique, à celle d'UUCP. Chaque nœud du réseau a une capacité de stockage local (pour faire face à l'intermittence des liaisons) et transmet des colis (bundles) de données au nœud suivant. L'architecture prévoit, comme avec la vraie Poste, différentes classes de service, des accusés de réception, etc. (Voir à ce sujet l'interview de Vint Cerf, « To Boldly Go Where No Internet Protocol Has Gone Before ».)

L'adressage se fait avec des EID (Endpoint Identifier) qui sont tout simplement des URI.

Le premier RFC spécifiant le détail de cette architecture a été le RFC 5050 (depuis dépassé par le RFC 9171). Puis sont venus les RFC sur le protocole de transport LTP, décrit dans le RFC 5325 et normalisé dans le RFC 5326.


Téléchargez le RFC 4838


L'article seul

RFC 4825: The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)

Date de publication du RFC : Mai 2007
Auteur(s) du RFC : J. Rosenberg (Cisco)
Chemin des normes
Première rédaction de cet article le 7 juin 2007


Les logiciels clients ont souvent besoin d'accéder à de l'information de configuration, qui est typiquement stockée en local. Ce protocole permet de la mettre sur un serveur distant.

Imaginons un client SIP qui veut connaitre les préférences de son utilisateur humain (par exemple les heures où il peut sonner). Traditionnellement, au démarrage, ledit client lit un fichier local (sur Unix, ce serait un fichier ~/.lelogicielrc ou équivalent). L'inconvénient de cette méthode est que l'humain ne peut pas facilement travailler sur plusieurs machines, sauf à prendre des précautions particulières pour s'assurer que les fichiers de configuration soient identiques partout.

Des protocoles ont donc été développés pour permettre l'accès à distance à la configuration, permettant ainsi sa centralisation sur un serveur. Le plus connu de ces protocoles est ACAP (décrit dans le RFC 2244), qui n'a jamais été un grand succès.

Notre RFC représente donc une nouvelle tentative, utilisant XML cette fois, et avec un nom qui rend hommage à ACAP.

XCAP permet de distribuer de l'information spécifiée dans un schéma XML. Le RFC utilise des exemples tirés du RFC 3857, qui normalise un moyen pour des utilisateurs SIP de surveiller une ressource. Mais bien d'autres schémas seront possibles.

L'accès à une partie de la configuration se fait avec un langage qui est un sous-ensemble de XPath.

Notre protocole est bâti sur HTTP. XCAP permet davantage que l'accès à la configuration, il autorise aussi la mise à jour de celle-ci, en suivant l'architecture REST (GET pour lire la configuration, DELETE pour supprimer une ressource, etc). C'est donc aussi un protocole d'avitaillement (provisioning).


Téléchargez le RFC 4825


L'article seul

RFC 4821: Packetization Layer Path MTU Discovery

Date de publication du RFC : Mars 2007
Auteur(s) du RFC : M. Mathis, J. Heffner (PSC)
Chemin des normes
Première rédaction de cet article le 4 mai 2007


La détermination de la MTU disponible entre deux nœuds de l'Internet n'a jamais été facile. Ce RFC propose un nouveau protocole pour cette tâche. (Il a depuis été modifié et étendu par le RFC 8899.)

Entre deux machines quelconques connectées à l'Internet, par exemple un serveur HTTP www.example.org et son client, il est très souhaitable de pouvoir déterminer la MTU maximum du chemin qui les relie (Path MTU). En IPv6, c'est indispensable, les routeurs intermédiaires n'ayant pas le droit de fragmenter les paquets mais c'est également recommandé en IPv4, la fragmentation faisant chuter les performances (l'excellente page http://www.psc.edu/~mathis/MTU/ décrit en détail pourquoi il serait bon d'augmenter les MTU).

La méthode standard est décrite dans le RFC 1191 (et RFC 1981 pour IPv6) et est connue sous le nom de Path MTU discovery. Elle consiste à envoyer des paquets avec le bit DF (Don't Fragment) mis et à attendre les messages ICMP Packet Too Big (le vrai nom de ce message, spécifié dans le RFC 792 est fragmentation needed and DF set). Mise en œuvre depuis longtemps dans tous les systèmes, elle peut se tester avec certaines versions de traceroute qui disposent de l'option -M :

% traceroute-nanog -M 192.0.2.42
traceroute to 192.0.2.42, 64 hops max
MTU=1500
...
MTU=1492

On voit le passage de la MTU de départ du client (les 1500 octets d'Ethernet) à celle du chemin complet, limité à 1492 octets, probablement par une encapsulation PPPoE. (On peut aussi utiliser un tel outil depuis le Web en http://www.ncne.org/jumbogram/mtu_discovery.php.)

Mais cette méthode a un défaut : il faut que les paquets ICMP arrivent. Or, beaucoup de sites filtrent stupidement tout ICMP sur leur coupe-feu et, en pratique, cette méthode n'est donc pas fiable (le RFC 2923 détaille pourquoi).

Notre RFC propose donc une alternative, ne dépendant pas de la réception des paquets ICMP et fonctionnant donc en présence de « trous noirs » qui absorbent tous ces paquets ICMP. Il suggère tout simplement de tenir compte des paquets perdus, en supposant que si seuls les plus gros se perdent, c'est probablement qu'ils étaient plus gros que la MTU. La nouvelle méthode est donc d'essayer des paquets de différentes tailles et de surveiller les pertes. Les détails de l'implémentation dépendent du protocole utilisé. La nouvelle méthode se nomme PLPMTUD (Packetization Layer Path MTU Discovery).

Les protocoles comme TCP surveillant déjà les pertes de paquets, la modification nécessaire serait donc raisonnable (section 10.1). Notre RFC décrit aussi comment réaliser cette recherche de MTU pour d'autres protocoles comme SCTP ou même au niveau applicatif (section 10.4).

Notre RFC détaille aussi les pièges possibles. Par exemple, si certains équipements réseaux ont un comportement non-reproductible (la section 4 cite le cas de répéteurs Ethernet qui ne refusent pas les paquets trop gros mais n'arrivent pas non plus à les transmettre de manière fiable, leur horloge n'étant pas stable sur une période suffisamment longue), ce protocole ne peut pas fonctionner.

Voilà, mais rappelez-vous que la procédure décrite ici a depuis été mise à jour dans le RFC 8899 notamment pour les autres protocoles que TCP.


Téléchargez le RFC 4821


L'article seul

RFC 4819: Secure Shell Public Key Subsystem

Date de publication du RFC : Mars 2007
Auteur(s) du RFC : J. Galbraith, J. Van Dyke, J. Bright
Chemin des normes
Première rédaction de cet article le 30 mars 2007


Le protocole SSH, jadis spécifié uniquement dans une implémentation, est désormais une norme IETF (RFC 4251 et RFC 4253). Cette norme permet l'ajout d'extensions, les subsystems. Notre RFC ajout donc un subsystem pour la transmission de clés d'un client à un serveur.

Traditionnellement, avec un programme comme OpenSSH, le client qui voulait être authentifié via sa clé publique, copiait celle-ci sur le serveur puis l'insérait dans ~/.ssh/authorized_keys. Désormais, une fois notre RFC mis en œuvre, il pourra utiliser SSH pour le faire, simplifiant le processus et limitant les risques de fausses manœuvres.

Le client SSH pourra donc désormais ajouter des clés, les lister, les modifier, de manière standard. Notre RFC prévoit aussi les autorisations liées aux clés (comme « cette clé ne doit pas être utilisée pour faire du forwarding X11 »), autorisations qui se faisaient avec OpenSSH en ajoutant des mots-clés au début des clés.


Téléchargez le RFC 4819


L'article seul

RFC 4818: RADIUS Delegated-IPv6-Prefix Attribute

Date de publication du RFC : Avril 2007
Auteur(s) du RFC : J. Salowey, R. Droms
Chemin des normes
Première rédaction de cet article le 3 février 2008


Une des grandes forces du protocole Radius est la possibilité d'ajouter de nouveaux attributs, par exemple pour spécifier des paramètres supplémentaires à une session. C'est ainsi que ce RFC normalise l'attribut qui permet de déléguer un préfixe IPv6 entier, pas une seule adresse.

Avec IPv4, l'utilisateur typique n'a qu'une adresse IP en tout et pour tout et l'attribut traditionnel de Radius (RFC 2865), Framed-IP-address, suffit largement. Mais avec IPv6, comme recommandé dans le RFC 6177, l'utilisateur, même simple particulier, peut avoir un préfixe (de longueur 48, disait le RFC 3177, même si tous les FAI n'en donnent pas autant, entre 48 et 64 pour le RFC 6177). Lorsqu'un utilisateur se connecte au NAS, il faut donc trouver un moyen pour le serveur Radius qu'interroge ce NAS de transmettre le préfixe et sa longueur.

Rien d'extraordinaire et ce RFC est très court : il définit (section 3) l'attribut Delegated-IPv6-Prefix qui contient le préfixe et sa longueur. Cet attribut apparait typiquement dans les réponses mais il peut aussi être présent dans la question, pour indiquer une préférence de l'utilisateur. Une fois reçu par le NAS, il peut être transmis à l'utilisateur, par exemple en DHCP (RFC 3633) puis être ensuite être diffusé sur le réseau local dudit utilisateur, par exemple avec les annonces RA du RFC 4862.

On note que cet attribut peut aussi être utilisé pour le concurrent de Radius, Diameter (RFC 6733), la section 5 expliquant comment.


Téléchargez le RFC 4818


L'article seul

RFC 4814: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking

Date de publication du RFC : Mars 2007
Auteur(s) du RFC : D. Newman (Network Test), T. Player (Spirent Communications)
Pour information
Réalisé dans le cadre du groupe de travail IETF bmwg
Première rédaction de cet article le 4 avril 2007


Un très intéressant RFC pour les amateurs de benchmarks. Il indique deux points faibles courants dans ces tests de performance réseau.

On le sait, les benchmarks sont très difficiles à faire proprement (et la plupart des résultats publiés le sont dans un but commercial, donc l'auteur n'essaie même pas d'être honnête). Il est donc utile que ce RFC avertisse les réalisateurs de tests de performances de réseaux.

Plusieurs RFC ont déjà été écrits sur les tests de performance, comme les RFC 2544 et RFC 2889. Ils sont l'œuvre du Benchmarking Methodology Working Group.

Le premier problème est le fait que le traitement d'un paquet dépend souvent du résultat d'une fonction de hachage et que celle-ci dépend du contenu du paquet. Si les paquets du tests ne sont pas suffisamment variés, les collisions dans la fonction de hachage affecteront le résultat.

Par exemple, notre RFC cite le cas d'un commutateur Ethernet qui comprend huit network processors (les processeurs spécialisés qui vont traiter les paquets entrants) et où l'affectation d'un paquet entrant à un network processor donné est fait par un hachage des adresses MAC de source et de destination. Si le jeu de test génère des adresses trop semblables, la collision des résultats de la fonction de hachage fait qu'un seul processeur sera utilisé, et qu'on sous-estimera le débit du commutateur. Et le même phénomène peut se reproduire à d'autres couches, comme la couche réseau ou la couche transport.

Notre RFC recommande donc de générer des paquets le plus aléatoires possibles.

Le deuxième problème est le fait que certains protocoles comme PPP doivent échapper certains motifs de bits qui pourraient être pris comme caractères de contrôle. Cet échappement rajoute des bits aux données, « faussant » ainsi les calculs de débit.

On notera que c'est pour cela qu'echoping, par défaut, envoie des données aléatoires (et dispose de l'option -f si on désire remplir avec des données fixes).

Il n'est pas évident de calculer en temps réel la taille effective des paquets et notre RFC recommande donc une approche probabiliste, le calcul de la probabilité qu'un échappement soit inséré, approche permettant d'arriver à des résultats presque exacts.


Téléchargez le RFC 4814


L'article seul

RFC 4810: Long-Term Archive Service Requirements

Date de publication du RFC : Mars 2007
Auteur(s) du RFC : C. Wallace (Cignacom), U. Pordesch (Fraunhofer), InterComponentWare
Pour information
Réalisé dans le cadre du groupe de travail IETF ltans
Première rédaction de cet article le 30 mars 2007


L'archivage de données à long terme est un enjeu essentiel et qui soulève d'innombrables difficultés techniques et sociales. Ce RFC fait le point sur le cahier des charges d'une solution IETF.

C'est une banalité, mais une banalité tristement vraie, que de dire que notre époque ne laissera que peu de traces. Si je veux écrire un livre sur la diplomatie française au XVIIIème siècle (je recommande la lecture du « Secret du Roi » de Gilles Perrault), j'ai à ma disposition une impressionnante quantité d'archives, chacun des protagonistes de l'époque écrivait abondemment et ce qu'il écrivaient est toujours lisible aujourd'hui. Au XXIème siècle, ils envoient des emails en Word et, dans cinquante ans, on aura perdu les sauvegardes, on ne pourra plus lire les clés USB ou les DVD et, de toute façon, Word sera oublié depuis longtemps.

Bref, un service d'archivage à long terme nécessite plus que des graveurs de DVD. Il nécessite une organisation sociale solide (cf. la BNF en France, BNF qui d'ailleurs travaille sur le dépôt légal du Web). Et il nécessite un certain nombre de services techniques.

Notre (court) RFC ne décrit pas en détail les solutions techniques (on peut consulter un article du CINES à ce sujet) mais les exigences du service.

Celui-ci devra donc permettre de gérer des autorisations (de dépôt et d'accès), de spécifier des métadonnées associées à chaque objet numérique archivé, de prouver (par exemple grâce à la cryprographie) que les objets n'ont pas été modifiés, etc.

Les considérations de sécurité sont particulièrement détaillées : car les données archivées peuvent être sensibles et nécessiter, en plus de l'intégrité, de la confidentialité.

Parmi les articles déjà publiés sur le sujet (comme celui du CINES cité plus haut), Nicolas Krebs recommande Archiver le web, il devient temps d’y penser qui résume bien le problème.


Téléchargez le RFC 4810


L'article seul

RFC 4795: Link-local Multicast Name Resolution (LLMNR)

Date de publication du RFC : Janvier 2007
Auteur(s) du RFC : Bernard Aboba, Dave Thaler, Levon Esibov (Microsoft)
Pour information
Réalisé dans le cadre du groupe de travail IETF dnsext
Première rédaction de cet article le 25 janvier 2007


Ce RFC aura connu un parcours exceptionnellement long et difficile. Il normalise un protocole permettant à deux machines du même réseau local de se trouver par leur nom, sans nécessiter de serveur.

Ce problème est connu sous le nom de « bureau du dentiste ». Il concerne les réseaux « non gérés », c'est-à-dire où il n'y a pas d'informaticien pour administrer un serveur, distribuer des adresses, etc. Ce problème était bien résolu par le protocole NBP d'AppleTalk mais pas encore par les protocoles de la famille TCP/IP. Pour allouer les adresses, nous avions le RFC 3927 (qui a un auteur en commun avec notre RFC) en IPv4 et l'autoconfiguration des adresses link-local (Stateless Address Autoconfiguration, RFC 4862) qui fait partie d'IPv6 depuis le début. Mais pour les noms ?

La seule solution normalisée, le DNS nécessite un ensemble de serveurs de noms, administrés par des professionnels. Cela ne convient pas au petit réseau local du particulier, de l'association ou de la PME. C'est ce créneau qu'occupe LLMNR.

LLMNR fonctionne donc par diffusion (restreinte au réseau local) des requêtes. Une machine qui veut contacter copain.example.org va donc envoyer à tout le réseau local (à 224.0.0.252, en IPv4) une requête LLMNR. Celle-ci utilise le même format de paquet que le DNS mais un protocole très différent. En effet, il n'y a pas de serveur dédié : chaque « requêrant » LLMNR est en même temps « répondant ». Lorsqu'une machine qui a été configurée pour le nom copain.example.org se reconnait, elle répond à la requête.

LLMNR a connu une histoire longue et compliquée (rappelons que le protocole NBP d'Apple faisait la même chose que LLMNR il y a quinze ans). L'Internet-Draft a connu pas moins de 47 versions, un record absolu à l'IETF. Parmi les raisons de ce retard, les divergences avec le projet mDNS d'Apple, part de leur technologie Bonjour (finalement normalisé dans le RFC 6762). Le débat, puisque Apple avait déjà déployé Bonjour, a porté sur un problème de fond : l'IETF doit-elle simplement mettre un coup de tampon sur les protocoles élaborés dans des cercles fermés, au nom du déploiement effectif ? Ou bien doit-elle avoir un réel travail technique, au risque que la norme ouverte ne soit pas intéropérable avec ce qu'a développé l'entreprise privée ?

C'est cette polémique, parfois virulente, qui a fini par coûter sa place sur le chemin des normes à LLMNR. Et qui l'a relégué au rang de « Pour information ».

Nous avons donc désormais deux protocoles différents (pas la même adresse multicast, pas le même nommage, mDNS utilisant le TLD .local, etc).


Téléchargez le RFC 4795


L'article seul

RFC 4790: Internet Application Protocol Collation Registry

Date de publication du RFC : Mars 2007
Auteur(s) du RFC : C. Newman (Sun), M. Duerst (AGU), A. Gulbrandsen (Oryx)
Chemin des normes
Première rédaction de cet article le 15 mars 2007


Dans la désormais longue série des RFC qui parlent d'internationalisation de l'Internet, voici un RFC décrivant un cadre dans lequel doivent s'inscrire les protocoles qui doivent chercher un identificateur parmi d'autres, ou bien trier des identificateurs. Le problème était trivial en ASCII mais la prise en compte de jeux de caractères plus étendus change la donne.

De nombreux protocoles Internet doivent manipuler des identificateurs (c'est le cas, par exemple, de Sieve ou de NAI). Ils doivent tester si deux identificateurs sont identiques (par exemple, un serveur IMAP doit, lorsqu'il reçoit la commande LOGIN stéphane monmotdepasse déterminer si c'est le même utilisateur que le STEPHANE qu'il a dans sa base). Ou bien ils doivent trier ces identificateurs (tiens, je n'ai pas trouvé de bon exemple, ici).

Avec le seul jeu de caractères US-ASCII, spécifier de tels tests était trivial. Il suffisait de dire si la comparaison était sensible à la casse ou pas. Avec les jeux de caractères modernes, adaptés à un Internet mondial, comme Unicode, tout est bien différent. Est-ce que stéphane est égal à stephane ? Et à STÉPHANE ? Chaque protocole va devoir répondre à cette question et chacun, jusqu'à présent, le faisait dans son coin.

C'est ce que veut changer notre RFC : désormais, tout protocole qui veut faire de la comparaison ou du tri de chaînes de caractères devra spécifier l'algorithme utilisé, en utilisant un format unique et en enregistrant cet algorithme dans le tout nouveau registre IANA. Notre RFC le peuple déjà avec quelques algorithmes simples comme i;ascii-casemap qui effectue une comparaison insensible à la casse, en n'utilisant que les caractères ASCII. L'espoir est que la plupart des algorithmes seront réutilisés, réduisant ainsi la charge de travail pour les programmeurs qui mettent en œuvre les RFC.


Téléchargez le RFC 4790


L'article seul

RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP

Date de publication du RFC : Janvier 2007
Auteur(s) du RFC : F. Audet (Nortel), C. Jennings (Cisco)
Réalisé dans le cadre du groupe de travail IETF behave
Première rédaction de cet article le 16 février 2007


En raison, notamment, de la pénurie d'adresses IPv4, de nombreux réseaux utilisent le NAT. Cette technique est très pénalisante et notre RFC essaie de limiter les dégâts en notant le comportement minimal d'une mise en œuvre de NAT qui ne perturbe pas trop les applications.

Si les applications TCP traditionnelles, comme le Web ou SSH passent en général bien à travers le NAT, en sortie, ce n'est pas le cas des applications multimédia comme SIP (RFC 3261) ou bien liées aux jeux en ligne. Celles-ci dépendent souvent d'UDP et ne passent pas à travers beaucoup de systèmes NAT. Plusieurs techniques ont été mises au point pour traverser ces systèmes proprement mais elles ne marchent pas toujours car il n'y a pas un seul type de NAT mais plusieurs. (Sur ces différents types, voir le RFC 2663, la terminologie du RFC 3489 n'ayant pas été retenue.)

Notre RFC, issu du travail du groupe de travail BEHAVE, définit donc les comportements suivants, que doit respecter le système NAT :

  • Indépendance par rapport à la destination : la table de correspondance entre un port et un couple (adresse IP, port) ne doit dépendre que de la source,
  • Si le système NAT a plusieurs adresses IP de sortie à sa disposition, il doit utiliser la même pour toute requête provenant d'une adresse IP interne donnée,
  • Le système NAT ne doit pas réutiliser un port pour une communication différente,
  • Plus surprenant, un système NAT doit préserver la parité du port (si une requête d'une machine interne vient d'un port pair, elle doit sortir avec un port source pair, certaines applications en dépendent),
  • Le système NAT doit être déterministe, c'est-à-dire que ses choix doivent être répétables (il ne doit donc pas choisir un port au hasard, par exemple),
  • Le système NAT doit permettre le fonctionnement en épingle à cheveux (hairpinning) où deux machines situées du même côté du routeur tentent de communiquer. Beaucoup de routeurs NAT ne permettent pas cette communication (section 6).
  • Et plusieurs autres obligations ou recommendations, toutes étant résumées dans la section 12, celle que tout implémenteur d'un système NAT devrait lire, s'il ne lit rien d'autre du RFC.

Un très bon article pour faire le point sur les techniques permettant de contourner le NAT est Peer-to-Peer Communication Across Network Address Translators.

Notez que ce RFC a été légèrement mis à jour sur certains points par le RFC 7857.


Téléchargez le RFC 4787


L'article seul

RFC 4786: Operation of Anycast Services

Date de publication du RFC : Décembre 2006
Auteur(s) du RFC : J. Abley (Afilias), K. Lindqvist (Netnod)
Première rédaction de cet article le 26 décembre 2006
Dernière mise à jour le 28 décembre 2006


L'anycast : un terme complètement inconnu il y a trois ans, qui est maintenant très souvent prononcé. Cette technique de distribution de serveurs a largement fait ses preuves et est maintenu reconnu comme « bonne pratique ».

Notons que le terme d'anycast est officiellement traduit (Journal Officiel de la République Française, 28 décembre 2006, Commissions générale de terminologie et de néologie, « Vocabulaire des télécommunications ») par « envoi à la cantonade ».

Le premier RFC a avoir parlé de l'anycast est le RFC 1546, il y a plus de dix ans. Mais la technique n'a vraiment décollé qu'à partir de la grande attaque d'octobre 2002 qui a mis en évidence la vulnérabilité des indispensables serveurs de la racine du DNS. Quelques mois après, les premiers serveurs racine anycastés voyaient le jour, nouvel hommage à la réactivité de l'Internet. La première documentation moderne était l'excellente note technique de l'ISC : Hierarchical Anycast for Global Service Distribution de Joe Abley, un des auteurs de notre RFC. Ce succès (l'attaque d'octobre 2002 ne s'est jamais reproduite) est largement dû aux efforts de l'ISC.

Le but principal de l'anycast est donc la sécurité, notamment la résistance aux attaques DoS. Cette résistance accrue est due au plus grand nombre de serveurs qui peut être déployé, grâce à l'anycast, et à la concentration des attaques dans un lieu proche des attaquants, ce qui permet de les détecter plus facilement.

En quoi consiste l'anycast ? Le principe est de disposer plusieurs serveurs, tous aptes à rendre le même service, et de permettre au client de choisir automatiquement le « meilleur ». Contrairement à la technique des miroirs, l'anycast se fait sans intervention du client. Contrairement aux systèmes de répartition de charge, la requête du client ne passe par aucune machine qui déciderait du serveur choisi. Le service de loin le plus anycasté est le DNS et la méthode la plus courante repose sur le protocole de routage BGP : le même préfixe (par exemple 192.5.5.0/24 pour F.root-servers.net) est annoncé par les routeurs de chaque site où se trouve une instance de F.root-servers.net. Le traditionnel algorithme de sélection des routes par BGP choisira l'instance anycast qui servira la requête. En général, les dites instances sont situées sur des points d'échange et l'instance anycast sert les opérateurs connectés à ce point.

Notre RFC n'explique pas comment on construit un service anycast (on trouve des informations utiles dans A Software Approach to Distributing Requests for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD ou bien sur le serveur du projet AS112). Il explique les bonnes pratiques, pour être sûr que les avantages de l'anycast l'emportent sur ses inconvénients.

Notre RFC commence donc par étudier les protocoles qui bénéficient le plus de l'anycast : le DNS, étant typiquement sans état (chaque requête est indépendante des autres) est le plus adapté et ce n'est pas un hasard s'il est le plus anycasté aujourd'hui. Les protocoles où les sessions peuvent être longues (SSH, par exemple) sont difficiles à anycaster : un changement des tables de routage et les paquets arrivent à une autre instance, qui ne sait pas comment reprendre la session.

Ensuite, le RFC examine des questions comme le placement des nœuds (instances) anycast.

Un gros morceau commence ensuite, dans les sections 4.3 et 4.4 : le routage. L'anycast peut fonctionner avec un protocole de routage externe comme BGP mais aussi avec un protocole de routage interne comme OSPF. Dans les deux cas, il faut coupler étroitement le routeur et le serveur, de façon à ce qu'un arrêt du serveur, entraine l'arrêt de l'annonce de la route. Le RFC détaille ensuite le cas de certains mécanismes comme PPLB ou comme RPF (décrit dans le RFC 3704) qui, dans certains cas très rares sur Internet, peuvent interférer avec l'anycast.

Le RFC détaille ensuite, notamment dans sa section 5, des considérations plus pratiques d'administration système : surveillance d'un service anycast (il faut surveiller chaque instance individuellement), débogage (anycast est conçu pour que les instances soient indistinguables par les clients, ce qui peut compliquer la recherche sur un problème), etc.

La sécurité étant une des principales motivations de l'anycast, on ne s'étonnera pas que le RFC se termine par une longue section sur ce sujet, qui insiste entre autres sur les risques nouveaux liés à l'anycast ; par exemple, une annonce BGP pirate (RFC 4272) sera moins facilement détectée qu'avec un service traditionnel.

Notons pour terminer que le site Web http://www.root-servers.org/ présente une liste des serveurs racines actuellement anycastés et la localisation de leurs instances.


Téléchargez le RFC 4786


L'article seul

RFC 4778: Operational Security Current Practices

Date de publication du RFC : Janvier 2007
Auteur(s) du RFC : M. Kaeo (Double Shot Security)
Pour information
Première rédaction de cet article le 8 juin 2007


La sécurité est désormais omniprésente sur Internet et d'innombrables RFC en parlent. Celui-ci liste les pratiques de sécurité actuellement mises en œuvre par les opérateurs réseau et les FAI.

C'est donc plutôt un reportage qu'un RFC normatif. Après avoir revu les menaces existant sur les réseaux, et les différents types d'attaque, notre RFC cite les contre-mesures adoptées. Pour chaque grande fonction, le RFC explique les attaques possibles sur cette fonction et les contre-mesures spécifiques. Les fonctions sont :

  • La protection physique des équipements, placés dans des locaux fermés, à accès contrôlé. Même dans ces locaux, l'utilisation de mots de passe sur les équipements est systématique, souvent avec déconnexion automatique au bout de N minutes,
  • La gestion à distance des équipements, typiquement via SSH (plus une base d'authentification, par exemple avec Radius), SNMP n'étant en général utilisé qu'en lecture et HTTP semblant souvent neutralisé. La plupart des acteurs enregistrent toutes les actions ainsi effectuées.
  • L'acheminement des paquets IP (forwarding). Certains opérateurs, mais pas tous, mettent en œuvre les méthodes de filtrage décrites dans le RFC 2827 ou bien le RFC 3704. Le filtrage par adresse MAC est très rare.
  • Les protocoles de routage (routing). Ceux-ci peuvent faire l'objet d'attaques spécifiques (RFC 4593). L'authentification dite MD5 est largement utilisée, ainsi que le GTSM (RFC 3682). Diverses règles contrôlent le nombre maximum de préfixes envoyés par un pair, mais rares sont les opérateurs qui filtrent selon le contenu des IRR (Internet Routing Registry).
  • DoS. Ce phénomène, plaie de l'Internet, est une des plus grosses préoccupations des opérateurs. Parmi les contre-mesures, l'établissement de routes spéciales pour faire disparaitre le trafic non désiré dans un trou noir, routes souvent injectées dans BGP pour assurer leur transport rapide dans tout le réseau.

Téléchargez le RFC 4778


L'article seul

RFC 4766: Intrusion Detection Message Exchange Requirements

Date de publication du RFC : Mars 2007
Auteur(s) du RFC : M. Wood (Internet Security Systems), M. Erlinger (Harvey Mudd College)
Pour information
Réalisé dans le cadre du groupe de travail IETF idwg
Première rédaction de cet article le 18 mars 2007


L'Internet d'aujourd'hui est un coupe-gorge où les attaques sont de plus en plus fréquentes et de plus en plus complexes ? Raison de plus pour échanger de l'information entre ceux qui se chargent de défendre le réseau. Cela nécessitera un format standard d'échange, dont ce RFC dresse le cahier des charges.

Le groupe de travail IDWG de l'IETF était chargé de réaliser ce format d'échanges standard, qui devait permettre d'échanger sous une forme normalisée les informations sur les attaques ou les repérages trop appuyés (port scan, par exemple). Actuellement, les outils d'analyse comme les IDS et les programmes utilisés par les responsables de la sécurité ne communiquent qu'avec des formats non normalisés. C'est gênant et c'est encore plus gênant lorsqu'on veut communiquer cette information à d'autres entités (police, CERT, autres victimes) ou bien lorsqu'on veut l'archiver.

Outre le format des données, le groupe travaillait aussi sur un protocole d'échange de ces données et notre RFC couvre les deux.

D'où ce cahier des charges qui prévoit que le nouveau format :

  • Transmette des faits, pas des méthodes de détection,
  • Attribue à chaque évenement de sécurité un identificateur unique,
  • Puisse transporter des données de type non spécifié (car le RFC ne peut pas tout prévoir),
  • Indique la source et la destination de l'attaque,
  • Indique l'analyseur (typiquement un IDS) qui a fait le rapport,
  • Indique le degré de confiance que l'analyseur a dans sa propre analyse,
  • Indique évidemment l'heure,
  • Fournisse un mécanisme d'extension, pour indiquer des données structurées non prévues à l'origine.

Le protocole, quant à lui, doit fournir la confidentialité, l'intégrité des données transmises et leur authentification.

Le groupe de travail a malheureusement échoué et les deux RFC décrivant le protocole ont été publiés « en l'état », avec le simple statut d'« Expérimental ». Ce sont le RFC 4765 pour le format et le RFC 4767.


Téléchargez le RFC 4766


L'article seul

RFC 4765: The Intrusion Detection Message Exchange Format (IDMEF)

Date de publication du RFC : Mars 2007
Auteur(s) du RFC : H. Debar (France Telecom), D. Curry (Guardian), B. Feinstein (SecureWorks)
Expérimental
Réalisé dans le cadre du groupe de travail IETF idwg
Première rédaction de cet article le 18 mars 2007


Ce RFC décrit un format XML d'échanges de données concernant des incidents de sécurité. Il permet aux entités concernées par un incident de sécurité de s'échanger de l'information structurée, donc plus facilement analysable.

Le groupe de travail IDWG de l'IETF a eu une histoire longue et compliquée. Le travail sur ce RFC a commencé il y a longtemps et de curieux archaïsmes y apparaissent (comme l'utilisation de DTD pour décrire le schéma XML ou bien comme l'utilisation du protocole ident, spécifié dans le RFC 1413). Finalement, le groupe n'a pas pu conclure et a été dissous. Les documents déjà prêts ont été publiés, comme notre RFC, avec le statut « Expérimental ». Un autre effort a porté sur un autre format, IODEF, finalement publié dans le RFC 5070 (et depuis mis à jour dans le RFC 7970).

Le problème était de toute façon très difficile : il existe des tas de façons de modéliser un incident de sécurité et une grande hétérogénéité des concepts. Le groupe de travail s'est attelé à une tâche d'ampleur. Le résultat est une modélisation en UML (système peu utilisé à l'IETF) de tous les concepts, accompagné d'un schéma XML écrit en DTD (un autre schéma, non officiel, écrit en W3C XML Schema figure égalemen dans le RFC mais c'est celui en DTD qui fait foi).

Voici un exemple d'un incident décrit dans ce langage, une attaque teardrop menée par 192.0.2.50 le 9 septembre 2000 :


<idmef:IDMEF-Message xmlns:idmef="http://iana.org/idmef"
                        version="1.0">
     <idmef:Alert messageid="abc123456789">
       <idmef:Analyzer analyzerid="hq-dmz-analyzer01">
         <idmef:Node category="dns">
           <idmef:location>Headquarters DMZ Network</idmef:location>
           <idmef:name>analyzer01.example.com</idmef:name>
         </idmef:Node>
       </idmef:Analyzer>
       <idmef:CreateTime ntpstamp="0xbc723b45.0xef449129">
         2000-03-09T10:01:25.93464-05:00
       </idmef:CreateTime>
       <idmef:Source ident="a1b2c3d4">
         <idmef:Node ident="a1b2c3d4-001" category="dns">
           <idmef:name>badguy.example.net</idmef:name>
           <idmef:Address ident="a1b2c3d4-002"
                          category="ipv4-net-mask">
             <idmef:address>192.0.2.50</idmef:address>
             <idmef:netmask>255.255.255.255</idmef:netmask>
           </idmef:Address>
         </idmef:Node>
       </idmef:Source>
       <idmef:Target ident="d1c2b3a4">
         <idmef:Node ident="d1c2b3a4-001" category="dns">
           <idmef:Address category="ipv4-addr-hex">
             <idmef:address>0xde796f70</idmef:address>
           </idmef:Address>
         </idmef:Node>
       </idmef:Target>
       <idmef:Classification text="Teardrop detected">
         <idmef:Reference origin="bugtraqid">
           <idmef:name>124</idmef:name>
           <idmef:url>http://www.securityfocus.com/bid/124</idmef:url>
         </idmef:Reference>
       </idmef:Classification>
     </idmef:Alert>
</idmef:IDMEF-Message>

Notez l'utilisation systématique d'identificateurs (les attributs ident pour pouvoir référencer les objets de manière non ambigüe.


Téléchargez le RFC 4765


L'article seul

RFC 4760: Multiprotocol Extensions for BGP-4

Date de publication du RFC : Janvier 2007
Auteur(s) du RFC : T. Bates (Cisco), R. Chandra (Sonoa), D. Katz, Y. Rekhter (Juniper)
Chemin des normes
Première rédaction de cet article le 20 juin 2007
Dernière mise à jour le 15 septembre 2020


Le protocole BGP distribue aujourd'hui des centaines de milliers de routes dans tout l'Internet. Spécifié uniquement pour IPv4 à l'origine, BGP peut aussi servir à d'autres protocoles, comme IPv6.

BGP est le seul protocole de routage utilisé aujourd'hui sur l'Internet pour échanger des routes entre opérateurs. Ce protocole, normalisé dans le RFC 4271, n'était à l'origine prévu que pour IPv4. L'Internet d'aujourd'hui compte de plus en plus de routes IPv6 et il était donc nécessaire de pouvoir également les distribuer. Même chose pour les labels MPLS (RFC 3107). BGP est donc devenu multi-protocoles avec le RFC 2283 puis avec le RFC 2858, dont notre RFC est le successeur.

À spécifier, cela va vite et le RFC est très court. Deux nouveaux attributs BGP, MP_REACH_NLRI et MP_UNREACH_NLRI apparaissent donc pour porter des routes indépendamment du protocole. Chaque route est marqué avec le type d'adresse (AFI, pour Address Family Identifier) utilisé, par exemple 2 pour IPv6, et les adresses sont donc de longueur variable, dépendant du type. Un marqueur supplémentaire, SAFI (Subsequent Address Family Identifier), indique le type de routage considéré (par exemple unicast). Les valeurs possibles du SAFI sont dans un registre IANA.

Les changements par rapport au prédécesseur, le RFC 2858 ne sont que de détail, par exemple la suppression d'une option pour un routage combiné de l'unicast et du multicast, option qui n'a jamais été réellement déployée.


Téléchargez le RFC 4760


L'article seul

RFC 4745: Common Policy: A Document Format for Expressing Privacy Preferences

Date de publication du RFC : Février 2007
Auteur(s) du RFC : H. Schulzrinne (Columbia University), H. Tschofenig (Siemens), J. Morris (CDT), J. Cuellar (Siemens), J. Polk, J. Rosenberg (Cisco)
Chemin des normes
Première rédaction de cet article le 20 décembre 2007


Les protocoles modernes comme SIP (qui sert surtout pour la téléphonie sur Internet mais aussi pour la messagerie instantanée) permettent d'obtenir bien des informations sensibles comme la localisation exacte de l'interlocuteur. Celui-ci n'a pas forcément envie de tenir le reste du monde au courant de ses activités. Notre RFC s'attaque donc à ce problème en décrivant un format de document exprimant des préférences en matière de protection de la vie privée.

Par exemple, une extension de SIP (RFC 3856, voir aussi le RFC 2778) permet d'être informé de la présence ou de l'absence d'une personne donnée. Ce n'est pas une information qu'on donne forcément à tout le monde ! D'une manière générale, la diminution considérable de la vie privée, consécutive au rôle grandissant de l'informatique, inquiète, à juste titre, de plus en plus de gens.

S'il est nécessaire que certains usages soient tout simplement interdits, comme le fait, par exemple, la loi française informatique & Libertés, pour d'autres, on peut envisager de négocier et d'arbitrer entre l'intimité et le caractère pratique de la diffusion d'informations. À condition qu'on puisse choisir et que ces choix soient respectés. L'IETF ne peut pas garantir ce respect mais elle peut au moins définir un format pour que les choix soient transmis de manière non ambigüe et c'est ce que fait ce RFC.

Il est l'héritier d'autres formats dont le plus connu est le P3P du W3C, qui permet aux serveurs Web de signaler leurs pratiques en matière de respect de la vie privée. P3P n'a eu aucun succès, sans doute en partie car les sites Web qui ont l'habitude de déclarer leurs politiques en vingt pages d'anglais légal incompréhensible ne voulaient pas les traduire dans un langage simple et non ambigü. Le W3C continue son travail sur ces « langages de politique » via l'activité Pling.

Notre RFC définit donc un format assez général pour couvrir d'autres besoins que ceux de SIP. La définition du format commence avec la section 4, qui détaille les principes de base. Notamment, ce format ne permet d'exprimer que des permissions, pas des interdictions. Tout est interdit par défaut et l'auteur du document doit lister les permissions. En effet, comme le sait toute personne qui a rédigé des ACL pour un routeur, on se trompe facilement, dans le sens d'une trop grande sécurité ou au contraire dans celui d'un laxisme involontaire. (La même section explique qu'il vaut mieux forcer l'utilisateur à exprimer clairement ses autorisations plutôt que de le laisser croire à tort qu'il est protégé.) Si une règle autorise 192.168.1.0/24 à faire une certaine action et qu'une autre interdit cette action à 192.168.1.0/26, il n'est pas immédiatement évident de savoir si 192.168.1.62 est autorisé...

La solution radicale adoptée par notre RFC rend l'écriture des règles plus simple, et notamment indépendante de l'ordre dans lequel elles sont exprimées (un piège classique avec les ACL). Pour les mêmes raisons de simplicité, la section 5 explique pourquoi des fonctions intéressantes comme les expressions rationnelles ont été omises.

La section 7 est le gros morceau du RFC. Elle détaille les conditions qui décident si une règle s'applique ou pas. Pour l'instant (mais des extensions ultérieures pourraient changer cela), il y a trois conditions possibles. La première est l'identité, décrite en section 7.1. Elle fonctionne en comparant une identité stockée dans la règle avec celle obtenue de l'autre utilisateur (l'authentification de cette seconde identité n'est pas couverte dans le RFC). Ainsi, on pourra dire « si l'appelant est +33 1 38 30 83 46, alors ... ». Voici un exemple inspiré du RFC (l'élément <identity> correspond si au moins un des éléments <one> correspond) :


              <identity>
                   <one id="sip:alice@example.org"/>
                   <one id="tel:+1-212-555-1234" />
                   <one id="mailto:bob@example.net" />
               </identity>

Dans un autre exemple, on voit la possibilité d'autoriser tout le monde sauf quelques uns :


               <identity>
                   <many>
                       <except domain="example.com"/>
                       <except id="sip:alice@bad.example.net"/>
                       <except id="sip:bob@good.example.net"/>
                       <except id="tel:+1-212-555-1234" />
                       <except id="sip:alice@example.com"/>
                   </many>
               </identity>

Une autre condition possible est la sphère (section 7.3). Une sphère n'est pas une identité mais une situation dans laquelle on se trouve (par exemple « au travail », « en train de manger » ou « endormi »). Le RFC n'essaie pas de définir une ontologie de ces situations, chacun est libre du vocabulaire utilisé. Enfin, la troisième espère de condition, la validité permet d'ajouter des contraintes temporelles. Voici un exemple (lorsqu'il y a plusieurs conditions, elles doivent toutes être vraies pour que le total soit vrai) :


<conditions>
   <sphere value="work"/>
   <identity>
          <one id="sip:boss@example.com"/>
   </identity>
   <validity>
                   <from>1900-01-01T08:00:00+01:00</from>
                   <until>2010-12-31T18:00:00+01:00</until>
   </validity>
</condition>

Une fois qu'on dispose de conditions, on peut exprimer des actions, qui font l'objet de la section 8 et des transformations (section 9). Notre RFC ne définit aucune action, cela sera laissé à des RFC ultérieurs.

Enfin, la section 13 est consacrée au schéma formel du langage, écrit en W3C Schema. Les actions et les transformations, non décrites dans ce RFC, sont marquées comme extensibles en les dérivant de xsd:anyType.


Téléchargez le RFC 4745


L'article seul

RFC 4741: NETCONF Configuration Protocol

Date de publication du RFC : Décembre 2006
Auteur(s) du RFC : R. Enns, editor (Juniper)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF netconf
Première rédaction de cet article le 20 décembre 2006


Netconf est un protocole de configuration de matériel réseau (typiquement des routeurs ou des commutateurs). Ce RFC est le premier publié par le groupe de travail IETF sur Netconf. Il a depuis été remplacé par le RFC 6241.

Si on doit gérer un seul routeur, le faire à la main est raisonnable. Mais, si on doit en gérer des dizaines ou des centaines, cela devient impossible sans automatisation. Il existe depuis longtemps de nombreux outils pour gérer un grand nombre d'équipements réseaux, Rancid étant le plus connu. (L'excellent article de Joe Abley, Managing IP Networks with Free Software en donne un bon aperçu. Le RFC 3535 rend compte d'un atelier de l'IAB qui a discuté de ces questions en 2002.) Netconf vise à rendre l'écriture de ces outils plus simple.

Netconf spécifie donc un protocole de RPC permettant à un gérant (manager) de modifier la configuration de l'équipement (device) en lui envoyant du XML.

Le contenu exact de ce document XML n'est pas entièrement spécifié par Netconf car il dépend de l'équipement configuré (la section 1.1 de notre RFC explique ce point). Un langage de description des modèles, Yang (RFC 6020), existe pour décrire les possibilités.

Extrait du RFC, voici un exemple (hypothétique) où on fixe à 1500 octets la MTU de l'interface réseau eth0 :


    <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>eth0</name>
               <mtu>1500</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

Il est difficile de ne pas penser à l'acronyme NIH en lisant ce RFC. Netconf définit un protocole de RPC alors qu'il existe déjà SOAP et XML-RPC, Netconf définit en section 6, un mécanisme d'extraction de sous-arbres XML alors que XPath existe déjà...

Il existe plusieurs mises en œuvres de Netconf en logiciel libre, voir la liste en http://www.ops.ietf.org/netconf/. Parmi d'autres, les routeurs Juniper peuvent déjà être configurés avec Netconf.


Téléchargez le RFC 4741


L'article seul

RFC 4732: Internet Denial-of-Service Considerations

Date de publication du RFC : Décembre 2006
Auteur(s) du RFC : M. Handley (UCL), E. Rescorla (Network Resonance), IAB
Pour information
Première rédaction de cet article le 19 janvier 2007


Les attaques par déni de service (DoS) étant le fléau de l'Internet depuis plusieurs années, et un fléau dont l'ampleur croît chaque jour, il n'est pas étonnant que l'IAB aie voulu consacrer un RFC à une vision générale du problème.

Contrairement à d'autres, les attaques DoS ne visent pas à prendre le contrôle d'un système informatique, mais à l'empêcher de fonctionner. Les motivations peuvent être de pur vandalisme ou bien relever de l'extorsion criminelle (à la veille du Super Bowl, beaucoup de sites Web de paris en ligne ont reçu des messages du genre « Payez ou bien on vous DoS demain, pendant la journée qui est normalement celle du plus gros chiffre d'affaires. ») Ces attaques sont d'autant plus difficiles à contrer qu'elles utilisent désormais en général un botnet, un réseau de dizaines ou de centaines de milliers de machines Windows piratées et transformées en zombies, prêts à attaquer sur l'ordre de leur contrôleur.

La section 2 de notre commence par expliquer les différents types d'attaques DoS. Elles peuvent viser un logiciel mal programmé, tenter d'épuiser une ressource limitée (mémoire ou espace disque ou bien des structures de données de taille finie), elles peuvent viser les machines ou bien les liens qui les relient, elles peuvent viser un service essentiel comme le DNS dont l'arrêt bloquera presque tout le reste (songeons à la la grande attaque du 21 octobre 2002 contre les serveurs racine).

Les attaques DoS peuvent aussi être physiques, c'est-à-dire consister en atteintes matérielles contre le réseau. Elle peut aussi être légale, comme les courriers menaçants, misant sur l'ignorance en droit du destinataire, et qui commandent l'arrêt immédiat de tel ou tel service (lettres cease and desist en anglais).

Notre RFC rappelle à plusieurs reprises que les DoS utilisent souvent une solution anti-DoS. Par exemple, un serveur de courrier qui utilise une liste noire pour tenter de limiter l'avalanche de spam peut être victime d'une DoS si les serveurs de la liste noire, piratés, se mettent à renvoyer, pour chaque adresse IP, « C'est un spammeur ».

Certaines attaques DoS se font par force brute : l'attaquant dispose de ressources supérieures à sa victime et peut, par exemple, se permettre d'envoyer des paquets IP en quantité, sans égard pour sa propre bande passante. C'est évidemment une tactique efficace si on contrôle un botnet puisque les plus grosses machines, reliées au mieux connecté des réseaux, ne peuvent jamais aligner autant de ressources que les centaines de milliers de zombies du botnet.

Mais d'autres attaques DoS sont plus subtiles car elles exploitent l'amplification : c'est une propriété de certains protocoles que la réponse peut être bien plus grosse que la requête, permettant ainsi à l'attaquant d'économiser ses propres ressources. Ainsi, la réponse à une requête DNS peut être des dizaines de fois plus grosses que la requête, propriété exploitée dans les attaques via des récursifs ouverts.

La section 4 du RFC envisage les contre-mesures : elle se divise en conseils pour les auteurs de protocoles, pour les implémenteurs, et pour les opérateurs de réseau.

Les auteurs de protocole, et l'IESG y veille désormais, doivent veiller à ce que leur protocole ne permette pas l'amplification pour un client non authentifié et n'alloue pas de ressources pour de tels clients. Par exemple, les anciennes mises en œuvre de TCP allouaient une petite quantité de mémoire pour chaque demande de connexion, même non confirmée, ce qui permettait l'attaque dite SYN flooding. Les implémentations récentes permettent d'utiliser des petits gâteaux à la place. L'invention de ce mécanisme de SYN cookies n'a été possible qu'en trichant légèrement avec la définition du protocole TCP.

Ce mécanisme, ainsi que les autres défenses spécifiques à TCP, sont exposées dans le RFC 4987.

De plus, les protocoles ne devraient plus permettre, comme le fait SIP, d'inclure dans les messages les adresses IP auxquelles il faut envoyer la réponse. Une telle possibilité fait que l'attaquant n'a même plus besoin d'usurper l'adresse IP de sa victime !

Mais, de toute façon, cela ne concerne que les nouveaux protocoles et on ne peut pas supprimer d'un coup les anciens. Et l'IAB note bien que les protocoles conçus pour faciliter la vie des utilisateurs et des administrateurs réseaux, comme DHCP ou LLMNR, sont particulièrement vulnérables et qu'on ne peut pas les renforcer sans perdre cette possibilité de « réseau sans configuration » qui est si pratique. La sécurité est clairement ici en opposition avec la facilité d'usage.

Les architectes et administrateurs de réseaux devraient veiller à ce que l'accès aux équipements soit toujours possible en cas d'attaque, par exemple via des connexions out-of-band, c'est-à-dire n'utilisant pas le réseau principal.

Les implémenteurs devraient veiller à se méfier de l'usage de structures de données de taille finie. D'un autre côté, comme la mémoire de l'ordinateur est finie, fermer une possibilité d'attaque pourrait en ouvrir une autre. Le RFC recommande donc de bien veiller à une bonne gestion en cas d'épuisement des ressources : le programme peut ralentir mais il ne devrait pas crasher.

À nouveau, notre RFC insiste sur l'importance qu'il y a à ne pas réagir n'importe comment : l'histoire de la sécurité est pleine de mesures adoptées dans l'urgence et qui se révèlent pires que le mal. La sécurité n'aime pas les Yaka et les Fokon...


Téléchargez le RFC 4732


L'article seul

RFC 4728: The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4

Date de publication du RFC : Février 2007
Auteur(s) du RFC : D. Johnson (Rice University), Y. Hu (UIUC), D. Maltz (Microsoft Research)
Expérimental
Première rédaction de cet article le 19 février 2007


De plus en plus de réseaux aujourd'hui sont ad hoc, c'est-à-dire non gérés et sans administrateur système. C'est notamment souvent le cas des réseaux sans-fil. Leurs besoins sont donc différents des réseaux traditionnels et ils nécessitent, par exemple, des protocoles de routage adaptés, comme DSR, que présente ce RFC.

Ce problème du réseau ad hoc est présent toutes les fois où un grand nombre de machines se trouvent rassemblées mais n'ont pas d'aministrateur commun. Cela peut être les portables des participants à une réunion ou bien les PC d'une école qui utilise le système OLPC. Ces machines ont besoin de services qui sont traditionnellement gérés par l'administrateur système comme le nommage (qui peut être pris en charge par LLMNR, décrit dans le RFC 4795) ou bien le routage. Chaque machine peut servir de routeur aux autres. Dans l'OLPC, c'est fait au niveau 2 du modèle en couches, directement par la puce WiFi (dont le pilote est non-libre, ce qui a suscité une polémique). Avec DSR, c'est fait au niveau 3 et DSR permet aux machines de trouver une route vers les autres.

Un réseau sans fil typique a des caractéristiques bien particulières, liées aux caprices des ondes radio : contrairement à l'Ethernet filaire, si une machine A peut parler à une machine B et que B peut parler à C, rien n'indique que A puisse parler à C (en raison de la distance ou bien d'obstacles). Pire, certains liens peuvent être unidirectionnels (A peut parler à B mais pas le contraire).

DSR fonctionne « à la demande ». Contrairement aux protocoles de routage classiques, il n'y a pas d'émission systématique de paquets de routage, c'est seulement lorsque les machines ont besoin de communiquer qu'un processus de découverte des routes est lancé. C'est le rôle des paquets Route Discovery du protocole. Route Discovery consiste à demander aux voisins, qui demandent à leur tour à leurs voisins. Une fois la route trouvée, elle est gardée dans le cache et utilisée tout en la surveillant avec d'autres paquets, ceux de Route Maintenance qui doivent gérer les changements de connectivité. La section 8.3 de notre RFC contient une discussion détaillée de la manière dont une machine peut savoir si ses paquets sont reçus ou pas.

La section 6 de notre RFC décrit le format des paquets. On notera que le protocole DSR est intrusif, l'en-tête DSR devant être inséré entre l'en-tête IP et l'en-tête TCP ou UDP. Un programme comme tcpdump devra donc être adapté, pour « sauter » l'information DSR avant d'analyser le « vrai » paquet.

DSR est un protocole assez ancien (spécifié en 1996 et mis en œuvre depuis 1999. Il existe une implémentation pour Linux, celle pour FreeBSD semblant non maintenue. La question de son déploiement reste ouverte.


Téléchargez le RFC 4728


L'article seul

RFC 4719: Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)

Date de publication du RFC : Novembre 2006
Auteur(s) du RFC : R. Aggarwal (Juniper), M. Townsley (Cisco), M. Dos Santos (Cisco)
Chemin des normes
Première rédaction de cet article le 28 décembre 2006


Le protocole L2TP était historiquement surtout conçu pour transporter du PPP. La version 3, définie dans le RFC 3931 permettant un plus grand choix de protocoles transportés, voici le moyen de transporter de l'Ethernet au dessus d'un réseau IP comme l'Internet.

Notre RFC est fort simple : une fois qu'une session L2TP est établie, on transmet simplement l'intégralité du paquet Ethernet sur ce lien L2TP. Ce protocole permet de traiter de l'Ethernet tagué (pour les VLAN) ou non.


Téléchargez le RFC 4719


L'article seul

RFC 4716: The Secure Shell (SSH) Public Key File Format

Date de publication du RFC : Novembre 2006
Auteur(s) du RFC : J. Galbraith (VanDyke), R. Thayer (Canola & Jones)
Pour information
Première rédaction de cet article le 2 décembre 2006


Le protocole SSH, mis au point il y a de nombreuses années, est normalisé depuis quelque mois (RFC 4253) mais il manquait la spécification du format de fichier pour l'échange des clés. Chaque serveur SSH utilisait une forme différente.

Désormais, c'est fait et notre RFC spécifie donc comment représenter les clés publiques des serveurs SSH, afin de pouvoir les transmettre d'une mise en œuvre de SSH à une autre.

C'est un simple format bâti sur ASCII, pas bien méchant, mais qui n'est pas exactement le même que celui utilisé actuellement par OpenSSH et qui va donc nécessiter quelques adaptations. Mais Putty, lui, sait déjà utiliser ce format (ainsi que celui d'OpenSSH.)


Téléchargez le RFC 4716


L'article seul

RFC 4714: Requirements for IETF Technical Publication Service

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : A. Mankin, S. Hayes (Ericsson)
Pour information
Première rédaction de cet article le 18 novembre 2006


Comme le RFC 4228, ce RFC appartient au groupe des « méta-RFC » qui normalisent le processus de production des normes IETF. Ici, il décrit le rôle de l'éditeur des RFC, une fonction qui est traditionnelement distincte de celle de l'IETF.

Ce n'est pas l'IETF qui publie les RFC mais, pour des raisons historiques, une entité séparée, le RFC editor, actuellement l'ISI (et qui vient d'être récemment confirmé dans cette fonction par l'ISOC).

L'IETF n'a pas de prise directe sur cette fonction, tout au plus peut-elle en normaliser les tâches. C'est ce que fait notre RFC.

Le travail d'un éditeur de normes est à la fois le travail d'un éditeur classique (relire, corriger les fautes, publier) et un travail très spécial. Des normes comme les RFC, dont la durée de vie active se compte en dizaines d'années (comme le RFC 791) posent des défis particuliers. Il faut être conservateur dans les formats (pas question de publier les RFC dans un format lié à un éditeur de logiciels particulier, qui aura changé dix fois ce format dans les prochaines années), et très prudent à chaque étape du processus (par exemple pour vérifier le texte légal, inclus dans chaque RFC, et qui fixe les conditions d'utilisation). Lorsqu'une erreur grave survient, comme dans le RFC 4676, la seule solution est de publier en urgence un autre RFC (ici le RFC 4776).

Notre RFC décrit donc successivement toutes ces responsabilités, par exemple :

  • Relire soigneusement le texte,
  • Valider les parties qui sont écrites dans des langages formels comme ABNF,
  • Attribuer un identificateur unique à chaque RFC (c'est parfois fait avec humour, comme le RFC 1984 qui parle de l'espionnage des communications par les autorités),
  • Maintenir la liste des RFC,
  • Publier (sur http://www.rfc-editor.org/) et annoncer sur la liste adaptée,
  • Publier la liste des errata (pour les erreurs les moins graves, qui ne justifient pas la publication d'un nouveau RFC) ; on notera que c'est un point sur lequel l'actuel RFC editor est défaillant beaucoup d'errata signalés ne sont jamais publiés,
  • etc.

Téléchargez le RFC 4714


L'article seul

RFC 4713: Registration and Administration Recommendations for Chinese Domain Names

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : X. Lee (CNNIC), W. Mao (CNNIC), E. Chen (TWNIC), N. Hsu (TWNIC), J. Klensin
Pour information
Première rédaction de cet article le 9 novembre 2006


Les IDN, noms de domaine en Unicode soulèvent des questions particulières pour les langues chinoises. Notre RFC décrit la solution actuelle.

La norme des IDN, le RFC 3490 s'arrête aux considérations techniques. Elle ne traite pas les questions politiques comme « Faut-il que le titulaire du nom de domaine café.fr soit forcément le même que celui de cafe.fr ? » On peut estimer que ces deux noms devraient être regroupées en un lot, qui soit attribué à un seul titulaire (c'est l'approche du RFC 4290).

Ces questions sont traitées par chaque registre et le mieux est que les registres d'une même aire linguistique s'entendent. C'est ce qu'on fait les registres chinois (.CN) et taïwanais (.TW) dans ce RFC, qui décrit la méthode choisie, suivant le schéma qui avait été défini dans le RFC 3743 pour les langues asiatiques.

Notamment, il faut noter qu'il existe deux écritures des langues chinoises : la traditionnelle, surtout utilisée à Taïwan et la simplifiée, surtout utilisée sur le continent. L'Internet étant international, les auteurs du RFC ont choisi de considérer les deux écritures comme équivalentes, pour ce qui concerne les noms de domaines.


Téléchargez le RFC 4713


L'article seul

RFC 4707: Netnews Administration System (NAS)

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : P. Grau, V. Heinau, H. Schlichting, R. Schuettler (Freie Universitaet Berlin)
Expérimental
Première rédaction de cet article le 3 novembre 2006


Les News ou Net News, et le réseau qui les transporte, Usenet, sont parmi les outils de communication entre humains les plus anciens sur les réseaux informatiques (y compris avant Internet). Traditionnellement, les News sont gérées de manière assez anarchique, en tout cas sans règles strictes, contrairement au DNS. Résultat, il est courant que deux serveurs de News ne soient même pas d'accord sur la question de savoir si un groupe existe. Ce RFC spécifie un mécanisme par lequel des serveurs de News peuvent communiquer la liste des groupes qu'ils gèrent.

Les News sont structurées en groupes et le schéma de nommage ressemble assez à celui du DNS, sauf que le label le plus significatif est à gauche. Par exemple fr.reseaux.internet.hebergement est un groupe de News francophone sur les fournisseurs d'hébergement Internet. Mais la grosse différence avec le DNS est qu'il n'existe pas d'autorité de gestion de la racine et que chaque serveur est libre de créer ou pas des groupes, voire des hiérarchies complètes (comme lorsqu'avait été créé la hiérarchie fr, suite à des débats forts vivants dans la communauté francophone, et malgré l'opposition d'un fournisseur, le dominant à l'époque).

Si cette souplesse présente de nombreux avantages, surtout lorsqu'on compare avec la gestion très bureaucratique du DNS par l'ICANN, elle a aussi des inconvénients. Par exemple, un groupe a pu être créé sur certains serveurs et d'autres serveurs, soit ont refusé délibèrement de le créer soit ont oublié (la création de groupes implique souvent une action manuelle). Les clients de ce serveur ne verront pas le groupe.

Notre RFC s'attaque au côté technique du problème : il spécifie un nouvau protocole, NAS (Netnews Administration System), qui permet à deux serveurs de News de s'échanger des informations sur les groupes qu'ils gèrent, ce qui leur donne une chance de pouvoir se synchroniser. On peut dire que NAS est le protocole pour transporter les métadonnées, les données, structurées selon le format indiqué dans le RFC 5536, étant transportées par d'autres moyens.

Dans ses concepts et sa syntaxe, ce protocole ressemble beaucoup à d'autres protocoles texte de l'Internet comme SMTP ou bien sûr NNTP, le protocole le plus utilisé aujourd'hui pour le transport des News.

Ainsi, notre RFC donne un exemple de la commande GETP qui permet de récupérer la description d'une hiérarchie, ici humanities pour les sciences humaines :

GETP 0 0 0 humanities
615 data follow
...
Name: humanities
Status: Complete
Serial: 20020821094529
Description: ...

Téléchargez le RFC 4707


L'article seul

RFC 4698: IRIS: An Address Registry (areg) Type for the Internet Registry Information Service

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : E. Gunduz (RIPE-NCC), A. Newton (Verisign), S. Kerr (RIPE-NCC)
Chemin des normes
Première rédaction de cet article le 22 novembre 2006


Le protocole IRIS, qui prétend remplacer le vénérable whois, se décline en plusieurs variantes, selon le schéma de données utilisé (et selon les requêtes spécifiques à ce schéma). Voici donc « areg », le schéma pour les registres d'adresses IP, comme le RIPE-NCC, qui a beaucoup contribué à ce RFC.

Contrairement à l'antédiluvien whois (spécifié dans le RFC 3912), IRIS permet de spécifier un schéma de données formel (spécifié en W3C Schema), garantissant ainsi qu'on pourra analyser les données sans se tromper sur leur signification. IRIS a été normalisé dans le RFC 3981 et le premier schéma de données était « dreg », pour les registres de noms de domaine, spécifié dans le RFC 3982. Les RIR sont également des gros utilisateurs de whois et il n'est donc pas étonnant qu'ils aient voulu un schéma IRIS pour leur activité.

« areg » permet donc de chercher les contacts associés à une adresse IP, ou à un système autonome, éventuellement en indiquant si on souhaite également les réseaux plus ou moins spécifiques que celui indiqué.


Téléchargez le RFC 4698


L'article seul

RFC 4693: IETF Operational Notes

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : H. Alvestrand (Google)
Intérêt historique uniquement
Première rédaction de cet article le 18 décembre 2006
Dernière mise à jour le 10 avril 2008


Ce RFC décrivait un moyen de ne pas écrire de RFC : il introduisait une nouvelle expérience, les ION, une série de documents qui aurait pu partiellement remplacer les RFC mais qui a finalement été abandonnée.

C'est une vieille blague au sein de l'IETF que de faire remarquer qu'il y aura bientôt plus de RFC consacrés aux procédures que de RFC consacrés aux protocoles. D'où l'idée d'une nouvelle série de documents, les ION (IETF Operational Notes).

En outre, le processus de publication des RFC est très lourd, et impose un passage par un organisme extérieur, le RFC editor. Les ION devaient donc être plus légers, plus faciles à publier, accessibles dans d'autres formats que le texte brut...

Mais ils seraient néanmoins plus stables qu'un Internet-draft et feraient plus autorité qu'une page Web quelconque. Chaque ION indiquait clairement quel organisme l'a approuvé (par exemple l'IESG) et quel était son numéro de version (les RFC ne sont pas versionnés, si on veut en changer un, il faut faire un nouveau RFC).

Une dizaine d'ION ont été publiés, les deux premiers ayant été : ion-ion-format sur leur format (étaient proposés le texte seul et le HTML) et ion-ion-store sur le dépôt des ION, son mécanisme d'accès (un accès Subversion était possible), ses URL, etc. L'IESG maintenait une page générale sur les IONs.

Le 11 mars 2008, l'IESG a annoncé la fin négative de l'expérience. Les IONs n'ont pas accroché et le projet a donc été abandonné, et ce RFC reclassé comme « Intérêt historique » par le RFC 6393. Les IONs existants ont été republiés sous d'autres formes.


Téléchargez le RFC 4693


L'article seul

RFC 4690: Review and Recommendations for Internationalized Domain Names (IDNs)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : J. Klensin, P. Faltstrom (Cisco), C. Karp (Swedish Museum of Natural History), IAB
Pour information
Première rédaction de cet article le 3 octobre 2006


Les IDN ont toujours déclenché des passions et suscité des oppositions vigoureuses, notamment de la part de ceux qui regrettent que tout le monde n'écrive pas en anglais. Autant dire que ce RFC, pourtant écrit de manière très prudente et donc les aspérités ont été gommées, ne va pas passer inaperçu. Il dresse un bilan plutôt négatif des IDN et exprime de nombreuses craintes.

Après un rappel des normes existantes (les IDN ont été normalisés à l'origine dans le RFC 3490) et du vocabulaire du domaine (beaucoup de gens, à commencer par l'ICANN confondent encore langue et écriture), ainsi que la littérature existante (l'ICANN a produit des documents sans intérêt, uniquement pour tenter de faire croire qu'elle avait un rôle dans l'internationalisation de l'Internet), le RFC consacre sa section 2 à lister plusieurs problèmes.

L'équivalence de deux noms dépend du langage : est-ce que cafe.fr et café.fr sont le même domaine ? D'autres peuples d'Europe accordent une plus grosse importance aux accents que les français.

Certaines langues peuvent s'exprimer en plusieurs écritures, par exemple l'azéri. Le même mot en différentes écritures sera considéré comme différent par le DNS.

La canonicalisation des caractères par IDN peut ne pas correspondre aux attentes des utilisateurs (straße.de est canonicalisé en strasse.de).

La forme imprimée de l'IDN peut ne pas être évidente à lire. C'est le problème connu à l'IETF sous le nom de "problème du côté des bus". Une publicité comprenant un URL, chose banale aujourd'hui, pourra t-elle être lue si elle se trouve sur le côté d'un bus qui passe, sachant que de nombreux caractères se ressemblent ?

De même, certains caractères peuvent être facilement confondus (comme .py - le Paraguay et .ру - la Russie, écrit en russe avec les caractères cyrilliques). Cela peut mener à des problèmes de sécurité, par exemple en cas d'hameçonnage.

Une longue section 3 est consacrée à un problème urgent : la migration vers de nouvelles versions d'Unicode. IDN est limité à la version 3.2, mais la 5.0 est déjà sortie. Un manque de stabilité de certaines normes Unicode fait qu'IDN se limite donc à une vieille version d'Unicode, sans moyen simple de mettre à jour.

De ces questions, notre RFC tire les conclusions suivantes :

  • Nécessité de revoir la norme IDN (une révision partielle a eu lieu depuis dans le RFC 5891), notamment en passant d'un modèle "Tous les caractères sont autorisés sauf" à un modèle "Sont autorisés les caractères suivants :",
  • Étudier les solutions non-DNS (par exemple avec un couche supplémentaire dans l'interface utilisateur pour traduire .com en chinois),
  • Restrictions sur l'usage de multiple écritures dans un seul nom.

D'autres conclusions sont explicitement dirigées plutôt vers l'ICANN (notons que le RFC fait comme si l'ICANN était responsable des politiques des registres) :

  • Politiques d'enregistrement plus strictes chez les registres,
  • Politique d'introduction des IDN dans la racine du DNS (ce qu'on nomme souvent les IDN.IDN par exemple café.ré pour l'île de la Réunion).

Le RFC appelle aussi à reconsidérer le rôle (limité) du DNS et à considérer que, peut-être, les efforts d'internationalisation pourraient porter sur des solutions non-DNS, par exemple des moteurs de recherche.

Si ce RFC est très prudent dans ses recommandations (tout est présenté sous forme de question, il n'y a pratiquement pas de directive concrète qui pourrait fâcher), il appartient quand même à la vaste catégorie des textes s'inquiétant, en général assez hypocritement, des problèmes liés à IDN. La plupart de ces textes sont émis par des organismes qui ne veulent pas de l'internationalisation de l'Internet (on peut lire un bon exemple). En fait, la plupart de ces textes, tout comme notre RFC, oublient deux choses :

  • La complexité ne vient pas d'IDN ou d'Unicode, elle vient des langues humaines. Cells-ci sont très complexes, point. On peut le regretter et se dire que cela serait plus simple si tout le monde parlait anglais ou lojban mais ce n'est pas le cas. L'IETF et les autres SDO doivent faire avec.
  • La plupart de ces problèmes sont marginaux. Ils ne se produisent que dans des cas rares, avec des écritures peu courantes. Retarder les IDN à cause de problèmes aussi artificiels serait retarder une évolution de l'Internet vers plus de prise en compte des autres cultures.

Ce RFC, comme beaucoup d'autres textes et discours analogues est, quoique écrit dans le style IETF, de la même eau : du FUD.


Téléchargez le RFC 4690


L'article seul

RFC 4686: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : J. Fenton (Cisco)
Pour information
Première rédaction de cet article le 9 octobre 2006


Le courrier électronique n'est pas sûr, on le sait bien. Notamment, il ne fournit pas de moyen d'authentifier l'émetteur et il est trivial d'envoyer un message prétendant venir de Nicolas.Sarkozy@poulaga.fr. Une des techniques prétendant traiter ce problème est DKIM et notre RFC décrit les risques auxquels répond DKIM et les menaces contre DKIM.

Précisons tout de suite que DKIM, contrairement à des techniques comme PGP ne vise nullement à la confidentialité des messages mais uniquement à leur authentification. DKIM, normalisé dans le RFC 6376, répond donc aux menaces d'usurpation d'une adresse. Le RFC commence par analyser les méchants : ce qu'ils peuvent faire (du script kiddie au professionnel entrainé), ce dont ils disposent (les algorithmes, par exemple, puisque la norme DKIM est disponible publiquement), ce qu'ils veulent (usurper une identité, bien sûr mais peut-être aussi réaliser une DoS en empêchant des vérifications).

L'essentiel du RFC, sa section 4, est ensuite consacrée à l'examen détaillé de toutes les attaques possibles, du vol de la clé privée à l'exploitation de limites des MUA qui n'afficheraient pas clairement le contenu qui est signé et ce qui ne l'est pas (DKIM permet de ne signer qu'une partie d'un message) ou bien qui afficheraient les parties non-vérifiées d'une adresse au même titre que les parties vérifiées (par exemple, dans l'adresse Ségolène Royal <plaisantin@hotmail.com>, seule l'adresse plaisantin@hotmail.com peut être vérifiée par DKIM, pas le nom affiché).

Beaucoup des attaques décrites ici ne sont pas spécifiques à DKIM, ni même à la cryptographie et on ne peut donc que rappeler les principes de base de la sécurité informatique, notamment le fait que le maillon faible est en général entre la chaise et le clavier...


Téléchargez le RFC 4686


L'article seul

RFC 4685: Atom Threading Extensions

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : J. Snell
Chemin des normes
Première rédaction de cet article le 26 septembre 2006


Petit à petit se construit la pile des formats de syndication de l'IETF. Notre RFC, première extension publiée sur le format Atom, normalise les fils de discussion (threads).

On le sait, une des motivations pour le format Atom était d'avoir une alternative ouverte, non contrôlée par une entreprise particulière, pour la syndication de contenu. Atom, normalisé dans le RFC 4287, est désormais largement répandu. Atom consiste en un format de base, plus la possibilité, décrite dans la section 6 du RFC 4287, d'ajouter des extensions. Le travail sur plusieurs de ces extensions a commencé imémdiatement et la première publiée concerne les fils de discussion (threads).

Notre RFC normalise donc un nouvel espace de nommage XML et de nouveaux éléments notamment <in-reply-to> qui permet à une entrée Atom de pointer vers l'entrée à laquelle elle répond. On notera que ces deux entrées peuvent être sur des sites Web ou des blogs différents, permettant ainsi un système de commentaires distribué.


Téléchargez le RFC 4685


L'article seul

RFC 4678: Server/Application State Protocol v1

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : A. Bivens (IBM)
Pour information
Première rédaction de cet article le 15 octobre 2006


Le succès de l'Internet et des service auquel il donne accés a entrainé une très forte pression sur certains serveurs populaires. Beaucoup de sites Web, comme Google ou Amazon ne pourraient plus, depuis longtemps, tenir le coup avec une seule machine, si puissante soit-elle. Aussi la plupart des gros services sont désormais répartis en plusieurs machines et c'est souvent un répartiteur (load balancer) qui assure la distribution de charge entre ces machines. Notre RFC spécifie un protocole pour piloter ces répartiteurs.

Certains protocoles ont dès le début été conçus pour que le service puisse être assuré par plusieurs machines. C'est notamment le cas du DNS, où les enregistrements de type NS (name server) sont toujours multiples (la plupart des registres, suivant le RFC 1034, exigent au moins deux serveurs). Pour les autres protocoles, une solution élégante existe, les enregistrements DNS de type SRV (server), spécifiés dans le RFC 2782, mais qui n'ont jamais été réellement déployés. Ils permettraient notamment de résoudre le problème de la répartition de charge des serveurs Web.

En attendant une solution dans le protocole, l'approche la plus répandue est de mettre un groupe, une ferme, de serveurs derrière un répartiteur. Celui-ci peut être une machine spécialisée, une boîte noire (appliance), ou bien il peut être un logiciel, comme pen. Le contrôle de ces répartiteurs se fait toujours par un protocole privé, et c'est là qu'intervient notre RFC. (Notons que les solutions comme CARP assurent la redondance mais pas vraiment la répartition de charge.)

Notre RFC (dont il faut noter qu'il est de statut Informational ce qui signifie qu'il n'est pas approuvé par l'IETF) propose donc un nouveau protocole, SASP (Server/Application State Protocol), qui sert à la communication entre un contrôleur, le GWM (Group Workload Manager) et, d'une part le répartiteur (appelé LB pour load balancer) et d'autre part les serveurs effectifs.

Les messages envoyés en SASP permettent ensuite aux acteurs (LB et serveurs) de s'enregistrer auprès du GWM et de lui indiquer leur état, ce qui permet de leur envoyer plus ou moins de trafic.

On notera enfin un point de sécurité important : SASP, conçu pour des environnements fermés (réseaux privés, probablement avec adresses IP privées et coupe-feu devant), n'a pratiquement pas de sécurité. La section 10 du RFC explique ce point et propose des solutions, typiquement l'utilisation de TLS.


Téléchargez le RFC 4678


L'article seul

RFC 4677: The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : P. Hoffman (VPN), S. Harris (University of Michigan)
Pour information
Première rédaction de cet article le 25 septembre 2006


Comme toute organisation, l'IETF a sa culture, ses règles, ses idiosyncrasies. Et les nouveaux arrivants peuvent avoir du mal à s'y retrouver. Ce RFC, surnommé "Le Tao", visait à guider ceux qui arrivent à leur première réunion IETF. (La forme RFC convenant mal à ce genre de documents, il a depuis été remplacé par une page Web.)

L'IETF est nettement moins formelle que la plupart des autres SDO. Mais elle est sans doute plus exigeante quant à la qualité du travail. Le RFC décrit donc la forme (comment s'habiller, comment faire ses présentations) et le fond : que lire et comment écrire. Il succède au RFC 3160 et a lui-même été rendu obsolète par le RFC 6722, qui remplaçait tous ces RFC par une page Web.

Pour l'habillement, c'est relativement simple. Comme le dit notre RFC, "comme les participants aux réunions doivent porter un badge, le T-shirt ou la chemise sont obligatoires. Les pantalons ou shorts sont recommandés."

Pour les présentations, si les gadgets PowerPoint touchent l'IETF comme beaucoup d'autres organisations, en revanche la publicité y est moins acceptée et les transparents doivent avoir du contenu.

Pour ce qui concerne le travail, ce n'est pas ce qui manque. Le débutant va devoir comprendre le rôle des différentes organisations qui gravitent dans la galaxie IETF (IAB, IESG, ISOC, RFC editor, etc). Et il va devoir apprendre la subtilité du statut des RFC, tous les RFC n'étant pas des normes.

Ensuite, si notre débutant va vouloir travailler à un RFC, il va devoir s'inscrire à un groupe de travail. Rien de plus simple puisqu'il n'y a pas de barrière à l'entrée. Mais les difficultés commencent après, et la description du processus qui mène d'une vague idée à un vrai RFC prend beaucoup de pages.

Bref, l'IETF, c'est intéressant, c'est utile, c'est ouvert, c'est bien documenté grâce entre autres au Tao, mais ce n'est pas pour autant un chemin de roses...


Téléchargez le RFC 4677


L'article seul

RFC 4656: A One-way Active Measurement Protocol (OWAMP)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : S. Shalunov (Internet2), B. Teitelbaum (Internet2), A. Karp (Internet2), J. Boote (Internet2), M. Zekauskas (Internet2)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 27 septembre 2006
Dernière mise à jour le 11 septembre 2008


Mesurer les performances d'une connexion à l'Internet est évidemment essentiel pour tous. Ce RFC propose un protocole, OWAMP, pour effectuer des mesures à sens unique (c'est-à-dire ne nécessitant pas que la réponse revienne).

Tout le monde a besoin de savoir si une liaison Internet fonctionne bien : du client qui veut vérifier les promesses de son fournisseur à l'ingénieur réseaux qui essaie de déboguer un problème de performances, avec les utilisateurs qui crient dans son dos "Ça rame !". Traditionnellement, ces mesures de performance étaient effectuées sur des trajets aller-retour (round-trip). Ainsi, le logiciel ping mesure le temps d'aller-retour (RTT pour round-trip time). Le RFC 5357 normalise un protocole de mesure de RTT, TWAMP. Non seulement cela nécessite que le chemin de retour fonctionne, mais cela interdit de séparer le temps de parcours aller du temps de parcours retour.

Le groupe de travail IETF IPPM (IP Performance Metrics) a donc produit de nombreux RFC spécifiant les métriques à utiliser pour des mesures de performance à sens unique (notamment les RFC 7679 et RFC 7680). En pratique, ces mesures se font en utilisant deux horloges très précises (par exemple GPS) sur les deux machines et en envoyant des paquets depuis la machine sonde vers la machine réceptrice.

Notre nouveau RFC franchit une nouvelle étape en normalisant le protocole de communication entre les deux machines, afin qu'elles puissent se mettre d'accord sur le test, puis l'effectuer. OWAMP (One-way Active Measurement Protocol) comprend deux parties :

  • OWAMP-Control est le protocole bi-directionnel de communication avant le test. Reposant sur TCP (port 861), il sert à se mettre d'accord sur les détails du test.
  • OWAMP-Test est le protocole de test, bâti sur UDP. Il fonctionne par l'envoi de paquets contenant l'heure de la machine émettrice. La réceptrice peut donc facilement calculer le temps de trajet, avec une résolution qui est celle des horloges utilisées par les deux machines.

OWAMP pose quelques problèmes de sécurité puisque, dans une communication à sens unique, il peut être difficile de s'assurer que les messages ont bien été transmis et pas altérés. Comme certains acteurs auraient intérêt à fausser les mesures, OWAMP-Protocol permet aux deux parties de se mettre d'accord sur des mécanismes d'authentification et de contrôle d'intégrité des paquets, en utilisant la cryptographie.

Deux mises en œuvre d'OWAMP en logiciel libre sont disponibles en http://e2epi.internet2.edu/owamp/ et http://www.av.it.pt/jowamp/ On peut lire aussi Comparing 2 implementations. of the IETF-IPPM One-Way. Delay and Loss Metrics, un excellent exposé qui donne beaucoup de détails techniques sur la mise en œuvre de ces mesures de trajets à sens unique. La question de la mesure du temps avec une résolution suffisante (une microseconde) n'est pas évidente sur un Unix de série !

Voici un exemple d'utilisation de l'OWAMP d'Internet2, sur une Debian :

# Lancer le démon qui servira pour le protocole de contrôle. Ici, pour les tests,
# on le lance en avant-plan (option -Z)
% sudo owampd -U dupont -Z -v -a O
...
# Lancer le client (ici, sur la même machine, ::1, l'adresse IPv6 locale) 
# et mesurer
% owping ::1      
Approximately 13.1 seconds until results available

--- owping statistics from [::1]:43537 to [::1]:43538 ---
SID:    00000001cc734425a191ff7187f24db9
first:  2008-09-11T09:15:50.875
last:   2008-09-11T09:16:01.171
100 sent, 0 lost (0.000%), 0 duplicates
one-way delay min/median/max = 0.0129/0.1/0.0439 ms, (err=1.48 ms)
one-way jitter = 0 ms (P95-P50)
TTL not reported
no reordering
...

Pour une critique vigoureuse de ce RFC (pas du protocole, mais de la rédaction du RFC), voir « How NOT to Write a Protocol Specification », de Dustin D. Trammell.


Téléchargez le RFC 4656


L'article seul

RFC 4648: The Base16, Base32, and Base64 Data Encodings

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : S. Josefsson (SJD)
Chemin des normes
Première rédaction de cet article le 14 janvier 2008
Dernière mise à jour le 29 septembre 2012


Même les plus simples encodages peuvent réveler des surprises. Base64 en est désormais à son quatrième RFC, mais il est vrai que c'est un des formats les plus utilisés, qu'on le trouve partout dans les protocoles. Ce RFC normalise donc Base64, ainsi que Base32 et Base16.

Quel est le problème que tentent de résoudre ces encodages ? Le fait que certains environnements n'acceptent pas le jeu de caractères qu'on voudrait utiliser. C'est bien sûr le cas si ce jeu de caractères est Unicode mais même le simple ASCII peut être trop vaste pour certains usages. Par exemple, les URL ne peuvent pas comporter d'espace, et nécessitent donc un encodage de ces espaces, pour les protéger. Base64 et ses camarades sont des encodages généralistes pour tous ces cas où on doit réduire d'un jeu de caractères trop vaste à un jeu restreint : Base64 (sections 4 et 5) utilise 64 caractères (les majuscules et les minuscules d'ASCII, les chiffres, le signe plus et la barre oblique). Base32 (sections 6 et 7) utilise uniquement les majuscules et les chiffres et Base16 (section 8, mais il faut noter que ce nom de Base16 n'a jamais pris) utilise uniquement les caractères des chiffres hexadécimaux (il sert par exemple, sous un autre nom, à l'encodage des URL, cf. RFC 3986, section 2.1).

La section 3 du RFC est très détaillée car elle doit expliquer tous les problèmes d'interopérabilité qui peuvent se poser avec l'encodage, notamment si celui-ci est incomplètement spécifié (ce qui était le cas avec les RFC précédant celui-ci, comme le RFC 2045). Ainsi, la section 3.1 parle du difficile problème des sauts de ligne, ou bien 3.3 se demande ce que doit faire le récepteur si des caractères en dehors du jeu normalement utilisé apparaissent néanmoins dans les données. Le monde des encodages est vaste et peu organisé... Heureusement que ce RFC décrit bien l'état actuel du problème.

Historiquement, des tas de variantes plus ou moins importantes d'un de ces encodages ont été utilisées, ce qui contribue à la difficulté de la tâche de décodeur. La section 5 normalise une de ces variantes, un encodage de Base64 qui n'utilise pas le / et le +, qui ont souvent une signification particulière, mais le _ et le -. Comme il est surtout utilisé pour les URL, cet encodage est souvent nommé URL encoding.

La section 12, sur la sécurité, est également très complète car, historiquement, plusieurs problèmes de sécurité ont été liés à ces encodages. Par exemple, beaucoup de spams sont encodés en Base64, même lorsque cela n'est pas nécessaire, pour tenter d'échapper à des logiciels de filtrage naïfs. (C'est au point que SpamAssassin donne désormais une mauvaise note aux messages ainsi encodés.)

Du fait de l'étendue des usages de Base64, il existe des bibliothèques pour l'encoder et le décoder dans tous les langages de programmation (Base32 est moins bien traité). Le RFC cite également une implémentation de référence en C.

Voici un exemple d'encodeur en Perl :

#!/usr/bin/perl

use MIME::Base64;

foreach $word (@ARGV) {
    print("$word: " . encode_base64($word) . "\n");
}

Et un exemple de décodage en une seule ligne de Perl :


% echo Y2Fm6Q= | perl -MMIME::Base64 -e 'printf "%s\n", decode_base64(<>)' 

Cet autre exemple est en D :


static import std.base64;
import std.stdio;

int main(char[][] argv)
{
  int argc = argv.length;
  char[] word;
  if (argc <= 1) {
    writefln("Usage: %.*s word ...", argv[0]); 
    return 1;
  }
  for (int i = 1; i < argc; i++) {
    // It would be cooler to use 'foreach (char[] word; argv)' but it
    // does not allow to skip 0th arg (and slices do not seem to work
    // in that context)
    word = argv[i];
    writefln("%s: %s", word, std.base64.encode(word));
  }
  return 0;
}

Voici un exemple d'encodage Base64 en Go, montrant la différence entre l'encodage standard et l'« encodage URL » :

package main

import (
	"bufio"
	"encoding/base64"
	"flag"
	"fmt"
	"io"
	"os"
)

const MAXSIZE int = 4096

func main() {
	result := make([]byte, MAXSIZE)
	value := make([]byte, MAXSIZE)
	rd := bufio.NewReader(os.Stdin)
	n, error := rd.Read(value)
        ...
	base64.StdEncoding.Encode(result, value[0:n])
	fmt.Printf("Standard encoding of %s is %s\n", value[0:n],
		result)
	base64.URLEncoding.Encode(result, value[0:n])
	fmt.Printf("URL encoding of %s is %s\n", value[0:n],
		result)
}

Depuis le shell, on cite parfois le logiciel aish, mais je l'ai toujours trouvé inutilisable. Je préfère OpenSSL qui a une option d'encodage en Base64 (l'argument -n d'echo permet de voir la différence selon qu'il y a un saut de ligne ou pas) :

% echo -n café | openssl enc -base64     
Y2Fm6Q==
% echo café | openssl enc -base64       
Y2Fm6Qo=

Et, pour décoder :

% echo Y2Fm6Qo=  | openssl enc -d -base64 

Il y a aussi dans les coreutils un utilitaire nommé base64.

Notre RFC 4648 succède au RFC 3548 (qui lui même complétait le RFC 2045 sur ce point). La section 13 liste les changements (modérés), comme par exemple l'ajout d'exemples à des fins de tests des logiciels.


Téléchargez le RFC 4648


L'article seul

RFC 4647: Matching of language tags

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : A. Phillips (Yahoo), M. Davis (Google)
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 11 septembre 2006


Le RFC 4646 qui spécifie les nouveaux language tags, les étiquettes pour indiquer la langue utilisée, étant désormais disponible, ce RFC complète le travail en définissant (partiellement) les algorithmes de correspondance entre une étiquette existante et une étiquette demandée, par exemple lors de la négocation de contenu entre un navigateur Web et un serveur.

Notre RFC définit donc une nouvelle syntaxe, le language range (intervalle de langues) qui exprime des préférences et que l'algorithme doit mettre en correspondance avec les étiquettes disponibles (par exemple, les valeurs de l'attribut xml:lang si le serveur sert des documents XML).

Le RFC définit ensuite deux classes d'algorithmes possibles, le filtering (filtrage), qui va trouver O, 1 ou N documents parmi ceux disponibles et le lookup (recherche) qui va trouver un document et un seul. Le filtrage est par exemple utilisé lorsque le processeur veut extraire d'une bibliothèque de documents XML tous les documents qui répondent au même critère (être en Breton, par exemple). La recherche est utilisée lorsque le processeur doit trouver un document et un seul, par exemple pour envoyer un message d'erreur à l'utilisateur.

L'intervalle ressemble à une étiquette mais certains champs peuvent contenir un astérisque qui signifie l'acceptation de n'importe quelle valeur. Ainsi, *-CH pourra désigner toutes les langues utilisées en Suisse.

À noter que les détails des deux algorithmes, de filtrage et de recherche, sont délibérement non complets : c'est au protocole qui utilise ce RFC de tout spécifier. Même chose pour le cas où le client souhaite indiquer une liste de langues possibles, comme ce que permet le protocole HTTP avec son champ Accept-Language. Notre RFC ne donne pas de syntaxe précise pour de telles listes, ce sera aux futurs RFC utilisateurs de le faire.


Téléchargez le RFC 4647


L'article seul

RFC 4646: Tags for Identifying Languages

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : A. Phillips (Yahoo), M. Davis (Google)
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 11 septembre 2006
Dernière mise à jour le 10 octobre 2006


Successeur du très utilisé RFC 3066, puis lui-même remplacé par le RFC 5646, notre RFC décrit les noms des langues (langues humaines, pas langages informatiques). Toute application qui a besoin d'indiquer une langue doit s'en servir.

Le protocole HTTP par exemple permet à un navigateur Web d'indiquer au serveur quelle langue il préfère (en-tête Accept-Language: dans le RFC 2616), au cas où le serveur aie plusieurs versions d'une page et soit correctement configuré (ce que Apache permet). Cela marche très bien avec des sites comme http://www.debian.org/.

Des normes non-IETF (notamment XML) se réfèrent à ce RFC.

Les noms des langues ont en général deux lettres et sont tirés de la norme ISO 639. Par exemple :

  • "fr" pour le français, à ne pas confondre avec le TLD ".fr", qui désigne la France,
  • "ar" pour l'arabe,
  • "br" pour le breton,
  • "en" pour l'anglais,
  • etc.

La norme complète est plus complexe : par exemple, l'anglais parlé aux États-Unis n'est pas tout à fait le même que celui parlé en Grande-Bretagne. Aussi, notre RFC permet de décrire la langue de manière plus fine par exemple fr-CH désigne le français tel qu'il est parlé en Suisse.

Il y a d'autres caractéristiques que la langue ou le pays. Ainsi, sr-Latn-CS représente le serbe (sr) écrit dans l'alphabet latin (Latn) tel qu'il s'utilise en Serbie (CS).

La question étant sensible (le croate est-il une langue différente du serbe, par exemple ?) l'IETF a évité les problèmes en s'appuyant sur des normes existantes (ISO 639 pour les langues comme le RFC 1591 s'appuie sur ISO 3166 pour éviter l'épineuse question de "qu'est-ce qui est un pays"). Néanmoins, le RFC confie un rôle de registre à l'IANA pour garantir une stabilité des noms (l'ISO ne la garantit pas, ne s'intéressant qu'au présent, alors que l'Internet a besoin de stabilité sur le long terme).

Les changement par rapport au précédent, le RFC 3066 sont détaillés à la fin du RFC. Le changement plus visible est le choix d'avoir désormais un registre complet à l'IANA. L'ancien registre IANA était très incomplet (beaucoup de langues n'étaient pas enregistrées) et ne séparait pas clairement les étiquettes (tag, la langue) des sous-étiquettes (subtag, le pays et/ou l'écriture), le tag complet étant considéré comme opaque aux applications. Le nouveau registre, initialisé par le RFC 4645 est bien plus complet. Il s'appuie toujours sur les normes existantes (ISO 639 pour les langues, ISO 15924 pour les écritures et ISO 3166 pour les pays). La syntaxe, si elle ne change pas en apparence (fr-BE sera toujours une étiquette valable pour le français pratiqué en Belgique), est plus rigoureuse. À son tour, notre RFC 4646, a été remplacé par un RFC plus récent, le RFC 5646.

Les auteurs du RFC ont expliqué leurs choix dans les excellents articles Reasons for Enhancing RFC 3066 et Understanding the New Language Tags.

Les transparents d'un exposé sur ces language tags sont disponibles.

Un analyseur de language tags en logiciel libre existe désormais, GaBuZoMeu.


Téléchargez le RFC 4646


L'article seul

RFC 4645: Initial Language Subtag Registry

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : D. Ewell (éditeur)
Pour information
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 11 septembre 2006


Ce RFC, compagnon du RFC 4646, décrit l'état initial du registre des langues de l'IANA.

Il est écrit dans le format dit record-jar, décrit dans le livre The Art of Unix programming.

Il servait juste à initialiser le nouveau registre IANA avec des affectations comme :

   %% Description d'une langue, ici l'arménien (hy)
   Type: language
   Subtag: hy
   Description: Armenian
   Added: 2005-10-16
   Suppress-Script: Armn
   %%
   %% Description d'une écriture, ici l'alphabet latin
   Type: script
   Subtag: Latn
   Description: Latin
   Added: 2005-10-16
   %%

Le registre a ensuite continué sa vie, accepté de nouveaux enregistrements et même une nouvelle grande mise à jour avec le RFC 5645.


Téléchargez le RFC 4645


L'article seul

RFC 4641: DNSSEC Operational Practices

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : O. Kolkman (NLnet labs), R. Gieben (NLnet labs)
Pour information
Première rédaction de cet article le 10 octobre 2006


Comme avec toute technique fondée sur la cryptographie, le protocole DNSSEC impose, non seulement des bons algorithmes et une mise en œuvre correcte, mais surtout des procédures rigoureuse et soigneusement exécutées. C'est le but de ce RFC, qui remplace le RFC 2541 et a lui-même été remplacé par le RFC 6781, et qui explique tout ce à quoi doivent s'attendre les registres qui déploieraient DNSSEC.

Notre RFC rappelle donc des concepts de base du DNS (notamment le fait que la propagation des modifications n'est pas instantanée) puis rappelle les différentes clés utilisées par DNSSEC et leurs caractéristiques souhaitables (longueur, période maximale pendant laquelle on les utilise, lieu de stockages, etc).

Il explique ensuite les considérations temporelles (DNSSEC utilise le temps et nécessite des horloges bien synchronisées, par exemple par NTP).

Enfin, le RFC étudie le rollover, le remplacement d'une clé. Les clés ne pouvant pas raisonnablement être utilisées éternellement, il faut prévoir à l'avance les remplacements périodiques et aussi, hélas les remplacements en urgence en cas de compromission. Il faut apporter beaucoup de soin à ce remplacement, si on veut éviter que, pendant une certaine période, les données publiées dans le DNS soient invalides et donc rejetées par un résolveur DNS paranoïaque (il faut publier la nouvelle clé suffisamment à l'avance pour qu'elle soit présente partout ou bien signer tous les enregistrements avec les deux clés, l'ancienne et la nouvelle).

Le DNS étant hiérarchique, il faut veiller, lors de toutes les manipulations, à bien rester synchronisé avec le gérant de la zone parente, dont les enregistrements de type DS (delegation signer) pointeront vers notre clé.

Bref, pour un registre, déployer DNSSEC, ce n'est pas uniquement signer la zone : c'est aussi mettre en place des procédures de sécurité, analogues à celle d'une autorité de certification.

Le RFC 6781 a depuis remplacé ce RFC et est donc la version actuelle sur les questions opérationnelles liées à DNSSEC.


Téléchargez le RFC 4641


L'article seul

RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : P. Arberg (Redback), D. Kourkouzelis (Redback), M. Duckett (Bell South), T. Anschutz (Bell South), J. Moisand (Juniper)
Pour information
Première rédaction de cet article le 18 novembre 2006


Beaucoup d'utilisateurs ADSL souffrent de la limite de MTU que leur impose le protocole PPPoE. Voici une solution possible.

La plupart des utilisateurs ADSL utilisent le protocole PPPoE, décrit dans le RFC 2516, entre leur routeur et celui du FAI. Ce protocole, qui consiste à utiliser PPP au dessus d'Ethernet a un gros défaut : les 8 octets de l'en-tête PPP sont soustraits des 1500 octets maximums d'Ethernet et la MTU est donc de seulement 1492 octets. Si les machines du réseau local gardent leur MTU Ethernet par défaut, les paquets seront fragmentés et le débit chutera. Ce problème est très bien expliqué dans l'article MTU, MSS etc..., de Christian Caleca.

Il existe plusieurs solutions à ce problème. Par exemple, abaisser de force la MTU sur toutes les machines (sur Unix, cela se fait typiquement avec la commande ifconfig). Ou bien utiliser le MSS clamping qui consiste à réduire la taille des segments TCP pour qu'elle tienne dans la MTU minimum du réseau (sur Linux, cela se fait typiquement en mettant dans /etc/ppp/peers/FAI, l'option -m à pppoe, par exemple pty "pppoe -I eth1 -T 80 -m 1412").

Mais notre RFC suggère une autre approche : la plupart des équipements Ethernet acceptent en fait des paquets plus grands que les 1500 octets normalisés. Ignorons donc la norme et créons des paquets PPPoE de 1500 octets (1508 avec l'en-tête). Si l'IESG a quand même glissé un avertissement dans le RFC pour cette violation formelle de la norme Ethernet de l'IEEE, cela fonctionne et permet de résoudre le problème.


Téléchargez le RFC 4638


L'article seul

RFC 4627: The application/json Media Type for JavaScript Object Notation (JSON)

Date de publication du RFC : Juillet 2006
Auteur(s) du RFC : D. Crockford (JSON.org)
Pour information
Première rédaction de cet article le 30 août 2006
Dernière mise à jour le 18 janvier 2012


Il existe une pléthore de langages pour décrire des données structurées. XML est le plus connu et voici un de ses concurrents, JSON, décrit dans ce RFC (depuis remplacé par le RFC 8259).

JSON existe depuis longtemps mais n'avait pas de norme formelle. C'est désormais fait dans notre RFC, puis dans son successeur, le RFC 8259.

JSON se veut plus léger que XML. Comme son concurrent XML, il permet de représenter des structures de données hiérarchiques.

À noter que JSON doit son origine, et son nom complet (JavaScript Object Notation) au langage de programmation Javascript, dont il est un sous-ensemble. Mais JSON n'est pas un langage de programmation, seulement un langage de description de données, et il ne peut donc pas servir de véhicule pour du code méchant.

Voici un exemple, tiré du RFC, d'un objet exprimé en JSON :

  {
      "Image": {
          "Width":  800,
          "Height": 600,
          "Title":  "View from 15th Floor",
          "Thumbnail": {
              "Url":    "http://www.example.com/image/481989943",
              "Height": 125,
              "Width":  "100"
          },
          "IDs": [116, 943, 234, 38793]
        }
   }

Les détails sont dans les sections 1 et 2 du RFC. Cet objet d'exemple a un seul champ, Image, qui est un autre objet (entre { et }) et qui a plusieurs champs. Un de ces champs, IDs, a pour valeur un tableau.

JSON est donc un format simple, il n'a même pas la possibilité de commentaires dans le fichier... Voir sur ce sujet une intéressante compilation.

Voici un exemple d'un programme Python pour écrire un objet Python en JSON (on notera que la syntaxe de Python et celle de JavaScript sont très proches) :

import json

objekt = {u'Image': {u'Width': 800,
                     u'Title': u'View from Smith\'s, 15th Floor, "Nice"',
                     u'Thumbnail': {u'Url':
                                    u'http://www.example.com/image/481989943',
                                    u'Width': u'100', u'Height': 125},
                     u'IDs': [116, 943, 234, 38793],
                     u'Height': 600}} # Example from RFC 4627, lightly modified

print json.dumps(objekt)

Et un programme pour lire du JSON et le charger dans un objet Python :

import json

# One backslash for Python, one for JSON
objekt = json.loads("""
{
      "Image": {
          "Width":  800,
          "Height": 600,
          "Title":  "View from Smith's, 15th Floor, \\\"Nice\\\"", 
          "Thumbnail": {
              "Url":    "http://www.example.com/image/481989943",
              "Height": 125,
              "Width":  "100"
          },
          "IDs": [116, 943, 234, 38793]
        }
   }
""") # Example from RFC 4267, lightly modified

print objekt
print ""
print objekt["Image"]["Title"]

Si vous voulez le faire en Go, il existe un bon article d'introduction au paquetage standard json.

JSON dispose d'une page Web officielle, où vous trouverez plein d'informations.


Téléchargez le RFC 4627


L'article seul

RFC 4620: IPv6 Node Information Queries

Date de publication du RFC : Août 2006
Auteur(s) du RFC : M. Crawford (Fermilab), B. Haberman (JHU APL)
Expérimental
Première rédaction de cet article le 14 septembre 2006


Une nouvelle brique se met en place dans le chantier IPv6 : ce RFC normalise un mécanisme permettant de connaitre le nom d'une machine, en lui demandant (il faut donc connaitre son adresse IP). Cela permet de se passer du DNS, pour les réseaux sans administrateur.

Les réseaux traditionnels étaient composés d'un petit nombre d'ordinateurs, gérés par des administrateurs système professionnels. Mais IPv6 vise à être utilisé dans des environnements très différents, sur des appareils nombreux, et dans des réseaux pas forcément administrés. Si un nouveau contrôleur RFID est branché dans l'entrepôt, faut-il vraiment avoir un serveur DNS à jour pour pouvoir associer son nom à son adresse ? Notre RFC propose une autre solution : on envoie un paquet Node Information Query en ICMP à ce contrôleur et il répond avec son nom. On a donc un système de nommage proche des utilisateurs, sans serveur central.

Pour avoir ce service sur sa machine Linux, il y a le logiciel ninfod (répond aux sollicitations) et nins (détecte les systèmes présents et met à jour le DNS). Apparemment, un logiciel équivalent est disponible en série sur d'autres Unix, comme FreeBSD, mais je n'ai pas investigué.

Merci à Jean-Jacques Sarton pour sa relecture.


Téléchargez le RFC 4620


L'article seul

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

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : M. Duke (Boeing Phantom Works), R. Braden (ISI), W. Eddy (Verizon), E. Blanton (Purdue University)
Pour information
Première rédaction de cet article le 28 septembre 2006


C'était un RFC de récapitulation. Il ne normalisait rien de nouveau mais dressait une liste commentée des RFC dont la connaissance est indispendable, ou simplement utile, au programmeur qui met en œuvre TCP. Il a depuis été remplacé par le RFC 7414.

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

Mais le RFC normatif, le RFC 793, quoique toujours valable, est bien vieux et beaucoup de choses ont été ajoutée ou retirées à TCP depuis. Comme pour beaucoup d'autres protocoles Internet (par exemple le DNS), TCP met donc le programmeur en face d'une rude tâche : avant de commencer à coder, il doit d'abord dresser la liste de tous les RFC dont il aura besoin. C'est cette tâche que lui épargne notre RFC en dressant cette liste.

Par exemple, le document original ne contient rien sur le contrôle de congestion, qui ne sera décrit que dans le RFC 2001. Ce RFC (ou plus exactement son successeur, le RFC 5681) fait désormais partie de ceux qu'il faut lire, ainsi que le RFC 1323 qui décrit plusieurs extensions nécessaires pour tirer des performances élevées, ou bien le RFC 3168 qui normalise ECN.

La sécurité ayant bien plus d'importance aujourd'hui, d'autres RFC décrivent comment se défendre contre certaines vulnérabilités par exemple la lecture du RFC 6528 est indispensable pour empêcher un attaquant d'insérer des paquets dans une session TCP existante.

D'autres extensions sont moins consensuelles et restent plutôt expérimentales à ce jour comme l'algorithme Eifel du RFC 3522.

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

Le protocole T/TCP, normalisé dans le RFC 1644, aurait permis de diminuer nettement la durée des connexions courtes, celles où on échange peu de données (beaucoup de connexions HTTP sont dans ce cas). Promu par des experts comme Stevens, implémenté dans des systèmes comme FreeBSD (option MSG_EOF de sendto), il a été remisé au grenier après que des analyses plus poussées aient montré ses failles de sécurité (il facilite l'utilisation de TCP avec usurpation d'adresses IP).

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

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

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

La section 7 couvre enfin un cas délicat : les extensions à TCP qui, bien que largement utilisées, n'ont jamais fait l'objet d'un RFC ni même, souvent, d'une description formelle.

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

Voilà, rappelez-vous qu'un tel travail est forcément temporaire, de nouveaux RFC apparaissent, des idées qui semblaient bonnes sont abandonnées, et il faut donc refaire ce catalogue de temps en temps. Notre RFC est dépassé et la version actuelle est dans le RFC 7414.


Téléchargez le RFC 4614


L'article seul

RFC 4593: Generic Threats to Routing Protocols

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : A. Barbir (Nortel), S. Murphy (Sparta), Y. Yang (Cisco)
Pour information
Première rédaction de cet article le 8 décembre 2006


Parmi tous les risques de sécurité qui touchent Internet, notre RFC s'attache à décrire ceux qui visent les protocoles de routage.

Il n'y a pas d'analyse spécifique de chaque protocole. Celle pour BGP est déà fournie par le RFC 4272. Notre RFC, au contraire, décrit des attaques génériques, avec l'espoir que des solutions génériques puissent être développées.

Comme dans toute bonne analyse de sécurité, notre RFC commence par une analyse des attaquants, de leurs motivations et de leurs capacités. Puis il décrit les conséquences possibles des différentes attaques (du DoS jusqu'au détournement de trafic vers une machine qui pourra alors s'insérer dans une communication qui ne lui était pas destinée). Enfin, la section 4 en arrive aux actions du méchant : par exemple, la falsification des données de routage, pour annoncer des routes qu'il ne gère normalement pas.


Téléchargez le RFC 4593


L'article seul

RFC 4592: The Role of Wildcards in the Domain Name System

Date de publication du RFC : Juillet 2006
Auteur(s) du RFC : E. Lewis
Chemin des normes
Première rédaction de cet article le 19 février 2007


La norme DNS avait prévu le cas des jokers (wildcards), des enregistrements DNS qui répondaient à toutes les questions. Ces jokers ont été une telle source de confusion pour les versions successives des protocoles DNS qu'il a fallu faire un RFC de clarification.

L'idée parait simple a priori. Si une zone DNS mondomaineamoi.example contient des enregistrements comme :

*    IN   A    192.0.2.42

alors, toute requête pour l'adresse IP absolumentnimportequoi.mondomaineamoi.example renverra 192.0.2.42. Cette fonction a été surtout mise en cause pour des raisons politiques (son utilisation par Verisign dans l'affaire des jokers de .com) mais elle a aussi des lourdes conséquences techniques : tous les protocoles bâtis sur le DNS (et il y en a beaucoup, en raison du succès du DNS) doivent gérer le cas particulier des jokers.

Par exemple, notre RFC note un problème dans le RFC 2782 sur l'enregistrement SRV, qui laisse entendre (et c'est une erreur fréquente) qu'un joker, comme dans le shell Unix, est interprété même s'il se trouve au milieu d'un nom (ce n'est pas le cas).

Une des victimes de cette confusion a été DNSSEC et c'est dans le cadre du travail sur ces extensions de sécurité du DNS qu'est apparue la nécessité de clarifier la norme sur ce point.

Disons-le tout de suite, notre RFC de clarification n'est pas un travail pédagogique. Son rôle est normatif, il vise à rendre la spécification des jokers moins ambigüe, pas à la rendre plus claire. Le texte est donc très abstrait et nécessite une connaissance détaillées des RFC 1034 et RFC 1035 et de leur vocabulaire.


Téléchargez le RFC 4592


L'article seul

RFC 4589: Location Types Registry

Date de publication du RFC : Juillet 2006
Auteur(s) du RFC : H. Schulzrinne (Columbia University), H. Tschofenig (Siemens)
Chemin des normes
Première rédaction de cet article le 17 juillet 2006
Dernière mise à jour le 25 février 2021


L'IETF s'occupe de tout : voici un RFC pour normaliser les noms de lieux. Le but est d'exprimer de manière standardisée l'endroit où se trouve un appareil mobile, de façon à pouvoir changer son comportement (par exemple, un téléphone mobile s'abstiendra de sonner s'il est dans un place-of-worship, A religious site where congregations gather for religious observances, such as a church, chapel, meetinghouse, mosque, shrine, synagogue, or temple.)

La mobilité étant à la mode, de plus en plus d'appareils sont capables de savoir où ils sont. Par exemple, avec un récepteur de position via des satellites (comme le système GPS), l'appareil peut connaitre sa latitude et sa longitude. Mais cela ne lui dit pas comment il doit se comporter. Pour cela, il a besoin d'une information différente. Or, si la manière d'exprimer la longitude et la latitude est normalisée depuis longtemps, celle d'indiquer le type de lieu où on se trouve ne l'était pas.

C'est chose faite avec ce RFC, qui décrit des termes standards, conçus pour être automatiquement traités (et donc pas affichés à un humain). On y trouve airport, hospital mais aussi bar (qui est distinct de cafe), ces termes n'étant pas exclusifs (on peut être en même temps dans restaurant, airport et public).

L'ensemble des types possibles de lieux est dans un registre IANA, et on peut en ajouter des nouveaux par la procédure « Examen par un expert » (RFC 8126).


Téléchargez le RFC 4589


L'article seul

RFC 4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)

Date de publication du RFC : Novembre 2006
Auteur(s) du RFC : M. Johnston (Intel), S. Venaas (UNINETT)
Pour information
Première rédaction de cet article le 17 décembre 2006


DHCP est une technique très utilisée pour distribuer à des postes clients, non seulement une adresse IP, mais également beaucoup d'autres informations. Ce RFC précise comment utiliser les options DHCP pour transmettre l'identité PXE.

DHCP est un immense succès, très répandu aujourd'hui dans de nombreux environnements. Un simple poste client, non géré comme un serveur, reçoit presque toujours son adresse IP, l'adresse de ses serveurs de noms ou de ses serveurs de temps par DHCP. Ce protocole, spécifié dans le RFC 2131 permet de passer des options supplémentaires (RFC 2132) telles que celles listées ci-dessus.

Notre RFC spécifie une nouvelle option, qui permet aux clients de passer trois nouvelles options, liées au système PXE. Par exemple, l'option Client Machine Identifier permet au client d'indiquer son nom (s'il est configuré dans un support fiable comme une mémoire Flash), de manière plus fiable et plus pérenne que la méthode classique d'examen de l'adresse MAC.


Téléchargez le RFC 4578


L'article seul

RFC 4504: SIP Telephony Device Requirements and Configuration

Date de publication du RFC : Mai 2006
Auteur(s) du RFC : H. Sinnreich (pulver.com), S. Lass (Verizon), C. Stredicke (Snom)
Pour information
Première rédaction de cet article le 29 juin 2006


Le succès de SIP dans le monde de la téléphonie sur IP a entrainé une floraison de RFC sur le sujet (seize aujourd'hui). L'implémenteur de SIP a de plus en plus de mal à s'y retrouver, d'où ce RFC d'information, qui regroupe en un endroit toutes les informations nécessaires pour le réalisateur d'un téléphone SIP.

Il existe plusieurs sortes de clients SIP (on dit UAC pour User Agent Client). Il y a des téléphones traditionnels, des PDA améliorés, mais aussi des soft phones, des téléphones entièrement logiciels, tournant sur un PC ordinaire.

Les règles de notre RFC s'appliquent à tous : des plus triviales aux plus essentielles, notre RFC liste 93 obligations pour les téléphones SIP, à la fois pour assurer l'interopérabilité et pour être sûr que leur utilisateur bénéficie d'un minimum de fonctions.

Par exemple, l'obligation 40 est que le téléphone doit pouvoir être mis dans un mode "muet", pour ne pas déranger l'entourage (par contre, il n'est pas nécessaire de transmettre cette information au réseau avant l'appel).

Autre exemple, l'obligation 92 dit que le téléphone SIP doit pouvoir appeler un URI SIP (de façon à éviter qu'ENUM devienne une obligation). Cela lui impose un clavier ou dispositif équivalent.


Téléchargez le RFC 4504


L'article seul

RFC 4501: Domain Name System Uniform Resource Identifiers

Date de publication du RFC : Mai 2006
Auteur(s) du RFC : S. Josefsson (SJD)
Chemin des normes
Première rédaction de cet article le 11 février 2007


Il existe des URI pour tout, pourquoi pas pour le DNS ? C'est ce que fait notre RFC, qui normalise un schéma d'URI pour représenter les enregistrements du DNS.

Traditionnellement, les enregistrements distribués par le DNS étaient représentés via une syntaxe (incomplètement) décrite dans le RFC 1034 :

www.bortzmeyer.fr.   IN   A   192.0.2.1

Cette syntaxe est simple et très répandue. Depuis le développement du Web, la syntaxe des URI est devenue la syntaxe de référence de toute ressource Internet. D'où ce court RFC qui spécifie comment désigner la clé d'un enregistrement, le tuple (nom de domaine, classe, type), par un URI :

dns:www.bortzmeyer.fr?class=IN;type=A

Notre RFC normalise également plusieurs options, par exemple pour interroger un serveur de noms précis, ici 192.0.2.33 :

dns://192.0.2.33/www.bortzmeyer.fr?class=IN;type=A

Il ne reste plus qu'à modifier dig pour utiliser cette nouvelle syntaxe et permettre dig dns://192.0.2.33/www.bortzmeyer.fr?class=IN;type=A à la place de l'actuel dig @192.0.2.33 A www.bortzmeyer.fr..


Téléchargez le RFC 4501


L'article seul

RFC 4472: Operational Considerations and Issues with IPv6 DNS

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : A. Durand (Comcast), J. Ihren (Autonomica), P. Savola (CSC/Funet)
Pour information
Première rédaction de cet article le 10 mai 2006


Le déploiement du protocole IPv6 est une opération de grande ampleur, qui n'a jamais eu d'équivalent sur Internet, et qui met en cause beaucoup de choses. Les normes qui spécifient le protocole ont donc intérêt à être accompagnées de documents comme notre RFC, qui résume les questions spécifiquement DNS pour IPv6.

Programmer des services IPv6 ou bien les déployer nécessite de lire beaucoup de RFC, si on veut connaitre toutes les normes applicables. Il est donc utile d'avoir des documents d'information comme notre RFC, qui fournit un point d'entrée unique sur les questions DNS qui se posent à IPv6.

Le RFC traite, entre autres, les points suivants :

  • Représentation des adresses IPv6 dans le DNS, y compris des catégories d'adresses spécifiques à IPv6 comme les adresses link-local,
  • Mauvais comportement de certains serveurs DNS (détaillé plus loin),
  • Recommandations pour le nommage (un enregistrement IPv6 et un IPv6 pour www.bortzmeyer.org ou bien seulement un IPv4 et le IPv6 pour www.ipv6.bortzmeyer.org ?),
  • Recommandations pour les résolveurs IPv6,
  • Recommandations pour la mise à jour des zones droites (traduction de noms en adresses) et inverses (traduction d'adresses en noms via le domaine ip6.arpa).

Le problème des serveurs incorrects (déjà discuté dans le RFC 4074) est une des plaies d'IPv6. En effet, beaucoup de serveurs DNS ne répondent pas correctement lorsqu'ils reçoivent des requêtes de type AAAA (adresses IPv6, les adresses IPv4 étant dans des enregistrements de type A) ; ils ne répondent pas ou, pire, ils répondent que le domaine n'existe pas, même s'il a des enregistrements d'autres types (le bon comportement serait de renvoyer une réponse vide : ne pas avoir un enregistrement DNS d'un type donné n'est pas une erreur).

Ces serveurs incorrects sont souvent des appliances, boîtes fermées, non documentées et non gérées, qu'il est très difficile de mettre à jour une fois qu'elles ont été déployées. Un résolveur IPv6 peut donc être obligé, en violation des normes, d'ignorer une réponse négative et de reessayer avec un autre type d'enregistrements.

Enfin le RFC rappelle que le transport utilisé pour atteindre le serveur de noms (IPv4 ou IPv6) n'a pas de rapport avec le type de données demandé : en effet, une machine qui interroge le DNS en IPv4 peut parfaitement être capable de faire de l'IPv6 et réciproquement. En outre, le client que voit le serveur DNS n'est en général pas le client final mais son cache récursif local. Ce serait donc une erreur de renvoyer préferentiellement des enregistrements A (IPv4) si la question arrive en IPv4.


Téléchargez le RFC 4472


L'article seul

RFC 4471: Derivation of DNS Name Predecessor and Successor

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : G. Sisson (Nominet), B. Laurie (Nominet)
Expérimental
Première rédaction de cet article le 25 septembre 2006
Dernière mise à jour le 27 septembre 2006


Le protocole DNSSEC, censé sécuriser le DNS a, tel qu'il est normalisé dans le RFC 4033 un gros défaut : il permet d'énumerer tous les domaines d'une zone signée. C'est cette faille que tente de résoudre notre RFC.

Pour permettre à un serveur DNSSEC de signer la non-existence d'un domaine, le RFC 4033 a normalisé l'enregistrement NSEC. Celui-ci dit "il n'y a aucun domaine avant XYZ.example" où XYZ est le label suivant celui demandé. "Suivant" est défini comme "suivant dans l'ordre alphabétique". Le gros problème de cette approche est qu'elle permet ainsi à un attaquant d'obtenir tous les domaines de la zone, par chaînage. C'est ainsi que Simon Josefsson a développé un programme de zone walking qui montre bien la vulnérabilité des zones DNSSEC. Muni du contenu de la zone, un attaquant peut ensuite utiliser whois ou un système équivalent pour obtenir des renseignements à des fins de spamming ou bien de harcèlement juridique. Le registre britannique, Nominet, avait ainsi refusé de déployer DNSSEC.

Certains, sans avoir suffisamment réfléchi au problème, disent "mais les données de la zone sont publiques, de toute façon", oubliant ainsi que l'obtention de la zone entière (ce que permet le zone walking) est autrement plus dangereux que la posisbilité d'interroger la zone sur quelques noms choisis : c'est bien pour cela que les registres ne distribuent par leur zone (cas de .fr ou en tout cas pas gratuitement (cas de Verisign).

Notre RFC s'attaque à ce problème en redéfinissant le mot "suivant". Il spécifie un algorithme qui permet d'obtenir un nom suivant ou précédant celui demandé, sans permettre d'utiliser ce nom suivant ou précédant pour obtenir d'autres noms. Le nom "suivant" ou "précédant" n'est pas vraiment lisible (de nombreux exemples figurent dans le RFC) mais est suffisant pour les besoins de DNSSEC.

Kim Minh Kaplan a mis en œuvre notre RFC, en Common Lisp. Son code peut être récupéré avec darcs :

darcs get http://www.kim-minh.com/src/cl-dnssec
cd cl-dnssec 
make

et ensuite exécuté ainsi :

%  ./rfc4471 -- P foobar.example.org. example.org.   
P(foobar.example.org., example.org.) = \255{49}.\255{63}.\255{63}.foobaq\255{57}.example.org.

Téléchargez le RFC 4471


L'article seul

RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : P. Savola (CSC/Funet)
Pour information
Première rédaction de cet article le 12 juin 2006


Les problèmes liés à la MTU des liens Internet empoisonnent la vie des administrateurs du réseau et parfois de ses utilisateurs. Ce RFC étudie en détail un cas particulier, celui des tunnels qui, en réduisant la MTU, requièrent des mesures comme la fragmentation (le découpage d'un paquet de données en paquets plus petits).

Si tous les liens utilisés pour les connexions Internet avaient la même MTU, tout irait bien. Mais ce n'est pas le cas et il faut donc, soit détecter la MTU maximale du chemin (PMTU pour Path MTU), soit laisser les routeurs fragmenter les paquets en paquets plus petits (le RFC décrit aussi d'autres solutions, moins communes).

Aucune solution n'est parfaite et le RFC explique bien pourquoi, par exemple parce que certains coupe-feux bloquent (stupidement) l'ICMP. Chacun des cas est étudié en détail, mais aucune solution générale ne semble possible dans l'Internet actuel. Cette réflexion a fini par mener à un tout nouveau mécanisme, décrit dans le RFC 4821.

(Un excellent article très complet sur la question est A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation.)


Téléchargez le RFC 4459


L'article seul

RFC 4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : T. Bates (Cisco), E. Chen (Cisco), R. Chandra (Sonoa)
Chemin des normes
Première rédaction de cet article le 18 mai 2006


Une mise à jour du RFC 2796, notre RFC spécifie comment connecter des routeurs BGP sans avoir à configurer chaque couple de routeur, en utilisant un routeur spécial, le route reflector.

L'un des principes de base du protocole BGP (décrit dans le RFC 4271) est que des routeurs iBGP, c'est à dire Internal BGP, à l'intérieur d'un même système autonome doivent être tous reliés entre eux, pour avoir la même information. Si on n'a que trois routeurs dans le système autonome, c'est facile. Si on en a cent, cela fait dix mille sessions à configurer : cela ne passe pas à l'échelle.

Notre RFC explique donc comment utiliser un ou deux routeurs pour distribuer à tous les autres l'information de routage. Il n'y a donc plus qu'à configurer cent sessions, depuis chaque routeur du système autonome vers le route reflector. Cela ne nécessite que des changements de détail au protocole BGP, changements qui sont depuis longtemps intégrés dans les mise en œuvre de BGP (puisque notre RFC n'est qu'une mise à jour du RFC 2796, qui datait d'avril 2000).

Le route reflector ne fait que distribuer les routes, il ne route pas les paquets IP. Sa seule fonction est de routing, pas de forwarding.

On notera que le terme de route server, lui, désigne en général un routeur BGP qui assure cette même fonction de redistribution des routes, mais entre systèmes autonomes différents (eBGP pour External BGP), par exemple sur un point d'échange (voir le RFC 7947).


Téléchargez le RFC 4456


L'article seul

RFC 4452: The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : H. Van de Sompel (LANL), T. Hammond (NPG), E. Neylon (Manifest Solutions), S. Weibel (OCLC)
Pour information
Première rédaction de cet article le 10 avril 2006


La guerre des identificateurs, entre les multitudes de solutions qui existent pour désigner les choses de manière unique, ne connait pas de répit : ce RFC propose encore un nouveau schéma, qui vise surtout à faire converger des espaces de nommage existants vers les URI.

On le sait, si on veut désigner une ressource, que ce soit un livre, une page Web ou une personne, il existe beaucoup de solutions concurrentes, des URL aux DOI en passant par les identifiants EPC de RFID. N'y a t-il pas assez de solutions différentes ? Non, ont pensé les auteurs de notre RFC qui viennent de proposer un nouveau schéma pour les URI : info:.

Ces nouveaux URI visent à « récupérer » les espaces de nommage existants comme la classification Dewey ou bien PubMed. En les préfixant du schéma info:, suivi d'un identifiant de l'espace de nommage, on transforme ainsi tous ces vénérables identificateurs en URI.

On verra ainsi peut-être demain des identificateurs comme info:pmid/12376099 (PMID désigne PubMed et vous pouvez chercher ce numéro au NCBI) ou comme info:ddc/22/eng//641.57 (DDC est la classification Dewey).

Ces URI ne sont pas forcément résolvables en une ressource accessible via le réseau et le RFC note qu'ils ne sont pas non plus forcément permanents. Les URI de info: ne sont donc pas forcément directement concurrents des URL (qui sont toujours résolvables) ou des URI tag: du RFC 4151 qui sont toujours permanents. Alors que les tag: utilient le système des noms de domaine, les info: cherchent simplement à sauver les espaces de nommage traditionnels.

Enfin, le RFC attribue la gestion du registre de info au NISO. Bien qu'il existe de nombreux espaces de noms « pré-Internet » dans le monde, c'est donc un organisme états-unien qui les gérera tous.


Téléchargez le RFC 4452


L'article seul

RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

Date de publication du RFC : Mars 2006
Auteur(s) du RFC : A. Conta (Transwitch), S. Deering (Cisco), M. Gupta (Tropos)
Chemin des normes
Première rédaction de cet article le 17 octobre 2010


Il y a un protocole peu connu dans le monde IP, c'est ICMP. Situé dans les couches basses, il ne sert pas directement aux applications, à part à ping, avec qui il est souvent confondu (c'est ainsi que pas mal de blaireaux administrateurs d'un pare-feu bloquent tout ICMP parce qu'ils se disent qu'il n'ont pas besoin de ping). ICMP pour IPv4 était normalisé dans le RFC 792 et la version (très proche) qui sert pour IPv6 était dans le RFC 2463, désormais remplacé par notre RFC 4443.

En quoi consiste ICMP ? Techniquement parlant, il est situé au dessus d'IP dans le modèle en couches, son champ Next Header portant le numéro 58. Mais, en fait, ce protocole est une partie intégrante d'IP. Il sert à transporter les messages liés au fonctionnement d'IP, par exemple à prévenir si un routeur ne peut plus acheminer les paquets car il n'a plus de route pour cette destination, ou bien à prévenir qu'un paquet est trop gros pour la MTU du lien suivant. ICMP v6 sert aussi à bâtir d'autres protocoles, comme NDP (RFC 4861), qui utilise des messages ICMP pour permettre la découverte d'une machine voisine sur le réseau local. ICMP faisant partie intégrante d'IP (cf. section 2), ce RFC 4443 fait donc partie des lectures indispensables pour qui veut comprendre la version 6 d'IP.

Le format des messages ICMP v6 est en section 2.1. Après l'en-tête IPv6 et zéro, un ou plus en-têtes d'extension (par exemple pour la fragmentation) arrive la partie purement ICMP, introduite par un champ Next Header valant 58. Les trois champs communs à tout paquet ICMP sont ensuite le type (huit bits), le code (huit bits) et une somme de contrôle (seize bits, définie en section 2.3). Voici comment Wireshark le représente en C :

struct icmp6_hdr {
	guint8	icmp6_type;	/* type field */
	guint8	icmp6_code;	/* code field */
	guint16	icmp6_cksum;	/* checksum field */
	union {
		guint32	icmp6_un_data32[1]; /* type-specific field */
		guint16	icmp6_un_data16[2]; /* type-specific field */
		guint8	icmp6_un_data8[4];  /* type-specific field */
	} icmp6_dataun;
};

Comme l'indiquent les commentaires dans le source de Wireshark, le format des données dépend du type. Il y a deux catégories de types, ceux qui indiquent une erreur (de 0 à 127) et les autres. Il existe de nombreux types possibles (stockés dans un registre IANA, cf. section 6). Parmi ceux définis directement par ce RFC, pour vous donner une idée :

  • 1 est envoyé par un routeur lorsque la destination n'est pas joignable,
  • 2 indique un paquet trop gros pour la MTU,
  • 3 indique que le nombre de routeurs traversé a atteint une limite (il est donc utilisé par traceroute) : on notera que le RFC l'appelle « Time exceeded », comme en IPv4, alors que le champ correspondant du paquet n'est officiellement plus un TTL en IPv6 mais un nombre de routeurs (hop count),
  • 100 et 101 sont réservés pour des expérimentations,
  • 128 (qui n'est donc pas une erreur, puisque > 127) est la demande d'un écho et 129 la réponse. Ce sont donc les deux types utilisés par ping.

Notez que les valeurs ne sont pas du tout les mêmes qu'en IPv4, même lorsque la sémantique est la même.

Le format détaillé figure en section 3. Ainsi, lorsque le type est 1 (Destination unrechable), le code indique la raison pour laquelle la dite destination était injoignable : 0 pour « aucune route disponible », 1 pour « interdit » (par un pare-feu), 3 pour « machine injoignable » (on est sur le bon réseau mais la machine de destination ne répond pas), etc. traceroute traduit ces codes en lettres précédées d'un ! donc respectivement !N, !X et !H.

Le cas du type 2, « paquet trop gros » (section 3.2) est intéressant car les routeurs IPv6, contrairement à leurs frères IPv4, n'ont pas le droit de fragmenter. La source doit donc prendre garde de ne pas générer des paquets plus gros que la MTU du chemin (cf. RFC 1981) et, pour cela, a besoin de ces paquets ICMP de type 2 (qui comprennent, après les trois champs génériques, un champ de 32 bits indiquant la MTU du prochain lien). Hélas, beaucoup de pare-feux sont gérés par des ignorants et bloquent tout l'ICMP. Ces paquets n'arrivent donc pas à la source et celle-ci ne peut plus ajuster la taille des paquets. C'est un des problèmes réseau les plus courants avec IPv6, que l'on voit dès que la MTU est inférieure aux traditionnels 1500 octets, par exemple parce qu'il y a un tunnel sur le trajet.

Les paquets liés à la fonction écho comprennent quant à eux un identificateur et un numéro de séquence (sections 4.1 et 4.2), de seize bits chacun. Copiés automatiquement dans la réponse, ils servent à mettre en correspondance une réponse avec une question (au cas où plusieurs utilisateurs d'une machine se servent de ping en même temps).

Quelle adresse IP source doit être utilisée lorsqu'un équipement IPv6 génère un paquet ICMP ? La section 2.2 est claire : si le paquet ICMP répond à un message qui était adressé personnellement à la machine (cas d'un ping), l'adresse source doit être celle à qui était adressé le message. Sinon (cas d'un routeur qui doit traiter un paquet qui ne lui est pas destiné), l'adresse source doit être une adresse unicast du routeur émetteur.

Reprenant les principes du RFC 1122, notre RFC spécifie, en section 2.4, les règles à suivre lors du traitement de paquets ICMP. Ainsi, les messages d'information de type inconnu doivent être ignorés (pour permettre leur introduction ultérieure sans rien casser). Comme en IPv4, un équipement IPv6 ne doit jamais répondre à un message ICMP d'erreur (pour éviter les boucles). Les messages d'erreur à propos d'un paquet doivent inclure autant d'octets que possible du paquet original sans toutefois dépasser les 1260 octets qui sont le minimum qu'un réseau doit accepter pour faire de l'IPv6 (cette règle est plus stricte que la règle IPv4 originale qui n'imposait pas de remplir le paquet au maximum). Autre point où ICMP v6 diffère, la limitation du nombre de paquets ICMP émis est obligatoire, pour éviter certaines attaques où le méchant convainc un routeur de générer des paquets ICMP en rafale. La méthode recommandée pour ce rate-limiting est le seau qui fuit. Les méthodes simplistes (du genre « un paquet émis toutes les N milli-secondes »), qui ne peuvent pas faire face à du trafic très variable (comme celui de traceroute) sont par contre déconseillées. Les paramètres du seau devraient être configurables (Linux permet apparemment cette configuration mais je n'ai pas regardé la documentation du paramètre sysctl net.ipv6.icmp.ratelimit, qui vaut 1000 par défaut, mais 1000 quoi ?).

Contrairement au RFC 792 sur ICMP v4, qui ne disait pas un mot sur la sécurité, notre RFC 4443, écrit à une époque plus sensible, consacre une section, la 5, à ces questions. Elle rappelle qu'il n'y a aucune authentification des paquets ICMP et qu'il ne faut donc pas agir aveuglément sur la base d'un paquet ICMP reçu. On peut toujours, prétend le RFC, utiliser IPsec pour les authentifier mais très peu de gens font cela. À part IPsec, solution peu réaliste aujourd'hui, notre RFC recommande des tests de validité (ou, plus exactement, de vraisemblance) pratiqués par les protocoles de transport, comme ceux du RFC 5927.

Depuis la précédente version, le RFC 2463, ICMP v6 a subi plusieurs changements, résumés dans l'annexe A. Parmi eux, le champ de 32 bits dans les messages d'erreur, après les trois champs génériques, même lorsqu'il est inutilisé (cas le plus fréquent), afin de permettre de le sauter facilement, même avec les types inconnus, pour accéder à la copie du paquet original. On note aussi la réservation de types pour des expérimentations.


Téléchargez le RFC 4443


L'article seul

RFC 4436: Detecting Network Attachment in IPv4 (DNAv4)

Date de publication du RFC : Mars 2006
Auteur(s) du RFC : B. Aboba (Microsoft), J. Carlson (Sun), S. Cheshire (Apple)
Chemin des normes
Première rédaction de cet article le 27 juin 2006


Plusieurs protocoles permettent à une machine d'obtenir une adresse IPv4, par exemple DHCP ou bien le protocole des adresses Link-Local décrit dans le RFC 3927. Mais notre RFC est le premier qui s'attache à décrire leurs interactions, surtout lorsque la machine change de réseau et doit détecter ce changement le plus vite possible, pour réacquérir une nouvelle adresse.

Le principe de DNA (Detecting Network Attachment) est simplement d'envoyer une requête ARP au dernier routeur connu. Contrairement à la requête ARP classique, le client DNA n'utilise pas la diffusion mais envoie un paquet unicast. S'il reçoit une réponse, et qu'elle a bien l'adresse MAC source attendue, tout est bon.

Ainsi, la machine qui vient de changer de réseau ou qui soupçonne que cela a pu être le cas (ce qui est courant en Wi-Fi où la connectivité va et vient), peut très rapidement vérifier que son adresse IP marche toujours. DNA n'est pas indispensable, ce n'est qu'une optimisation (et qui n'est acceptable que pour les adresses allouées par DHCP), mais qui aidera beaucoup les machines dont la liaison avec le réseau n'est pas réellement permanente.


Téléchargez le RFC 4436


L'article seul

RFC 4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record

Date de publication du RFC : Février 2006
Auteur(s) du RFC : M. Andrews (ISC), S. Weiler (SPARTA)
Intérêt historique uniquement
Première rédaction de cet article le 3 novembre 2006
Dernière mise à jour le 14 novembre 2007


L'une des faiblesses les plus souvent citées du DNS est son manque de sécurité. Pour authentifier les données servies, le protocole DNSSEC a été développé, dans les RFC 4033 et suivants. Notre RFC vient d'ajouter un nouveau type de données, pour indiquer une racine de signature différente de la "vraie" racine. (Notez que ce RFC a ensuite été ramené à la catégorie « Intérêt historique seulement », en novembre 2019, et que DLV est donc abandonné depuis, voir le RFC 8749.)

DNSSEC calque sa structure sur celle du DNS : hiérarchique, avec une racine, gérée par le gouvernement des États-Unis, via l'IANA. Normalement, la racine est signée par l'IANA, qui signe les délégations des TLD qui à leur tour signent les délégations des titulaires de noms de domaine. (Ces délégations apparaissent dans les enregistrements de type DS - Delegation Signer.)

Mais cette hiérarchie pose des problèmes : que faire si l'IANA, par exemple parce que l'ICANN est bloquée par des problèmes politiciens, ne veut ou ne peut pas signer la racine ? (Aujourd'hui, la seule racine du DNS signée l'est en PGP et par Verisign, l'opérateur à qui le gouvernement états-unien a délégué la gestion technique de la racine. Elle est accessible en ftp://rs.internic.net/domain/root.zone.gz, la signature étant dans le même répertoire.)

D'ou l'idée de base de DLV (DNSSEC Lookaside Validation) : dissocier la racine du DNS et la racine de signature DNSSEC. Avec DLV, on peut créer une racine de signature en, par exemple, dlv.isc.org et la peupler d'enregistrements DLV. Si les résolveurs DNS sont configurés pour les chercher là, DNSSEC marchera bien et on aura contourné le problème policitien.

Les enregistrements DS sont donc remplacés par des DLV, spécifiés dans notre RFC, et qui ont exactement le même format. BIND les met en œuvre depuis la version 9.3.2 et 9.4.0. Voici un exemple de récupération de DLV avec dig :


% dig DLV sources.org.dlv.isc.org.  

; <<>> DiG 9.5.0-P2 <<>> DLV sources.org.dlv.isc.org.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30687
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sources.org.dlv.isc.org.       IN      DLV

;; ANSWER SECTION:
sources.org.dlv.isc.org. 3600   IN      DLV     22107 5 2 AF12A23DFBCDB5609DCEC2C2FBD3CD65AEEFE49CBE0751C65C71C983 986B7DE5
sources.org.dlv.isc.org. 3600   IN      DLV     14347 3 2 0D5D5B209264BBA5EDAEC9B95843901073BF27F01702B144FFC1389D 747DAB7F
...

À noter que notre RFC normalise un format de données, pas la façon de l'utiliser. C'est l'objet du RFC 5074 qui, entre autres, décrit ce qui se passe si deux racines DLV coexistent, peut-être pour des parties différentes du DNS.


Téléchargez le RFC 4431


L'article seul

RFC 4423: Host Identity Protocol (HIP) Architecture

Date de publication du RFC : Mai 2006
Auteur(s) du RFC : R. Moskowitz (ICSA Labs), P. Nikander (Ericsson)
Pour information
Réalisé dans le cadre du groupe de travail IETF hip
Première rédaction de cet article le 29 mai 2006
Dernière mise à jour le 21 avril 2008


Voici un RFC très ambitieux : il s'agit tout simplement de changer radicalement l'architecture de l'Internet en utilisant un nouveau type d'identificateur, le Host Identifier (HI) pour beaucoup d'usages qui sont actuellement ceux des adresses IP.

Une adresse IP sert actuellement à deux choses : désigner une machine (l'adresse IP sert par exemple à distinguer plusieurs connexions en cours) et indiquer comment la joindre (routabilité). Dans le premier rôle, il est souhaitable que l'adresse soit relativement permanente, y compris en cas de changement de FAI ou de mobilité (actuellement, si une machine se déplace et change d'adresse IP, les connexions TCP en cours sont cassées). Dans le second cas, on souhaite au contraire une adresse qui soit le plus "physique" possible, le plus dépendante de la topologie. Ces deux demandes sont contradictoires. (HIP est depuis normalisé dans un RFC plus récent, le RFC 9063.)

HIP résout le problème en séparant les deux fonctions. Avec HIP, l'adresse IP ne serait plus qu'un identifiant "technique", ne servant qu'à joindre la machine, largement invisible à l'utilisateur et aux applications (un peu comme une adresse MAC aujourd'hui).

Pour pouvoir être vérifié, le nouvel identificateur, le HI sera une clé publique cryptographique, qui sera allouée hiérarchiquement par PKI ou de manière distribuée par tirage au sort (comme le sont les clés SSH ou PGP aujourd'hui).

Cette séparation de l'identificateur et du localisateur est un sujet de recherche très actif actuellement et d'autres propositions que HIP existent.

Soyons patients : si la spécification du protocole est désormais publiée (notre RFC ne décrivait qu'une architecture générale, il est complété par les RFC 5201, RFC 5202, RFC 5203, RFC 5204, RFC 5205, RFC 5206 et RFC 5207, on peut consulter les projets sur la page Web du groupe de travail HIP) et, si des implémentations expérimentales existent déjà et que des serveurs publics utilisent HIP, aucun déploiement significatif n'est encore en vue. (Depuis, HIP v1 a été remplacé par HIP v2, normalisé dans le RFC 7401, puis dans le RFC 9063.)


Téléchargez le RFC 4423


L'article seul

RFC 4417: Report of the 2004 IAB Messaging Workshop

Date de publication du RFC : Février 2006
Auteur(s) du RFC : P. Resnick (IAB), P. Saint-Andre (JSF)
Pour information
Première rédaction de cet article le 29 mars 2006


Ce RFC est simplement le compte-rendu (fort tardif) d'un séminaire que l'IAB a organisé en octobre 2004 pour examiner, de haut, le statut des solutions de messagerie sur Internet et les recherches souhaitables pour l'améliorer.

Le séminaire associait à la messagerie par courrier électronique les techniques de messagerie instantanée et, même, dans une certaine mesures, certains aspects des blogs.

En effet, la messagerie, comme les autres applications de l'Internet, n'a pas été conçue en chambre : elle a évolué dans le monde réel, s'ajustant, s'étendant, se modifiant, sans schéma directeur bien précis. D'un côté, c'est ce qui a permis son succès, alors que les schémas géniaux d'organisations plus rigides que l'IETF ne connaissaient aucun succès. De l'autre, l'état actuel de la messagerie est celui d'un empilement de diverses techniques, avec peu de principes d'architecture, et qui est menacé par des phénomènes anti-sociaux comme le spam.

Le spam n'était pas un sujet de ce séminaire en tant que tel : les sujets couverts étaient de plus haut niveau, portant sur des principes d'architecture et cherchant à savoir dans quelle direction la recherche devrait se porter. Les sujets étaient :

  • Autorisation : comment un destinataire peut-il simplement et de façon sûre autoriser les envois vers sa boîte ? Les systèmes de réputation sont-ils l'avenir ? Les participants au séminaire ont recommandé leur étude.
  • Multiplicité des canaux de communication : si une conversation commence par courrier et se termine en Jabber, comment marquer les deux échanges pour voir qu'il s'agit de la même conversation ? Par exemple, dans le RFC 2822, les références au sein d'un fil de discussion sont uni-directionnelles, il faudrait étudier des systèmes plus riches.
  • Négociation: par exemple comment décider des options de vie privée avant une conversation (enregistrement ou pas) ?
  • Contrôle par l'utilisateur : un exemple typique est le filtrage du courrier. Que peut apporter l'architecture de la messagerie pour rendre ce filtrage plus efficace et plus simple ? Le langage Sieve est cité comme base possible pour des règles plus puissantes.
  • Transport des messages : transport fiable ou non-fiable mais avec réémission ? Les participants souhaitent le développement de techniques permettant de faire voyager les différentes parties d'un message sur des transports différents. Par exemple, la vidéo contenue dans un message pourrait passer sur un transport moins fiable mais moins coûteux.
  • Identité : notamment comment associer des clés cryptographiques à une identité ? DNSSEC semble l'outil préféré pour cette distribution.

La question des identifiants est souvent revenue dans le séminaire : toutes ces techniques nécessiteront des identifiants uniques et stables.


Téléchargez le RFC 4417


L'article seul

RFC 4409: Message Submission for Mail

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : R. Gellens (Qualcomm), J. Klensin
Chemin des normes
Première rédaction de cet article le 26 juin 2006


Pendant longtemps, le système de courrier électronique de l'Internet ne faisait aucune différence entre le serveur de messagerie et le simple PC de l'utilisateur. Tous utilisaient le même protocole SMTP, spécifié dans le RFC 2821. Depuis le RFC 2476 et plus encore depuis ce nouveau RFC, ce n'est plus vrai. Le simple PC doit désormais utiliser une autre solution, la soumission de message. (Ce RFC a depuis été mis à jour dans le RFC 6409.)

L'ancienne architecture était raisonnable à l'époque où toutes les machines connectées à l'Internet étaient de gros serveurs gérés par des professionnels. Ceux-ci pouvaient faire en sorte que tout soit correctement configuré. Et, donc les autres serveurs, les MTA pouvaient ériger en principe le "Pas touche" et ne jamais modifier ou contester un message reçu.

Aujourd'hui, avec le nombre de micro-ordinateurs non gérés qui sont connectés à Internet, cela n'est plus possible. Le RFC 2476 avait donc séparé les clients SMTP en deux catégories : les MTA qui se connectent au port traditionnel, le numéro 25 et les MUA qui, s'ils veulent envoyer en SMTP, doivent utiliser un autre service, tournant en général sur le port 587, et soumis à d'autres règles :

  • Le serveur est autorisé à modifier le message (par exemple en ajoutant des en-têtes comme Date ou Message-ID s'ils sont absents ou incorrects),
  • Une authentification est souvent requise, surtout si le port de soumission est accessible de tout l'Internet.

Notre RFC, qui remplace le RFC 2476, et a été lui-même remplacé par le RFC 6409, pose en principe que, désormais, les machines des simples utilisateurs devraient désormais utiliser ce service.

Si vous utilisez Postfix, vous pouvez lire un exemple de configuration de Postfix conforme (partiellement) à ce RFC.


Téléchargez le RFC 4409


L'article seul

RFC 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : M. Wong, W. Schlitt
Expérimental
Première rédaction de cet article le 10 mai 2006


On le sait, le courrier électronique, tel qu'il est spécifié dans les RFC 5321 et RFC 5322, ne fournit aucune authentification, même faible, de l'émetteur. Un expéditeur de courrier peut toujours prétendre être Jacques Chirac <president@elysee.fr> et il n'y a aucun moyen de l'en empêcher. SPF vise à diminuer cette facilité de frauder en permettant à un titulaire de nom de domaine de déclarer quelle(s) adresse(s) IP sont autorisées à envoyer du courrier pour ce domaine. (Ce RFC a depuis été remplacé par le RFC 7208.)

SPF dépend donc du DNS. Le principe de base est d'ajouter à sa zone DNS, par exemple bortzmeyer.eu, un enregistrement de type TXT (le SPF original) ou bien du nouveau type SPF (créé par notre RFC). Cet enregistrement déclare, dans un langage ad hoc, quelle(s) adresse(s) IP peuvent envoyer du courrier pour ce domaine. Par exemple, bortzmeyer.eu a "v=spf1 mx -all", ce qui veut dire en français que seuls les MX (les serveurs qui reçoivent le courrier) de ce domaine peuvent en émettre, le reste de l'Internet (all) est exclu.

Pour voir ces enregistrements SPF, on peut par exemple utiliser dig :

% dig +short TXT freebsd.org 
"v=spf1 ip4:216.136.204.119 ~all"
% dig +short TXT gentoo.org 
"v=spf1 mx ptr ?all"

On note que SPF, comme la plupart de ses concurrents, n'authentifie que le domaine, pas la personne émettrice (ce point, et plusieurs autres, est discuté en détail dans la section 10, « Sécurité » de notre RFC).

Authentifier le courrier électronique est plus compliqué qu'il ne semble au premier abord, en partie parce qu'il existe plusieurs identités possibles :

  • L'expéditeur de l'enveloppe (MAIL FROM de la session SMTP),
  • L'expéditeur des en-têtes, qui lui-même dépend de l'en-tête qu'on choisit (From: ? Sender: ? Une combinaison de plusieurs en-têtes comme l'algorithme PRA du RFC 4407 ?).

Les partisans de la première approche (celle de SPF) lisent le RFC 5321 et ceux de la seconde lisent plutôt le RFC 5322. Chacune a ses avantages et ses inconvénients.

La question de l'authentification du courrier électronique est très chaude. Les protocoles candidats, comme SPF, ont fait l'objet de nombreuses polémiques. C'est pourquoi l'IESG a collé un gros avertissement au début du RFC, bien que SPF soit, et de très loin, le plus testé des protocoles d'authentification (avec PGP, qui est dans une catégorie très différente).

En même temps que notre RFC a été publié le RFC 4406 sur Sender ID. SenderID, comme SPF, avait été discuté dans le défunt groupe de travail MARID de l'IETF, groupe qui avait été autoritairement dissous avant d'avoir atteint un consensus. Malgré le déploiement bien plus important de SPF, l'IESG a choisi de traiter les deux propositions de manière égale et de publier les deux RFC comme expérimentaux. Ce n'est qu'en 2012 que l'IETF est revenu sur cette décision et a décidé, dans le RFC 6686, que SPF était le net vainqueur sur ce créneau. SPF est désormais normalisé dans le RFC 7208, qui a remplacé notre RFC 4408.


Téléchargez le RFC 4408


L'article seul

RFC 4407: Purported Responsible Address in E-Mail Messages

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : J. Lyon (Microsoft)
Intérêt historique uniquement
Première rédaction de cet article le 17 mai 2006


Un très court RFC qui décrit l'algorithme PRA (Purported Responsible Address) qui permet de désigner un expéditeur à partir des en-têtes d'un message électronique. (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)

Il existe en effet plusieurs identités possibles pour l'émetteur d'un courrier : l'adresse indiquée par la commande MAIL FROM de SMTP (RFC 2821) ? Celle indiquée par le champ From: des en-têtes (RFC 2822) ? Aucune n'est idéale et le choix dépend de pas mal de considérations. (Meng Weng Wong, concepteur de SPF), fait remarquer que les gens du logiciel libre préfèrent l'identité SMTP et Microsoft préfère une identité extraite des en-têtes ; selon lui, c'est parce que le logiciel libre sur Unix domine dans le monde des MTA et Microsoft domine dans celui des MUA.)

Par exemple, un message envoyé sur la liste de diffusion des utilisateurs francophones de Debian contient :

MAIL FROM (SMTP) bounce-debian-user-french=stephane=sources.org@lists.debian.org
From: Demba COULIBALY <demcoul@yahoo.com>
To: debian-user-french@lists.debian.org
Resent-From: debian-user-french@lists.debian.org
Resent-Sender: debian-user-french-request@lists.debian.org

Quel est l'expéditeur ? Demba Coulibaly l'a écrit (et c'est typiquement l'expéditeur que va m'indiquer mon MUA) mais c'est une machine de Debian qui me l'a transmis, via le programme de gestion de listes de diffusion.

Or, tous les efforts d'authentification de l'émetteur d'un courrier dépendent de cette identité.

Notre RFC propose donc de ne pas utiliser le From: aveuglément mais de ne le prendre que s'il est seul, et d'utiliser Resent-From: ou Resent-Sender: s'ils sont présents. Je ne reprends pas l'algorithme ici, il figure dans le RFC mais il est de toute façon trivial (vous pouvez en voir une mise en œuvre en Python, par moi, PRA.py et une en Perl, par Mark Kramer, pra2.pl).

Ce RFC est un des produits du groupe de travail IETF maudit, MARID, qui avait tenté de créer une norme ouverte d'authentification du courrier électronique mais avait été fermé d'autorité avant d'être arrivé à un résultat. Les documents survivants ont été publiés avec un gros avertissement de l'IESG, qui, dans le cas de notre RFC, met en garde contre le fait que l'algorithme PRA ne marche pas pour la plupart des listes de diffusion (la liste Debian, citée plus haut, n'a pas de problèmes).

Une des raisons de la crise du groupe de travail MARID était le fait que PRA est plombé par un brevet de Microsoft. Beaucoup refusaient de normaliser une technologie où il aurait fallu obtenir une licence, même gratuite, de la part d'une grosse société dominante.

Mais PRA illustre aussi à quel point le système des brevets est délirant et a échappé à tout contrôle : l'algorithme PRA est trivial, il tient en quelques lignes de Perl ou de Python et il n'aurait jamais dû être brevetable. Il est scandaleux que les organismes de dépôt de brevet soient payés au nombre de brevets enregistrés, les encourageant ainsi à accepter des brevets futiles, comme celui sur PRA.


Téléchargez le RFC 4407


L'article seul

RFC 4406: Sender ID: Authenticating E-Mail

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : J. Lyon (Microsoft), M. Wong (pobox.com)
Intérêt historique uniquement
Première rédaction de cet article le 26 mai 2006


On le sait, le courrier électronique, tel qu'il est spécifié dans les RFC 2821 et RFC 2822, ne fournit aucune authentification, même faible, de l'émetteur. Un expéditeur de courrier peut toujours prétendre être Nicolas Sarkozy <iznogoud@jeveuxetrealelysee.fr> et il n'y a aucun moyen de l'en empêcher. Sender ID vise à diminuer cette facilité de frauder en permettant à un titulaire de nom de domaine de déclarer quelle(s) adresse(s) IP sont autorisées à envoyer du courrier pour ce domaine. (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)

Sender ID est un concurrent de SPF. SPF avait été spécifié à l'origine (pas dans un RFC mais dans un processus informel) puis, dans le cadre du défunt groupe de travail MARID de l'IETF, une tentative de fusion entre SPF et le protocole de Microsoft, Caller ID, avait été tentée et avait donné naissance à Sender ID.

Sender ID partage donc beaucoup des caractéristiques de SPF (spécifié dans le RFC 4408). Les principales différences sont :

  • Sender ID marque ses enregistrements avec "spf/2.0" et pas avec "v=spf1" mais, si ceux-ci ne sont pas présents, Sender ID utilise les enregistrements SPF, mais en leur donnant un sens différent (ce qui n'aurait jamais dû être accepté par l'IESG et a fait l'objet d'un appel, malheureusement repoussé),
  • Sender ID authentifie surtout une adresse tirée des en-têtes (via l'algorithme PRA, spécifié dans le RFC 4407).

Il est amusant de noter qu'AOL est un des rares domaines à publier à la fois du SPF et du Sender ID :

% dig +short TXT aol.com 
"spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
"v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

alors que Microsoft, auteur et principal promoteur de Sender ID ne publie que du SPF.

En même temps que notre RFC a été publié le RFC 4408 sur SPF. SPF, comme Sender ID, avait été discuté dans le groupe de travail MARID, groupe qui avait été autoritairement dissous avant d'avoir atteint un consensus. Malgré le déploiement bien plus important de SPF, l'IESG a choisi de traiter les deux propositions de manière égale et de publier les deux RFC comme expérimentaux. C'est seulement en 2012, avec la publication du RFC 6686, que l'IETF a reconnu que Sender ID n'avait connu aucun déploiement significatif et que SPF restait seul en lice.


Téléchargez le RFC 4406


L'article seul

RFC 4405: SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : E. Allman (Sendmail), H. Katz (Microsoft)
Intérêt historique uniquement
Première rédaction de cet article le 23 mai 2006


Une petite extension au protocole SMTP pour permettre d'indiquer, lors de l'envoi de l'enveloppe du message (et non pas dans ses en-têtes) l'expéditeur responsable de l'envoi (responsible submitter). (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)

On le sait, authentifier l'expéditeur d'un courrier électronique bute souvent sur un problème tout bête : quel expéditeur choisir ? Dans le cas simple, la réponse est évidente. Mais si le message a fait l'objet d'une retransmission ? Ou s'il a été reçu via une liste de diffusion ? Quel est alors l'expéditeur à authentifier ? Il y a eu des propositions (comme l'algorithme PRA du RFC 4407) pour extraire un expéditeur supposé depuis les en-têtes (le contenu du message, spécifié dans le RFC 2822). Mais beaucoup de MTA n'ont pas un accès facile à ces en-têtes et préféreraient filtrer sur les informations contenues dans l'enveloppe (l'information d'acheminement du message, spécifiée dans le RFC 2821).

C'est ce que leur permet notre RFC. Ici, dans une session SMTP, le client indique l'expéditeur avec la classique commande MAIL FROM et le vrai responsable, trouvé par l'algorithme PRA, avec la nouvelle extension SUBMITTER :

MAIL FROM:<alice@example.org> SUBMITTER=bob@mobile.example

Le MTA peut donc authentifier l'expéditeur avec Sender-ID avant même d'avoir vu le message (et donc les en-têtes).


Téléchargez le RFC 4405


L'article seul

RFC 4398: Storing Certificates in the Domain Name System (DNS)

Date de publication du RFC : Mars 2006
Auteur(s) du RFC : S. Josefsson
Chemin des normes
Première rédaction de cet article le 27 avril 2006


Il existe de nombreux moyens de distribuer les certificats utilisés en cryptographie, comme les serveurs de clé de PGP. Notre RFC en ajoute un nouvau, le DNS.

Les certificats étant protégés par leur signature, le transport n'a pas besoin d'être fiable. On peut donc se servir du DNS, même sans DNSSEC. C'est ce que faisait le RFC 2538 que notre RFC a légèrement remis à jour.

Notre RFC crée donc un nouveau type d'enregistrement DNS , CERT et définit le format pour y mettre des certificats comme ceux de X.509 ou de OpenPGP. Il contient également une section, la 3, pour discuter du nom à donner à ces enregistrements. (Par exemple l'adresse de courrier pour un certificat OpenPGP, donc ma propre clé PGP, dès que je saurai l'encoder proprement, pourrait être publiée sous stephane.bortzmeyer.org.) Mais je ne connais pas encore de logiciel de cryptographie capable de récupérer un certificat via le DNS.

Un bon tutoriel sur la publication de clés PGP dans le DNS est « How to publish PGP keys in DNS ».


Téléchargez le RFC 4398


L'article seul

RFC 4395: Guidelines and Registration Procedures for New URI Schemes

Date de publication du RFC : Février 2006
Auteur(s) du RFC : T. Hansen, T. Hardie, L. Masinter
Première rédaction de cet article le 11 mai 2009


Les URI, ces identificateurs normalisés dans le RFC 3986 commencent tous par un plan (scheme), la partie de l'URI avant le premier deux-points. Ce RFC explique les anciennes procédures d'enregistrement dans le registre des plans (remplacées depuis par celles du RFC 7595).

Il existe de nombreux plans, du très connu http: au moins fréquent tag: (RFC 4151) en passant par bien d'autres, souvent assez confidentiels comme le dns: du RFC 4501 ou le dict: du RFC 2229. Le RFC 3986 décrit seulement la syntaxe générique des URI, celle commune à tous les URI et qui se limite largement à « un plan, deux points, puis du texte » (par exemple, http://www.bortzmeyer.org/608.html ou tag:bortzmeyer.org,2006-02:Blog/608). La grande majorité du contenu de l'URI a une signification qui dépend du plan et un logiciel d'usage très général doit donc connaître ces plans et leurs particularités. Et si j'ai une idée géniale de nouveaux URI et que je veux réserver un plan, je fais comment ? Je lis ce RFC 4395. Que me dit-il ?

La section 2 du RFC fournit des critères pour déterminer si un nouveau plan d'URI est une bonne idée. Ainsi, pour que son enregistrement soit accepté, le plan doit présenter une utilité à long terme (section 2.1). Cette restriction est justifiée par le fait que tout nouveau plan peut nécessiter une modification de tous les logiciels qui traitent des URI et agissent différemment selon le plan. (Le RFC note également que, bien que l'espace de nommage des plans soit infini, en pratique, il pourrait y avoir une concurrence trop forte pour les noms courts et facilement mémorisables et que cela justifie donc de ne pas accepter toutes les candidatures.)

Il y a aussi des contraintes plus techniques. Ainsi, la section 2.2 impose que le nouveau plan respecte les règles syntaxiques existantes. Ainsi, le // a une signification bien précise dans un URI, il précède le nom de la machine qui sert d'autorité de nommage, pour attribuer le reste de l'URI (section 3.2 du RFC 3986). En l'absence d'une telle machine de référence, le // ne doit donc pas être utilisé. (c'est pour cela que dict://dict.example.org/d:chocolate: a un //, car il contient le nom d'un serveur, ici dict.example.org alors que mailto:echo@generic-nic.net n'en a pas, car les adresses de courrier sont globales, elles ne dépendent pas d'un serveur particulier).

Il faut bien sûr que le plan soit correctement et complètement défini (sections 2.3 et 2.4). Par exemple, si l'URI est résolvable, sa description doit expliquer comment. Autre exemple, la description doit expliquer ce qu'on peut faire de l'URI. Accéder (et parfois modifier) à une ressource (cas du http:) ? À une machine (cas de telnet:) ?

Enfin, le plan doit recevoir un nom (section 2.8), qui soit à la fois assez court pour être pratique et assez long pour être descriptif. Pire, comme ces plans sont visibles (des URI sont souvent affichés dans les publications, sur les cartes de visite, sur les publicités), le nom du plan ne doit pas interférer avec des marques déposées défendues par des bataillons d'avocats. Il vaut donc mieux ne pas essayer de normaliser le plan coca-cola: (qui permettrait d'écrire des choses utiles comme coca-cola:light)... Le RFC recommande aussi d'éviter des noms trop marketing comme tout ce qui contient « universal » ou « standard ».

Ces règles de la section 2 sont obligatoires pour les plans enregistrés de manière permanente. Mais le registre contient aussi des plans enregistrés à titre provisoire et les règles en question ne sont qu'indicatives pour eux (section 3).

Bref, une fois qu'on a bien lu toutes ces considérations, on peut passer à l'enregistrement proprement dit. Pour cela, il faut suivre la procédure exposée en section 5 (qui utilise les termes du RFC 5226). On remplit un formulaire (section 5.4), il est examiné (dans la plupart des cas) sur une liste de diffusion comme uri@w3.org, puis par un expert (section 5.2).

C'est par exemple le processus qu'a suivi le plan geo, qui permet des URI comme geo:48.208333,16.372778 (la cathédrale Saint-Étienne à Vienne).La section 3 de la norme sur geo:, le RFC 5870, contient le formulaire d'enregistrement :

3.  IANA Registration of the 'geo' URI Scheme

   This section contains the fields required for the URI scheme
   registration, following the guidelines in Section 5.4 of [RFC4395].

3.1.  URI Scheme Name

   geo

3.2.  Status

   permanent

3.3.  URI Scheme Syntax

   The syntax of the 'geo' URI scheme is specified below in Augmented
   Backus-Naur Form (ABNF) [RFC5234]:

             geo-URI       = geo-scheme ":" geo-path
             geo-scheme    = "geo"
             geo-path      = coordinates p
             coordinates   = coord-a "," coord-b [ "," coord-c ]

             coord-a       = num...

À noter que, bien qu'il existe une norme pour les URI en Unicode (le RFC 3987, sur les IRI), il n'y a pas de plan en caractères non-ASCII.

Ce RFC remplaçait les anciens RFC 2717 et RFC 2718, et a lui-même été remplacé par le RFC 7595. Ces deux anciens RFC avaient été écrits avec l'idée d'une stricte séparation entre localisateurs (les URL) et noms (les URN). À l'usage, cette distinction est apparemment bien moins claire qu'on ne le pensait, beaucoup de gens ont utilisé, à juste titre, des URL (par exemple des URI http:) comme noms et, inversement, ont développé des mécanismes pour accéder à une ressource à partir d'un nom. Notre RFC 4395 ne parle donc plus que d'URI. Un autre changement est que le RFC 2717 avait tenté d'organiser hiérarchiquement les plans alors que nous sommes revenus à un espace de nommage plat.

Un récit très vivant (mais très subjectif) d'un enregistrement difficile : http://lists.w3.org/Archives/Public/uri/2011May/0001.html.


Téléchargez le RFC 4395


L'article seul

RFC 4367: What's in a Name: False Assumptions about DNS Names

Date de publication du RFC : Février 2006
Auteur(s) du RFC : J. Rosenberg (IAB)
Pour information
Première rédaction de cet article le 2 avril 2006


Ce RFC rappelle quelques principes des protocoles Internet, que les utilisateurs du DNS risquent d'oublier en croyant que les noms listés dans le DNS portent une sémantique.

L'intérêt du DNS, c'est qu'il permet de choisir des noms très parlants, comme bortzmeyer.org pour mon domaine personnel ou bien elysee.fr pour celui de Jacques Chirac. Mais cet avantage est également une malédiction : cela charge beaucoup le DNS, qui devient l'enjeu de batailles politiques, économiques et juridiques très pénibles.

Autre problème avec ces noms parlants, beaucoup d'utilisateurs croient que le DNS "dit la vérité", c'est à dire que www.whitehouse.com a un rapport avec la Maison Blanche (c'est bien un site politique mis qui abuse du nom) ou qu'un ordinateur nommé www.example.net porte un serveur Web (alors que cela peut être une simple erreur de configuration).

Pire, le RFC estime que certains logiciels font la même erreur et choisissent le protocole de communication à utiliser, ou bien la langue des documents transmis, en fonction d'un nom de domaine. Je dois dire que, à titre personnel, je trouve les exemples du RFC peu convaincants et que je pense qu'il manque de cas réels.

Notre RFC rappelle donc qu'il ne faut pas accorder de sémantique à un nom de domaine et que, si on veut choisir un protocole ou une langue, il faut utiliser les techniques normalisées (par exemple le schéma de l'URI pour choisir le protocole, l'en-tête Accept-Language de HTTP pour indiquer la langue, etc).


Téléchargez le RFC 4367


L'article seul

RFC 4366: Transport Layer Security (TLS) Extensions

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright
Chemin des normes
Première rédaction de cet article le 19 mars 2009


Ce RFC décrivait les premières extensions au protocole cryptographique TLS. Il décrit le mécanisme général d'extension (qui a depuis été déplacé dans le RFC 5246) puis certaines extensions spécifiques (résumées en section 1). Il est désormais remplacé par le RFC 6066.

Ces extensions ne changent pas le protocole : un client ou un serveur TLS qui ne les comprend pas pourra toujours interagir avec ceux qui les comprennent. Le serveur doit en effet ignorer les informations contenues dans le Hello Client qu'il ne connait pas (section 7.4.1.2 du RFC 5246).

La section 2 décrit le mécanisme général des extensions. Elle a été remplacée par le RFC 5246, notamment la section 7 de ce dernier (voir la structure en 7.4.1.2). En gros, le principe est d'ajouter des données à la fin du paquet Hello, qui marque le début de la négociation TLS. Dans le langage de spécification propre à TLS, la liste des extensions possibles est un enum (section 2.3) mais elle est désormais en ligne à l'IANA.

Les premières extensions normalisées sont décrites dans la section 3. J'en cite seulement certaines. Leur description officielle est désormais dans le nouveau RFC 6066.

SNI (Server Name Indication, section 3.1) permet au client TLS d'indiquer au serveur le nom sous lequel il l'a trouvé. Cela autorise le serveur à présenter des certificats différents selon le nom sous lequel on y accède, fournissant ainsi une solution au problème récurrent de l'authentification avec TLS lorsqu'un serveur a plusieurs noms. À noter que SNI fonctionne avec les IDN, le RFC décrivant le mécanisme à suivre.

Maximum Fragment Length, section 3.2, permet au client d'indiquer qu'il souhaiterait des fragments de données de taille plus réduite. Cela peut être utile pour un client contraint en mémoire ou en capacité réseau, par exemple un téléphone portable. Certains de ces clients contraints apprécieront également Truncated HMAC (section 3.5) qui autorise à réduire la taille du MAC utilisé pour protéger l'intégrité des paquets.

La section 3.6 décrit (Certificate Status Request), une extension qui permet d'indiquer la volonté d'utiliser OSCP, un protocole d'interrogation de certificats X.509 (plus léger que l'habituelle liste de certificats révoqués).

Qui dit nouvelles extensions, dit nouvelles erreurs. La section 4 est donc consacrée aux nouveaux codes d'erreur, pour toutes les extensions décrites. La plus évidente étant unsupported_extension où le client TLS reçoit une extension qu'il n'avait pas demandé (mise dans son Hello).

Enfin, la section 5 décrit la procédure pour l'enregistrement des nouvelles extensions mais, comme elle a été assouplie par le RFC 5246, il vaut mieux consulter la section 12 de ce dernier.

Notre RFC annule le RFC 3546 (le principal changement est un léger assouplissment des règles d'enregistrement de nouvelles extensions) et est lui-même remplacé par les RFC 5246 et RFC 6066.


Téléchargez le RFC 4366


L'article seul

RFC 4360: BGP Extended Communities Attribute

Date de publication du RFC : Février 2006
Auteur(s) du RFC : S. Sangli, D. Tappan (Cisco), Y. Rekhter (Juniper)
Chemin des normes
Première rédaction de cet article le 4 juillet 2010


Depuis 1996, le protocole de routage BGP permet d'étiqueter les routes annoncées avec une ou plusieurs communautés, une suite de chiffres sont la signification dépend en général de l'AS qui l'émet. Ces communautés, normalisées dans le RFC 1997, permettent d'indiquer, par exemple, qu'une route a été initialement apprise à tel point d'échange. Mais elles ont plusieurs limitations et ce RFC normalise donc une version améliorée, les communautés étendues.

Quelles limites des communautés ordinaires sont désormais dépassées (section 1 du RFC) ? Qu'apporte notre RFC ? D'abord, une augmentation de taille, qui permet d'encoder davantage de choses. Ensuite, l'ajout d'un champ « Type » qui permet de donner une structure aux communautés. Il autorise également des traitements (comme de filtrer ou, au contraire de laisser passer) appliqués à toutes les communautés d'un type donné (alors que, avec les communautés ordinaires, le traitement doit être spécifié pour chaque communauté, celles-ci n'ayant aucune structure normalisée).

La section 2 décrit notre nouvel attribut BGP, numéro 16, alias « Extended Communities Attribute ». Il comporte huit octets, un ou deux pour le type et le reste pour les données. Pourquoi un nombre variable d'octets pour le type ? Parce qu'il peut y avoir des types ordinaires (un octet) et des types étendus (deux octets). Par exemple, les communautés pour AS de quatre octets, dans le RFC 5668, utilisent les types étendus. En outre, les deux premiers bits du type indiquent des propriétés qui peuvent être comprises même par un routeur qui n'a jamais vu ces communautés de ce type plus tôt. Le premier bit indique le type d'allocation par l'IANA (0 : allocation en « Premier Arrivé, Premier Servi », 1 : allocation plus restrictive). Le second indique si la communauté est transitive ou pas (si elle doit être transmise aux AS voisins ou pas). Ainsi, même sans avoir lu le RFC 5668, un routeur BGP sait que les communautés de type 0x02 sont transitives (puisque le deuxième bit est à zéro, signe de transitivité).

La section 3 passe tout de suite aux applications pratiques en réservant plusieurs types et en décrivant leur structure. La structure des données, elle, dépend en effet du type. Ainsi, la section 3.2 spécifie une communauté attachée à une adresse IPv4. Le type vaut 0x01 (si elle est transitive) ou 0x41, les données contiennent l'adresse (évidemment sur quatre octets) et un champ Local Administrator sur deux octets, qui contient ce que veut l'AS émetteur.

Autre exemple de communauté étendue, les destinataires de routes (section 4) où un routeur qui émet une route indique dans la communauté quels routeurs peuvent recevoir cette annonce (cf. RFC 4364 pour un exemple d'utilisation). Les routeurs acceptés sont indiqués par leur adresse IP. Un mécanisme analogue permet d'indiquer le routeur d'origine (section 5).

L'enregistrement des types possibles se fait dans un registre IANA (cf. section 7). Consulter ce registre permet de voir le grand nombre d'usages de ces communautés étendues. Rappelons que les deux premiers bits indiquent si l'allocation est simplement « Premier Arrivé, Premier Servi » ou plus formelle, et si la communauté est transitive (transmise aux autres AS) ou pas. À noter que le registre a été par la suite complètement réorganisé par le RFC 7153.

À l'heure actuelle, ces communautés étendues semblent rares dans la nature. Les communautés documentées par les opérateurs (par exemple par Level 3 ou Cable & Wireless) sont généralement des communautés du type traditionnel. Au passage, un bon outil pour examiner les politiques d'étiquetage par communautés des principaux opérateurs est http://onesc.net/communities/.


Téléchargez le RFC 4360


L'article seul

RFC 4350: A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government

Date de publication du RFC : Février 2006
Auteur(s) du RFC : F. Hendrikx (NZ government), C. Wallis (NZ government)
Pour information
Première rédaction de cet article le 6 février 2006


Un curieux et intéressant RFC, qui documente la mise en place d'un espace de nommage d'URN pour le compte du gouvernement de la Nouvelle-Zélande.

La syntaxe des URN et la gestion des espaces de noms associés sont définis dans le RFC 8141. Le gouvernement néo-zélandais crée donc un nouvelle espace, préfixé par urn:nzl:, qui servira à des URN tel que urn:nzl:govt:registering:recreational_fishing:form:1-0, URN qui identifieront tous les documents officiels. Ces derniers seront tous en format XML, ce qui assure notamment l'indépendance par rapport à tout éditeur de logiciel (beaucoup de gouvernements sont assez inconscients pour publier et stocker leurs documents officiels dans le format non-libre d'un éditeur logiciel états-unien particulier).

Comme le montre le choix du format, ce RFC n'est qu'une petite partie d'un projet de gouvernement numérique bien plus ambitieux, incluant notamment un engagement à assurer la pérennité de ces documents officiels. Un identificateur stable comme l'URN (ou bien comme les URI tag du RFC 4151) est un élement essentiel de cette pérennité. Le RFC explique les autres choix possibles (on notera que des identificateurs très gonflés par le marketing, comme les DOI n'ont pas été considérés).

Le RFC désigne un registre, le SSC, qui gérait déjà le domaine govt.nz. Il prévoir aussi une délégation sous l'URN officiel, à d'autres organismes (comme les noms de domaine, les URN sont hiérarchiques).

On notera qu'il n'y a pas de mécanisme de résolution des URN en adresses de prévu dans ce RFC : les URN sont ici de simples identificateurs (une solution possible pour résoudre les URN est d'utiliser DDDS, décrit dans le RFC 3401 mais elle ne semble pas envisagée par les néo-zélandais).

Les amoureux de la diversité linguistique noteront que notre RFC discute de la possibilité d'avoir des URN en māori, une des langues officielles.


Téléchargez le RFC 4350


L'article seul

RFC 4347: Datagram Transport Layer Security

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : E. Rescorla (RTFM), N. Modadugu (Stanford University)
Intérêt historique uniquement
Première rédaction de cet article le 16 juin 2009


Le protocole de cryptographie TLS, normalisé dans le RFC 5246, ne s'appliquait traditionnellement qu'à TCP. Les applications utilisant UDP, comme le fait souvent la téléphonie sur IP ne pouvaient pas utiliser TLS pour protéger leur trafic contre l'écoute ou la modification des données. Mais, désormais, cette limitation disparait, DTLS permet de protéger du trafic UDP. Ce RFC était le premier sur DTLS, il a été remplacé depuis par le RFC 6347 et l'ancienne version de DTLS décrite dans notre RFC est maintenant abandonnée.

TLS ne tournait que sur TCP car il avait besoin d'un transport fiable, garantissant que les données arrivent toutes, et dans l'ordre. Le grand succès de TLS (notamment utilisé pour HTTP et IMAP) vient de sa simplicité pour le programmeur : rendre une application capable de faire du TLS ne nécessite que très peu de code, exécuté juste avant l'envoi des données. Par contre, cela laissait les applications UDP comme SIP non protégées (section 1 de notre RFC). Les solutions existantes comme IPsec ne sont pas satisfaisantes, notamment parce qu'elles n'offrent pas la même facilité de déploiement que TLS, qui tourne typiquement dans l'application et pas dans le noyau.

DTLS a été conçu pour fournir TLS aux applications UDP. Il offre les mêmes services que TLS : garantie de l'intégrité des données et confidentialité.

La section 3 explique les principes de DTLS : protégé ou pas par DTLS, UDP a la même sémantique, celle d'un service de datagrammes non fiable. DTLS est une légère modification de TLS : il en garde les principales propriétés, bonnes ou mauvaises.

Mais pourquoi ne peut-on pas faire du TLS normal sur UDP ? Parce que TLS n'a pas été conçu pour tourner au dessus d'un protocole non fiable. TLS organise les données en enregistrements (records) et il ne permet pas de déchiffrer indépendamment les enregistrements. Si l'enregistrement N est perdu, le N+1 ne peut pas être déchiffré. De même, la procédure d'association initiale de TLS (handshake) ne prévoit pas de perte de messages et ne se termine pas si un message est perdu.

Le premier problème fait l'objet de la section 3.1. La dépendance des enregistrements TLS vis-à-vis de leurs prédécesseurs vient du chaînage cryptographique (chiffrement par blocs) et de fonctions anti-rejeu qui utilisent un numéro de séquence, qui est implicitement le rang de l'enregistrement. DTLS résout le problème en indiquant explicitement le rang dans les enregistrements.

Et la question de l'association initiale est vue dans la section 3.2. Pour la perte de paquets lors de l'association, DTLS utilise un système de retransmission (section 3.2.1) et pour l'éventuelle réorganisation des paquets, DTLS introduit un numéro de séquence (section 3.2.2). En prime, DTLS doit gérer la taille importante des messages TLS (souvent plusieurs kilo-octets), qui peut être supérieure à la MTU. DTLS permet donc une fragmentation des paquets au niveau applicatif, un message pouvant être réparti dans plusieurs enregistrements (section 3.2.3).

Enfin, l'anti-rejeu a été modifié pour tenir compte du fait que la duplication de paquets, en UDP, n'est pas forcément malveillante (sections 3.3 et 4.1.2.5).

La définition formelle du nouveau protocole est en section 4. DTLS étant une légère évolution de TLS, la définition se fait uniquement en listant les différences avec TLS, dont il faut donc garder le RFC 5246 sous la main.

Au niveau du Record Protocol de TLS, l'enregistrement spécifié dans la section 6.2.1 du RFC 5246 gagne deux champs (section 4.1) :

  struct {
         ContentType type;
         ProtocolVersion version;
         uint16 epoch;                                    // NOUVEAU
         uint48 sequence_number;                          // NOUVEAU
         uint16 length;
         opaque fragment[DTLSPlaintext.length];
       } DTLSPlaintext;

notamment le numéro de séquence sequence_number (qui était implicite dans TLS, puisque TCP garantissait l'ordre des messages). Pour éviter la fragmentation et les ennuis associés, les mises en œuvre de DTLS doivent déterminer la MTU du chemin et n'envoyer que des enregistrements plus petits que cette MTU (section 4.1.1).

Contrairement à IPsec, DTLS n'a pas la notion d'identificateur d'association. Une machine qui reçoit du TLS doit trouver l'association toute seule, typiquement en utilisant le tuple (adresse IP, port).

En toute rigueur, DTLS n'est pas spécifique à UDP, il peut marcher sur n'importe quel protocole de transport ayant une sémantique « datagrammes ». Certains de ces protocoles, comme DCCP (cf. RFC 5238), ont leur propres numéros de séquence et ils font donc double emploi avec ceux de DTLS. Petite inefficacité pas trop grave.

Au niveau du Hanshake protocol, les modifications que DTLS apporte à TLS font l'objet de la section 4.2. Les trois principales sont :

  • L'ajout d'un gâteau pour limiter les risques de DoS,
  • Modification des en-têtes pour gérer les pertes ou réordonnancements des paquets (section 4.2.2),
  • Ajouts de minuteries pour détecter les pertes de paquets (section 4.2.4).

Les gâteaux de DTLS sont analogues à ceux de Photuris ou IKE (section 4.2.1). Le message ClientHello de la section 7.4.1.2 du RFC 5246 y gagne un champ :

 opaque cookie<0..32>;         // NOUVEAU

OpenSSL gère DTLS depuis la version 0.9.8 (on peut aussi consulter le site Web du développeur). Un exemple d'utilisation se trouve dans http://linux.softpedia.com/get/Security/DTLS-Client-Server-Example-19026.shtml. Il me reste à inclure ce protocole dans echoping. GnuTLS n'a pas de support DTLS (et aucun développement n'est en cours, les volontaires sont les bienvenus).

Une très bonne description de la conception de Datagram TLS et des choix qui ont été faits lors de sa mise au point, se trouve dans l'article The Design and Implementation of Datagram TLS, écrit par les auteurs du RFC. C'est une lecture très recommandée.


Téléchargez le RFC 4347


L'article seul

RFC 4340: Datagram Congestion Control Protocol (DCCP)

Date de publication du RFC : Mars 2006
Auteur(s) du RFC : E. Kohler (UCLA), M. Handley (UCL), S. Floyd(ICIR)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dccp
Première rédaction de cet article le 26 avril 2006
Dernière mise à jour le 27 avril 2006


Si IP est la base de l'Internet, la grande majorité des applications utilisent un protocole de transport situé au dessus d'IP et ne parlent pas directement IP. Les deux protocoles de transport les plus connus sont TCP et UDP mais il en existe d'autres dont, désormais, DCCP.

Pour comprendre l'intérêt de DCCP, qui vient d'être normalisé, il faut se souvenir des services que fournissent TCP et UDP :

  • TCP fournit un service de flot de données (il ne transporte pas des messages séparés mais un flot continu d'octets) fiable, c'est-à-dire que c'est TCP, pas l'application, qui se charge d'envoyer et de surveiller les accusés de réception, et de demande des retransmissions si un paquet se perd. Outre ce service rendu à l'application, TCP rend un service à l'Internet : il assure le contrôle de congestion, c'est-à-dire qu'il ralentit le débit sortant si les accusés de réception lui montrent que le réseau est surchargé. TCP est donc gentil pour le réseau. Enfin, les données ne sont échangées qu'après l'établissement d'une connexion, établissement pendant lequel les deux parties peuvent s'accorder sur des options.
  • UDP, lui, ne fournit presque rien de plus qu'IP : son service est de datagrammes, c'est-à-dire de messages séparés, et il n'a aucune fiabilité, l'application ne sait même pas si le datagramme est arrivé ou pas. Si elle a besoin d'accusé de réception ou de fiabilité, c'est à elle de les gérer. Si l'application ne pense pas à gérer la congestion, elle risque d'aggraver les problèmes de l'Internet en (ré)envoyant davantage de données justement lorsque le réseau est saturé. Contrairement à TCP, aucune connexion n'est nécessaire.

Il n'est donc pas étonnant que la plupart des applications utilisent TCP, bien plus simple pour le concepteur et pour le programmeur. Mais TCP consomme davantage de ressources et introduit des délais non négligeables, surtout à l'ouverture de connexion. UDP est donc utilisé si le temps de réponse est primordial (cas du DNS) ou bien si l'application peut tolérer la perte d'un certain nombre de paquets (cas des protocoles de transmission de son ou d'image comme RTP, où on peut accepter quelques silences ou quelques trames manquantes).

Entre TCP et UDP, d'autres protocoles de transport ont été créés pour des usages divers mais tous sont restés marginaux.

DCCP aura peut-être davantage de succès :

  • Comme TCP, DCCP fournit un service d'accusé de réception (donc l'application peut savoir quels messages sont arrivés) et nécessite une connexion, ce qui permet de choisir des options. Mais il ne rentransmet pas les données perdues, l'application est juste tenue au courant.
  • Comme TCP, DCCP fournit à l'Internet un service de contrôle de la congestion. Il y en a même plusieurs, choisis lors de la négociation initiale.
  • Comme UDP, DCCP fournit un service de messages non fiable.

On trouvera des détails et des articles plus détaillés sur le site de l'UCLA ou bien sur celui de l'ICIR (qui semble moins bien maintenu et contient des informations dépassées).

Une mise en œuvre limitée de DCCP est inclue dans le noyau Linux mais je n'ai pas encore eu l'occasion de la tester ni de voir quelle API devait être utilisée par echoping (un exemple de programmes figure dans http://wand.net.nz/~iam4/dccp/dccp-cs-0.01.tar.bz2).


Téléchargez le RFC 4340


L'article seul

RFC 4310: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 25 novembre 2009


Le protocole EPP d'avitaillement d'un registre (par exemple un registre de noms de domaine), normalisé dans le RFC 5730, manipule des objets qui sont des instances d'une classe (nommée mapping). Par exemple, il existe une classe (un mapping) pour les noms de domaine, décrite dans le RFC 5731. Notre RFC 4310 (remplacé depuis par le RFC 5910) décrit, lui, une extension EPP à ce mapping permettant de spécifier les données nécessaires à DNSSEC, notamment la clé publique d'une zone signée.

DNSSEC, normalisé dans le RFC 4033, utilise la même délégation que le DNS. La zone parente d'une zone signée délègue en indiquant la clé publique de sa zone fille. Plus exactement, la zone parente publie un condensat cryptographique de la clé publique de la zone fille, l'enregistrement DS (pour Delegation Signer), normalisé dans la section 5 du RFC 4034 (voir aussi le rappel en section 2.1 de notre RFC 4310).

Lorsqu'un bureau d'enregistrement crée un nom de domaine signé, ou bien informe le registre qu'un domaine est désormais signé, comment indique t-il ce DS ? Il y a plusieurs façons, et notre RFC propose d'utiliser EPP.

L'extension nécessaire est résumée en section 2. Elle fonctionne en ajoutant des éléments à la classe Domaine du RFC 5731. Un élément obligatoire est le condensat cryptographique de la clé (alors qu'il n'est pas forcément unique : cette erreur a été corrigée dans le RFC 5910). Mais le client EPP peut aussi fournir la clé elle-même (le RFC 6781 explique pourquoi le condensat, le futur DS, est obligatoire alors que la clé est facultative). Le RFC prévoit également que le registre de la zone parente peut également récupérer la clé dans le DNS (enregistrement DNSKEY) pour tester si le condensat reçu est correct (et il est donc recommandé que ladite DNSKEY soit publiée avant de prévenir le parent par EPP). La clé transmise au registre doit être une clé de confiance, c'est-à-dire avoir le bit SEP à 1 (cf. RFC 3757). En terminologie moderne, cette clé doit être une KSK (Key Signing Key).

Les commandes EPP pour gérer cette information font l'objet de la section 3. Ainsi, les réponses à <info> doivent désormais contenir un élément <secDNS:infData>, qui contient lui-même des éléments comme <secDNS:dsData> qui a son tour contient les champs qu'on trouve dans un enregistrement DS comme <secDNS:keyTag> (l'identificateur de la clé), <secDNS:alg> (l'algorithme utilisé), etc. L'espace de noms urn:ietf:params:xml:ns:secDNS-1.0 (ici avec le préfixe secDNS) est enregistré dans le registre IANA (voir section 6). (C'est désormais secDNS-1.1, depuis le RFC 5910.) Voici un exemple de réponse à <info> sur le domaine example.com :


<resData>
...
<domain:name>example.com</domain:name>
...
<extension>
  <secDNS:infData
   xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
   xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
    <secDNS:dsData>
      <secDNS:keyTag>12345</secDNS:keyTag>
      <secDNS:alg>3</secDNS:alg>
      <secDNS:digestType>1</secDNS:digestType>
      <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
    </secDNS:dsData>
  </secDNS:infData>
</extension>

Le condensat est de type SHA1 (<digestType>1</digestType>), la clé elle-même étant DSA/SHA1 (<alg>3</alg>).

L'extension DNSEC permet évidemment de créer un domaine signé, avec <create> (section 3.2.1) :


<domain:create>
  <domain:name>example.com</domain:name>
  ...
  <extension>
  <secDNS:create xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
    xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
  <secDNS:dsData>
    <secDNS:keyTag>12345</secDNS:keyTag>
    <secDNS:alg>3</secDNS:alg>
    <secDNS:digestType>1</secDNS:digestType>
    <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
    <!-- <secDNS:keyData>, la clé elle-même, est *facultatif* -->
  </secDNS:dsData>
</secDNS:create>
 ...

Une fois le domaine ainsi créé, le registre publiera typiquement un enregistrement DS comme :

example.com.  IN DS 12345 3 1 49FD46E6C4B45C55D4AC

Bien sûr, on peut aussi ajouter DNSSEC à un domaine existant, ou bien changer une clé existante. Cela se fait avec <update> :


    <domain:update>
        <domain:name>example.com</domain:name>
    ...
    <extension>
      <secDNS:update
       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
        <secDNS:add>
          <secDNS:dsData>
            <secDNS:keyTag>12346</secDNS:keyTag>
            <secDNS:alg>3</secDNS:alg>
            <secDNS:digestType>1</secDNS:digestType>
            <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
            <!-- <secDNS:keyData>, la clé elle-même, est *facultatif* -->
          </secDNS:dsData>
        </secDNS:add>
      </secDNS:update>
     ...

Et, en utilisant <secDNS:rem> au lieu de <secDNS:add>, on peut retirer une délégation sécurisée (« dé-signer » le domaine).

Comme la grande majorité des extensions et mappings d'EPP, celle-ci est spécifiée en utilisant la syntaxe formelle des W3C schemas, ici en section 4.


Téléchargez le RFC 4310


L'article seul

RFC 4301: Security Architecture for the Internet Protocol

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : S. Kent, K. Seo (BBN Technologies)
Chemin des normes
Première rédaction de cet article le 9 février 2009


L'Internet n'est pas sûr, on le sait bien. Un méchant peut lire les paquets IP qui circulent, il peut injecter de faux paquets, avec une fausse adresse IP source, etc. Il existe des tas de façons d'aborder ce problème et ce RFC décrit une des plus ambitieuses, une complète architecture de sécurité pour IP, IPsec.

Actuellement, le problème est en général traité au niveau des applications. Par exemple, SSH va complètement sécuriser une session, quelles que soient les vulnérabilités de la couche réseau sous-jacente. Un attaquant ne pourra pas faire passer sa machine pour une autre, même s'il peut envoyer de faux paquets IP.

Cette approche est relativement simple, assez facile à déployer et règle une grande partie des problèmes. Elle a deux limites : il faut modifier chaque application. Lorsque leur nombre augmente, cela devient vite pénible. Et elle ne protège pas contre certaines attaques. Par exemple, des faux paquets TCP RST (ReSeT, c'est-à-dire remise à zéro de la connexion TCP) peuvent couper une session SSH puisque la couche transport n'est pas authentifiée. De tels faux paquets RST se trouvent dans le monde réel, par exemple, envoyés par la censure chinoise.

D'où l'idée de IPsec : sécuriser au niveau IP afin que toutes les applications soient automatiquement protégées, contre toutes les attaques. Ce RFC décrit l'architecture générale d'IPsec. Ce protocole est réputé très complexe à comprendre (et à déployer) et le RFC est gros et complexe (alors même qu'une partie des détails figure dans d'autres RFC comme le RFC 4303 ou le RFC 4305, ce dernier normalisant les algorithmes de cryptographie obligatoires).

Comme le rappelle bien la section 1.1, IPsec est une architecture de sécurité pour IP, pas pour l'Internet. La securisation complète d'un réseau comme l'Internet dépend de bien d'autres choses.

La section 2.1 décrit le cahier des charges d'IPsec : fournir des services d'authentification, d'intégrité et de confidentialité à IP (IPv4 ou IPv6).

Commençons par quelques généralités (section 3) : IPsec crée une barrière entre une zone non protégée et une zone protégée (section 3.1). Au passage de la barrière, IPsec traduit les paquets, d'une forme protégée vers une non-protégée, ou bien le contraire.

IPsec peut sécuriser la communication de deux façons : en authentifiant les paquets, sans chercher à assurer leur confidentialité, c'est le protocole AH, Authentication Header (section 3.2 et RFC 4302). Ou bien authentifier tout en chiffrant pour empêcher les méchants de lire le contenu, c'est le protocole ESP, Encapsulating Security Payload (section 3.2 et RFC 4303). Le second est de loin le plus utilisé, entre autre parce que AH ne passe pas à travers les routeurs NAT.

Pour ces deux protocoles, AH et ESP, IPsec dispose de deux modes, tunnel et transport. Dans le mode transport, la connexion est sécurisée de bout en bout entre les deux machines. Ce mode est donc le plus sûr mais nécessite IPsec sur les deux engins. Le mode tunnel, crée un VPN entre deux routeurs et les machines des deux réseaux locaux ainsi connectés sont protégées dans leurs communications entre ces deux réseaux, sans qu'elles aient besoin d'IPsec elles-mêmes.

Comment IPsec place ses informations dans le paquet ? Avec AH, le mode transport et IPv4, le champ Protocole de l'en-tête IPv4 indique non pas le protocole de la couche transport (typiquement TCP) mais AH (valeur 51 dans le registre IANA). On trouve donc un second en-tête après l'en-tête IP normal, contenant les données notamment :

  • Le SPI, Security Parameter Index, un nombre qui permet à la machine de retrouver les paramètres de la session, par exemple l'algorithme cryptographique utilisé (plusieurs algorithmes sont possibles, puisque la technologie en ce domaine ne cesse pas d'évoluer),
  • Le résumé cryptographique des données qu'on veut authentifier, notamment l'adresse IP source,
  • L'indication du « protocole suivant », c'est-à-dire le protocole de la couche transport.

Pour un routeur IP, un paquet protégé par AH est donc un paquet IP comme un autre, le champ Protocole d'IP n'étant lu qu'à l'arrivée.

En mode tunnel, le « protocole suivant » de l'en-tête AH sera IP, tout simplement, et c'est un paquet IP complet qui sera encapsulé.

L'un des principaux problèmes avec AH concerne les routeurs NAT. Comme AH vise à garantir l'intégrité du paquet et donc l'absence de modifications, il rentre directement en conflit avec le NAT qui modifie au moins l'adresse source. Le RFC 3715 discute plus en détail ce problème. À noter que AH n'est plus désormais obligatoire dans IPsec (section 3.2), ESP le remplaçant en mieux dans presque tous les cas.

Et ESP ? Cette fois, le paquet est chiffré et l'indication du protocole suivant indique comment analyser le contenu, après déchiffrement. Le SPI joue le même rôle qu'avec AH, il indique le contexte dans lequel a été fait le chiffrement et donc notamment l'algorithme utilisé. À noter que l'en-tête IP circule donc en clair et peut, à lui seul, fournir des indications à un indiscret : qui communique avec qui et même quel genre d'applications (par les bits DSCP).

Contrairement à AH, ESP ne garantit pas l'intégrité de l'en-tête IP mais celui lui permet de passer le NAT.

Comme AH, ESP peut fonctionner en mode tunnel ou en mode transport.

En pratique, aujourd'hui, rares sont les utilisateurs de AH, la grande majorité des sessions IPsec sont protégées par ESP.

Je reviens maintenant un peu sur le SPI (Security Parameter Index). Il fait partie d'un contexte plus large, la SA (Security Association, section 4). Ce contexte est ce qui permet de retrouver les paramètres d'une session IPsec notamment l'algorithme de chiffrement. Stocké dans une SAD (Security Associations Database, section 4.4.2), la SA est indexée par le SPI et, selon les cas, également par les adresses IP et le protocole (AH ou ESP). À chaque arrivée d'un paquet IP entrant, c'est le SPI dans ce paquet qui servira à trouver la politique à appliquer (section 5.2).

Puisque j'ai mentionné la SAD, c'est l'occasion de revenir sur les bases de données d'IPsec (section 4.4). Leur forme exacte dépend évidemment de l'implémentation mais, conceptuellement, toute mise en œuvre d'IPsec doit avoir les bases suivantes :

  • SPD (Security Policy Database) qui stockera les préférences de l'administrateur réseau : quels paquets doivent être protégés par IPsec, notamment, en fonction de sélecteurs qui sont en général des adresses IP et numéros de port. Une politique sera par exemple, « Protéger avec ESP tous les paquets échangés avec 2001:DB8:1:27::/64 et laisser passer le reste non protégé ».
  • SAD (Security Association Database), qui indique les SA en cours.
  • PAD (Peer Authorization Database), liée à la gestion des clés.

La SPD est présentée en détail dans la section 4.4.1. Sur FreeBSD, on la trouve typiquement dans /etc/ipsec.conf et elle contient des appels à setkey. Les politiques possibles sont PROTECT (protéger le trafic avec IPsec), BYPASS (laisser passer, même non protégé) et DISCARD (ne pas laisser passer). Les sélecteurs possibles sont décrits en section 4.4.1.1. Toute mise en œuvre d'IPsec doit au moins accepter les adresses IP source et destination comme sélecteurs. Les sélecteurs pouvant se recouvrir partiellement, l'ordre des directives dans cette base est crucial (voir l'annexe B pour un algorithme permettant de supprimer ce recouvrement).

Une fois la SPD configurée, elle sera consultée à chaque paquet IP, pour déterminer l'action à entreprendre (section 5 pour le traitement des paquets IP). Par défaut, en l'absence d'une mention dans la SPD, le paquet sera mis à la poubelle.

La SAD est décrite en section 4.4.2. Elle garde mémoire des options de chaque association de sécurité, comme l'algorithme cryptographique utilisé (la section 4.4.2.1 détaille le contenu des entrées de cette base). Pour les paquets sortants, IPsec utilise typiquement un cache associant une prise réseau à une association de sécurité présente dans la SAD. Pour les paquets entrants, le SPI (Security Parameter Index) dans le paquet sert d'index dans la SAD.

La gestion des clés est traitée dans la section 4.5. C'est de loin la partie la plus complexe d'IPsec (comme de beaucoup d'autres protocols de sécurité). En pratique, la grande majorité des utilisateurs d'IPsec ne comptent que sur des clés gérés manuellement (section 4.5.1), IKE (RFC 4306) étant très peu déployé.

Comme souvent en sécurité, le diable est dans les détails. Par exemple, la section 6 couvre le traitement des paquets ICMP. Que faire d'eux ? Les ignorer lorsqu'ils ne sont pas protégés par IPsec ? Du point de vue sécurité, cela serait cohérent mais, dans l'état actuel du déploiement d'IPsec, presque tous les paquets ICMP émis par des routeurs intermédiaires seraient alors ignorés, bien qu'ils apportent des informations essentielles. Notre RFC recommande donc (section 6.1.1) de laisser le choix à l'administrateur réseau de les accepter ou pas.

Si la section 7 traite un autre détail délicat, la gestion de la fragmentation, la section 8 parle des problèmes de MTU, une des plaies de l'Internet. AH et ESP ajoutent tous les deux des octets au paquet qu'ils protègent, et ces octets peuvent faire que le paquet dépasse la MTU du lien. Le problème est donc similaire à celui de tous les autres tunnels. Aux autres difficultés de déploiement d'IPsec s'ajoute donc le problème de MTU.

Le déploiement réel d'IPsec est très faible. Conçu pour sécuriser peu ou prou toutes les communications sur Internet, sa principale utilisation aujourd'hui est pour faire des tunnels entre deux réseaux de la même organisation. Comme un protocole normalisé est moins vital dans ce cas, IPsec est concurrencé par d'autres protocoles de tunnel (comme celui d'OpenVPN).

Quelles sont les implémentations pour les systèmes d'exploitation Unix ? Sur Linux, la plus répandue est Openswan mais il y a aussi StrongSwan (les deux dérivant du même code). Sur NetBSD, IPsec est inclus dans le système et bien documenté dans la NetBSD IPsec FAQ. Avec NetBSD, la SPD peut être par prise : Per-socket: configured via setsockopt(2) for a certain socket. You can specify like "encrypt outgoing packets from this socket". This works well when you would like to run IPsec-aware server program. . Sinon, elle est par paquet, la SPD se configure (c'est pareil sur FreeBSD par exemple dans /etc/ipsec.conf) avec setkey(8) :

#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use;
EOF

9876 et 10000 sont le SPI.

Ce RFC décrit « IPsec version 3 » (le RFC 2401 étant la version 2), même si ces numéros de version ne sont pas mentionnés dans le RFC (mais ils apparaissent dans d'autres documents). La section 13 liste les différences avec la version 2, notamment le fait qu'AH n'est plus obligatoire (ce qui reflète son faible usage), des SPD plus souples, etc.

Pour une excellente introduction à IPsec, je recommande l'article de Steve Friedl « An illustrated guide to IPsec », qui contient notamment de bons schémas des paquets tels qu'ils sont présents sur le câble. Parfait si on veut comprendre comment IPsec marche.

IPsec a toujours suscité des passions. Une des critiques les plus fouillées a été écrite par Niels Ferguson et Bruce Schneier dans un article très vivant et très pédagogique, A Cryptographic Evaluation of IPsec. Ferguson et Schneier font remarquer que IPsec semble avoir été conçu par un comité, où l'important était de faire plaisir à tout le monde plutôt que de produire un protocole sûr. Ainsi, ils reprochent à IPsec d'avoir deux protocoles (AH et ESP) alors qu'ESP seul suffirait. De même, ils contestent les deux modes, tunnel et transport, puisque le mode transport assurerait l'équivalent des fonctions des deux modes. La sécurité d'un protocole dépendant largement de sa simplicité, IPsec, pour eux, ne peut pas être vraiment sûr. Cette critique couvre la version 2 mais la plupart des remarques s'appliquent encore à la version actuelle. (Notez tout de même que le RFC actuel reconnait que AH n'est pas vraiment indispensable.)


Téléchargez le RFC 4301


L'article seul

RFC 4297: Remote Direct Memory Access (RDMA) over IP Problem Statement

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : A. Romanow (Cisco), J. Mogul (HP), T. Talpey (NetApp), S. Bailey (Sandburst)
Pour information
Première rédaction de cet article le 9 février 2006


Ce RFC ne spécifie pas une norme, il écrit juste un problème intéressant et appelle aux solutions. Le problème est d'accélérer les transmissions de données entre machines connectées à Internet, en permettant un accès direct à la mémoire de l'autre machine.

Notre RFC décrit très en détail, avec forces chiffres et références, les goulets d'étranglement lors d'une transmission de données entre machines. La simple copie des données prend en général beaucoup de temps. La solution envisagée est la copie directe (DMA) de la mémoire d'une machine à l'autre, au dessus du protocole IP (les solutions existants de DMA fonctionnent au dessus d'un bus machine comme PCI).

Le RFC appelle donc à l'étude d'une solution DMA au dessus d'IP, et propose comme point de départ le RFC 4296, par les mêmes auteurs.


Téléchargez le RFC 4297


L'article seul

RFC 4291: IP Version 6 Addressing Architecture

Date de publication du RFC : Février 2006
Auteur(s) du RFC : R. Hinden (Nokia), S. Deering (Cisco)
Chemin des normes
Première rédaction de cet article le 10 décembre 2007


Ce RFC décrit l'architecture d'adressage d'IPv6, ainsi que des points comme la représentation textuelle des adresses.

IPv6 a beaucoup changé depuis dix ans, le manque de déploiements opérationnels laissant davantage de liberté aux auteurs de protocole. Moins de base installée égale moins de stabilité des normes, jusqu'à la dissolution récente du groupe de travail IPv6 de l'IETF. Ce RFC sera donc probablement le dernier sur ce sujet. Il succède au RFC 3513, avec des changements peu importants, le principal étant l'abandon des adresses locales au site.

Il n'y a rien d'extraordinaire dans l'adressage IPv6, par rapport à son prédécesseur IPv4 depuis que celui-ci a abandonné les anciennes classes d'adresses. Les mêmes concepts sont à l'œuvre, notamment la notion de préfixe d'une adresse (les N premiers bits, où N dépend de l'architecture du réseau).

Une importante exception à cette règle, qui n'a pas d'équivalent en IPv4, est que les 64 derniers bits sont réservés à l'identificateur d'interface (interface identifier ou IID). On ne peut donc pas, contrairement à IPv4, utiliser des préfixes de longueur quelconque (la section 2.5.1 indique toutefois des cas où on peut utiliser des préfixes de plus de 64 bits).

Cet interface identifier était souvent dérivé de l'adresse MAC (l'algorithme est décrit dans l'annexe A) mais il peut être généré autrement (méthode recommandée par le RFC 8064), attribué arbitrairement, ou encore fabriqué par l'algorithme décrit dans le RFC 8981. L'abondance des adresses en IPv6 permet des fantaisies nouvelles, par exemple le serveur racine F a pour adresse 2001:500::1035 en l'honneur du RFC 1035, qui normalise le DNS. De même, le serveur racine B a comme adresse 2001:478:65::53, 53 étant le port utilisé par le DNS.

Les premiers bits de l'adresse IPv6 indiquent son type. C'est ainsi que le préfixe FE80::/10 identifie les adresses locales au lien (link-local). De même, les adresses de diffusion (peu utilisées à l'heure actuelle) sont couvertes par le préfixe FF00::/8. Attention, les adresses locales au site ont été abandonnées dans le RFC 3879, remplacées par les ULA du RFC 4193.

La section 2.2 décrit la forme textuelle des adresses, avec les nombres codés en hexadécimal et avec le deux-points comme séparateur, par exemple 2001:DB8:42::1954:2:1. Deux deux-points successifs identifient une suite de zéros. L'adresse ci-dessus aurait donc pu s'écrire 2001:DB8:42:0:0:1954:2:1.

On notera qu'il n'a jamais existé de représentation textuelle normalisée des adresses IPv4 (la forme avec quatre octets en décimal séparés par des points est la plus courante mais pas la seule, essayez telnet 651667656 si vous ne me croyez pas et regardez à quelle machine il tente de se connecter).


Téléchargez le RFC 4291


L'article seul

RFC 4290: Suggested Practices for Registration of Internationalized Domain Names (IDN)

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : J. Klensin
Pour information
Première rédaction de cet article le 10 février 2006
Dernière mise à jour le 17 mars 2006


Les IDN ont toujours suscité des passions et il n'était donc pas évident de normaliser des politiques d'enregistrement, d'autant plus que chaque langue a ses particularités. L'IETF n'a donc pas essayé et le premier RFC non technique sur les IDN n'est donc pas une norme.

Le RFC 3490 spécifiait la norme IDN, permettant de représenter des noms de machines écrits en Unicode et pas seulement en US-ASCII. Ce RFC 3490, purement technique, ne spécifiait pas les politiques d'enregistrement des registres de noms. Ce choix est tout à fait justifié : au contraire des choix techniques, qui doivent être uniformes, il n'y a aucune raison de normaliser ces politiques, qui dépendent des choix de chaque registre.

Comme exemple de politiques possibles, dans le cas d'une population francophone, on peut imaginer que pere-noel.fx et père-noël.fx puissent être délégués à des entités différentes, malgré le risque de confusion ou bien au contraire que on définisse un lot (bundle) qui est l'ensemble des noms IDN équivalents (par exemple, pere-noel.fx est équivalent à père-noël.fx). Tous les membres du lot seraient alors délégués au même titulaire.

Plusieurs efforts ont été tentés pour discuter de ces politiques et, à défaut de normes, spécifier un cadre commun pour les exprimer. Cela a été fait, par exemple, dans la liste idn-reg-policy, aujourd'hui inactive. Parallèlement, certains registres asiatiques ont écrit le RFC 3743 qui décrit leur cadre politique.

Dans le cadre de la liste idn-reg-policy, Paul Hoffman, un expert en internationalisation avait proposé un langage pour décrire des tables de caractères avec leurs variantes (par exemple, ÿ peut être considéré comme une variante de y et donc pierre-louÿs.fx serait équivalent à pierre-louys.fx).

Notre RFC est proche des dernières versions des propositions d'Hoffman. Il ne présente pas une politique d'enregistrement mais il suggère des pistes, pointe des problèmes potentiels et propose une syntaxe pour exprimer les tables.

À titre d'information, voici la table des caractères utilisés en français, dans cette syntaxe (utilisant la notation Unicode donc U+00E7 est le "c cédille"). Le point de départ de cette table avait été un excellent article de Jacques André :

# Variant table for the French language

# A sentence with every composed character: 
# Ils se sont réveillés à Nîmes, très tôt, dans la même Citroën
# niçoise sentant l'aïoli où ils avaient joué de cette flûte aiguë la
# nuit de Pâques, près de l'Haÿ-les-Roses.

# a-z
# a and its variants : à â
# á (a acute) does not seem to exist in French: for further study (town names?)
# a with ring above (U+00E5) does not exist in french but in picard
# http://www.picard.free.fr/lgpic/a-e.htm
U+0061|U+00E0:U+00E2
U+0062
# c
U+0063|U+00E7
U+0064
# e and its variants : è é ê ë
U+0065|U+00E8:U+00E9:U+00EA:U+00EB
U+0066
U+0067
U+0068
# i and its variants : î ï
U+0069|U+00EE:U+00EF
U+006A
U+006B
U+006C
U+006D
# ñ (U+00F1) does not exist in french but in breton
# http://www.ouest-france.fr/dossiershtm/cours-de-breton/lecture.htm
# or in basque.
U+006E
# o and its variants : ô. ö (U+OOF6) exists in French? No word uses 
# it.
# ò (U+00F2) does not exist in french but in occitan
# http://occitanet.free.fr/fr/index.html
U+006F|U+00F4
U+0070
U+0071
U+0072
U+0073
U+0074
# u and its variants : ù û ü
# ú (u acute) does not seem to exist in French: for further study
U+0075|U+00F9:U+00FB:U+00FC
U+0076
U+0077
U+0078
# y. ÿ only in names? (L'Haÿ-les-Roses)
U+0079|U+00FF
U+007A
# 0-9
U+0030
U+0031
U+0032
U+0033
U+0034
U+0035
U+0036
U+0037
U+0038
U+0039
# - (hyphen)
U+002D
# Ligature oe: the variant is a *string*
U+0153|U+006F-U+0065
# Ligature ae (æ). Only in names like Lætitia?
U+OOE6|U+0061-U+0065

À noter que le RFC prend ses distances avec l'ICANN, qui a décidé d'établir une table des langages à l'IANA, table pour laquelle l'ICANN n'a ni légitimité, ni compétence et que la plupart des registres ont refusé de remplir.


Téléchargez le RFC 4290


L'article seul

RFC 4287: The Atom Syndication Format

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : M. Nottingham (editor), R. Sayre (editor)
Chemin des normes
Première rédaction de cet article le 12 décembre 2005
Dernière mise à jour le 28 mai 2011


La syndication des sites Web, c'est-à-dire la récupération de résumés structurés par un autre site, par le biais des flux (feeds) RSS est à la mode. Tout le monde en fait et n'importe quel blog affiche un lien vers son flux RSS. Beaucoup de gens lisent le Web essentiellement via un agrégateur RSS, qui lit de nombreux flux RSS et présente ces résumés sous une forme qui permet une navigation facile.

Mais ce succès cache une rude rivalité entre les différents RSS. Il en existe plusieurs, le 0.9, le 1.0, le 2.0 et ce ne sont pas des évolutions plus ou moins récentes de la même norme, mais des normes bien différentes et incompatibles.

L'IETF tente donc de régler le problème, avec la norme Atom. Atom est spécifié dans ce nouveau RFC, et peut-être fera t-il la synthèse entre tous les formats de syndication. Ou bien peut-être rajoutera t-il juste une Nième norme incompatible avec les autres, l'avenir le dira.

Rien d'extraordinairement nouveau dans ce RFC, qui reprend les élements classiques d'un flux RSS. Atom est bâti sur XML et et ses éléments de type content peuvent inclure du texte brut, du XHTML mais aussi n'importe quel élément XML, que l'usage des espaces de noms sépare de l'XML d'Atom.

On note que ce RFC est, à ma connaissance, le premier RFC utilisant XML qui se serve de RelaxNG et non pas les W3C Schema comme langage de schéma, pour décrire les éléments autorisés et leurs relations. À une époque, un groupe de l'IETF avait tenté de rendre obligatoire l'usage des W3C Schema, plus complexes et moins expressifs mais l'IETF avait finalement pris, dans le RFC 3470 une approche plus nuancée, reconnaissant le pluralisme des langages de schémas, même si ce RFC montre un fort biais en faveur des W3C Schemas, utilisés notamment dans les RFC 3730 et RFC 3981.

Ce blog est doté d'un flux de syndication Atom, en /feed.atom. Son moteur de recherche permet de produire le résultat des recherches au format Atom.


Téléchargez le RFC 4287


L'article seul

RFC 4282: The Network Access Identifier

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : B. Aboba (Microsoft), M. Beadles (ENDFORCE), J. Arkko (Ericsson), P. Eronen (Nokia)
Chemin des normes
Première rédaction de cet article le 3 janvier 2006
Dernière mise à jour le 4 janvier 2006


Autrefois, chaque FAI avait sa propre base d'utilisateurs et tous ses équipements réseaux savaient comment interroger cette base. Aujourd'hui, il est de plus en plus fréquent qu'on doive s'authentifier auprès d'un autre FAI que le sien, parce qu'il sous-traite à un vrai opérateur, parce que son réseau de collecte est différent de son épine dorsale, parce qu'on est en déplacement et qu'on bénéficie d'accords de roaming avec un autre FAI... Le network access identifier, décrit dans ce RFC, permet à l'abonné d'avoir une identité unique, que les équipements réseaux du FAI du moment sauront auprès de qui vérifier. (Le NAI a depuis été sérieusement réformé dans le RFC 7542.)

Le NAI est de la forme user@sub.realm.example. Il ressemble syntaxiquement à une adresse de courrier électronique mais n'en est pas une (les règles de syntaxe ne sont même pas exactement identiques, voir la section 2.5 du RFC). La partie droite, le domaine d'authentification (realm), ressemble à un nom de domaine mais ne l'est pas forcément même si c'est conseillé par le RFC (mon NAI actuel est bortzmeyer@net2.nerim.nerim).

C'est ce NAI qu'on configure dans son client réseau, par exemple dans les fichiers du répertoire /etc/ppp sur une machine Unix.

Lorsque le premier équipement réseau du trajet (le RFC le nomme NAS pour Network Access Server) reçoit le NAI, il sait, d'après la partie droite, à qui il doit demander d'authentifier l'utilisateur indiqué en partie gauche. Par exemple, si mon NAI est jean.durand@gold.iap.example, il sait qu'il doit authentifier jean.durand auprès des serveurs (par exemple Radius, RFC 2865) de gold.iap.example.

Notons que, pour faciliter ce routage vers le bon serveur d'authentification, le RFC prévoit une syntaxe (facultative) avec routage explicite (section 2.7), en utilisant le point d'exclamation. Ainsi, myserver.example.org!jean.durand@gold.iap.example est un NAI légal, qui demande que l'authentification passe d'abord par gold.iap.example, qui devra ensuite rediriger vers myserver.example.org.

Notre RFC est une mise à jour du précedent RFC sur les NAI, le RFC 2486. Le principal changement est l'addition de l'internationalisation, qui permet désormais des NAI comme stéphane@immeuble.cité.fr. La partie gauche sera traitée par un profil de l'algorithme stringprep, décrit dans le RFC 4013, la partie droite sera encodée en IDN, immeuble.xn--cit-dma.fr. Le RFC 7542, qui a remplacé notre RFC, a sérieusement changé le modèle d'internationalisation (en supprimant Punycode).


Téléchargez le RFC 4282


L'article seul

RFC 4274: BGP-4 Protocol Analysis

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : D. Meyer (Cisco), K. Patel (Cisco)
Pour information
Première rédaction de cet article le 9 mars 2006


Ce RFC analyse les grandes caractéristiques du protocole BGP.

BGP est un protocole riche et complexe (le RFC 4271 fait 104 pages). Et il est bien agréable d'avoir une analyse qui décrit les principaux éléments de BGP et comment remplit-il son cahier des charges. Si ce RFC n'est pas un tutoriel, et ne dispense pas de lire le RFC 4271, il peut quand même servir de carte pour la navigation dans le monde riche et complexe du routage inter-domaine sur Internet.


Téléchargez le RFC 4274


L'article seul

RFC 4272: BGP Security Vulnerabilities Analysis

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : S. Murphy (Sparta)
Pour information
Première rédaction de cet article le 21 janvier 2006


BGP est un protocole absolument vital au bon fonctionnement de l'Internet et il est toujours amusant et parfois un peu inquiétant de s'apercveoir qu'il est très peu sécurisé. Ce RFC fait le point sur les vulnérabilités de BGP, notamment sur celles qui affectent la communication directe entre deux pairs, deux routeurs BGP.

BGP, décrit dans le RFC 4271, est le protocole d'échange de routes dans l'Internet. Si on peut compromettre des routeurs grâce à une faiblesse de BGP, on peut, comme l'explique bien l'introduction de notre RFC, couper une partie de l'Internet mais aussi détourner tout le trafic à son profit (par exemple pour l'espionner) ou bien tricher sur son adresse IP (une bonne part de la sécurité de l'Internet repose sur le fait qu'avec des protocoles comme TCP, correctement implémentés, tricher sur son adresse IP est difficile ; ce n'est plus vrai si BGP est activement compromis).

Il existe deux façons de s'attaquer à BGP : en attaquant la communication entre deux pairs, deux routeurs BGP qui échangent des routes, ou bien en injectant de fausses informations que les routeurs vont relayer. Notre RFC parle surtout de la première attaque, la seconde, sur laquelle je reviendrai à la fin de cet article, est bien plus difficile à contrer.

Notre RFC décrit de manière très détaillée les failles possibles du protocole, et comment un attaquant peut les utiliser pour s'immiscer dans le bon fonctionnement de BGP.

Il ne fournit pas beaucoup de solutions clé en main : à part une mise en œuvre soignée du protocole, la difficulté de sécuriser BGP ne vient pas tellement du canal de communication entre deux pairs (qui peut être relativement protégé par la signature MD5, RFC 2385, par la plus récente TCP-AO, RFC 5925, ou bien par IPsec) mais du fait que le message lui-même, l'annonce de routes, n'est pas protégé. Autrement dit, un pair BGP peut être authentifié, sans que l'on sache pour autant s'il n'injecte pas de routes invalides, que ce soit délibérement ou parce qu'il relaie ces routes qu'il a lui même reçu d'un pair.

Notre RFC cite quelques protections contre ces routes invalides comme le protocole Secure-BGP qui permet de signer les annonces de route. Comme avec beaucoup de protocoles utilisant des signatures cryptographiques, le problème n'est pas tant le protocole (même si la cryptographie est souvent délicate) que l'infrastructure sociale : qui va signer, qui a l'autorité pour dire que tel opérateur est autorisé ou non à annoncer tel réseau ? Il n'existe aucune autorité suprême coiffant tous les opérateurs Internet et pouvant amorcer le processus de signature. (Le RFC 3779 propose une technique pour encoder ces certificats.) Cette approche a depuis été normalisée, sous le nom de RPKI+ROA, dans une série de RFC.

Le RFC 4272 cite également une autre possibilité : le filtrage de routes, basée sur le contenu des registres de route (IRR pour Internet routing registry), exprimé en langage RPSL (Routing Policy Specification Language, RFC 2622). Ces registres, comme celui du RIPE-NCC, sont notoirement mal tenus et rarement à jour et il est peu réaliste de compter dessus. BGP reste donc assez vulnérable à des injections de routes invalides, injections qui en pratique se produisent assez souvent, en général par accident.

Ces attaques BGP ne sont pas que théorie. Une étude de Georgia Tech montre qu'elles sont réellement utilisées par les spammeurs.


Téléchargez le RFC 4272


L'article seul

RFC 4271: A Border Gateway Protocol 4 (BGP-4)

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : Y. Rekhter, T. Li, S. Hares
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 21 janvier 2006


BGP 4 est aujourd'hui l'unique protocole d'échange de routes entre les opérateurs Internet. Il joue donc un rôle central dans le subtil routage d'une machine à l'autre. Un nouveau RFC vient de remplacer l'ancienne norme, sans guère de changements.

BGP est à la fois peu connu de la majorité des utilisateurs d'Internet et en même temps un outil indispensable. Il y a belle lurette que l'Internet est trop complexe pour que les tables de routage soient mises à jour à la main. Il faut donc un protocole pour échanger l'information de routage entre routeurs et pour calculer ensuite la route nécessaire pour acheminer un paquet d'une machine à l'autre. Il existe deux familles de tels protocoles, pour le routage interne à un opérateur (où les différents routeurs ont, par définition, la même politique) et pour le routage externe, entre '''systèmes autonomes''', c'est-à-dire entre opérateurs. BGP est de cette deuxième famille.

BGP fonctionne entre '''pairs''', deux pairs étant des routeurs qui ont été configurés pour s'échanger des routes. Notre RFC décrit le modèle de table de routage, tel que BGP le considère, les messages que peuvent échanger deux pairs et la façon de représenter l'information sur les routes que ces messages contiennent. Le RFC est relativement complexe (plus de cent pages en tout, ce qui est rare pour un RFC) mais le protocole est riche, car il doit pouvoir être utilisé entre machines gérées par des organismes différents, et il doit permettre l'application de politiques de routage complexes.

Tout ceci était déjà dans le prédécesseur de notre RFC, le RFC 1771. Les nouveautés ultérieures comme les extensions multi-protocoles (spécifiées dans le RFC 4760, elles sont notamment indispensables pour IPv6, décrit dans le RFC 2545) ou comme les capacités (RFC 5492) n'ont pas été incluses, contrairement à ce qui a été fait pour SMTP où le RFC 2821 avait incorporé beaucoup de RFC publiées postérieurement au RFC 822 qu'il remplaçait. Il faut donc toujours lire plusieurs RFC si on veut développer une mise en œuvre de BGP (un défi non trivial).

Les principales nouveautés de notre RFC par rapport à son prédécesseur de mars 1995 sont :

  • L'option d'authentifcation et d'intégrité par signature TCP MD5, spécifiée dans le RFC 2385, devient obligatoire. Elle est très contestée, soit parce qu'elle viole le modèle en couches, soit parce que certains auraient préféré IPsec. Mais il ne fait pas de doute qu'elle est très largement utilisée. Peut-être, depuis la publication du RFC 5925, sera t-elle remplacée par TCP-AO (TCP Authentication Option).
  • Formalisation de ''trucs'' très employés comme la répétition de son propre numéro de système autonome dans le chemin d'AS ou comme la coupure d'une session BGP lorsqu'un pair annonce un nombre de routes supérieur à une certaine limite (ce qui indique en général que ledit pair est mal configuré).

En même temps que notre RFC ont été publiés plusieurs autres RFC liés à BGP, le RFC 4272 sur la sécurité, le RFC 4273 sur la MIB de gestion, le RFC 4274 qui analyse le protocole, le RFC 4275 qui étudie les mises en œuvres de la MIB, le RFC 4276 qui examine les logiciels qui mettent en œuvre BGP, le RFC 4277 qui tire les leçons de la longue expérience de l'Internet avec BGP, et enfin le RFC 4278 sur des détails de la signature TCP MD5.


Téléchargez le RFC 4271


L'article seul

RFC 4264: BGP Wedgies

Date de publication du RFC : Novembre 2005
Auteur(s) du RFC : T. Griffin (University of Cambridge), G. Huston (APNIC)
Pour information
Première rédaction de cet article le 15 décembre 2005


Un assez court RFC, pour décrire un cas pathologique de routage BGP entrainant un coincement permanent dans un état non-optimal.

Depuis sa normalisation sous sa forme actuelle, dans le RFC 1771, le protocole de routage BGP a largement servi l'Internet et a connu peu de problèmes fondamentaux. C'est un des grands succès de l'IETF.

Néanmoins, BGP réserve toujours son lot de surprises : dans un immense réseau sans administration centralisée, comme l'Internet, il y a toujours des cas particuliers gênants. Ce RFC décrit un syndrome particulier, le "coincement" (wedgie), où le routage converge vers un état non-optimal (le trafic IP ne passe pas là où il devrait passer) qui peut être semi-permanent, c'est-à-dire survivre jusqu'au redémarrage d'un ou de plusieurs routeurs.


Téléchargez le RFC 4264


L'article seul

RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : J. Schlyter (OpenSSH), W. Griffin (Sparta)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF secsh
Première rédaction de cet article le 2 avril 2006
Dernière mise à jour le 3 septembre 2007


On le sait, le protocole SSH dépend, pour la sécurité du client, d'une vérification de la clé publique du serveur, lors de la première connexion. Cette vérification étant rarement faite, notre RFC propose un moyen de l'automatiser via le DNS.

Voici une session SSH typique, la première fois qu'on se connecte à foobar.example.org :

% slogin foobar.example.org
The authenticity of host 'foobar.example.org (172.19.1.33)' can't be established.
RSA key fingerprint is 38:e8:5b:3f:25:41:e2:ca:fa:4e:71:38:b8:db:f0:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'foobar.example.org,172.19.1.33' (RSA) to the list of known hosts.
Last login: Sun Apr  2 17:45:12 2006 from ludwigvi.sources.org
NetBSD 3.99.17 (XEN3_U) #5: Sat Mar 25 19:01:14 CET 2006

Comme je ne m'étais jamais connecté depuis cette machine, la clé publique du serveur (dont l'empreinte, le résumé par une fonction de hachage cryptographique, est 38:e8:5b:...) n'était pas stockée (sur Unix, dans ~/.ssh/known_hosts). Comme SSH est sensible aux attaques d'un intermédiaire, une machine qui intercepte la requête du client et prétend être le serveur, il demande une vérification manuelle.

En théorie, je devrais vérifier (par téléphone, par échange d'empreintes signées avec PGP, etc) la clé publique du serveur. En pratique, quasiment personne ne le fait. Comme souvent en cryptographie, on a des techniques formidables et un facteur humain qui fait perdre toute la sécurité qu'aurait pu donner la cryptographie.

Notre RFC propose donc une solution : de distribuer les clés publiques des serveurs SSH via le DNS. Comme celui-ci, par défaut, n'offre aucune sécurité, cela implique évidemment DNSSEC.

Notre RFC normalise donc un nouveau type de données, le SSHFP, qui stocke les empreintes des clés publiques. Par exemple :

       foobar.example.org.  SSHFP 2 1 38e85b3f2541e2cafa4e7138b8dbf0d1

me permettra de vérifier que je me suis bien connecté vers le bon serveur.

À l'heure d'aujourd'hui, si on veut supprimer cette agaçante question affichée plus haut, il faut utiliser un client SSH comme OpenSSH, dans une version très récente, et activer l'option VerifyHostKeyDNS dans le fichier de configuration. Pour publier les clés dans le DNS, le plus simple est sans doute d'utiliser ssh-keygen -r $DOMAIN ou bien le programme sshfp. (Merci à Phil Regnauld pour les détails pratiques. sshfp devrait être remplacé par hash-slinger.)

Si vous voulez voir des enregistrements SSHFP en vrai, il en existe un sur anoncvs.netbsd.org, le serveur CVS anonyme du projet NetBSD :

% dig SSHFP anoncvs.netbsd.org
...
;; ANSWER SECTION:
anoncvs.netbsd.org.	86400	IN	SSHFP	1 1 198C34A92FC0B2AB1DA52B688C2F191D2D960C09

(Ou bien, avec le DNS Looking Glass, en https://dns.bortzmeyer.org/anoncvs.netbsd.org/SSHFP.)

Quelques détails pratiques sur l'utilisation de SSHFP figurent dans « How to get OpenSSH to see DNSSEC AD flags on SSHFP lookups with glibc ». Un autre client SSH qui a SSHFP est GateOne (voir la discussion). Sur leur sécurité avec OpenSSH, voir « On the safety of SSHFP records ». Sur leur production et leur publication lorsqu'on a beaucoup de machines, voir « On collecting SSH host keys for SSHFP DNS records ». Sur les limites et certains problèmes de cette technique, voir, du même auteur, « VerifyHostKeyDNS=maybe ». Un exemple de publication est « SSHFP tutorial: how to get SSHFP records, DNSSEC, and VerifyHostKeyDNS=yes to work » de Tony Finch.


Téléchargez le RFC 4255


L'article seul

RFC 4253: The Secure Shell (SSH) Transport Layer Protocol

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : T. Ylonen (SSH Communications Security Corp, C. Lonvick (Cisco Systems)
Chemin des normes
Première rédaction de cet article le 2 août 2020


Le protocole SSH de sécurité est composé de plusieurs parties, spécifiées dans des RFC différents. Ici, il s'agit de la couche basse de SSH, située juste au-dessus de TCP, et en dessous de protocoles qui permettent, par exemple, la connexion à distance. Cette couche basse fournit l'authentification (de la machine, pas de l'utilisateur) et la confidentialité, via de la cryptographie.

Le principe général de cette partie de SSH est classique, et proche de celui d'autres protocoles de cryptographie comme TLS (RFC 4251 pour une vue générale de l'architecture de SSH). Le client établit une connexion TCP avec le serveur puis chaque partie envoie une liste des algorithmes utilisés pour l'authentification, l'échange de clés et le chiffrement ultérieur. Une fois un accord trouvé, le serveur est authentifié, typiquement par de la cryptographie asymétrique, comme ECDSA. Un mécanisme d'échange de clés comme Diffie-Hellman permet de choisir des clés partagées qui serviront pour les opérations de chiffrement symétrique (par exemple avec AES) qui chiffreront tout le reste de la communication. Ce processus de négociation fournit l'agilité cryptographique (RFC 7696). Du fait de cette agilité, la liste des algorithmes utilisables n'est pas figée dans les RFC. Démarrée par le RFC 4250, sa version à jour et faisant autorité est à l'IANA.

Notez que j'ai simplifié le mécanisme de négociation : il y a d'autres choix à faire dans la négociation, comme celui de l'algorithme de MAC. Les autres fonctions de SSH, comme l'authentification du client, prennent place ensuite, une fois la session de transport établie selon les procédures définies dans notre RFC 4253.

L'établissement de connexion est normalisé dans la section 4 du RFC. SSH suppose qu'il dispose d'un transport propre, acheminant des octets sans les modifier et sans les interpréter. (TCP répond à cette exigence, qui est très banale.) Le port par défaut est 22 (et il est enregistré à l'IANA, lisez donc le récit de cet enregistrement). En pratique, il est fréquent que SSH utilise d'autres ports, par exemple pour ralentir certaines attaques par force brute (OpenSSH rend cela très simple, en indiquant dans son ~/.ssh/config le port du serveur où on se connecte). Une fois la connexion TCP établie, chaque machine envoie une bannière qui indique sa version de SSH, ici la version 2 du protocole (la seule survivante aujourd'hui) et la version 7.6 de sa mise en œuvre OpenSSH :

% telnet localhost 22
...
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
  

Un établissement de session complet comprend :

  • Connexion TCP,
  • envoi des bannières (qui peut être fait simultanément par le serveur et le client, pas besoin d'attendre l'autre),
  • début de la procédure d'échange de clés (KEX, pour Key EXchange) avec les messages SSH_MSG_KEXINIT (qui peuvent aussi être envoyés simultanément),
  • échange de clés proprement dit, par exemple avec des messages Diffie-Hellman.

Comme certains messages peuvent être envoyés en parallèle (sans attendre l'autre partie), il est difficile de compter combien d'aller-retours cela fait. (Optimiste, le RFC dit que deux aller-retours suffisent dans la plupart des cas.)

Le protocole décrit dans ce RFC peut être utilisé pour divers services (cf. RFC 4252 et RFC 4254). Une des utilisations les plus fréquentes est celle de sessions interactives à distance, où SSH avait rapidement remplacé telnet. À l'époque, certaines personnes s'étaient inquiétées de l'augmentation de taille des paquets due à la cryptographie (nouveaux en-têtes, et MAC). Le débat est bien dépassé aujourd'hui mais une section 5.3 du RFC discute toujours la question. SSH ajoute au moins 28 octets à chaque paquet. Pour un transfert de fichiers, où les paquets ont la taille de la MTU, cette augmentation n'est pas importante. Pour les sessions interactives, où il n'y a souvent qu'un seul octet de données dans un paquet, c'est plus significatif, mais il faut aussi prendre en compte le reste des en-têtes. Ainsi, IP et TCP ajoutent déjà 32 octets au minimum (en IPv4). Donc l'augmentation due à SSH n'est pas de 2800 % mais de seulement 55 %. Et c'est sans même prendre en compte les en-têtes Ethernet. En parlant d'Ethernet, il faut aussi noter que la taille minimale d'une trame Ethernet est de 46 octets (cf. RFC 894), de toute façon et que donc, sans SSH, il faudrait de toute façon remplir la trame… Bref, le problème n'est guère important. (Le RFC donne un autre exemple, avec des modems lents, qui n'est probablement plus d'actualité aujourd'hui.)

La section 6 du RFC décrit ensuite le format des en-têtes SSH, un format binaire, comme le DNS ou BGP, mais pas comme SMTP ou HTTP version 1. Le tout est évidemment chiffré (même la longueur du paquet, qu'on ne peut donc pas connaitre avant de déchiffrer). Le chiffrement se fait avec l'algorithme sélectionné dans la phase de négociation. Si vous utilisez OpenSSH, l'option -v affichera l'algorithme, ici ChaCha20 :


% ssh -v $ADDRESS
...
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

  

ChaCha20 n'existait pas à l'époque du RFC 4253. Il n'est toujours pas enregistré à l'IANA. C'est ce qui explique que le nom d'algorithme inclut un arobase suivi d'un nom de domaine, c'est la marque des algorithmes locaux (ici, local à OpenSSH), non enregistrés officiellement. Un article du programmeur décrit l'intégration de ChaCha20 dans OpenSSH. Il y avait eu une tentative de normalisation (dans l'Internet-Draft draft-josefsson-ssh-chacha20-poly1305-openssh) mais elle a été abandonnée. C'était peut-être simplement par manque de temps et d'intérêt, car ChaCha20 est utilisé dans d'autres protocoles cryptographiques de l'IETF comme TLS (cf. RFC 7905 et, pour une vision plus générale, RFC 8439). OpenSSH permet d'afficher la liste des algorithmes de chiffrement symétriques qu'il connait avec l'option -Q cipher :

% ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
  

À l'inverse, le RFC 4253 listait des algorithmes qui ont été abandonnés depuis comme RC4 (nommé arcfour dans le RFC pour des raisons juridiques), retiré par le RFC 8758. La liste comprend également l'algorithme none (pas de chiffrement) qui avait été inclus pour des raisons douteuses de performance et dont l'usage est évidemment déconseillé (section 6.3 de notre RFC).

Le paquet inclut également un MAC pour assurer son intégrité. Il est calculé avant le chiffrement. Pour le MAC aussi, la liste des algorithmes a changé depuis la parution du RFC 4253. On peut afficher ceux qu'OpenSSH connait (les officiels sont dans un registre IANA) :

% ssh -Q mac        
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com
  

Bon, mais les algorithmes de chiffrement symétrique comme ChaCha20 nécessitent une clé secrète et partagée entre les deux parties. Comment est-elle négociée ? Un algorithme comme par exemple Diffie-Hellman sert à choisir un secret, d'où sera dérivée la clé.

Le format binaire des messages est décrit en section 6 en utilisant des types définis dans le RFC 4251, section 5, comme byte[n] pour une suite d'octets ou uint32 pour un entier non signé sur 32 bits. Ainsi, un certificat ou une clé publique sera :

string    certificate or public key format identifier
byte[n]   key/certificate data
    

Un paquet SSH a la structure (après le point-virgule, un commentaire) :

uint32    packet_length
byte      padding_length
byte[n1]  payload; n1 = packet_length - padding_length - 1
byte[n2]  random padding; n2 = padding_length
byte[m]   mac (Message Authentication Code - MAC); m = mac_length    
  

La charge utile (payload) a un format qui dépend du type de messages. Par exemple, le message d'échange de clés initial, où chacun indique les algorithmes qu'il connait :

byte         SSH_MSG_KEXINIT
byte[16]     cookie (random bytes)
name-list    kex_algorithms
name-list    server_host_key_algorithms
name-list    encryption_algorithms_client_to_server
name-list    encryption_algorithms_server_to_client
name-list    mac_algorithms_client_to_server
name-list    mac_algorithms_server_to_client
name-list    compression_algorithms_client_to_server
name-list    compression_algorithms_server_to_client
name-list    languages_client_to_server
name-list    languages_server_to_client
boolean      first_kex_packet_follows
uint32       0 (reserved for future extension)
    

Les types de message (message ID ou message numbers) possibles sont listés dans un registre IANA. Par exemple l'exemple ci-dessus est un message de type SSH_MSG_KEXINIT, type qui est défini en section 12 et dans le RFC 4250, section 4.1.2. Il a la valeur 20.

Affiché par Wireshark, voici quelques messages que SSH transmet en clair, avant le début du chiffrement. Après l'échange des bannières, il y aura le KEXINIT en clair, Wireshark suit les termes du RFC donc vous pouvez facilement comparer ce message réel à la description abstraite du RFC, ci-dessus :

    
SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 1388
        Padding Length: 4
        Key Exchange
            Message Code: Key Exchange Init (20)
            Algorithms
                kex_algorithms length: 269
                kex_algorithms string [truncated]: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,di
                server_host_key_algorithms length: 358
                server_host_key_algorithms string [truncated]: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25
                encryption_algorithms_client_to_server length: 108
                encryption_algorithms_client_to_server string: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
                encryption_algorithms_server_to_client length: 108
                encryption_algorithms_server_to_client string: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
                mac_algorithms_client_to_server length: 213
                mac_algorithms_client_to_server string [truncated]: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-
                mac_algorithms_server_to_client length: 213
                mac_algorithms_server_to_client string [truncated]: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-
                compression_algorithms_client_to_server length: 26
                compression_algorithms_client_to_server string: none,zlib@openssh.com,zlib
                compression_algorithms_server_to_client length: 26
                compression_algorithms_server_to_client string: none,zlib@openssh.com,zlib

  

Notez qu'un seul message SSH contient tous les algorithmes, aussi bien ceux servant à l'authentification qu'à l'échange de clés, ou qu'au chiffrement symétrique. Le premier algorithme listé est le préféré. Si les deux parties ont le même algorithme préféré, il est choisi. Autrement, on boucle sur les algorithmes listés par le client, dans l'ordre, en sélectionnant le premier qui est accepté par le serveur. Voici maintenant le lancement de l'échange de clés :


SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 44
        Padding Length: 6
        Key Exchange
            Message Code: Diffie-Hellman Key Exchange Init (30)
            Multi Precision Integer Length: 32
            DH client e: c834ef50c9ce27fa5ab43886aec2161a3692dd5e3267b567...
            Padding String: 000000000000

  

Et la réponse en face :

    
SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 260
        Padding Length: 9
        Key Exchange
            Message Code: Diffie-Hellman Key Exchange Reply (31)
            KEX host key (type: ecdsa-sha2-nistp256)
            Multi Precision Integer Length: 32
            DH server f: 2e34deb08146063fdba1d8800cf853a3a6830a3b8549ee5b...
            KEX H signature length: 101
            KEX H signature: 0000001365636473612d736861322d6e6973747032353600...
            Padding String: 000000000000000000
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 12
        Padding Length: 10
        Key Exchange
            Message Code: New Keys (21)
            Padding String: 00000000000000000000

  

À partir de là, tout est chiffré et Wireshark ne peut plus afficher que du binaire sans le comprendre :

    
SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length (encrypted): 44cdc717
        Encrypted Packet: ea98dbf6cc50af65ba4186bdb5bf02aa9e8366aaa4c1153f
        MAC: e7a6a5a222fcdba71e834f3bb76c2282

  

OpenSSH avec son option -v permet d'afficher cette négociation :

    
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

  

Et les algorithmes acceptés pour l'échange de clés :

% ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
  

(Ceux à courbes elliptiques comme curve25519-sha256 n'existaient pas à l'époque. curve25519-sha256 a été ajouté dans le RFC 8731.) On trouve aussi les algorithmes acceptés pour l'authentification du serveur via sa clé publique :

% ssh -Q key    
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com
  

Ce RFC 4253 ne décrit que la couche basse de SSH. Au-dessus se trouvent plusieurs services qui tirent profit de la sécurité fournie par cette couche basse. Une fois la session chiffrée établie, le protocole SSH permet de lancer d'autres services. Ils ne sont que deux depuis le début, mais d'autres pourront se rajouter dans le registre IANA. Actuellement, il y a ssh-userauth (authentifier l'utilisateur, par mot de passe ou par clé publique, RFC 4252) et ssh-connection (connexion à distance, et services qui en dépendent, cf. RFC 4254).

Nous avons vu plus haut le type de messages SSH_MSG_KEXINIT (code numérique 20). Il y a de nombreux autres types, présentés dans la section 11 du RFC. Par exemple SSH_MSG_DISCONNECT (type 1 dans le registre IANA) est défini ainsi :

byte      SSH_MSG_DISCONNECT
uint32    reason code
string    description in ISO-10646 UTF-8 encoding [RFC3629]
string    language tag [RFC3066]
  

Il indique la fin de la session SSH (l'étiquette de langue pour indiquer la raison est désormais normalisée dans le RFC 5646, et plus le RFC 3066). Autre exemple, SSH_MSG_IGNORE (code 2) pour faire du remplissage afin de diminuer les risques d'analyse du trafic. Pour une vision complète des risques de sécurité de SSH, (re)lisez la très détaillée section 9 du RFC 4251.

Notez qu'il avait existé une version 1 du protocole SSH, qui n'a pas fait l'objet d'une normalisation formelle. La section 5 de notre RFC traite de la compatibilité entre la version actuelle, la 2, et cette vieille version 1, aujourd'hui complètement abandonnée. Ça, c'est le passé. Et le futur ? Le cœur de SSH n'a pas bougé depuis les RFC de la série du RFC 4250 au RFC 4254. Mais il existe un projet (pour l'instant individuel, non accepté par l'IETF de remplacer ce RFC 4253 par QUIC, en faisant tourner le reste de SSH sur QUIC (lisez draft-bider-ssh-quic).


Téléchargez le RFC 4253


L'article seul

RFC 4251: The Secure Shell (SSH) Protocol Architecture

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : T. Ylonen (SSH communications security), C. Lonvick (Cisco)
Chemin des normes
Première rédaction de cet article le 27 février 2009


Pendant longtemps, les connexions interactives à une machine distante, via l'Internet, se faisaient par un protocole (telnet ou rlogin) qui ne chiffrait pas les communications et notamment le mot de passe échangé pour s'authentifier. D'innombrables sniffers ont ainsi capturés des mots de passe et les ont ensuite transmis à Eve, pour qu'elle en fasse un mauvais usage. L'arrivée de SSH, en 1995, a donc bouleversé la sécurité sur Internet. Sa simplicité d'usage, la possibilité de résoudre enfin la majorité des problèmes de sécurité de X11, et la sécurité qu'il offre lui ont permis de l'emporter facilement contre des concurrents compliqués à déployer et à utiliser comme Kerberos telnet.

SSH est désormais un des protocoles de base de l'infrastructure d'Internet. Il a plusieurs mises en œuvre dont une en logiciel libre, OpenSSH. Longtemps spécifié uniquement dans les documents liés à une mise en œuvre particulière, SSH est aujourd'hui normalisé dans une série de RFC dont ce RFC 4251 est le point de départ. Il décrit l'architecture générale, le RFC 4252 décrit le protocole d'authentification, le RFC 4253 le protocole de transport, le RFC 4254 le protocole de connexion et le RFC 4250 les différents identificateurs utilisés par SSH.

Les différents protocoles sont résumés dans la section 1 :

  • Tout en bas, le protocole de transport (RFC 4253), authentifie le serveur et chiffre les communications avec lui.
  • Un cran au dessus, le protocole d'authentification (RFC 4252) permet au client de s'authentifier auprès du serveur.
  • Enfin, tout en haut, le protocole de connexion (RFC 4254) multiplexe plusieurs canaux (par exemple une session interactive de type shell et une session X11) sur un seul transport chiffré.

Quels sont les composants essentiels de SSH ? La section 4 les énumère. D'abord, il y a la notion de clé de machine (section 4.1). Il n'existe pas sur Internet de mécanisme général d'identité des machines. Ce manque est parfois gênant, par exemple dans un réseau pair-à-pair où on essaie de garder trace des services que rend un pair, ou bien dans des modèles de sécurité comme la Same Origin Policy de Javascript où le navigateur Web ne peut se connecter qu'à « la même machine » que celle d'où vient le code Javascript, sans que « la même machine » soit une notion définie rigoureusement, ce qui permet les changements d'adresse IP.

SSH fonctionne donc en donnant à chaque machine une identité qui est sa clé publique (stockée, avec OpenSSH, en /etc/ssh/ssh_host_dsa_key.pub). Cette clé permettra de s'assurer qu'on parle bien à la machine attendue. Quel modèle de confiance utiliser ? Le RFC en cite deux, une base locale des clés publiques des machines connues, qui a l'avantage de ne pas nécessiter de lourdes et chères PKI, ou bien une PKI, avec une CA qui signe les clés. SSH n'impose pas un modèle particulier mais encourage la première méthode. En effet, le RFC insiste beaucoup sur la nécessité pour le protocole d'être facile à utiliser et facilement déployable. Les PKI en sont tout l'opposé et, si SSH avait imposé l'usage d'une PKI, il n'aurait probablement jamais connu de succès (le RFC 5218 discute ce point). (Depuis, le RFC 4255 a fourni un mécanisme permettant de récupérer la clé dans le DNS ; sans DNSSEC, ce mécanisme ne vaut pas grand'chose.)

Pour peupler cette base locale, la même section 4.1 conseille un modèle dit TOFU (Trust On First Use) ou encore (mais ce terme est moins précis) leap of faith (acte de foi), où la clé est vérifiée systématiquement, sauf à la première connexion, où on demande juste à l'utilisateur son accord pour enregistrer la nouvelle machine, en lui indiquant l'empreinte de la clé publique :

% ssh susanna
The authenticity of host 'susanna (2001:660:3003:3::1:3)' can't be established.
DSA key fingerprint is 56:b7:62:30:11:d3:6d:b6:d5:ec:5d:1e:7e:3c:42:1e.
Are you sure you want to continue connecting (yes/no)? 

Si ce modèle rencontre l'opposition de certains experts en sécurité (car il rend SSH vulnérables aux attaques de l'homme du milieu lors de la première connexion), c'est aussi lui qui a permis le succès du déploiement de SSH, d'autant plus qu'il n'existe aucune PKI largement déployée sur l'Internet. Ici, le mieux était clairement l'ennemi du bien si on avait attendu une telle PKI, on utiliserait toujours des connexions non chiffrées et bien plus vulnérables. (La section 9.3.4 revient en grand détail sur le risque d'attaque par l'homme du milieu et sur la vérification des clés des machines auxquelles on se connecte.)

(À noter qu'aujourd'hui, des techniques comme Perspectives tentent d'améliorer le système TOFU.)

Les clés SSH sont donc en général non signées. On peut aussi, outre les clés des machines, avoir des clés liées à un utilisateur. Celui-ci les génère, avec OpenSSH, en tapant ssh-keygen, et peut les utiliser pour s'authentifier, ce qui est plus sûr qu'un mot de passe, car cela évite de transmettre un secret réutilisable (le mot de passe) à une machine pas forcément fiable (le serveur). Les sections 9.4.4 et 9.4.5 discutent les forces et les faiblesses des deux mécanismes d'authentification : la clé publique ne nécessite pas de transmettre un secret au serveur mais sa compromission sur la machine client est toujours possible, et le serveur ne peut pas contrôler si la machine client applique de bonnes politiques de sécurité.

Comme précisé dans la section 4.5, SSH peut utiliser plusieurs algorithmes. La cryptographie et la cryptanalyse évoluent en effet sans cesse et il peut être nécessaire de changer les algorithmes de cryptographie utilisés, sans changer le protocole (cf. section 9.3.1). Pour cela, chaque algorithme a un nom (la section 6 détaille les règles de nommage) et peut être négocié à l'établissement de la connexion (avec OpenSSH, option -c en ligne de commande et mot-clé Ciphers dans sshd_config). Les algorithmes officiels sont enregistrés dans un registre IANA et les non-officiels ont un nom qui inclus un @, par exemple mon-algo@leroidelacrypto.fr.

La section 9, consacrée à l'étude détaillée des questions de sécurité est évidemment particulièrement longue. C'est une lecture indispensable pour qui veut évaluer la sécurité de SSH. 9.1 rappelle l'importance cruciale de bons algorithmes de génération de nombres aléatoires, une faiblesse classique en cryptographie (bien illustrée, par exemple, par la faille Debian/OpenSSL, qui a affecté OpenSSH sur Debian). Il est donc nécessaire de suivre les consignes du RFC 4086.

La section 9.3.1 discute le choix des algorithmes de cryptographie, en recommandant de s'appuyer sur l'état actuel de la science, en utilisant des algorithmes reconnus comme AES.

Certaines fonctions de SSH sont débrayables. La section 9.3.2 rappelle que le contrôle d'intégrité par MAC peut être ainsi coupé (option -m de OpenSSH) et insiste que cela doit être fait uniquement pour le débogage.

Tous les systèmes utilisant la cryptographie sont vulnérables à des attaques DoS où l'attaquant va déclencher chez sa victime de lourds calculs... sans aller jusqu'à s'authentifier. La section 9.3.5 recommande donc de permettre de limiter les tentatives depuis certaines machines (avec OpenSSH, on utilise en général les tcpwrappers pour cela et on met quelque chose comme sshd: [2001:DB8:0:1::]/64 dans /etc/hosts.allow et pour arrêter les machines en dehors de 2001:DB8:0:1::/64, on a sshd: ALL dans /etc/hosts.deny.

Pour illustrer un certain nombre de points de SSH, voici le résultat d'un ssh -v depuis une machine OpenSSH (Debian) depuis une autre (Gentoo) :

OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
...
debug1: Connecting to munzer.bortzmeyer.org [10.75.84.80] port 6622.
debug1: Connection established.

La connexion TCP a été établie.

...
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024

Le test ci-dessus est spécifique à Debian et correspond à la faille Debian 1571.

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
...
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none

Ici, les algorithmes de cryptographie acceptés ont été transmis (section 4.5 du RFC). Le premier est AES.

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: checking without port identifier
debug1: Host 'munzer.bortzmeyer.org' is known and matches the RSA host key.
debug1: Found key in /home/stephane/.ssh/known_hosts:24
debug1: ssh_rsa_verify: signature correct

Ici, la vérification de la machine distante, munzer.bortzmeyer.org, a été faite. Déjà connue, sa clé a été acceptée.

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/stephane/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).

Une authentification de l'utilisateur par la clé publique DSA qu'il a présentée a marché.

debug1: Entering interactive session.

Et le reste n'est plus que formalité...

Si, par contre, une machine s'était glissée au milieu, devant le serveur attendu, on aurait obtenu le fameux message :

The authenticity of host '[munzer.bortzmeyer.org]:6622 ([10.75.84.80]:6622)' can't be established.
RSA key fingerprint is ac:73:5e:34:59:29:7f:4a:a0:9f:56:d4:00:21:fe:c6.
Are you sure you want to continue connecting (yes/no)? 

SSH est aujourd'hui présent sur pratiquement, toutes les machines, du téléphone portable au commutateur Ethernet. Malgré cela, les mauvaises habitudes ont la vie dure et le rapport 2008 d'Arbor Network sur la sécurité remarquait que 24 % des opérateurs utilisaient toujours telnet (et ce rapport est basé uniquement sur les déclarations des acteurs, qui n'ont pas intérêt à avouer de telles faiblesses ; le chiffre réel est donc probablement supérieur.).


Téléchargez le RFC 4251


L'article seul

RFC 4236: HTTP Adaptation with Open Pluggable Edge Services (OPES)

Date de publication du RFC : Novembre 2005
Auteur(s) du RFC : A. Rousskov (Measurement factory), M. Stecher (CyberGuard)
Chemin des normes
Première rédaction de cet article le 6 décembre 2005


OPES est composé d'un grand nombre de RFC. Celui-ci décrit l'adaptation d'OPES au cas du protocole HTTP, le protocole principal du Web.

S'appuyant sur les RFC 3835, pour la description de l'architecture, et RFC 4037 pour OCP, le protocole de communication entre un processeur OPES et son serveur sous-traitant, notre RFC décrit les adaptations spécifiques à HTTP, quels messages transmettre, lesques peuvent être ignorés, les transformations autorisées et sous quelles conditions, etc.

OPES spécifiant que les processeurs OPES doivent obéir à une exigence de traçabilité et laisser trace de leur activité, ce RFC spécifie deux nouveaux en-têtes HTTP que nous verrons dans les flux HTTP, dès que des processeurs OPES seront déployés : OPES-System, le principal, qui identifiera le processeur OPES, et OPEN-Via.

Les deux exemples complets de session donnés par notre RFC concernent un application classique pour le Web, le filtrage de certains URL (le processeur OPES reçoit une demande GET et renvoie une erreur 403, "accès interdit") et un service de traduction au vol des pages, plus futuriste.


Téléchargez le RFC 4236


L'article seul

RFC 4234: Augmented BNF for Syntax Specifications: ABNF

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : D. Crocker (Brandenburg InternetWorking), P. Overell (THUS plc.)
Chemin des normes
Première rédaction de cet article le 7 septembre 2006
Dernière mise à jour le 1 février 2008


Ce RFC, désormais remplacé par le RFC 5234, fait partie des RFC ancillaires, qui ne spécifient pas directement un protocole IETF mais fournissent des outils pour les "vrais" RFC. En l'occurrence, il normalise le mini-language pour écrire des grammaires.

Beaucoup de RFC doivent spécifier un langage, en général assez simple (jamais de la taille d'un langage de programmation) mais néanmoins suffisamment important pour que les descriptions informelles du langage soient risquées. Depuis longtemps, on utilise en informatique des notations dérivées du langage BNF pour spécifier formellement un langage. Le problème est qu'il existe plusieurs dialectes de BNF (comme EBNF) et que les RFC ont besoin d'une référence stable. D'où ce RFC, qui succède au fameux RFC 2234 (avec très peu de changements), et qui a lui-même été remplacé par le RFC 5234. Il décrit ABNF, le dialecte IETF de BNF. Classique sur beaucoup de points, ce dialecte a quand même quelques variations, issues d'une histoire très ancienne. Par exemple, le signe | pour le choix est remplacé par /.

Quelques outils sont disponibles pour aider les auteurs de grammaires. Mais je trouve que c'est encore insuffisant. S'il existe deux vérificateurs (qui peuvent tester qu'une grammaire est cohérente), il n'existe guère de générateurs d'analyseurs syntaxiques. En revanche, à des fins de test, il existe un programme, Eustathius, qui génère automatiquement des exemples à partir d'une grammaire. Vous trouverez de nombreux exemples de grammaires ABNF dans les sources d'Eustathius.

À titre d'exemple, voici la spécification de SPF (décrit dans le RFC 4408) en ABNF :


   record           = version terms *SP
   version          = "v=spf1"

   terms            = *( 1*SP ( directive / modifier ) )

   directive        = [ qualifier ] mechanism
   qualifier        = "+" / "-" / "?" / "~"
   mechanism        = ( all / include
                      / A / MX / PTR / IP4 / IP6 / exists )

   all              = "all"
   include          = "include"  ":" domain-spec
   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
   PTR              = "ptr"    [ ":" domain-spec ]
   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
   exists           = "exists"   ":" domain-spec

   modifier         = redirect / explanation / unknown-modifier
   redirect         = "redirect" "=" domain-spec
   explanation      = "exp" "=" domain-spec
   unknown-modifier = name "=" macro-string

   ip4-cidr-length  = "/" 1*DIGIT
   ip6-cidr-length  = "/" 1*DIGIT
   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

   ip4-network      = qnum "." qnum "." qnum "." qnum
   qnum             = DIGIT                 ; 0-9
                      / %x31-39 DIGIT       ; 10-99
                      / "1" 2DIGIT          ; 100-199
                      / "2" %x30-34 DIGIT   ; 200-249
                      / "25" %x30-35        ; 250-255
             ; conventional dotted quad notation.  e.g., 192.0.2.0
   ip6-network      = <as per [RFC 3513], section 2.2>
             ; e.g., 2001:DB8::CD30

   domain-spec      = macro-string domain-end
   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
   toplabel         = ( *alphanum ALPHA *alphanum ) /
                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
                      ; LDH rule plus additional TLD restrictions
                      ; (see [RFC3696], Section 2)

   alphanum         = ALPHA / DIGIT

   explain-string   = *( macro-string / SP )

   macro-string     = *( macro-expand / macro-literal )
   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
                      / "%%" / "%_" / "%-"
   macro-literal    = %x21-24 / %x26-7E
                      ; visible characters except "%"
   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
                      "c" / "r" / "t"
   transformers     = *DIGIT [ "r" ]
   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="

   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )

   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
                      [ key-value-list ] CRLF

   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
                      "None" / "TempError" / "PermError"

   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
                      [";"]

   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )

   key              = "client-ip" / "envelope-from" / "helo" /
                      "problem" / "receiver" / "identity" /
                       mechanism / "x-" name / name

   identity         = "mailfrom"   ; for the "MAIL FROM" identity
                      / "helo"     ; for the "HELO" identity
                      / name       ; other identities

   dot-atom         = <unquoted word as per [RFC2822]>
   quoted-string    = <quoted string as per [RFC2822]>
   comment          = <comment string as per [RFC2822]>
   CFWS             = <comment or folding white space as per [RFC2822]>
   FWS              = <folding white space as per [RFC2822]>
   CRLF             = <standard end-of-line token as per [RFC2822]>


Téléchargez le RFC 4234


L'article seul

RFC 4228: Requirements for an IETF Draft Submission Toolset

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : A. Rousskov (The Measurement Factory)
Pour information
Première rédaction de cet article le 8 mars 2006


Il est banal de dire que les cordonniers sont les plus mal chaussés. L'IETF, l'organisme qui normalise les protocoles de l'Internet traite ses projets de norme de manière encore très manuelle. Mais voici un cahier des charges pour la future automatisation.

Les fameux RFC, parmi lesquels se trouvent les normes de l'Internet, commencent leur vie comme Internet-drafts. Ces projets sont soumis au secrétariat de l'IETF, publiés par l'IETF et une minorité d'entre eux deviendront des RFC. Notre RFC explique comment soumettre un draft à l'heure actuelle et c'est un processus très manuel, lent, et propice aux erreurs.

L'IETF prend donc le taureau par les cornes et publie un cahier des charges pour le futur outil (The Toolset) de soumission. Les auteurs disposeront d'une interface Web pour voir leurs soumissions et les annuler éventuellement. L'outil devra pouvoir faire automatiquement un certain nombre de vérifications (comme la syntaxe du titre, ou comme la présence des textes juridiques obligatoires), générer le draft à partir de son source XML, etc.

Naturellement, le RFC insiste beaucoup sur l'importance que le futur outil soit ouvert et pérenne, donc en logiciel libre.


Téléchargez le RFC 4228


L'article seul

RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : E. Nordmark (Sun Microsystems), R. Gilligan (Intransa)
Chemin des normes
Première rédaction de cet article le 19 décembre 2005


La version actuelle, la 4, du protocole IP avait eu bien de la chance, d'être déployée dans un environnement quasi-vierge. IP version 6 doit au contraire se frayer un passage dans un monde où tout est en IPv4. D'où l'importance des mécanismes de transition, dont ce RFC décrit deux exemples.

Cette transition est un des principaux défis auquel doit faire face IPv6. Il est même possible que sa difficulté soit la cause principale de ses problèmes, plus que ses qualités ou défauts intrinsèques.

Mettant à jour le RFC 2893, notre RFC décrit deux mécanismes (il en existe de nombreux autres, plus exotiques) pour assurer la transition : la "double pile" qui consiste pour une machine à avoir les deux protocoles (et donc les deux compétences pour son administrateur) et le tunnel configuré pour faire passer de l'IPv6 dans un Internet très majoritairement IPv4.

Dans le premier cas, la machine a les deux protocoles et, parfaitement bilingue, peut parler avec n'importe quelle autre machine, que cette dernière soit v4 ou bien v6. Mais cela empêche d'abandonner IPv4 et sa pénurie d'adresses. Et cela ne résout pas tous les problèmes comme par exemple "Quelle adresse choisir si la machine avec laquelle je veux parler est également double pile ?" (très partiellement discuté dans la section DNS du RFC).

Le tunnel traite un problème un peu différent : une des extrémités du tunnel met les paquets IPv6 dans un paquet IPv4, les envoie à l'autre extrémité du tunnel, où on décapsule le paquet IPv6. La technique étant relativement complexe dans ses détails, elle forme l'essentiel de notre RFC.

Pour plusieurs raisons, comme le problème de MTU que notre RFC discute en profondeur, les performances sont alors moins bonnes.

Dans le cas du tunnel, deux machines qui n'ont qu'IPv6 peuvent se parler au travers de l'Internet actuel (peu d'opérateurs routent la v6). Mais cela ne résout pas le problème de parler aux machines purement v4 (comme l'est, aujourd'hui, www.bortzmeyer.org).


Téléchargez le RFC 4213


L'article seul

RFC 4193: Unique Local IPv6 Unicast Addresses

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : R. Hinden (Nokia), B. Haberman (JHU-APL)
Chemin des normes
Première rédaction de cet article le 26 novembre 2005


Le RFC 3513 sur l'adressage IPv6 spécifiait des adresses purement locales à un site, les adresses site-local qui commençaient par FEC0::/10. Ces adresses ayant été rendues obsolètes par le RFC 3879, notre RFC 4193 spécifie un remplacement : des adresses quasi-uniques mais attribuées sans registre central.

Les adresses locales à un site ont été très utiles lorsque les RIR n'attribuaient pas d'adresses IPv6 et qu'il était difficile d'en obtenir. Elles permettaient de se mettre doucement à IPv6, sans démarches bureaucratiques. Mais elles avaient le même inconvénient que les adresses privées IPv4 du RFC 1918 : en cas de connexion de deux sites utilisant ces adresses (par exemple suite à une fusion d'entreprises), le risque de collision est élevé.

Notre RFC propose donc une meilleure solution : dans un espace réservé, FC00::/7, le site qui souhaite des adresses quasi-uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC, qui utilise l'heure et l'adresse MAC comme point de départ, et a pour but d'éviter que tout le monde prenne le même préfixe. La probabilité de collision entre sites est donc très faible, vue la taille de l'espace d'adressage de IPv6.

Si on veut son ULA (Unique Local Address), on peut faire tourner cet algorithme en http://www.kame.net/~suz/gen-ula.html ou en http://www.sixxs.net/tools/grh/ula/.


Téléchargez le RFC 4193


L'article seul

RFC 4192: Procedures for Renumbering an IPv6 Network without a Flag Day

Date de publication du RFC : Septembre 2005
Auteur(s) du RFC : F. Baker (Cisco), E. Lear (Cisco), R. Droms (Cisco)
Pour information
Première rédaction de cet article le 22 octobre 2005


Rénuméroter son réseau, par exemple, parce qu'on change de fournisseur d'accès, n'a jamais été drôle. C'est même souvent pénible, l'adresse IP du réseau se trouvant en général dans de nombreux endroits sur les machines. Sur Unix, un outil comme grep est une aide considérable pour retrouver ces endroits. Si on a la chance d'avoir des adresses PI (Provider Independant), on ne connaitra pas ls joies de la renumérotation. Sinon, il faudra lire ce RFC.

IPv6 rend théoriquement les choses plus faciles. Notamment parce qu'il permet, depuis le début, d'attribuer plusieurs adresses IP à la même interface (c'est en général possible également en IPv4 mais c'est moins bien géré, car cela été ajouté après).

Le RFC dresse une liste de tout ce qui peut avoir besoin de changer lors de cette opération. La liste est suffisamment longue pour qu'il n'y aie aucun espoir de tout réussir en une seule journée, le flag day.

Puis il décrit la procédure à suivre soigneusement, en n'oubliant rien et en étant conscient, comme le rappelle Clausewitz, cité par le RFC, que de toute façon quelque chose ira mal...

Une grande partie de cette procédure peut d'ailleurs également convenir pour IPv4. Souhaitons que ce RFC soit donc largement utilisé pour limiter les cafouillages qui se présentent souvent lors d'une telle opération.


Téléchargez le RFC 4192


L'article seul

RFC 4186: Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : H. Haverinen (Nokia), J. Salowey (Cisco)
Pour information
Première rédaction de cet article le 24 octobre 2006


L'IETF a normalisé un cadre de définition des protocoles d'authentification, EAP (RFC 3748). Ce profil d'EAP est appliqué aux réseaux GSM (les réseaux comme UMTS ont un autre protocole).

Comme le sait tout possesseur d'un téléphone portable, l'information sur l'utilisateur n'est pas contenue dans le téléphone mais dans la carte SIM, démontable. D'où le nom de ce protocole, EAP-SIM. Défini au sein du cadre EAP, il permet d'authentifier le possesseur de la carte, via un NAI (RFC 7542).

EAI-SIM est fort complexe (le RFC fait presque cent pages) car la sécurité est un domaine délicat. Le RFC est plein de sigles issus du monde des télécoms.

EAP-SIM prévoit également l'anonymat (section 4.2.1.2) en générant un pseudonyme pour l'utilisateur.

On notera que, comme beaucoup d'autres RFC, il ne spécifie pas une norme Internet, n'ayant été publié que "pour information", après avoir été écrit par le forum 3GPP.


Téléchargez le RFC 4186


L'article seul

RFC 4185: National and Local Characters for DNS Top Level Domain (TLD) Names

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : John Klensin
Pour information
Première rédaction de cet article le 21 octobre 2005


Depuis que les noms de domaine en Unicode sont disponibles (IDN, décrits en RFC 3490), la question se pose d'enregistrer des domaines de premier niveau (TLD, Top Level Domain comme .org ou .ci) en Unicode. Le problème n'est pas technique (un TLD est un domaine comme un autre et peut être enregistré grâce aux IDN) mais politique.

L'ajout de nouveaux TLD est en effet contrôlé par le gouvernement des États-Unis, via une organiation écran, l'ICANN. Celle-ci s'oppose régulièrement au déploiement des IDN donc il y a peu de chance que des TLD en Unicode soient acceptés.

Le RFC propose donc une autre solution : traiter la représentation des TLD en Unicode uniquement comme une question de présentation à l'utilisateur. .org resterait ainsi en US-ASCII mais le logiciel pourrait afficher et accepter en entrée une traduction chinoise, en caractères chinois.

Il n'y aurait donc pas de changement du nombre de TLD.

L'idée semble raisonnable mais on peut regretter que, pour la défendre, l'auteur du RFC ignore d'autres solutions. Par exemple, la section 1.3.2 du RFC discute de certains mécanismes qui pourraient être utilisés pour s'assurer que le TLD en US-ASCII et le TLD en Unicode aient le même contenu. Il conclut que ces mécanismes ne sont pas suffisants (et donc qu'il vaut mieux avoir un seul TLD par pays) mais il oublie d'autrs possibilités techniques comme un simple lien symbolique entre les deux fichiers de zone (solution qui marche très bien avec les logiciels BIND et NSD).


Téléchargez le RFC 4185


L'article seul

RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : Y. Shafranovich (SolidMatrix Technologies)
Pour information
Première rédaction de cet article le 9 mai 2007
Dernière mise à jour le 22 août 2017


Curieusement, bien que très utilisé, le format CSV n'avait jamais fait l'objet d'une spécification officielle. Voilà qui est fait.

CSV est un format simple et cela explique donc que le RFC soit très court. Pour enregistrer le type MIME text/csv, l'IETF avait besoin d'un standard stable de CSV, qu'est notre RFC. Normaliser après coup n'est jamais facile et on trouve dans le RFC quelques perles, qui reflètent l'état de CSV dans le monde réel. Par exemple, « The last record in the file may or may not have an ending line break » ou bien « There maybe an optional header line appearing as the first line of the file ».

Le format CSV étant très simple, il est trivial de produire du CSV à partir de n'importe quelle source de données. Mais, la plupart du temps, il n'y a pas d'effort particulier à faire, beaucoup de logiciels savent déjà exporter en CSV. Par exemple, avec PostgreSQL :

psql -c "COPY $TABLE TO STDOUT WITH CSV" $DATABASE

Et, si on veut l'en-tête facultatif :

psql -c "COPY $TABLE TO STDOUT WITH CSV HEADER" $DATABASE

Autre problème liée à la normalisation tardive : des questions comme l'échappement des caractères sont laissées dans le vague. Mais la prime revient, comme souvent, à un logiciel Microsoft, en l'occurrence Excel, qui, dans sa version française, exige un point-virgule et pas une virgule comme séparateur ! Il ne peut donc pas lire le CSV « standard ».

Il existe des bibliothèques pour manipuler du CSV facilement dans tous les langages de programmation. En Python, je recommande le module csv standard. En C, il existe une libcsv.

Sur la difficulté à lire et écrire du CSV en pratique, on peut lire l'excellent « Alors comme ça tu veux faire du CSV ? » (en anglais, « So You Want To Write Your Own CSV code? ».)

Sur le Web, un examen de quelques fichiers CSV montre que peu de serveurs HTTP prennent la peine d'étiqueter avec le type correct. On trouve plus souvent text/plain. Un exemple de fichier CSV en ligne (et servi avec le type correct) est sur ce blog, en simple-http-transfer.csv. C'était un fichier pcap (simple-http-transfer.pcap), transformé en CSV grâce à tshark (commande tshark -r simple-http-transfer.pcap -T fields -E separator=, -e ipv6.src -e tcp.srcport -e ipv6.dst -e tcp.dstport -e tcp.flags -e frame.len ce qui fait que le fichier CSV comprend donc l'adresse IP source, le port source, l'adresse IP de destination, le port de destination, les booléens TCP et la longueur du paquet). Autre exemple correct, sur http://data.gouv.fr/, par exemple avec http://static.data.gouv.fr/e9/751955c5dd1f2953cb1296e64efc4fded236f22ccc064da82cae11ec5bb450.csv (c'est une liste de monuments historiques). Si le fichier CSV comprend l'en-tête optionnel mentionné plus haut (ce qui est le cas de celui de data.gouv.fr que je viens de mentionner), le type MIME devrait en théorie se terminer par un paramètre, ;header=present. En pratique, je ne l'ai jamais vu.

La section 5 du RFC, portant sur la sécurité, prétend que CSV ne contient que des données, pas de code, et ne pose donc pas de problèmes de sécurité à lire. C'est en fait excessivement optimiste avec Excel ou Google Spreadsheets.

Une des preuves de l'utilité de CSV est que mon article Transformer du XML en CSV est un des plus populaires, grâce aux nombreuses requêtes « Comment je transforme du XML en CSV ? » sur les moteurs de recherche.


Téléchargez le RFC 4180


L'article seul

RFC 4177: Architectural Approaches to Multi-homing for IPv6

Date de publication du RFC : Septembre 2005
Auteur(s) du RFC : G. Huston (APNIC)
Pour information
Première rédaction de cet article le 13 octobre 2005


Le multihoming, ou capacité pour un site Internet d'être relié à plusieurs fournisseurs d'accès Internet (FAI), est à la fois une très forte demande de la part des utilisateurs et un problème très complexe, qui n'a pas encore de solution satisfaisante. Le protocole IPv6 apporte quelques outils supplémentaires mais ne résout pas magiquement le problème.

Si tous les FAI étaient parfaitement fiables, et merveilleusement connectés, il n'y aura guère besoin de multihoming. Mais, en pratique, tout site qui veut une bonne fiabilité et une bonne connexion avec tout le monde a souvent intérêt à avoir plusieurs fournisseurs. La technique "normale" pour cela est d'avoir des adresses IP indépendantes (PI pour Provider Independant) et de faire du BGP avec tous ses fournisseurs. C'est techniquement assez complexe et c'est surtout très coûteux, sans compter la difficulté d'obtenir des adresses PI auprès des RIR (IPv6 ne change rien à ce sujet).

En attendant, le client de base reste donc très dépendant de son FAI.

Le groupe de travail Multi6 de l'IETF travaille sur la question et ce RFC explique son analyse des différentes architectures envisageables (le RFC 3582 détaillait le cahier des charges du multihoming IPv6). On est encore loin d'une solution.

Le RFC identifie cinq architectures possibles. Pour les comprendre, il faut d'abord lire la section 2 du RFC, qui rappelle que l'adresse IP est actuellement utilisée pour deux choses bien différentes, comme identificateur d'une machine et comme index dans les tables de routage (certaines solutions de multihoming vont séparer les deux fonctions) :

  • Adresses PI et routage BGP, comme vu plus haut. Le problème est de passage à l'échelle : que deviendront les routeurs BGP si un million de sites publient leur route ? Le problème n'est pas celui du nombre d'adresses IP (qu'IPv6 résoud) mais celui du nombre de routes.
  • Utilisation des techniques de mobilité : être connecté à un deuxième FAI n'est pas différent d'être en voyage et connecté par un FAI distinct de son FAI habituel.
  • Les trois dernières architectures prévoient toutes une séparation des deux fonctions de l'adresse IP. Les sessions (par exemple TCP) seraient maintenus entre deux machines identifiées, non pas par une adresse IP, mais par un identifiant de plus haut niveau.

Le RFC décrit ensuite en détail les différentes façons de réaliser cette séparation et ces conséquences (il s'agit de remettre en cause un principe central des applications Internet).


Téléchargez le RFC 4177


L'article seul

RFC 4151: The 'tag' URI Scheme

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : Tim Kindberg (Hewlett-Packard), Sandro Hawke (W3C)
Pour information
Première rédaction de cet article le 26 octobre 2005
Dernière mise à jour le 13 mars 2006


Les URI comme http://www.bortzmeyer.org/4151.html ou ISBN:0-395-36341-1 (RFC 8254) sont devenus la référence en matière d'identificateurs de ressources sur le réseau. Quelques alternatives comme les DOI n'ont jamais eu aucun succès (la lettre d'information de l'International DOI foundation ne contient que des URL et aucun DOI). Les URI commencent toujours par un schéma, un plan comme http ou mailto et ce RFC crée un nouveau schéma : tag.

Ce nouvau schéma sert uniquement à construire des identificateurs uniques, stables et compréhensibles. Il n'est pas prévu de mécanisme de résolution en adresses.

Le RFC décrit les autres éléments du cahier des charges et les raisons pour lesquelles les autres mécanismes ne sont pas satisfaisants. Notamment, un identificateur doit pouvoir être créé sans recourir à une autorité centrale.

Ainsi, un identificateur tag: est typiquement construit à partir d'un nom de domaine ou d'une adresse de courrier (mais n'importe quelle source d'unicité - tagging entity - comme un numéro de téléphone pourrait être utilisée), suivie d'une date de création. Par exemple, cela peut donner tag:bortzmeyer@internatif.org,2005-10-26:/Blog/RFC4151.

Comme exemple d'utilisation, le RFC 4151 sur le format de syndication ATOM recommande que chaque entrée du flux de syndication aie un identificateur unique, le <atom:id> et conseille When an Atom Document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change. Put another way, an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource. The content of an atom:id element MUST be created in a way that assures uniqueness.

Et il est conseillé d'utiliser le schéma tag: pour cela, ce que fait le flux de syndication de ce blog.

Pour plus d'informations, une page Web de l'auteur du RFC fait le point sur le schéma tag:.


Téléchargez le RFC 4151


L'article seul

RFC 4144: How to Gain Prominence and Influence in Standards Organizations

Date de publication du RFC : Septembre 2005
Auteur(s) du RFC : D. Eastlake 3rd (Motorola)
Pour information
Première rédaction de cet article le 5 novembre 2005


Encore un RFC sur les procédures et pas sur les protocoles. Celui-ci vise à éduquer les participants aux organismes de normalisation en promettant plus d'efficacité à leurs actions, s'ils suivent quelques règles.

Aujourd'hui, une grande partie de la politique industrielle et parfois de la politique tout court se fait via des organismes de normalisation comme l'IETF, le W3C ou OASIS. Ce qui se passe dans ces organismes devient donc de grande importance et beaucoup de gens tentent d'y participer, souvent avec des résultats mitigés, par exemple car ils ont ignoré la culture particulière de l'organisme où ils sont intervenus.

Ce RFC est donc destiné à tous ceux qui voudraient participer à un organisme de normalisation avec succès. Il donne des conseils de bon sens, assez classiques mais toujours bons à rappeler : par exemple qu'il est normal qu'un organisme apparaisse toujours comme une secte fermée, quand on le regarde de l'extérieur. Ou que la conquête d'une certaine influence prend du temps et des efforts. Ou encore qu'il faut être actif dans le groupe, qu'on ne peut pas espérer devenir quelqu'un qui compte juste par un ou deux messages sur une liste de diffusion.


Téléchargez le RFC 4144


L'article seul

RFC 4141: SMTP and MIME Extensions for Content Conversion

Date de publication du RFC : Novembre 2005
Auteur(s) du RFC : K. Toyoda (PCC), D. Crocker (Brandenburg)
Chemin des normes
Première rédaction de cet article le 21 décembre 2005


Traditionnellement, la règle d'un MTA était "Ne touche pas au courrier, fais-le passer sans changement". Le MTA était juste un facteur, pas un secrétaire de rédaction, afin de garantir quel acteur a la responsabilité d'un message. Pour tout un tas de raisons, cette règle semble avoir de moins en moins appliquée. Ce nouveau RFC peut donc se permettre de spécifier un mécanisme pour demander à un serveur SMTP de faire des conversions du contenu du message.

Le serveur SMTP peut donc annoncer, en utilisant les mécanismes de Extended SMTP (RFC 2821) qu'il accepte ce nouveau mécanisme, s'il est prêt à effectuer ces conversions coûteuses.

Voici un exemple de session SMTP où le client va demander une conversion d'image dans un autre format, en utilisant la syntaxe du RFC 2533 :

      <<RFC 2822 message with MIME Content-Type:TIFF-FX
      Per:
      (  image-file-structure=TIFF-minimal
         dpi=400
         image-coding=JBIG
         size-x=2150/254
         paper-size=letter
      )
      with MIME body-parts including:
      Content-Convert:
         (&(image-file-structure=TIFF-minimal)
           (MRC-mode=0)
           (color=Binary)
           (|(&(dpi=204)
               (dpi-xyratio=[204/98,204/196]) )
             (&(dpi=400)
               (dpi-xyratio=1) ) )
           (|(image-coding=[MH,MR,MMR])
             (&(image-coding=JBIG)
               (image-coding-constraint=JBIG-T85)
               (JBIG-stripe-size=128) ) )
           (size-x<=2150/254)
           (paper-size=[letter,A4])
           (ua-media=stationery) )
      >>

Téléchargez le RFC 4141


L'article seul

RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace

Date de publication du RFC : Juillet 2005
Auteur(s) du RFC : Paul J. Leach (Microsoft), Michael Mealling (Refactored Networks, LLC), Rich Salz (DataPower Technology, Inc.)
Chemin des normes
Première rédaction de cet article le 1 avril 2008


Ce RFC décrit un espace de noms URN pour les UUID, une famille d'identificateurs uniques, obtenus sans registre central.

Les UUID, également connus sous le nom de GUID, sont issus à l'origine du système des Apollo, adopté ensuite dans la plate-forme DCE. Ils ont une taille fixe, 128 bits, et sont obtenus localement, à partir d'un autre identificateur unique comme l'adresse MAC ou bien en tirant au hasard, la grande taille de leur espace de nommage faisant que les collisions sont très improbables (section 2 du RFC). Ce RFC reprend la spécification de DCE de l'Open Group (ex-OSF) et ajoute la définition d'un espace de noms pour des URN (section 3). (Il existe aussi une norme ITU sur les UUID et un registre des UUID, pour ceux qui y tiennent.)

Les UUID peuvent donc convenir pour identifier une entité sur le réseau, par exemple une machine mais aussi, vu leur nombre, comme identificateur unique pour des transactions (ce qui était un de leurs usages dans DCE). En revanche, ils ne sont pas résolvables.

Sur Unix, on peut fabriquer un UUID avec la commande uuidgen, qui affiche la représentation texte standard que normalise notre RFC :

% uuidgen 
317e8ed3-1428-4ef1-9dce-505ffbcba11a
% uuidgen
ec8638fd-c93d-4c6f-9826-f3c71436443a

On trouve les UUID à de nombreux endroits en informatique, par exemple dans les logiciels Mozilla (cf. http://developer.mozilla.org/en/docs/Generating_GUIDs).

Pour l'affichage sous forme d'URN (RFC 8141), on ajoute juste l'espace uuid par exemple urn:uuid:ec8638fd-c93d-4c6f-9826-f3c71436443a.

La section 4 du RFC détaille le format interne de l'UUID (en dépit des apparences, l'UUID n'est pas plat, il a une structure). Notamment, la section 4.1.3 précise le champ Version (qui devrait plutôt s'appeler Type), puisqu'un UUID peut être généré à partir d'une estampille temporelle (version 1, option -t de uuidgen), d'une valeur aléatoire (version 4, option -r) ou d'un résumé cryptographique (version 3).

L'UUID utilise également l'adresse MAC de la machine, si elle est présente (section 4.1.6).

La section 4.2, elle, décrit le processus de génération d'un UUID à base temporelle. Idéalement, il faut utiliser une graine enregistrée sur le disque (pour éviter de générer des UID identiques) ainsi que l'instant de la génération. Mais lire sur le disque prend du temps (alors qu'on peut vouloir générer des UUID rapidement, par exemple pour identifier des transactions) et l'horloge de la machine n'a pas toujours une résolution suffisante pour éviter de lire deux fois de suite le même instant. Cette section contient donc également des avis sur la génération fiable d'UUID, par exemple (section 4.2.1.2) en gardant en mêmoire le nombre d'UUID générés, pour les ajouter à l'heure. Si on préfère des UUID créés par résumé cryptographique, la section 4.3 est là pour cela.

La section 6, consacrée à la sécurité, rappelle qu'un UUID ne doit pas être utilisé comme capacité (car il est trop facile à deviner) et qu'il ne faut pas demander à un humain de comparer deux UUID (ils se ressemblent trop pour un œil humain).

L'annexe A est une excellent mise en œuvre, en langage C, des principes décrits dans la section 4. Si on préfère utiliser Python, il existe, depuis la version 2.5, un module UUID qui offre des fonctions de génération d'UUID de différentes versions :

import uuid

myuuid = uuid.uuid1() # Version 1, Time-based UUID
otheruuid = uuid.uuid4() # Version 4, Random-based UUID
yetanotheruuid = uuid.uuid5(uuid.NAMESPACE_DNS,
                            "www.example.org")
                      # Version 5, a name hashed by SHA1
if (myuuid == otheruuid or \
    myuuid == yetanotheruuid or \
    otheruuid == yetanotheruuid):
    print "They are equal, PANIC!"

print myuuid
print otheruuid
print yetanotheruuid
    

À noter que le SGBD PostgreSQL, à partir de la version 8.3, inclus un type UUID.

essais=> CREATE TABLE Transactions (id uuid, value INT);
CREATE TABLE
essais=> INSERT INTO Transactions VALUES 
           ('74738ff5-5367-5958-9aee-98fffdcd1876', 42);
INSERT 0 1
essais=> INSERT INTO Transactions VALUES 
            ('88e6441b-5f5c-436b-8066-80dca8222abf', 6);
INSERT 0 1
essais=> INSERT INTO Transactions VALUES ('Pas correct', 3);
ERROR:  invalid input syntax for uuid: "Pas correct"
essais=> SELECT * FROM Transactions;
                  id                  | value 
--------------------------------------+-------
 74738ff5-5367-5958-9aee-98fffdcd1876 |    42
 88e6441b-5f5c-436b-8066-80dca8222abf |     6
(2 rows)

Il existe plusieurs exemples d'utilisation des UUID. Par exemple, Linux s'en sert pour identifier les disques attachés à la machine, de préférence à l'ancien système où l'ajout d'un nouveau disque pouvait changer l'ordre des numéros sur le bus et empêcher le système de trouver un disque. Un :etc/fstab typique sur Linux contient donc désormais des :

UUID=da8285a0-3a70-413d-baed-a1f48d7bf7b2       /home   ext3 defaults ...

plutôt que les anciens :

/dev/sda3       /home           ext3    defaults  

car sda3 n'est pas un identificateur stable. L'UUID, lui, est dans le système de fichiers et ne changera pas avec les changements sur le bus. On peut l'afficher avec dumpeéfs :


# dumpe2fs -h /dev/sda3
...
Filesystem UUID:          da8285a0-3a70-413d-baed-a1f48d7bf7b2
...


Téléchargez le RFC 4122


L'article seul

RFC 4116: IPv4 Multihoming Practices and Limitations

Date de publication du RFC : Juillet 2005
Auteur(s) du RFC : J. Abley (ISC), K. Lindqvist (Netnod Internet Exchange), E. Davies, B. Black (Layer8 Networks), V. Gill (AOL)
Pour information
Première rédaction de cet article le 18 janvier 2007


Le multihoming, le fait pour un site d'être connecté à plusieurs FAI devenant de plus en plus fréquent, il était utile de le documenter.

Notre court RFC explique donc comment on fait du multihoming en IPv4 aujourd'hui. La technique plus « lourde » est d'utiliser BGP avec plusieurs FAI, et elle requierts des adresses IP PI, c'est-à-dire Provider-Independant, indépendantes du FAI. Une autre solution, qui marche avec les classiques adresses PA (Provider-Aggregatable) est d'utiliser le NAT. (Il y a aussi le cas un peu particulier du « multi-attachement » où le site a bien plusieurs liens Internet mais ils sont tous vers le même FAI.)

Ces différentes techniques ont leurs propriétés, décrites dans la section 4 :

  • Redondance, souvent la principale motivation,
  • Répartition de charge,
  • Etc.

mais elles ne sont pas équivalentes. Par exemple, les sessions de longue durée (comme celles de SSH) ne survivent typiquement pas aux changement de chemin si le multihoming est réalisé avec du NAT (avec BGP et des adresses PI, cela marche). En revanche, BGP et les adresses PI sont la solution qui impose le plus de charge au système de routage global de l'Internet, imposant à chaque routeur de la DFZ (Default-Free Zone, les routeurs du cœur de l'Internet) une entrée supplémentaire dans sa table de routage.

Rappelons qu'il n'existe pas encore de solution générale et adaptée à la taille de l'Internet pour multihomer la majorité des petits et moyens sites.


Téléchargez le RFC 4116


L'article seul

RFC 4101: Writing Protocol Models

Date de publication du RFC : Juin 2005
Auteur(s) du RFC : Eric Rescorla (RTFM)
Pour information
Première rédaction de cet article le 28 février 2008


Écrire un protocole réseau n'est pas facile. La description doit être suffisamment rigoureuse pour qu'elle puisse être mise en œuvre sans ambiguïté et elle doit être suffisamment lisible pour être compréhensible par le lecteur pressé. Les implémenteurs des protocoles préfèrent la précision et l'exactitude, les simples lecteurs, par exemple ceux qui relisent le protocole avant sa publication, préfèrent un texte plus littéraire et de plus haut niveau. Ce RFC, publié par l'IAB, estime que les normes IETF, publiées dans les RFC, sont allées trop loin vers les besoins des seuls implémenteurs et que les RFC récents manquent d'un modèle, d'une description de haut niveau du protocole.

Les normes écrites par l'IETF et publiées dans les RFC sont toutes soumises à un examen public, avant leur officialisation. Relire des projets de RFC, comme l'explique la section 1, n'est pas une tâche facile. Si les RFC d'autrefois étaient courts et souvent écrits de manière assez littéraire, les RFC modernes sont bien plus longs, souvent écrits par plusieurs personnes et le style s'en ressent. Plus corrects dans leur description du protocole, ils sont bien plus difficiles à lire. Si on doit programmer le protocole en question, on doit lire tout le RFC de toute façon. Mais si on veut juste faire une analyse du document, il est pénible de « rétro-ingénierer » les concepts à partir du texte.

La section 2 explique donc qu'il faudrait, dans chaque RFC qui normalise un protocole, un modèle, qui décrive le protocole à un niveau plus élevé et qui permette de répondre à trois questions :

  • Quel problème le protocole tente t-il de résoudre ?
  • Quels messages sont transmis et quelle est leur signification ?
  • Quelles sont les caractéristiques importantes du protocole ?

Le modèle doit se fonder sur les caractéristiques essentielles du protocoles. Par exemple, le fait que Kerberos (RFC 1510) utilise un système KDC (Key Distribution Center) est essentiel mais le fait que la syntaxe soit décrite en ASN.1 est un détail, les S-expressions auraient aussi bien convenu.

La section 3 décrit ensuite en quoi consiste un modèle. Le principe essentiel est que le modèle est plus court que le protocole complet. C'est une carte, pas un territoire. Il va donc abstraire le protocole et n'en garder que ce qui est essentiel.

La section 4 parle ensuite de l'écriture concrète de ces modèles. Elle recommande une approche très graphique, avec « des boîtes et des flèches » (même si la section 5 note que l'obligation de publier les RFC uniquement en texte brut en ASCII ne facilite pas les choses ; j'en profite pour signaler l'excellent outil Graph::Easy, pour générer des diagrammes en art ASCII à partir d'une description de haut niveau).

D'abord (section 4.1), le modèle doit décrire le problème qu'on essaie de résoudre. L'exemple que donne notre RFC est celui de STUN (RFC 3489), qui ne contient pas cette description. Notre RFC 4101 en propose donc une, avec un diagramme des différents composants des entités qui tentent de communiquer malgré le NAT et de leurs échanges.

Ensuite (section 4.2), le modèle doit donner une vue générale du protocole. L'exemple est pris dans le protocole DCCP (RFC 4340) dont RFC 4101 propose une telle vue de DCCP.

Enfin (section 4.3), le modèle doit pointer du doigt les caractéristiques importantes du protocole, surtout si elles ne sont pas évidentes à première vue. Ainsi, dans l'exemple de WebDAV, RFC 4918, contrairement à ce qu'on pourrait croire en lisant rapidement le RFC sur WebDAV, notre RFC 4101 montre qu'une discussion détaillée de la différence entre un renommage d'une ressource (commande MOVE de WebDAV) et sa copie suivie de la destruction de l'original (commandes COPY et DELETE de WebDAV) ne sont pas équivalents (mais le RFC sur WebDAV décrivant chaque commande séparément, ce n'est pas évident à voir).

La section 6 du RFC synthétise toutes ses recommandations en fournissant un exemple d'un modèle complet pour le protocole IKE (RFC 4306), l'un des plus complexes de l'IETF.

Si les auteurs de RFC suivent ces recommandations, les RFC deviendront encore plus lisibles et accessibles.


Téléchargez le RFC 4101


L'article seul

RFC 4097: Middlebox Communications (MIDCOM) Protocol Evaluation

Date de publication du RFC : Juin 2005
Auteur(s) du RFC : M. Barnes (Nortel)
Pour information
Réalisé dans le cadre du groupe de travail IETF midcom
Première rédaction de cet article le 10 février 2006


Ce RFC étudie les différents candidats au rôle de protocole Midcom, le protocole de communication avec les middleboxes, lancé par le RFC 3303.

Le RFC 3304 spécifiait le cahier des charges du protocole Midcom, qui permettra la communication entr l'agent Midcom et les middleboxes. Notre RFC étudie maintenant les différents protocoles candidats auprès du groupe de travail :

et en déduit que tous pourraient convenir, SNMP étant quand même le plus proche des exigences. Midcom a donc été spécifié comme une MIB SNMP (pas encore publiée comme RFC).


Téléchargez le RFC 4097


L'article seul

RFC 4086: Randomness Requirements for Security

Date de publication du RFC : Juin 2005
Auteur(s) du RFC : D. Eastlake (Motorola), J. Schiller (MIT), S. Crocker (MIT)
Première rédaction de cet article le 1 août 2007


La sécurité, c'est toujours un problème difficile. Parmi les sous-problèmes à résoudre pour rendre un système informatique sûr, la sécurité du générateur de nombres aléatoires occupe une bonne place, mais qui est souvent méconnu. Ce RFC fait donc le point sur le problème et sur les mesures à adopter lors de la mise en œuvre des protocoles IETF.

L'alerte de sécurité CVE-2007-2926 sur le générateur aléatoire de BIND est venue nous le rappeler : beaucoup de mécanismes de sécurité informatique reposent sur la génération « sûre » de nombres aléatoires. « Sûre » voulant dire ici « Difficile à prévoir par l'adversaire ». Comme tout serveur récursif DNS, BIND doit placer dans les requêtes sortantes une query ID que le serveur faisant autorité mettra dans sa réponse, permettant ainsi de s'assurer de la validité de la réponse (la query ID sert donc de cookie). Si les query ID sont prévisibles par un méchant, il peut facilement fabriquer de fausses réponses qui ont l'air vraies et ainsi empoisonner le cache du serveur récursif.

Cette faille est très classique : nombreux sont les logiciels qui utilisent, sans bien s'en rendre compte, un générateur aléatoire prédictif. Notre RFC donne une explication partielle pour cet aveuglement : les textes classiques sur les générateurs aléatoires ne les jugent que par des considérations statistiques, pas en prenant le point de vue d'un adversaire qui chercherait à trouver le nombre suivant. Notre RFC cite l'exemple d'un générateur qui, devant fabriquer des nombres de 128 bits aléatoires, produirait en moyenne 50 % de nombres égaux à zéro et 50 % de nombres aléatoires. Statistiquement, il y aurait toujours 64 bits d'entropie, ce qui peut sembler suffisant. Mais un attaquant n'aurait qu'à essayer un nombre nul pour réussir la moitié du temps et l'entropie réelle serait donc de un bit...

Ce RFC, qui succède au RFC 1750, est donc consacré à l'exposé des bonnes pratiques en matière de générateur aléatoire. Depuis le RFC 1750, le monde des protocoles Internet a été bouleversé puisque presque tous dépendent désormais plus ou moins de la cryptographie, qui elle-même dépend souvent de générateurs aléatoires sûrs, par exemple pour fabriquer les clés de session.

Les bonnes pratiques peuvent se regrouper en deux catégories, utiliser le hasard présent dans la matériel, et utiliser des générateurs cryptographiquement forts.

Le matériel d'un système informatique est en effet source de nombreux bruits très aléatoires. Le bruit de fond du micro (section 3.2.1) ou les interruptions envoyées par le disque dur (section 3.2.2) sont deux bons exemples. Presque tous les ordinateurs ayant un tel matériel, il est recommandé de l'utiliser comme source d'entropie. (Les cartes réseaux ne sont mentionnées qu'en passant, car leurs interruptions peuvent être influencées par un tiers, surtout s'il est sur le même réseau.) Idéalement, il faudrait utiliser des dispositifs quantiques comme un ensemble d'atomes radioactifs dont on mesure la désintégration mais les PC ont plus souvent un micro qu'un compteur Geiger... (À défaut d'un tel compteur, on peut utiliser un générateur de bruit blanc comme l'Alea.)

Le RFC détaille aussi des mauvaises idées, par exemple le programmeur qui doit initialiser un générateur aléatoire avec une graine (seed) utilise souvent l'horloge de la machine (par exemple en Python, quelque chose comme generator = random.Random (time.time()) ou bien en C, initstate(time(NULL), state, NUMSTATES);). C'est en général très peu sûr, car les horloges ont typiquement une résolution très faible : si l'attaquant sait à quelle heure approximative le système a démarré, il peut trouver la graine et en déduire les nombres générés (section 3.4 du RFC). La section 6.1 détaille d'autres mauvaises idées, notamment celle de croire que, si on fait des manipulations très complexes des données, on est davantage en sécurité (en fait, c'est souvent le contraire).

Il y a beaucoup d'autres détails à prendre en compte (le RFC note que le problème est « étonnamment difficile ») comme le fait qu'une machine qui démarre a accumulé peu d'entropie et est donc particulièrement vulnérable (sauf si on sauvegarde le dernier résultat du générateur lors de l'arrêt, pour l'utiliser comme graine au démarrage suivant).

Pour le programmeur qui trouve cela bien difficile, notons que le RFC, dans le traditionnel esprit IETF de se soucier des problèmes pratiques, pas juste de la théorie, a prévu une section 7 qui détaille les fonctions déjà écrites et qu'il n'y a plus qu'à utiliser comme /dev/random sur beaucoup de systèmes Unix. /dev/random est un pseudo-fichier rempli par le noyau du système en utilisant diverses sources d'entropie, dont celles fournies par le matériel. Sur Linux, il existe aussi un /dev/urandom, sans doute moins sûr (car utilisant également un générateur pseudo-aléatoire) mais non bloquant (la lecture de /dev/random peut durer longtemps, car le noyau n'y écrit rien tant qu'il n'a pas assez récolté d'entropie). Voici un exemple d'utilisation de /dev/urandom pour obtenir 512 octets aléatoires dans un fichier :

dd bs=512 count=1 if=/dev/urandom > /tmp/random_data

Ceux qui aiment lire le code source noteront que, dans les noyaux Linux 2.6, ce mécanisme est programmé dans drivers/char/random.c et que les commentaires très détaillés de ce fichier sont instructifs.

Les personnes allergiques aux mathématiques sont prévenues que ce RFC est un des rares documents de l'IETF à comporter des formules mathématiques (qui n'ont pas été faciles à publier en texte seul).


Téléchargez le RFC 4086


L'article seul

RFC 4085: Embedding Globally-Routable Internet Addresses Considered Harmful

Date de publication du RFC : Juin 2005
Auteur(s) du RFC : D. Plonka (University of Wisconsin)
Première rédaction de cet article le 8 août 2007


Un RFC de nature opérationnelle, pour rappeler à quel point l'idée de mettre des adresses IP en dur dans la configuration des équipements réseaux est une mauvaise idée.

L'auteur parle d'expérience : son université, University of Wisconsin a été sérieusement perturbée lorsque des routeurs fabriqués par Netgear ont, par milliers, tenté de se connecter à son serveur NTP. Sans vergogne, les fabricants du routeur avaient mis l'adresse IP dudit serveur dans la configuration par défaut du routeur !

Une mésaventure identique était survenue à un ingénieur danois connu, dont le serveur NTP avait été surchargé par des routeurs D-link, produits par des gens peu scrupuleux.

Notre RFC s'appuie donc sur ces exemples pour demander que les adresses IP ne soient pas mises en dur dans la configuration de machines, surtout si celles-ci, comme la plupart des petits équipements réseaux, ne seront jamais mises à jour après leur livraison au client, et jamais administrées professionnellement. Même si le fabricant est bien titulaire de l'adresse IP du serveur, il ne peut pas garantir qu'il le restera. Comme le notent le RFC 2101 et le RFC 7020, les adresses IP ne sont pas éternelles.

On trouve de telles adresses IP dans les documentations (alors qu'il faudrait utiliser les adresses spéciales décrites dans les RFC 5737 et RFC 3849) et dans les configurations (pour que la machine fonctionne immédiatement, sans configuration manuelle, ce qui peut être plus pratique pour le client mais est très dangereux pour l'Internet, comme dans les cas ci-dessus).

Notre RFC décrit aussi dans sa section 3 les alternatives, comme d'utiliser des noms de domaine, plus stables que les adresses IP et surtout permettant des techniques de répartition de charge ou bien d'indirection, par exemple avec les enregistrements SRV (RFC 2782).

Une autre alternative est de compter sur des annonces faites localement, par exemple par DHCP, pour trouver les serveurs utiles.


Téléchargez le RFC 4085


L'article seul

RFC 4084: Terminology for Describing Internet Connectivity

Date de publication du RFC : Mai 2005
Auteur(s) du RFC : J. Klensin
Première rédaction de cet article le 17 mai 2005


Autrefois, tout était simple, il n'y avait qu'un seul type d'accès Internet : l'accès complet. Aujourd'hui, les offres sont bien plus éclatées : il y a la traduction d'adresse (NAT), le filtrage (plusieurs FAI bloquent le port 25 - celui du courrier - en sortie, pour gêner les vers Windows qui tentent d'émettre du spam), les passages obligatoires par des relais plus ou moins transparents.

Très peu de fournisseurs documentent ces restrictions.

Rien de plus agaçant que d'avoir payé l'hôtel pour avoir "une connexion Internet" avant de découvrir qu'elle ne donne pas accès au port 22 et qu'on ne peut donc pas faire du SSH vers ses serveurs lorsqu'on est en déplacement.

Une des raisons au manque de documentation est l'absence d'un vocabulaire commun pour décrire ces offres. Le marché ne peut fonctionner qu'en présence d'information et il n'y a pas d'information sans la standardisation des termes.

C'est ce à quoi s'attaque le RFC 4084. Tâche difficile car, selon les mots de l'auteur, "il faut éviter d'utiliser un vocabulaire péjoratif". Il est en effet essentiel que ce vocabulaire soit utilisé par les fournisseurs d'accès. L'IETF n'a aucune autorité pour forcer l'usage de ces termes et ils doivent donc plaire à tous, clients et fournisseurs. D'autre part, il faut parler en termes de services pour l'utilisateur et évidemment pas en termes techniques, pour être compréhensible par le client.

Le RFC distingue donc notamment : "Connectivité Web", qui ne donne accès qu'à ce service, ce qui est le cas de beaucoup de points chauds WiFi, "Client seulement" (qui interdit la plupart des services "peer to peer" comme la téléphonie Skype ou comme BitTorrent), "Connectivité Internet filtrée" et "Connectivité Internet complète".

Peut-être verra t-on un jour une loi sur la protection des consommateurs obliger à décrire une offre de connexion Internet avec les termes du RFC 4084 :-)


Téléchargez le RFC 4084


L'article seul

RFC 4071: Structure of the IETF Administrative Support Activity (IASA)

Date de publication du RFC : Avril 2005
Auteur(s) du RFC : R. Austein (ISC), B. Wijnen (Lucent)
Première rédaction de cet article le 9 janvier 2006


Ce RFC fait partie des nombreux RFC "bureaucratiques" au sens où il ne décrit pas un protocole réseau mais le fonctionnement interne de l'IETF. Il introduit l'ensemble des structures administratives de l'IETF, qui étaient précémment plus ou moins informelles. Ces structures ont par la suite été complètement changées par le RFC 8711, quatorze ans après.

Comme toute organisation de normalisation, l'IETF a des activités ancillaires : organiser des réunions, publier des documents, etc. Et a donc besoin d'une structure pour prendre en charge cette activité "administrative". Jusqu'à présent, tout fonctionnait informellement, ce qui ne pouvait pas durer, vu le caractère crucial des travaux de l'IETF.

Sous le nom générique d'IASA (IETF Administrative Support Activity), notre RFC décrit donc :

  • IAD (IETF Administrative Director), la personne qui va diriger l'activité administrative (actuellement Ray Pelletier).
  • IAOC (IETF Administrative Oversight Committee), le groupe de travail qui va superviser l'activité administrative. Dirigé par Lucy Lynch, de l'ISOC, il a un site Web très complet. (C'est cette IAOC qui a été supprimée par le RFC 8711, remplacée par l'IETF LLC.)

L'IASA est, en pratique, une branche de l'ISOC (qui fournit un parapluie financier et légal à l'IETF), même si elle est supervisée par l'IAOC.

On notera qu'une autre structure a été créée récemment et qui n'est pas décrite dans ce RFC, l'IETF Trust.


Téléchargez le RFC 4071


L'article seul

RFC 4058: Protocol for Carrying Authentication for Network Access (PANA) Requirements

Date de publication du RFC : Mai 2005
Auteur(s) du RFC : A. Yegin, Y. Ohba, R. Penno, G. Tsirtsis, C. Wang
Pour information
Réalisé dans le cadre du groupe de travail IETF pana
Première rédaction de cet article le 8 janvier 2007


Beaucoup de protocoles IETF ont besoin de faire de l'authentification. Traditionnellement, chacun le fait à sa manière et introduit ses propres bogues. D'où l'effort actuel de rationalisation dont le projet PANA, introduit par ce RFC, est une partie.

Actuellement, il existe de nombreux protocoles pour gérer l'authentification du client qui veut accéder à un réseau. Par exemple, si on veut empêcher que toute machine qui se connecte à un commutateur Ethernet puisse envoyer des paquets, on peut utiliser 802.1X. De même, lorsqu'on se connecte à un point chaud WiFi ou depuis sa chambre d'hôtel, on est souvent redirigé vers une page Web d'authentification (technique du « portail captif »). Ces protocoles sont souvent spécifiques à un type de média particulier et chacun d'eux « réinvente la roue » en redéveloppant fonctions et protocole les utilisant. Or, en matière de sécurité, cette approche est dangereuse : chaque protocole va devoir faire l'objet d'une analyse de sécurité séparée. D'où l'idée de factoriser certaines fonctions courantes et c'est le but du projet PANA.

Notre RFC expose le cahier des charges pour PANA : le futur protocole servira uniquement de transport au vrai protocole d'authentification, par exemple EAP (RFC 3748). PANA circulera sur IP, ce qui garantit son indépendance par rapport au média.


Téléchargez le RFC 4058


L'article seul

RFC 4035: Protocol Modifications for the DNS Security Extensions

Date de publication du RFC : Mars 2005
Auteur(s) du RFC : R. Arends (Telematica Institute), R. Austein (ISC), M. Larson (Verisign), D. Massey (Colorado State University), S. Rose (NIST)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsext
Première rédaction de cet article le 5 juin 2008


L'ensemble connu sous le nom de DNSSEC vise à authentifier les réponses des serveurs DNS en signant cryptographiquement lesdites réponses. Cet ensemble est normalisé dans plusieurs RFC dont notre RFC 4035, qui spécifie les changements dans le protocole. Ces modifications du protocole sont modérées mais indispensables pour l'authentification des données.

Ce RFC complète donc le RFC 4033 qui exposait les principes généraux de DNSSEC, ainsi que son cahier des charges, et du RFC 4034 qui décrivait les nouveaux types d'enregistrements DNS nécessaires, DS, DNSKEY, RRSIG et NSEC. Il met à jour l'ancien RFC qui couvrait tous les aspects de DNSSEC (RFC 2535). Il explique ce que doivent faire des serveurs et résolveurs DNSSEC pour permettre l'authentification. En effet, la simple utilisation des nouveaux enregistrements ne suffit pas à valider les réponses.

D'abord, la section 2 explique ce que doivent faire les programme de génération des zones (dnssec-keygen chez BIND) et de signature des zones (dnssec-signzone chez BIND). Elle parle donc du comportement « hors-ligne » du serveur, indépendamment des requêtes qu'il reçoit. La section 2.1 couvre la gestion des clés : leur partie publique doit être incluse dans la zone, dans des enregistrements DNSKEY, par exemple, ici dans .bg :

bg.   IN  DNSKEY  257 3 5 AwEAAcNsUEdXDwV5Sgr55kFzm0kCFNOL9iP8asHh1FKvDcxdJCe4mQJm l4kQ0C1CZyMwPIL3QWNP8yWcBLs2rfFeTX/lPXWDRvujLVxDCXCDvYkH Av4q3OkwDn+5pSH3DApKjVaW9K5XFFzNVTf3DRXWGzPNiWWXB35JHSo+ Iz2nYEHX4ZQumcT7z1BmQgQ91cS+wFT4FiCKrKdpPfxBFDSRgVZKPrL5 l6BFd/EK4jrbpzGM+83UxEBsqhR+K/GDk/yZC9jSm9DMOZJ7woYBhIwz q3lPpaoBBMbFLKw1FVQR4oFL1yznFkkcOOvZ5bu1G2s6lohoYz9Qlwld jwSqVg2TMXMclZzlUzGLFiMJsqwNnwfnD6mFaqjWbZXqRXLMupNYlKiu NKKs9zvnjpH5P/QjWX3Ym6owMebVTvlqbGc3lwIhk+d8gOYQzaUBf7Vk NRS3lb92zQe8DDhdyGosH7Po/rIP/QewKrcmgcExB4YpEZQ8M2EI5ddy 4bcnHCAqgjZ05b2mQyaxN3y4m3Ws85QsNQ7t9MnBXMkRkL6Zh9Zvs4k3 MQK4h0S6Jn22/kjqoBBsJYB2VYhToE/ljEt+uHjHVMWUtZ3jyfo1nY23 7cWXaYRW/2XNWXYluaOPdzJOuaDm6bBz5w+JbaY3GjEs78T7nmkn7MsK gDjDNwYf+8hrbDO3

La section 2.2 passe ensuite aux signatures. Elles doivent être mises dans des enregistrements RRSIG et il doit y en avoir un par RRset (ensemble des enregistrements de différents types pour un même nom de domaine). Cette section rappelle aussi qu'on ne signe que les enregistrements pour lesquels on fait autorité. Ainsi, les NS qui indiquent les serveurs de noms d'une zone, sont signés dans la zone fille, pas dans la zone parente qui s'en sert pour la délégation. Même chose pour la colle (adresses IP indispensables à la délégation), qui n'est pas signée.

Un des problèmes les plus difficiles de DNSSEC est la « preuve de non-existence ». Afin que les requêtes et réponses DNS puissent passer par des serveurs traditionnels (pour que le DNS continue à marcher, même sans validation), DNSSEC utilise des enregistrements DNS classiques. Prouver qu'un nom de domaine existe consiste simplement à produire une signature d'un enregistrement portant sur ce nom. Mais comment prouver qu'un nom de domaine n'existe pas, alors qu'il n'existe rien à signer ? DNSSEC résout ce problème par deux sortes d'enregistrement prouvant la non-existence, les NSEC, introduits dans le RFC 4034 et dont l'inclusion dans le fichier de zone est spécifiée en section 2.3 de notre RFC, et les NSEC3 qui ont été introduits plus tard par le RFC 5155. Les NSEC qui, à l'époque de la publication de notre RFC 4035, étaient le seul mécanisme de preuve de non-existence, ont en effet un gros défaut : ils permettent à un client DNS de récupérer indirectement toute la zone DNS.

La section 2.3 dit donc que tout nom de domaine pour lequel un enregistrement est signé doit avoir un NSEC, par exemple, ici le MX de laperouse.sources.org est signé et un NSEC annonce que le nom suivant est ludwigVII.sources.org :

laperouse.sources.org.  86400   IN MX   10 aetius.bortzmeyer.org.
                        86400   RRSIG   MX 3 3 86400 20080802035206 (
                                        20080601035206 55957 sources.org.
                                        CH+eYPc36AXc9W9sEIaUFnOLdlodKXa+9yLQ
                                        SuXYgDbmEQMufy052L0= )
                        43200   NSEC    ludwigVII.sources.org. MX RRSIG NSEC

La section 2.4 explique le placement des DS, les enregistrements qui complètent les NS dans la zone parente, afin de permettre une délégation signée depuis une zone vers sa fille. Un DS référence les clés publiques de la zone fille. Les DS ne se trouvent donc pas dans la zone déléguée. Ils sont générés par le gérant de cette zone déléguée et transmis au gérant de la zone parente, qui les inclut dans son fichier de zone et les signe. (On pourrait aussi envoyer les DNSKEY au parent pour qu'il génère les DS lui-même mais le RFC 6781, section 4.3.2, recommande plutôt d'envoyer les DS.) Ainsi, si le gérant de bortzmeyer.example signe sa zone avec BIND, dnssec-signzone va lui générer un fichier dsset-NOMDELAZONE. qui contiendra les DS qu'il transmettra au gérant de .example (par exemple en EPP selon le RFC 4310 ou bien selon une procédure qui dépend du registre). Voici le contenu de ce fichier des DS :

sources.org.            IN DS 55957 3 1 A12F149F84B34E09501C32CC9F984FB9E1ED196A
sources.org.            IN DS 55957 3 2 DFE4A96D7FCC9B3F99990861AE3B915E832B699FC9628CE0DF7BE45D DE37DFB3

La section 2.5 parle des CNAME, ces enregistrements « alias » qui permettent à un nom de domaine de pointer vers un autre. Les CNAME doivent évidemment être signés, ce qui implique de leur adjoindre un RRSIG et notre RFC 4035 adoucit donc la vieille règle (RFC 1034) selon laquelle on ne pouvait pas mettre des données avec un CNAME :

openid.sources.org.     86400   IN CNAME munzer.bortzmeyer.org.
                        86400   RRSIG   CNAME 3 3 86400 20080802035206 (
                                        20080601035206 55957 sources.org.
                                        CFhUR1j+1b684LERarhf6bmIbWHvnox6/cZT
                                        txCiMpOS5rRHBcQQHYQ= )
                        43200   NSEC    sub.sources.org. CNAME RRSIG NSEC

De même, la section 2.6 modère l'ancienne règle qui disait que, dans la zone parente, seuls des NS pouvaient être présents pour une zone fille (désormais, les DS et les NSEC sont également possibles).

La section 3 s'attaque aux serveurs de noms qui veulent distribuer des données authentifiées. Ces serveurs se voient d'abors imposer de gérer l'extension EDNS0 (RFC 2671), notamment en raison de la plus grande taille de réponse qu'elle permet (les enregistrements DNSSEC sont typiquement assez grands). Mais c'est aussi parce que EDNS0 permet aux résolveurs DNS d'indiquer qu'ils acceptent DNSSEC, selon le mécanisme du DO bit, décrit dans le RFC 3225. Pour BIND, utilisé en résolveur, on met ce bit avec l'option dnssec-validation yes; dans le fichier de configuration. Pour dig, si je donne l'option +dnssec, dig va mettre ce DO bit (bit DNSSEC OK) dans la requête, comme on le voit ici avec wireshark et son option Export (tcpdump ne permet apparemment pas de l'afficher) :


    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0

Outre ce bit dans les requêtes, DNSSEC prévoit deux bits dans les réponses, les CD (Checking Disabled) et AD (Authentic Data).

La section 3.1 traite d'un serveur faisant autorité pour une zone. Pour que BIND gère le DNSSEC dans ce cas, il faut mettre l'option dnssec-enable yes; dans son fichier de configuration. Un tel serveur qui reçoit une requête avec le bit DO doit inclure les enregistrements DNSSEC comme les RRSIG, et fournir les NSEC si le nom n'existe pas (ou s'il existe mais sans enregistrement du type demandé). Voici un exemple avec dig et BIND :


% dig +dnssec MX sources.org
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
# La réponse a été validée, "ad" est présent
...
;; ANSWER SECTION:
sources.org.            86379   IN      MX      10 uucp.bortzmeyer.org.
sources.org.            86379   IN      RRSIG   MX 3 2 86400 20080802035206 20080601035206 55957 sources.org. CEYv0Tds6c7OSD7ZxEPmY0hQgs4ZMM5QE/8Ecmgm8Re7srtPhPEGVyg=

# Et, si le nom n'existe pas :
% dig +dnssec MX nexistepas.sources.org
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14178
# Le nom n'existe pas, NXDOMAIN
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
# Réponse validée grâce aux NSEC
...
;; AUTHORITY SECTION:
...
ludwigvii.sources.org.  10800   IN      NSEC    openid.sources.org. AAAA RRSIG NSEC
# Le NSEC dit qu'il n'existe rien entre ludwigvii.sources.org et openid.sources.org

L'inclusion des RRSIG (section 3.1.1) peut poser des problèmes de taille, car ils sont nettement plus gros que les enregistrements habituels. Le RFC détaille donc dans quels cas les envoyer. L'envoi des NSEC obét à des règles encore plus complexes, détaillées dans la section 3.1.3. Par exemple, s'il y a une réponse, mais qu'elle a été générée par un joker (le caractère * dans le fichier de zone), il faut envoyer les NSEC.

Après les serveurs faisant autorité de la section précédente, la section 3.2 parle des serveurs récursifs. Lorsque leur client indique son désir de faire du DNSSEC, via le bit DO, le serveur récursif doit leur envoyer les enregistrements DNSSEC et procéder à la validation, puis en indiquer le résultat via le bit AD (« ces données sont authentiques, je les ai vérifiées »). Pour BIND, c'est l'option dnssec-validation yes; qui met en route DNSSEC pour un serveur récursif.

Il y a tout un débat sur le meilleur endroit où effectuer la validation DNSSEC. Dans les applications pour qu'elles aient le plus d'informations possibles et puissent ajuster ainsi leurs messages à l'utilisateur ? Dans un résolveur situé sur la machine de l'utilisateur, la seule à laquelle il puisse vraiment faire confiance, puisque les autres machines et le réseau peuvent être sous le contrôle des méchants ? (Mais l'utilisateur de base ne va certainement pas installer et gérer BIND et il n'existe pas de serveur récursif et validateur « clés en main ».) Dans les résolveurs du FAI, qui sont déjà utilisés et configurés et qui sont gérés par des professionnels ? (Mais le FAI est parfois le premier à mentir, par exemple en dissimulant les réponses NXDOMAIN - ce domaine n'existe pas - derrière des fausses réponses menant à un serveur publicitaire qu'il contrôle.)

Ce débat n'aura pas de réponse consensuelle de si tôt (voir par exemple la section 4.9.3 du RFC). En attendant, notre RFC permet tous les modes de fonctionnement. Par exemple, si le résolveur ne veut pas que les serveurs auxquels il parle fassent de la validation, il peut leur demander avec le bit CD (section 3.2.2). S'il veut signaler à son client qu'il a validé (libre au client de le croire ou pas), il a le bit AD (section 3.2.3) pour cela.

La liste des tâches à accomplir par un résolveur continue en section 4, qui couvre tous les résolveurs, pas seulement les serveurs de noms récursifs de la section précédente. Eux aussi doivent gérer EDNS0 (section 4.1).

Si un résolveur valide les réponses avec DNSSEC, la section 4.3 donne les résultats auquel il peut parvenir :

  • Sûres (Secure) : les réponses DNS ont été vérifiées avec DNSSEC et sont correctes. Le résolveur peut alors positionner le bit AD, comme précisé dans la section 4.9.3.
  • Non sûres (Insecure) : en l'absence de clé cryptographique connue (voir le paragraphe suivant), les réponses DNS n'ont pas pu être vérifiées.
  • Invalides (Bogus) : le résolveur avait une clé mais les signatures sont fausses. Cela peut être bien sûr parce qu'un attaquant a modifié les données mais c'est souvent aussi en raison d'une erreur des gérants de la zone signée, voire du résolveur ; signatures expirées (un mois par défaut, dans BIND), décalage de l'horloge (DNSSEC implique une synchronisation des horloges), modification maladroite d'un fichier, etc. Ce genre de problèmes est très fréquent en cryptographie pratique et sera certainement une source d'amusement sans fin pour les utilisateurs de DNSSEC. Si la réponse est invalide, un serveur récursif doit - section 5.5 - retourner le code SERVFAIL (Server failure).
  • Incertaines (Indeterminate) : quelque chose a empêché le résolveur de se faire une opinion ferme.

Mais, justement, comment vérifier une signature ? Faut-il mettre dans le résolveur la clé de toutes les zones DNS du monde ? Évidemment pas. La section 4.4 parle des trust anchors (« points de départ de la confiance »), ces clés (au moins une) qui sont mises en dur dans la configuration du résolveur. À partir d'une telle clé, on peut vérifier une zone, et toutes ces sous-zones signées, en suivant les enregistrements DS, où on trouvera les clés des sous-zones. Idéalement, si la racine du DNS était signée, un seul trust anchor suffirait, la clé de la racine.

En pratique, la racine n'est pas actuellement signée. Il faut donc gérer à la main un ensemble de trust anchors (voici par exemple le fichier que j'utilise avec BIND, qui est à jour le 2008-06-04). On retrouve ces clés sur des sites tels que https://www.ripe.net/projects/disi/keys/ ou http://www.iis.se/domains/sednssec/publickey. La meilleure façon de gérer ces trust anchors est décrite dans la section 5, qui décrit par exemple les vérifications de cohérence que devrait faire un résolveur (tester que la trust anchor se retrouve bien dans la zone sous la forme d'un enregistrement DNSKEY). La section 5.1 parle notamment des « îlots de confiance » (islands of security), qui sont les zones signées sans que leur zone parente le soit (la très grande majorité, à l'heure actuelle). Par exemple, aujourd'hui, la zone .org n'est pas signée donc sources.org, qui l'est, est un « îlot de sécurité » dont les clés sont :

sources.org. IN DNSKEY 256 3 3 CKoOFAptkq5oqs8hlDf1gYDDpRPrjySc+wjBxLBbQtkXOrAUoBOrUa6I Yx83fYsA/i3BbhOXjS3K5/JlIupCszv2xTtrgIb0uivatvtO1WSySjOw R4dhfgPXdYbTAcYLYZRSiOFXxzXjnczRgqJu6tu50U7m7RK5wiIBTE6Q StNEanhez3srKtJK07iYutga/INvPxE82zVdGeBmIJpLqQ7gnCR3VaMh FtX+jO0/QHY/07vtZxNJhMucQt/oCG8rGQYVl1g8diZUtfd4iIgf2ill fBppxqc5EW3lLH1yVmu4JcHLaC4E7WiipupGd9N4APi5PzR3tuER8iua JYDHaZIwBmOm9weedHM9fUhOWYjmbEejvC8DvX6epDHVpAxgzysTapLa VBAci4a2/A/VVnrO2snUTdRzx8B8p5gnAgwl0ojXrgQRcPb0eDaFUdQx b9qLM75oM6miFeg1qsoqWNW/P1YvX/Kd2IDRcpskFE/ReYMpna40Ywj9 941/dRoDm6AMRpejsXYTlcpQRuRW54qpJuaY
sources.org. IN DNSKEY 256 3 5 AwEAAduXW4l/heiryuKxgipsGR2mIDnZxotS1Cf6+hzYROeGqPUnO2SI aQVh8s89u2hUT6I8T0C0UGVAJ2lmgTV6jEXwNyAm9wYzkZg6WnP5Nt3W eitsSBPQljAQvWsxNpp99QQrtycE4RDCtOiQS1igFPaEFPSawuvDEW8X oM2adQFa7RBXue8Xk5uxgbHorLLb3UTi7Ai1E7/J786XhlNGGJmpQJaB +qbyWG6Y81Uvnvj+CkU/hl7gRq2PE4TD2cJOZ85kia3fVUqOY6rOWK0X gylkQCV8Pjsd0LwVUfQ73/yDEpmw3ZBZDZUahWYnya2jFaidFJqfACoK ZXKMFcqkFt0=

La section 5.4 est consacrée aux NSEC, qui nécessitent des règles particulières pour leur validation.

Le reste du RFC est consacré à des exemples détaillés de zones signées, et de requêtes et réponses DNSSEC, avec leurs explications.

Si on veut tester un résolveur DNSSEC, il existe une zone prévue pour cela, test.dnssec-tools.org. Elle contient à peu près toutes les erreurs possibles. Par exemple, futuredate-A.newzsk-ns.test.dnssec-tools.org a une date de signature située dans le futur :


% dig A futuredate-A.newzsk-ns.test.dnssec-tools.org

; <<>> DiG 9.4.2 <<>> A futuredate-A.newzsk-ns.test.dnssec-tools.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10278

Et, sur le serveur résolveur, le journal contiendra :

28-May-2008 14:07:59.910 dnssec: info: validating @0xa9c450: futuredate-A.newzsk-ns.test.dnssec-tools.org A: no valid signature found

Voici quelques extraits des fichiers de configuration de BIND, pour faire du DNSSEC (on peut trouver des instructions plus détaillées dans le DNSSEC HOWTO, a tutorial in disguise ou dans DNSSEC Resolver Test) :

options {

        dnssec-enable yes; // Accepte les requêtes avec le bit DO et
        // renvoie les enregistrements DNSSEC

        dnssec-validation yes; // Valide les
	// enregistrements DNSSEC reçus (le bit DO est mis
	// systématiquement par les BIND récents)
        
};

Pour le débogage, il peut être prudent de mettre le résultats des traitements DNSSEC dans un fichier séparé :


 logging {
          channel dnssec_log {             // a DNSSEC log channel
                  file "/var/tmp/bindlog/dnssec.log" size 20m;
                  print-time yes;        // timestamp the entries
                  print-category yes;    // add category name to entries
                  print-severity yes;    // add severity level to entries
                  severity debug 7;      // print debug message <=7
                          // Cela va noter *beaucoup* de messages
                          // On peut aussi mettre "severity info;" qui
			  // est nettement moins bavard.
          };

    category dnssec  { dnssec_log; };
};

Une fois que c'est fait, on peut tester le résultat avec des noms correctement signés comme sigok.verteiltesysteme.net ou délibérement mal signés comme sigfail.verteiltesysteme.net.

Pour un serveur faisant autorité, il faut générer des clés par exemple :

% dnssec-keygen -a RSASHA1 -b 2048 -n ZONE sources.org

On peut aussi générer plusieurs clés de types différents et les inclure dans la zone, par exemple, pour une clé DSA, avec dnssec-keygen -a DSA -b 1024 -n ZONE sources.org. Notons que cette commande dépend du générateur aléatoire de la machine et elle consomme beaucoup d'entropie, se bloquant dès qu'il n'y en a pas assez de disponible. Paradoxalement, il vaut donc mieux l'exécuter sur une machine chargée.

Il faut ensuite signer la zone et penser à la resigner après chaque modification (ou bien avant son expiration, selon l'évenement qui a lieu en premier). Pour simplifer le processus, on peut utiliser make avec un Makefile de ce genre :

reload: sources.org.signed foobar.example.signed
        rndc reload
        # Ou nsdc rebuild && nsdc reload pour NSD

%.signed: %
        @echo Signing requires a lot of entropy in /dev/random, do not hesitate to load the machine...
        # 5356800 seconds = two months of validity
        dnssec-signzone -e +5356800 $^

Le serveur devra alors avoir dans son fichier de configuration (named.conf pour BIND, nsd.zones pour NSD), le fichier sources.org.signed (et non pas le fichier sources.org qu'on édite et qui ne contient pas les signatures).


Téléchargez le RFC 4035


L'article seul

RFC 4034: Resource Records for the DNS Security Extensions

Date de publication du RFC : Mars 2005
Auteur(s) du RFC : R. Arends (Telematica), R. Austein (ISC), M. Larson (Verisign), D. Massey (Colorado State University), S. Rose (NIST)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsext
Première rédaction de cet article le 22 avril 2008


Complétant la série des RFC sur DNSSEC, ce RFC 4034 décrit les types d'enregistrements utilisés par ce protocole, DNSKEY, RRSIG, DS et NSEC.

DNSSEC, décrit dans les RFC 4033 et RFC 4035, permet de signer cryptographiquement les enregistrements DNS de façon à garantir leur authenticité. Pour cela, DNSSEC ne modifie pas le format des paquets DNS, mais il ajoute plusieurs types d'enregistrement nouveaux. Notre RFC fait partie de la série de RFC qui décrit DNSSEC-bis (la première version de DNSSEC, assez différente, n'ayant eu aucun succès) et il succède au RFC 2535.

La plupart des exemples ci-dessous ont été obtenus pour la zone sources.org qui est désormais signée. Vous pouvez interroger en DNSSEC ses serveurs de noms (dig NS sources.org. vous en donnera la liste).

Chacun des nouveaux types d'enregistrement va faire l'objet d'une section. La section 2 est consacrée à DNSKEY, les clés publiques des zones. Un de ces enregistrements stocke notamment l'algorithme de chiffrement utilisé et la clé. La représentation texte officielle (chaque type d'enregistrement DNS a une représentation binaire, utilisée sur le câble, et une représentation texte, utilisée par exemple dans les fichiers de zone de BIND), décrite en section 2.2, affiche la clé encodée en Base64 :

sources.org.                        86400   DNSKEY  256 3 3 (
   CL9vwM+5gCMZdycMOYJQ7lSspHDTsaZmZkDR
   l+KNx/VytmbPSfcdYmhJJHyTdGpzqXmm6qEd
   4Kpyqbd59RXv9JCVVM3MntiX/hruxbB3WsV0
   hlVej1IuWFDncJFLWhaD9UjgGm+UoqlQJGVJ
   rGZf7KvwL4iKZhr1fiDEJFD7e9cxU8dojhHp
   mmAOZLjEYKytDMB0rj8/Mnm5cVVu29UFS+0y
   jvkdbQD0EJ9FwF/8MwG4DHj6ZtFwxeNp2NCD
   6oj0kxDi5ktY0rQtSv506aAMmGBqS6tNno+g
   9KgCLZ5jk5e8fpl9Rlmd2SlVMAyf8E3C9joB
   ZqCqYX+VcooSrcvgn/4m6CTDPxK+DuE+KW5/
   NiE062MKdID7xAxiCj14Suj9K9TKL60buuFa
   gJ3qTjhS5C62uPk8U9+zHpQ0qjcb0gv3/M+l
   RcXi46g0OF17cTLy83lgU6s2ApMmaboeUbm2
   3lfCEl8B6R2BhE98mfoDNg+Xlj63X8w93LCo
   XP/c1SZivNolol/Ky6apULe3euFuwdOFfYCR
   ) ; key id = 55957

Ici, la clé 55957 utilise DSA/SHA-1 (valeur 3). Ces clés peuvent être générées, par exemple, par le programme dnssec-keygen, qui fait partie de BIND. Bien lire la liste des algorithmes utilisables pour une zone dans l'annexe A.1 sinon, on aura un message du genre a key with algorithm 'HMAC-SHA256' cannot be a zone key.

Les enregistrements RRSIG sont le cœur de DNSSEC, puisqu'ils stockent les signatures des autres enregistrements. Ce sont les RRSIG que vérifie un validateur DNSSEC. Un enregistrement RRSIG contient notamment :

  • le type de l'enregistrement couvert par la signature,
  • l'algorithme de chiffrement utilisé (la liste des algoritmes possibles à l'origine figure dans l'annexe A.1 et la liste actuelle est maintenue par l'IANA),
  • les dates de signature et d'expiration,
  • la signature elle-même.

Sous la forme texte décrite en section 3.2, voici un tel enregistrement :

laperouse.sources.org.  86400   IN MX   10 aetius.bortzmeyer.org.
                        86400   RRSIG   MX 3 3 86400 20080522104407 (
                                        20080422104407 55957 sources.org.
                                        CIxBOzsaxBexcAQQE1ukqNfBz5yDnPBVhgxr
                                        MNR7FrfM2iH/AOWoO/8= )

Ici, ce RRSIG signe un MX.

La section 4 est consacrée à NSEC, un type d'enregistrement qui va résoudre un problème délicat, la « preuve de non-existence ». En effet, DNSSEC fonctionne en joignant une signature aux enregistrements existants, ce qui permet de prouver leur existance. Mais si un nom n'existe pas et que le serveur veut renvoyer NXDOMAIN (No Such Domain) ? On ne peut pas signer un enregistrement qui n'existe pas. La solution DNSSEC est de créer des enregistrements NSEC qui sont signés et qui indiquent l'enregistrement suivant (l'ordre est défini dans la section 6, c'est simplement l'ordre des codes ASCII). Ainsi, si je demande nexistepas.example.org et que je récupère :

lulu.sources.org.    43200   IN      NSEC    patou.sources.org. AAAA RRSIG NSEC

je sais que nexistepas.sources.org n'existe pas, puique le NSEC ci-dessus me garantit qu'il n'y a rien entre lulu et patou.

Un autre type d'enregistrement permettant la « preuve de non-existence », le NSEC3, est décrit dans le RFC 5155. En effet, le NSEC a un gros inconvénient, il permet l'énumération complète de la zone, en suivant simplement les NSEC. Cette faiblesse des NSEC est une des raisons pour lesquelles DNSSEC n'a pas été d'avantage déployé.

C'est très bien de signer sa zone mais ensuite, comment les résolveurs partout dans le monde vont-ils connaitre sa clé ? Ils ont pu l'obtenir par un autre moyen et la mettre dans leur configuration (ce qu'on nomme une trust anchor). Mais un tel mécanisme ne se généralise évidemment pas à tout l'Internet. Il faut donc un seul trust anchor, la clé de la racine, et un système de délégations. Ces délégations sont mises en œuvre par les enregistrements DS, décrits en section 5. Ces enregistrements contiennent un condensat cryptographique de la clé :

sources.org.            IN DS 55957 3 1 A12F149F84B34E09501C32CC9F984FB9E1ED196A

Ici, 55957 est l'identité de la clé, 3 l'algorithme de la clé et 1 celle du condensat (SHA-1, la liste complète est maintenue par l'IANA).


Téléchargez le RFC 4034


L'article seul

RFC 4033: DNS Security Introduction and Requirements

Date de publication du RFC : Mars 2005
Auteur(s) du RFC : R. Arends (Telematica Instituut), R. Austein (ISC), M. Larson (VeriSign), D. Massey (Colorado State University), S. Rose (NIST)
Chemin des normes
Première rédaction de cet article le 21 novembre 2005
Dernière mise à jour le 15 février 2010


Le DNS n'est pas sûr, on le sait (le RFC 3833 décrit les vulnérabilités du DNS en détail). Comme la quasi-totalité des applications de l'Internet dépendent du DNS à un moment ou à un autre, cette vulnérabilité inquiète beaucoup de gens. Notre RFC, avec ses compagnons RFC 4034 et RFC 4035, propose une solution à certains de ces problèmes, solution nommée DNSSEC.

Ce RFC décrit le deuxième DNSSEC, le premier était présenté dans le RFC 2535 mais n'a jamais été un succès.

DNSSEC-bis propose une sécurisation des données, pas du canal. La cryptographie permet en effet de sécuriser un canal de communication entre deux machines (ce que fait SSL) ou bien de sécuriser le message lui-même, qui peut alors être authentifié et protégé quels que soient les messagers intermédiaires : c'est ce que fait DNSSEC.

Pour cela, DNSSEC signe cryptographiquement, par la cryptographie asymétrique, les enregistrements DNS. Plus rigoureusement, il signe des RRsets ou Resource Record Sets, c'est-à-dire un ensemble d'enregistrements ayant même nom et meme type (en pratique, rassurez-vous, la différence entre enregistrement et RRset est peu importante). Cette signature est portée par un nouveau type d'enregistrement, le RRSIG. Le RRSIG authentifie un enregistrement qui figure en partie gauche tandis que la partie droite contient la signature, ainsi que quelques informations utiles comme l'algorithme utilisé (c'est typiquement RSA + SHA1).

Les parties publiques des clés utilisées par le registre de la zone pour la signature sont publiées dans des enregistrements de type DNSKEY. Pour "amorcer la pompe" de DNSSEC, on récupère typiquement ces clés via un canal non-DNS, par exemple un accès à un serveur Web authentifié.

Voici par exemple un enregistrement RRSIG tel que l'affiche dig :

   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642 example.com.
                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

Ici, le signataire example.com (ce nom apparait en partie droite) a authentifié l'adresse IPv4 (la signature couvre un enregistrement de type A, c'est indiqué juste après le type RRSIG) de host.example.com. La signature est le texte en base64 (RFC 4648) qui figure à la fin. S'il possède la clé de example.com (on peut la récupérer, par exemple, dans l'enregistrement de type DNSKEY ou "hors bande", par exemple sur une clé USB remise en mains propres), un résolveur DNS pourra alors être sûr de l'authenticité de cette adresse et ceci même si l'enregistrement a été transmis via des relais inconnus.

Enfin, DNSSEC spécifie également deux autres types d'enregistrement, plus subtils : NSEC et DS.

Les NSEC servent à répondre à une question délicate : authentifier la non-existence d'un domaine. En effet, DNSSEC marche par la signature d'enregistrements (ce choix a été fait pour éviter de modifier trop fortement le protocole DNS). Mais, si un nom n'existe pas, il n'y a pas d'enregistrement à signer ! Le problème est résolu avec les enregistrements de type NSEC (Next Secure). Ces enregistrements (qui sont signés comme les autres) indiquent quel est le prochain domaine de la zone. Ainsi, lorsqu'on demande nimportequoi.example.org, le serveur de example.org peut répondre par un NSEC pointant vers le domaine suivant.example.org qui, lui, existe. Voici un exemple d'enregistrement NSEC qui dit que alfa.example.com a des enregistrements de quatre types et que le nom suivant est host.example.com (donc, on peut être certain que beta.example.com n'existe pas) :

   alfa.example.com. 86400 IN NSEC host.example.com. (
                                   A MX RRSIG NSEC)

On note que, puisque les NSEC permettent d'obtenir le domaine suivant, puis le suivant du suivant, ils donnent donc potentiellement accès à l'intégralité de la zone, tout comme un transfert de zones. Ce problème, connu sous le nom de zone walking a contribué à la décision de certains registres (typiquement ceux qui ne veulent pas distribuer leur fichier de zone) de ne pas déployer DNSSEC. C'est ainsi que Simon Josefsson a développé un programme de zone walking qui montre bien la vulnérabilité des zones DNSSEC. Ce problème est résolu en remplaçant les NSEC par les NSEC3 du RFC 5155.

Les enregistrements DS (Delegation Signer), quant à eux, permettent d'authentifier les délégations. En effet, signer les enregistrements de délégation (les NS, pour name servers) dans la zone parente ne suffit pas, puisqu'il faut aussi permettre de trouver la clé de la zone fille. Un enregistrement DS va donc pointer vers l'enregistrement DNSKEY de la zone fille (si celle-ci n'est pas elle-même signée, le DS est inutile).

DNSSEC bis est aujourd'hui mis en œuvre dans plusieurs serveurs de noms dont BIND (à partir de la version 9.2) et NSD (à partir de la version 2.3.0).

L'outil dig permet d'effectuer une requête avec DNSSEC :

% dig +dnssec @ns3.nic.fr +dnssec A ripe.net.  
...
;; ANSWER SECTION:
ripe.net.               600     IN      A       193.0.0.214
ripe.net.               600     IN      RRSIG   A 5 2 600 20051221061607 20051121061607 49526 ripe.net. 2NePKf/On6ZgcQD0zpinEou4QiojhW1A2IKoxHBdtawMa7aSeQdL+hZp RktjuqbFwv9rkVPOVXPGWhtB9sSfoI5         aMjHWjrjdsAfc6LTBLr2veHiV +6qOeiV24ALYwZKpwP5tEh6hiJXN6fVAxQ6ye32u7+01xL+dG9oaMA6x 6x/5GkJKHfS4E         EbF+OaUX2m2DlQHsh0n

On voit ici la réponse à la question posée (l'adresse de ripe.net) et la signature.

On peut aussi récupérer la partie publique de la clé :

% dig  DNSKEY ripe.net.                     
...
;; ANSWER SECTION:
ripe.net.               3480    IN      DNSKEY  256 3 5 AQPhEMiv80EEjX6gYDc8E7Osfumf4C/pZxBmTRRiOVL3h6lx1CIVCyPl V34WuVUkqqpID2fxGzmUFTG0f61x9lzRapX0lIdlo2AtRCYWpkPY+D3F IrMYukWiC8pyeHF/a/Wk6HZNLVYko2dcLwUpfiDrK7zCFgR9DLcZkOmj N5xB9CBzVrZDkd1lsGCC9hytndbLuZ3VtpE=
ripe.net.               3480    IN      DNSKEY  257 3 5 AQOTT7bx7N38sPgDWniKnHnSnTxYxdMpEq7dyrDHDaRQgq7DULPWX6ZY 0U1XKKMuNloHRP7H8r17IBhgXcPZjZhtSGYagtPe22mhAMjZ4e8KGgP9 kJTTcpgzoYulvSiETBxjQ42EZWJG+6bxK+vyrwTbqEScmdZfqQz3ltVw k6Sos0UuSmTeb2C6RSkgHaTpKCu5yIrncVer1gvyvXGv3HOel8jiDGuj 8peNByiaSRD4OIJUxu1jUqLvfDH6Anq6ZeNohxsYVUVajiRl1T+3x5+8 acgwat3V55Z1Nm4O4Z1BKECdPO65EXIEC7/pqs5XvpsiJbafdj03uqLS a3aScpy3

Et si je veux signer ma zone, quelles solutions puis-je utiliser ? Une version récente de BIND inclue les logiciels dnssec-keygen et dnssec-signzone qui fournissent tous les services nécessaires. Testons-les sur une Debian en version lenny. Il faut d'abord générer la clé de la zone :

% dnssec-keygen -a DSA  -b 1024 -n  ZONE sources.org

Cette commande laissera sur le disque les fichiers Ksources.org.+003+55957.key et Ksources.org.+003+55957.private. Il faut évidemment les sauvegarder précieusement (autrement, il faudra changer la clé, une opération complexe qu'on nomme le rollover) et vérifier que la clé privée n'est pas accessible à tous.

Il faut alors inclure la clé publique (ici, le contenu de Ksources.org.+003+55957.key) dans le fichier de zone.

Ensuite, à chaque modification de la zone, il faudra signer :

% dnssec-signzone sources.org
sources.org.signed

Le programme dnssec-signzone produit un fichier du même nom que la zone mais suffixé par .signed. Un exemple de règle dans un Makefile pour automatiser cela est :

reload: sources.org.signed example.org.signed foobar.example.signed

%.signed: %
        @echo Signing requires a lot of entropy in /dev/random, do not hesitate to load the machine...
        dnssec-signzone $^

L'avertissement sur l'entropie vient du fait que, sur une machine Linux peu chargée, /dev/random se bloque s'il n'a pas assez d'entropie pour générer des nombres vraiment aléatoires, et on a l'impression que dnssec-signzone est arrêté.

dnssec-signzone produit également un fichier avec les enregistrements DS, pour qu'on puisse les transmettre à son registre (uniquement pour une nouvelle clé ou bien une clé qui change).

Le cas présenté ici, avec une seule clé, est le plus simple. Elle est peut-être préférable pour les petites zones, ou pour ceux qui débutent avec DNSSEC. Mais le RFC recommande une autre approche, plus complexe mais plus sûre, la séparation en deux clés, la KSK (Key Signing Key) et la ZSK (Zone Signing Key). La première, introduite dans le RFC 3757, ne sert qu'à signer la seconde. Elle est typiquement très robuste (à l'heure actuelle, typiquement de 4096 bits) et change relativement rarement car c'est elle qui est utilisée par les autres zones, comme trust anchor. La seconde, la ZSK, est plus légère (par exemple 1024 bits, taille au delà de laquelle la signature des grandes zones devient vraiment pénible) et sert à signer les enregistrements. Du fait de cette utilisation, il y a davantage d'information qui « fuit »,; et qui peut donc aider un attaquant. Elle change donc plus fréquemment, ce qui ne pose pas trop de problèmes opérationnels puisqu'elle n'est connue que localement.

Pour créer la KSK, on doit normalement s'entourer de multiples précautions (si la zone qui l'utilisera est vitale, on s'enfermera dans une cage de Faraday, on se déconnectera du réseau, etc). Ensuite, on tape :

% dnssec-keygen -f KSK \
    -a RSASHA1 -b 4096 -n ZONE example.org

(Cette opération peut prendre plusieurs heures sur une machine qui a peu d'entropie.) On garde évidemment précieusement la partie privée de cette clé ! On publie la partie publique (par exemple en l'envoyant à la zone parente ou bien en la mettant sur son site Web) et on la met dans son fichier de zone.

La ZSK se génère avec une commande presque identique à part l'option -f et une clé plus petite :

% dnssec-keygen \
    -a RSASHA1 -b 1024 -n ZONE example.org

Les deux clés se mettent ensuite dans le fichier de zone. Au moment de la signature, dnssec-signzone ne signera qu'avec la ou les clés qui n'ont pas été générées avec l'option -f KSK. Toutefois, BIND ne trouve pas forcément les signatures seul et, selon la façon dont les clés ont été nommées et/ou placées, il peut être utile de dire à dnssec-signzone quelle est la KSK (option -k) et quelle est la ZSK (nom de fichier après le nom de la zone) :

dnssec-signzone -t -k example.org.KSK example.org example.org.ZSK 

Notez que tout ce processus peut s'automatiser partiellement avec des outils comme OpenDNSSEC.

Quelques documentations sur la configuration de DNSSEC :

Voyons maintenant quelques points important de DNSSEC mais qui ne sont pas mentionnés dans le RFC (celui-ci ne fait que spécifier un protocole, il ne traite pas de tous les problèmes liés à ce protocole).

On notera que le RFC ne spécifie pas l'API du service. Que doit faire une fonction comme getaddrinfo(3) lorsqu'une vérification DNSSEC échoue ? L'API actuelle ne permet pas de donner de détails sur la cause de l'échec. En outre, à ma connaissance, aucune mise en œuvre actuelle ne permet à l'administrateur système de définir une politique de sécurité (par exemple dans son fichier de configuration /etc/resolv.conf).

Aujourd'hui, plusieurs registres ont commencé à déployer DNSSEC comme le RIPE-NCC, notamment pour les domaines de résolution inverse (in-addr.arpa) qu'il gère ou bien le registre suédois. La racine du DNS est en cours de signature.

Si on souhaite plus d'informations, on pourra regarder un excellent article de Bert Hubert, l'auteur de PowerDNS ou bien le portail de DNSSEC. Et, sur mon blog, il y a de nombreux articles sur DNSSEC.


Téléchargez le RFC 4033


L'article seul

RFC 4013: SASLprep: Stringprep Profile for User Names and Passwords

Date de publication du RFC : Février 2005
Auteur(s) du RFC : K. Zeilenga (OpenLDAP Foundation)
Chemin des normes
Première rédaction de cet article le 20 juin 2008


Beaucoup de protocoles Internet ont besoin de comparer des noms, par exemple pour tester leur égalité avant une authentification de ce nom. Si les noms sont en Unicode, il est préférable de les normaliser avant la comparaison, pour que le résultat de celle-ci ne soit pas trop déroutant pour l'utilisateur. C'est le but de SASLprep, normalisé dans ce RFC.

Le RFC sur SASLprep est très court car SASLprep est juste un profil de stringprep (normalisé dans le RFC 3454). Stringprep était l'algorithme général de normalisation des noms à l'IETF. Il ne spécifiait pas tous les détails de la normalisation effectuée, laissant ceux-ci à des profils comme nameprep (RFC 3491, utilisé dans les IDN) ou bien notre SASLprep. Stringprep ayant depuis été abandonné (cf. RFC 7564), ce RFC 4013 a été remplacé par le nouveau mécanisme du RFC 7613.

SASLprep est conçu pour l'utilisation dans le contexte de l'authentification, notamment pour SASL (RFC 4422). L'idée est de passer les noms et les mots de passe à travers SASLprep avant toute comparaison, pour que le résultat de celle-ci corresponde aux attentes de l'utilisateur (section 1).

Le profil lui-même est décrit dans la section 2. Par exemple, SASLprep utilise la normalisation Unicode NFKC (section 2.2 de notre RFC et section 4 du RFC 3454). Ainsi, comme l'illustre les exemples de la section 3, la chaîne U+2168 (Ⅸ, chiffre romain 9) sera transformée en la chaîne « IX », qui a la même signification. Sans SASLprep, un utilisateur dont le nom comporterait ce caractère Unicode aurait du mal à se loguer ! La section 2 spécifie aussi (section 2.3) les caractères interdits par SASLprep, comme les caractères de contrôle.

On peut tester cet algorithme sur Unix avec la commande idn de la GNU libidn et son option --profile :

% echo Café | idn --quiet --stringprep --profile SASLprep
Café

% echo pi² | idn --quiet --stringprep --profile SASLprep
pi2

Dans le premier exemple, on note que SASLprep est sensible à la casse (qui n'a pas été modifiée). Dans le second exemple, l'exposant 2 dans « pi au carré » a été remplacé par un 2 ordinaire, conséquence de la normalisation NFKC. Un hypothétique mot de passe « pi² » serait donc équivalent à « pi2 ».

Une mise en œuvre de SASLprep, sous forme d'une bibliothèque utilisable depuis vos programmes, figure dans la GNU SASL Library.


Téléchargez le RFC 4013


L'article seul

RFC 4001: Textual Conventions for Internet Network Addresses

Date de publication du RFC : Février 2005
Auteur(s) du RFC : M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder
Chemin des normes
Première rédaction de cet article le 9 mars 2009


Il y a plein de normes Internet dans lesquelles il faut représenter sous forme texte des adresses IP. Parmi elles, les MIB, normalisées dans le RFC 2578 pour la gestion des réseaux (cf. section 2 du RFC et le RFC 3410). Comment représenter une adresse ? La question est un peu plus difficile que cela ne parait et méritait une norme.

Notre RFC spécifie donc à quoi doit ressembler une adresse IP dans une MIB. Par exemple, le RFC 4292 normalise une MIB pour le routage des paquets IP et doit donc indiquer des adresses, par exemple pour les objets inetCidrRouteNextHop qui indiquent l'adresse du « routeur suivant ». Notez que notre RFC 4001 peut même être utilisé en dehors du monde des MIB comme dans le RFC 5388 qui décrit un schéma XML pour les résultats d'un traceroute et qui doit donc également contenir des adresses IP.

Contrairement à une croyance répandue, il n'existe pas de norme générale pour la représentation des adresses IPv4. Le RFC 791 est muet à ce sujet et, bien qu'il y ait une représentation courante (192.0.2.134), d'autres représentations sont possibles. Pour IPv6, en revanche, il existe une représentation texte normalisée, dans le RFC 5952.

Notez bien que le RFC 4001 ne normalise que la représentation d'adresses IP « pures » sans les informations liées à la couche transport comme le port. Pour des adresses généralisées, voir le RFC 3419.

C'est la section 3 qui contient les définitions des représentations des adresses IP en ASN.1. On note que les noms de domaine sont inclus comme alternative :

InetAddressType ::= TEXTUAL-CONVENTION
...
         ipv4(1)     An IPv4 address as defined by the
                     InetAddressIPv4 textual convention.

         ipv6(2)     An IPv6 address as defined by the
                     InetAddressIPv6 textual convention.
...
         dns(16)     A DNS domain name as defined by the
                     InetAddressDNS textual convention.
...
InetAddressIPv4 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d"
    STATUS       current
    DESCRIPTION
        "Represents an IPv4 network address:
           Octets   Contents         Encoding
            1-4     IPv4 address     network-byte order
...
InetAddressIPv6 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
    STATUS       current
    DESCRIPTION
        "Represents an IPv6 network address:

           Octets   Contents         Encoding
            1-16    IPv6 address     network-byte order

         The corresponding InetAddressType value is ipv6(2).
...
    SYNTAX       OCTET STRING (SIZE (16))

La section 4, quant à elle, donnant des indications sur l'usage de ces variables. On trouve aussi des adresses munies d'un zone index, qui indique le réseau auquel elles appartiennent, pour le cas d'adresses locales au lien par exemple celles du RFC 3927 pour IPv4 ou du RFC 4007 pour IPv6 (section 4.2).

Enfin, le RFC se conclus sur un exemple d'utilisation (section 5) pour une MIB imaginaire de peerAddress :

peerTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF PeerEntry
...
    ::= { somewhere 1 }

peerEntry OBJECT-TYPE
    SYNTAX      PeerEntry
...
    INDEX       { peerAddressType, peerAddress }
    ::= { peerTable 1 }

PeerEntry ::= SEQUENCE {
    peerAddressType     InetAddressType,
    peerAddress         InetAddress,
...
}

peerAddressType OBJECT-TYPE
    SYNTAX      InetAddressType
...
    ::= { peerEntry 1 }

peerAddress OBJECT-TYPE
    SYNTAX      InetAddress (SIZE (1..64))
...
    DESCRIPTION
        "The Internet address for the peer.  The type of this
         address is determined by the value of the peerAddressType
         object.  ...
    ::= { peerEntry 2 }

Ce RFC remplace le RFC 3291 avec peu de changements (détaillés en section 8).


Téléchargez le RFC 4001


L'article seul

RFC des différentes séries : 0  1000  2000  3000  4000  5000  6000  7000  8000  9000