Mon blog

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.

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.

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

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.

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.

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.

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.

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

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.

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

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 ?

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

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.

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.

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.

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.

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.

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

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 :

• Le registre Adams' Names a son protocole au dessus de XML-RPC,
• Le registrar Gandi utilise son protocole, au dessus de XML-RPC pour ses revendeurs,
• Le registrar BookMyName utilise son protocole, au dessus de SOAP pour ses revendeurs,

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.

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

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

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, ROHC - RFC 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.

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.

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.

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.

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.

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.

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

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.

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.

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 (depuis remplacé par le RFC 9580).

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 l'avant-dernière version, la dernière étant le RFC 9580.

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.

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

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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

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.

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

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.

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.

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

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.

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

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.

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

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.

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.

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

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.