Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

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


Un exemple de problème dans BGP

Première rédaction de cet article le 24 juillet 2015


« On » me demande parfois quels outils utiliser pour analyser un problème BGP quand on n'a pas accès à un routeur de la DFZ (d'ailleurs, certaines techniques ici peuvent servir même dans ce cas). Voici un exemple avec la panne de plus de deux heures de Swift hier 22 juillet.

Point de départ, la machine 204.13.164.192 n'est plus joignable. Bête panne d'un serveur, comme cela arrive tout le temps sur l'Internet ? Non, cette fois, c'est plus rigolo, le préfixe IP 204.13.164.0/24 qui l'englobe a disparu de la table de routage mondiale. De même que d'autres préfixes du même opérateur, comme 204.8.32.0/24 (qui héberge notamment les serveurs DNS de swiftco.net, rendant ce nom de domaine inutilisable ; on ne le répétera jamais assez, il faut mettre ses serveurs DNS dans plusieurs réseaux différents).

Comment voir ce que contient cette table de routage ? Si on a accès à un routeur qui a une table complète, on peut le faire soi-même mais, si ce n'est pas le cas, on peut utiliser un des innombrables looking glasses qui vous donnent un accès indirect à ces routeurs. Par exemple, voici ce que donne celui de Hurricane Electric une fois la panne réparée (on voit les routes pour le 204.8.32.0/24, pendant la panne, on avait « None of the BGP4 routes match the display condition ») :

Qu'on utilise ce looking glass ou bien qu'on passe par un de ses routeurs à soi, on n'a qu'une vision immédiate. Il serait intéressant de pouvoir regarder le passé, notamment si on a été prévenu trop tard et qu'on veut investiguer a posteriori. C'est ce que permet RIPEstat qui fournit tout un tas d'outils d'analyse (qui ne sont pas toujours d'un abord facile). L'un des plus simples est le BGP Update activity. Voici ce qu'il affichait juste après la réparation :

On y voit une grosse activité BGP vers 0810 UTC au moment où le préfixe, pour une raison inconnue, était retiré. Cette activité comporte des retraits (withdraw) mais aussi des annonces (announce). C'est normal, les routeurs BGP réagissent au retrait en annonçant des routes alternatives pendant une minute ou deux, le temps que tous réalisent que le préfixe est bien retiré, qu'il n'y a pas d'alternative. Puis on voit une autre période d'activité vers 1045 UTC au moment où ça repart. Celle-ci ne comporte que des annonces.


L'article seul

RFC 7608: IPv6 Prefix Length Recommendation for Forwarding

Date de publication du RFC : Juillet 2015
Auteur(s) du RFC : M. Boucadair (France Telecom), A. Petrescu (CEA, LIST), F. Baker (Cisco Systems)
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 23 juillet 2015


Comme IPv4, IPv6 route les paquets en fonction d'un préfixe d'adresses, préfixe qui a une longueur comprise entre 0 (tout l'Internet) et 128 bits (une seule machine). Ce très court RFC a juste pour but de rappeler cette règle : la longueur d'un préfixe est quelconque, les mises en œuvres de IPv6, logicielles ou matérielles, ne doivent pas imposer ou favoriser une longueur de préfixe particulière (même pas 64, souvent considéré, à tort, comme spécial). Le routage se fait exclusivement sur le plus long préfixe, quelle que soit sa longueur.

Il est normal qu'IPv6 et IPv4 fassent pareil, ce sont après tout deux versions du même protocole. IPv4 utilisait autrefois un système différent mais, depuis CIDR, il suit les mêmes règles qu'IPv6 : le routage se fait sur la base d'un préfixe d'adresses de longueur quelconque. C'est le préfixe le plus long qui est choisi. Ainsi, pour prendre un exemple IPv4, si la destination est 203.0.113.51 et qu'il existe deux routes possibles, une vers le préfixe 203.0.113.0/26 (longueur 26 bits) et l'autre vers le préfixe 203.0.0.0/18, c'est la première, la plus spécifique (le préfixe le plus long) qui gagne. En IPv6, si on veut envoyer un paquet à 2001:db8:440:fe::25a:9ff et qu'il existe deux routes possibles, 2001:db8:440:fe::/80 (longueur 80 bits) et 2001:db8:440::/48, c'est la première qui est choisie. Le routage sur la base du préfixe le plus long, un concept fondamental d'IP, c'est juste ça. (Le terme de CIDR, introduit par le RFC 1380 et décrit dans le RFC 4632, terme très spécifique à IPv4 et aujourd'hui dépassé techniquement depuis l'abandon de l'ancien système des classes, n'est pas utilisé pour IPv6.)

Mais pas mal de gens qui ne connaissent pas bien IPv6 ont des idées fausses à ce sujet et croient, par exemple, que les préfixes de longueur 64 bits ont un rôle particulier pour le routage, voire que les préfixes comme le /80 donné en exemple plus haut sont illégaux. Le RFC 4291, qui normalise l'adressage IPv6, dit bien (dans sa section 2.5) que n'importe quelle longueur de préfixe (« arbitrary bit-length ») est possible. Mais c'est vrai que la confusion peut venir du rôle particulier de certaines longueurs, notamment 64, dans d'autres utilisations que le routage. Ainsi, le RFC 7421 note que les préfixes plus longs que 64 bits ont des problèmes pour certaines utilisations, comme le SLAAC. Mais il s'agit là de questions liées à l'adressage : cela ne devrait pas affecter le routage, si on veut que les changements futurs de l'adressage n'empêchent pas les routeurs de fonctionner (deux exemples de changement d'adressage : au début d'IPv6, il était envisagé que ce soit /80 plutôt que /64 qui soit la longueur de préfixe « de référence » et, autre exemple, la recommandation pour les liens point à point a varié de /64 à /127, cf. RFC 6164).

Donc, pour résumer, l'adressage est une chose (et les recommandations du RFC 7421, indiquant les avantages à utiliser du /64 pour un lien local, continuent à s'appliquer), le routage en est une autre : le routage IPv6 doit suivre l'algorithme du préfixe le plus long, et ne doit pas avoir de longueurs de préfixes privilégiées ou spéciales.

Cette exigence est formalisée dans la section 2 de notre RFC :

  • Les routeurs IPv6 doivent suivre les règles de la section 5.1 du RFC 4632.
  • La transmission d'un paquet doit se faire sur la base du préfixe le plus long et toutes les longueurs sont également acceptables, même 128, même des valeurs qui ne sont pas un multiple de 8.

Ces règles s'appliquent au code des routeurs : l'administrateur d'un routeur donné peut toujours avoir sa propre politique (par exemple, en BGP, ne pas accepter de préfixes plus longs que 48 bits) mais cela ne doit pas se retrouver dans le logiciel, autrement, les futures évolutions seraient sérieusement compliquées.


Téléchargez le RFC 7608


L'article seul

Thunderbird contre Logjam

Première rédaction de cet article le 22 juillet 2015


La sécurité informatique, c'est compliqué. Voilà qu'un utilisateur d'un serveur de messagerie que je gère me signale qu'il ne peut plus lire son courrier avec Thunderbird. Et je découvre que le problème était en fait dû au zéle que mettait Thunderbird à protéger ses utilisateurs de la faille Logjam.

Avant de revenir sur cette faille et sur la solution, voici les symptômes : Thunderbird était configuré pour récupérer le courrier avec POP. Récemment mis à jour automatiquement, il ne récupère plus de courrier. Apparemment pas de messages d'erreurs côté client, mais pas de courrier non plus. Côté serveur (un Courier), on trouve juste dans le journal :

pop3d-ssl: couriertls: accept: error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter

Message sybillin, non, d'autant plus que ce serveur refuse évidemment SSLv3, comme le dit le RFC 7568. C'est ça, les messages d'erreur d'OpenSSL...

Bon, je n'ai pas eu trop à chercher, des tas de gens avaient le même problème (par exemple chez CentOS). Deux bogues enregistrées chez Mozilla (la fondation qui développe Thunderbird) donnaient les détails : #1183650 et #1184488. L'explication est simple : la mise à jour de Thunderbird (ou plus exactement celle de la bibliothèque TLS NSS dont il dépend), introduit un refus des paramètres Diffie-Hellman trop faibles.

De quoi s'agit-il encore ? La faille de sécurité Logjam, contre le protocole TLS, concerne les échanges de clés Diffie-Hellman. TLS peut fonctionner sans Diffie-Hellman (et c'est pour cela que certaines utilisateurs n'ont pas eu de problèmes) mais, si on l'utilise, l'échange de clé peut être deviné par un attaquant car les groupes Diffie-Hellman ont pu être pré-calculés, surtout s'ils sont trop petits (768 bits par exemple, taille souvent utilisée par défaut, cf. la bogue Debian #787579). Outre le site officiel de Logjam, on peut consulter sur cette faille une excellente explication chez Cloudflare. Donc, Thunderbird (ou plutôt NSS) refuse désormais les paramètres Diffie-Hellman trop faibles. Testons notre serveur (le problème initial concernait aussi bien POP que IMAP, ici, je teste le serveur IMAP) :

% openssl s_client -connect server.bortzmeyer.org:993
CONNECTED(00000003)
...
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 768 bits
...
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc.  See COPYING for distribution information.

En effet, avec ses 768 bits (DH = Diffie-Hellman), le serveur ne suit pas les bonnes pratiques et c'est pour cela que Thunderbird coupe la communication.

Quelle est la solution ? Le site officiel de Logjam a une bonne page d'explications pour les administrateurs système mais, ici, j'ai simplement utilisé le commentaire 13 dans la bogue Mozilla #1184488. Il faut regénérer des paramètres Diffie-Hellman. Le serveur est une machine Debian, les paramètres sont en /etc/courier/dhparams.pem, et le script à utiliser, mkdhparams, est fourni avec Courier. À noter que sa documentation est inexacte sur la méthode à utiliser pour augmenter le nombre de bits (bogue Debian #793184). J'ai choisi une taille de 3 072 bits (plutôt exagérée aujourd'hui mais c'est ce qui est recommandé par le RGS) et j'ai donc fait :

server# export DH_BITS=3072

server# mkdhparams                  
512 semi-random bytes loaded
Generating DH parameters, 3072 bit long safe prime, generator 2
This is going to take a long time
................................................+....... 
...
server# /etc/init.d/courier-imap-ssl restart
[ ok ] Restarting courier-imap-ssl (via systemctl): courier-imap-ssl.service.
server# 

Testons le résultat :

% openssl s_client -connect server.bortzmeyer.org:993
CONNECTED(00000003)
...
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 3072 bits
...
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc.  See COPYING for distribution information.
closed

Parfait, cette fois, ça marche, et Thunderbird est content, il peut récupérer le courrier de manière sécurisée.

Amusante coïncidence, le lendemain de cet article, à la réunion IETF de Prague, Aaron Zauner faisait un excellent exposé sur des tests de la sécurité des serveurs de courrier (SMTP, POP et IMAP) qu'il avait réalisés dans l'Internet. Beaucoup d'entre eux sont encore vunérables à Logjam.


L'article seul

RFC 7558: Requirements for Scalable DNS-SD/mDNS Extensions

Date de publication du RFC : Juillet 2015
Auteur(s) du RFC : K. Lynn (Verizon), S. Cheshire (Apple), M. Blanchet (Viagenie), D. Migault (Ericsson)
Pour information
Réalisé dans le cadre du groupe de travail IETF dnssd
Première rédaction de cet article le 17 juillet 2015


Pour résoudre des noms de domaine en informations (comme l'adresse IP) sur le réseau local, sans configurer de serveur DNS, nous avons mDNS (RFC 6762). Pour découvrir des services (par exemples les imprimantes) avec ce mDNS, nous avons DNS-SD (RFC 6763). Mais ces deux techniques, mDNS et DNS-SD, ne fonctionnent que sur un seul segment du réseau, à l'intérieur d'un domaine de diffusion. Il serait bien pratique de pouvoir les utiliser dans un réseau étendu (comme l'Internet...). Ce RFC décrit le problème, les souhaits et établit une liste d'exigences pour cette extension de mDNS et DNS-SD « au-delà du lien local ». (À l'heure actuelle, on n'a pas encore de solution satisfaisant ces exigences.)

C'est par conception que mDNS (RFC 6762) ne passe pas les routeurs IP. Ce protocole marche par diffusion. On crie à la cantonade « qui connait iPhone-de-Jean-Bernard ? » et la machine qui se reconnait répond. mDNS s'appuie donc sur un service de couche 2, la diffusion, et ne fonctionne donc pas sur un réseau composé de plusieurs segments L2 reliés par des routeurs.

Or, il y a évidemment des cas où on voudrait des services comme ceux fournis par mDNS et DNS-SD au-delà du lien local. Parce que le campus ou l'entreprise où on travaille a plusieurs segments L2 (par exemple un pour le filaire et un pour le WiFi), ou bien parce qu'on travaille avec une association située à des centaines de kilomètres, mais joignable par l'Internet. Il n'existe pas actuellement de solutions standard pour cela. Et pas encore de consensus sur la façon la plus propre de le faire.

Autre cas où on se retrouve facilement coincé, celui de réseaux ad hoc comme les 6LowPAN (RFC 6568) où chaque machine ou presque peut devenir routeur (RFC 4903).

D'ailleurs, même en l'absence de ce problème multi-segments, la technique de mDNS, la diffusion (globale, ou bien restreinte) n'est pas idéale dans tous les cas. Sur de l'Ethernet filaire, la diffusion consomme relativement peu de ressources. Mais, sur certains segments, la diffusion coûte cher. En WiFi, elle peut vite mener à consommer une bonne partie de la capacité, d'autant plus qu'il faut ralentir au niveau du récepteur le plus lent (cf. section 2.2). Au passage, autre problème de 802.11 : il n'y a pas d'accusé de réception des trames diffusées et donc des pertes peuvent se produire.

La section 2 de notre RFC décrit le problème qu'on veut résoudre. D'abord, on voudrait pouvoir découvrir des ressources distantes (comme des imprimantes ou des serveurs de fichier) même si elles ne sont pas sur le même segment L2. Actuellement, la seule solution standard est le DNS classique. Cela nécessite soit une configuration manuelle par l'administrateur système, ce qui fait du travail, surtout en cas de changement (on modifie l'adresse IP de l'imprimante mais on oublie de changer la base DNS : tous les sites n'ont pas forcément un IPAM intégré qui prend en charge tout cela et tous les réseaux ne sont pas centralement gérés). Autre solution avec le DNS classique, autoriser les mises à jour dynamiques du DNS, ce qui implique qu'on configure les imprimantes pour faire ces mises à jour.

Et la solution à ce problème doit marcher pour des cas où on a des centaines ou des milliers de machines, et à un coût raisonnable (y compris le coût pour le réseau en terme de trafic).

Les réseaux contraints (LLN pour Low power and Lossy Networks, cf. RFC 7102) posent des défis particuliers. Ils sont souvent multi-segments, avec des nœuds devenant routeurs pour prolonger la portée des ondes radio, et ne peuvent donc pas se contenter des actuels mDNS et DNS-SD. Mais ils connectent souvent des machines peu dotées en ressources. Celles-ci sont parfois injoignables (hibernation ou déconnexion) et on ne peut donc pas compter sur leur présence permanente. Ainsi, mDNS assure l'unicité des noms par la vérification, par une nouvelle machine, que le nom n'était pas déjà présent sur le réseau. Si le possesseur de ce nom hiberne, il ne pourra pas « défendre » son nom.

La section 3 du RFC présente ensuite quelques scénarios d'usage concrets, pour qu'on se fasse une meilleure idée de cas où mDNS et DNS-SD ne suffisent pas. D'abord, un cas de base, le PAN (Personal Area Network, qui regroupe les machines d'un seul utilisateur, par exemple, dans un cas trivial, son PC portable et son imprimante). Pas de routeur présent, mDNS et DNS-SD suffisent bien et résolvent tous les problèmes. On passe ensuite à un cas un peu plus riche : une maison, avec un routeur qui connecte à un FAI et un réseau local d'un seul segment (il peut y avor plusieurs segments physiques, par exemple filaire et WiFi, mais le routeur, qui fait également point d'accès WiFi, les présente comme un seul réseau L2. C'est le réseau de M. Michu aujourd'hui et, là encore, mDNS et DNS-SD marchent bien.

On passe ensuite au réseau SOHO ou bien à la maison « avancée ». Cette fois, on introduit plusieurs routeurs (RFC 7368). Un tel réseau peut s'auto-organiser (il n'y a typiquement pas d'administrateur réseaux professionnel) mais la résolution de noms devient difficile, mDNS ne fonctionnant plus (il ne passe pas les routeurs).

Ensuite viennent les réseaux d'« entreprise » (en fait, de n'importe quelle grande organisation, entreprise à but lucratif ou pas). Plusieurs routeurs, des réseaux compliqués mais, cette fois, on a des administrateurs réseaux professionnels pour s'en occuper. À noter que les grands réseaux des conférences (comme le réseau WiFi des réunions IETF) rentrent dans cette catégorie. mDNS ne marche plus mais on peut désormais avoir des serveurs DNS administrés sérieusement.

Le RFC cite un cas encore plus élaboré, avec les NREN, qui mèlent administration centrale du réseau national, avec des équipes qui gèrent des réseaux régionaux ou de campus.

Et les réseaux « mesh » ? Ils sont multi-segments mais en général pas administrés, ils posent donc le plus de problèmes.

Bon, assez de préliminaires, les exigences maintenant, le vrai cahier des charges. Il figure en section 4. Les exigences sont notées REQn où N est un numéro de 1 à 15. REQ1, par exemple, dit qu'il faut un mode d'auto-configuration permettant à la future solution de marcher toute seule, pour le cas des réseaux non administrés. Mais attention, le RFC précise aussi que les objectifs de sécurité, de passage à l'échelle, de facilité et de déployabilité sont souvent contradictoires et qu'il ne faut pas prendre les exigences isolément mais en groupe (il faudra parfois en sacrifier une pour atteindre l'autre).

REQ2, complémentaire de REQ1, dit que pour les réseaux administrés, il faut pouvoir configurer le mécanisme de manière à partitionner le réseau, pour éviter qu'une requête ne voyage partout (voir aussi REQ15). REQ3 demande que cette possibilité de partition ne se fasse pas sur des critères topologiques (si on a deux segments dans un même bâtiment et un troisième dans un autre bâtiment, il faut pouvoir faire une partition regroupant un des segments du bâtiment et le segment de l'autre bâtiment, voir aussi REQ7).

Parmi les autres exigences, le fait (REQ5) de réutiliser les protocoles existants, notamment mDNS (RFC 6762) et DNS-SD (RFC 6763), l'obligation de fonctionner sur des réseaux où la consommation électrique est un facteur crucial (REQ10, qui dit en gros que le protocole ne doit pas réveiller toutes les machines toutes les cinq minutes), la nécessité de marcher correctement sur des réseaux de plusieurs milliers de machines (REQ11), l'importance de fournir aux utilisateurs un vécu identique que les ressources qu'ils cherchent soient locales au lien ou au contraire distantes (REQ12), le souhait que l'information présentée audit utilisateur ne soit pas dépassée (pas question de lui montrer les services tels qu'ils étaient il y a deux heures, ou même simplement deux minutes, REQ13), etc.

Après cette liste d'exigences, la section 5 de notre RFC se penche sur un problème délicat, la coexistence de plusieurs espaces de noms. En effet, si on utilise le DNS « normal », les noms sont uniques, et c'est une des propriétés les plus essentielles du DNS (RFC 2826). Mais si on utilise mDNS, chaque segment réseau a ses propres noms, sous le TLD .local. On peut parfaitement avoir une Imprimante-Couleur.local dans un bâtiment et voir une toute autre imprimante sous le même nom dans un autre bâtiment. Les noms ne sont plus mondialement uniques. Comme beaucoup d'engins seront livrés avec des noms par défaut identiques, ces « collisions » seront fréquentes. Le problème reste ouvert (voir aussi la section 6.2).

Enfin, la section 6 du RFC se préoccupe de la sécurité. Bien sûr, l'exigence d'un service automatique et efficace ne va pas forcément dans le sens de la sécurité (difficile d'authentifier sans ennuyer les utilisateurs, par exemple). Mais il y a aussi d'autres pièges. Par exemple, avec le mDNS traditionnel, les requêtes et les réponses ont une portée limitée (au seul segment de réseau local). Si on donne un nom à sa machine, le nom ne sera vu que localement et l'utilisateur peut donc donner un nom ridicule ou grossier sans trop de risques. Avec le projet d'étendre cette résolution de noms plus loin que le réseau local, le nom donné aura davantage de conséquences. Sans même parler du cas de noms à problèmes, une extension de la découverte de services peut faciliter la tâche d'un attaquant (imaginez ce que Shodan ferait d'un tel service) et/ou permettre/faciliter l'accès à des ressources qu'on pensait privées (une imprimante, par exemple). Bien sûr, la découverte d'un service n'implique pas son accessibilité mais le risque est quand même là.

Autre problème, la vie privée. Déjà, aujourd'hui, une technologie comme Bonjour est très bavarde. Un Mac ou un iPhone diffusent à tout le réseau local en donnant le nom de l'utilisateur ("l'iPhone de Jean Durand"). Mais le problème ne peut que s'aggraver si on va plus loin que le réseau local. Ce n'est sans doute pas une bonne idée qu'une machine arrivant dans un réseau inconnu annonce le nom de son propriétaire immédiatement. À noter que, en juillet 2015, une expérience de collecte du trafic diffusé à la réunion IETF de Prague a suscité de nombreuses discussions.


Téléchargez le RFC 7558


L'article seul

RFC 7578: Returning Values from Forms: multipart/form-data

Date de publication du RFC : Juillet 2015
Auteur(s) du RFC : L. Masinter (Adobe)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF appsawg
Première rédaction de cet article le 15 juillet 2015


Voici la nouvelle définition du type de données Internet multipart/form-data, qui est notamment envoyé par les navigateurs Web une fois qu'on a rempli un formulaire. Elle remplace la définition du RFC 2388.

Il y a plusieurs façons de représenter les données d'un formulaire rempli (cf. annexe B de notre RFC). (Et il faut aussi se rappeler qu'il n'y a pas que les formulaires en HTML : le format décrit dans ce RFC peut servir à d'autres types de formulaires.) Les deux plus fréquentes sont le format par défaut des formulaires Web, application/x-www-form-urlencoded, et le multipart/form-data qui fait l'objet de notre RFC. La sagesse générale des développeurs Web (citée par exemple dans la norme HTML 4) est d'utiliser application/x-www-form-urlencoded sauf s'il faut transmettre des fichiers ou des données binaires, auquel cas on préfère multipart/form-data. En HTML, cela se choisit par l'attribut enctype. Voici un exemple de formulaire HTML pour envoyer un fichier :

  
<form action="http://www.example.com/register"
       enctype="multipart/form-data"
       method="post">
   <p>
   What is your name? <input type="text" name="submit-name"/>
   What files are you sending? <input type="file" name="thefile"/>
   <input type="submit" value="Send"/> 
 </form>
  

Si l'utilisateur « Larry » envoie ainsi le fichier fi1e1.txt, le navigateur encodera les données du formulaire ainsi :

Content-Type: multipart/form-data; boundary=---------------------------14768918103265920051546586892
Content-Length: 359

-----------------------------14768918103265920051546586892
Content-Disposition: form-data; name="submit-name"

Larry
-----------------------------14768918103265920051546586892
Content-Disposition: form-data; name="thefile"; filename="file1.txt"
Content-Type: text/plain

   ... contents of file1.txt ...

-----------------------------14768918103265920051546586892--

Alors que l'encodage pour du application/x-www-form-urlencoded aurait été submit-name=Larry&thefile=file1.txt (ce qui ne convient pas pour le fichier). Cette différence entre les formats des données des formulaires est bien expliquée dans cette réponse sur StackOverflow. Et si vous voulez expérimenter vous-même avec netcat, voyez cette autre réponse.

Vu de l'utilisateur, les choses se passent comme cela (section 1 de notre RFC) : on présente à l'utilisateur un formulaire L'utilisateur le remplit, il sélectionne (par exemple en cliquant) le contrôle qui sert à dire « j'ai fini, traite-moi ce formulaire ». Le contenu est envoyé à une application sur le serveur. (Petit souvenir personnel : les formulaires sont apparus avec la version 2 de Mosaic et, pendant un certain temps, il était difficile de compter dessus car tout le monde n'avait pas encore mis à jour. Mais ça semblait formidable d'avoir un formulaire en Motif développé avec juste trois lignes d'HTML.)

Quel est le format de ce contenu qu'on envoie ? Il faut se rappeler que les formulaires ne sont pas spécifiques au Web, à HTML et à HTTP : le format peut être utilisé dans toute application qui a une notion de formulaire. Notre RFC ne spécifie pas le formulaire, ni le traitement sur le serveur de réception, mais uniquement le format de transport du formulaire rempli.

Il travaille donc sur une vision abstraite d'un formulaire, composé d'une séquence de champs, chaque champ ayant une valeur, fournie par l'utilisateur (certains champs peuvent avoir une valeur par défaut). Les champs ont un nom, qui est une chaîne de caractères Unicode (mais il est conseillé de se limiter à ASCII si on veut maximiser les chances d'interopérabilité). Il est également conseillé que les noms des champs soient uniques.

La section 4 de notre RFC détaille le format complet. Un message multipart/form-data suit de près le format des autres multipart/ MIME (RFC 2046, section 5.1). Comme son nom l'indique, il est composé de plusieurs parties séparées par une frontière, une ligne commençant par deux tirets. La valeur complète de cette ligne-frontière est donnée dans le champ Content-Type:. Il ne faut évidemment pas que cette ligne apparaisse dans les données envoyées.

Pour chaque partie, il est obligatoire d'avoir un champ Content-Disposition: (RFC 2183) avec un paramètre name qui indique le nom original du champ. Si la partie concerne un fichier qui a été envoyé, le RFC recommande que le champ Content-Disposition: contienne un paramètre filename, suggérant au serveur un nom pour le fichier. (« Suggérant » car, pour des raisons de sécurité, le serveur ne doit pas utiliser ce nom aveuglément, cf. aussi la section 7.)

Problème toujours intéressant, le jeu de caractères utilisé, et son encodage. On peut mettre un paramètre charset au Content-Type: de chaque partie MIME. Mais il est plus fréquent d'avoir un tel paramètre qui soit global. En HTML, la convention est qu'un champ caché du formulaire, nommé _charset_, fixe l'encodage par défaut. (Rappelez-vous que, dans les protocoles IETF et W3C, charset est mal nommé : c'est un encodage, plus qu'un jeu de caractères.) D'autre part, lorsque le transport du multipart/form-data est « 8-bit clean », ce qui est le cas de HTTP, l'utilisation du Content-Transfer-Encoding: est déconseillée.

La section 5 rassemble un ensemble de conseils pratiques pour la bonne transmission et interprétation des données des formulaires. D'abord, il est fortement déconseillé (même si, légalement parlant, ce n'est pas systématiquement interdit) d'éviter les caractères autres que ceux d'ASCII pour les noms des champs dans un formulaire. Ce n'est pas grave en pratique puisque ces noms, contrairement aux étiquettes affichées dans le formulaire, ne sont pas visibles à l'utilisateur. Voici un exemple en HTML :


<p>Envoyez une copie de votre carte d'identité 
<input type="file" name="idscan"/></p>

Le texte d'accompagnement comprend des caractères non-ASCII mais pas le paramètre name.

Toujours d'un point de vue pratique, quelques conseils de sécurité en section 7 :

  • Les données envoyées peuvent être des données personnelles, voire sensibles. C'est d'autant plus vrai que certains navigateurs Web ont une fonction d'auto-remplissage qui met automatiquement des informations personnelles dans les formulaires, ce qui fait qu'un utilisateur distrait peut envoyer davantage d'informations qu'il ne le voulait. L'auteur du formulaire et de son traitement doit donc faire attention à ces données.
  • Le contenu du fichier peut être dangereux (malware).

Le type multipart/form-data est, comme les autres types MIME, enregistré à l'IANA.

Quels sont les changements depuis le RFC 2388 ? Le format a été spécifié à l'origine dans le RFC 1867 puis dans la norme HTML 3.2. L'annexe A de notre RFC détaille les changements, parmi lesquels :

  • Les noms des champs non-ASCII doivent désormais être en UTF-8 et non plus encodés selon la méthode du RFC 2047 (mais, de toute façon, il est recommandé de les éviter). Cf. la section 5.1
  • Lorsque plusieurs fichiers sont envoyés (pour un même champ du formulaire), l'ancienne recommandation (RFC 2388) était d'utiliser un multipart/mixed, la nouvelle est de mettre chaque fichier dans une partie MIME spécifique (en utilisant le même nom de champ).
  • La convention du champ _charset_ (encodage par défaut) est désormais documentée.

Téléchargez le RFC 7578


L'article seul

RFC 7574: Peer-to-Peer Streaming Peer Protocol (PPSPP)

Date de publication du RFC : Juillet 2015
Auteur(s) du RFC : A. Bakker (Vrije Universiteit Amsterdam), R. Petrocco, V. Grishchenko (Technische Universiteit Delft)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ppsp
Première rédaction de cet article le 14 juillet 2015


Le pair-à-pair est un succès énorme de l'Internet et du contenu en quantités impressionnantes est échangé tous les jours avec des techniques fondées sur ce principe. Toutefois, il s'agit surtout de téléchargement (obtenir un contenu statique) alors qu'on voudrait pouvoir utiliser le même concept, le pair-à-pair, pour du ruissellement (streaming), afin de distribuer du contenu dynamique, comme un évenement en train de se produire et qu'on filme. C'est ce que permet le nouveau protocole PPSPP (Peer-to-Peer Streaming Peer Protocol), que normalise ce RFC. Son but est de fournir l'équivalent de BitTorrent pour du contenu dynamique, et beaucoup de concepts de PPSPP sont très proches de BitTorrent (cf. son cahier des charges, dans le RFC 6972).

Dans PPSPP, le contenu est « auto-certifié ». L'identificateur d'un contenu permet sa vérification. Contrairement au contenu statique, on ne peut pas utiliser un simple condensat cryptographique (méthode de BitTorrent) puisqu'on ne connait pas tous les octets à l'avance. PPSPP se sert donc d'un arbre de Merkle calculé récursivement au fur et à mesure que le contenu est disponible (comme cela avait été proposé pour BitTorrent, voir aussi la section 5.5). L'identificateur du contenu est le condensat cryptographique de la racine de cet arbre de Merkle. Grâce à cette auto-certification, un pair malveillant ne pourra pas modifier le contenu (il reste à s'assurer de l'authenticité de l'identificateur mais c'est une autre histoire... BitTorrent a le même problème.)

PPSPP est un protocole applicatif qui peut tourner sur plusieurs protocoles de transport. À l'heure actuelle, le seul normalisé est LEDBAT (RFC 6817), le protocole « durable », qui n'envoie des octets que lorsque le tuyau est libre. Ainsi, l'usage de PPSPP ne va pas perturber les autres applications. (La section 8 détaille l'usage de LEDBAT sur UDP.)

PPSPP peut découvrir la liste des pairs de plusieurs façons : via un tracker centralisé, ou via une DHT. Ce nouveau RFC suppose la liste des pairs déjà connue et ne décrit que le protocole pour récupérer le contenu. L'obtention de la liste fera l'objet d'autres travaux.

La section 2 de notre RFC présente le protocole, à travers trois exemples. D'abord, un pair qui rejoint un essaim (swarm). Un utilisateur humain regarde une page Web contenant un élément <video>. Son navigateur Web lui a présenté une image avec les contrôles habituels comme un bouton Play. L'utilisateur clique sur ce bouton. L'URL derrière la vidéo indique du PPSPP. Le navigateur va alors récupérer la liste des pairs (rappelez-vous que ce point n'est pas couvert dans ce RFC). Supposons qu'on utilise un tracker centralisé. Le logiciel PPSPP va s'enregistrer auprès de ce tracker. Il a une liste de pairs, il peut commencer à parler le protocole PPSPP avec eux. D'abord, le message HANDSHAKE (section 3.1 de notre RFC). Ensuite, il recevra des messages HAVE (section 3.2) indiquant quels sont les parties du flux de données que ses pairs connaissent déjà et peuvent donc fournir à leurs pairs. Il est maintenant un membre de l'essaim.

Deuxième exemple, on veut échanger des données. Notre logiciel PPSPP va envoyer des messages REQUEST (section 3.7) indiquant ce qui l'intéresse, en tenant compte des HAVE reçus. Les pairs envoient des messages DATA (section 3.3) contenant les octets de la vidéo, ainsi que des messages INTEGRITY (section 3.5) contenant les éléments de l'arbre de Merkle et permettant de vérifier que des intermédiaires n'ont pas modifié la vidéo (les détails sur cette vérification sont dans la section 5).

Une fois que notre logiciel a des données, il peut téléverser (to upload). Il va à son tour envoyer des messages HAVE aux pairs, et répondre à des requêtes REQUEST.

Le départ « propre » de l'essaim se fait en envoyant un message HANDSHAKE (et en se désincrivant du tracker, s'il y en a un). Mais, évidemment, dans un réseau pair-à-pair, il est fréquent que des machines ne partent pas proprement : coupure du réseau, plantage de la machine ou du logiciel, etc. Les pairs doivent donc être prêts à gérer le cas de pairs qui ne répondent plus.

La section 3 de notre RFC présente tous les messages qui peuvent être échangés (rassurez-vous : je n'en couvre qu'une partie mais ils ne sont pas si nombreux, seulement douze types). Les messages ne demandent pas de réponse : une absence de nouvelles de la part du pair indique qu'il y a un problème. Par exemple, si on envoie un message HANDSHAKE à des pairs qui ne veulent pas de nous, ils ne répondront pas avec un message d'erreur, ils s'abstiendront simplement de répondre. Il y a donc deux sortes de pairs : ceux qui répondent vite et bien et ceux qui répondent peu ou pas, et qu'on va donc petit à petit décider d'ignorer. On n'insiste pas avec les pairs non répondants.

À noter que PPSPP ignore le format des données envoyées : il transmet des octets, sans savoir si c'est du MPEG nu, ou bien un container rassemblant plusieurs fichiers, comme le permettent des formats comme AVI. PPSPP est un protocole de transfert de données, pas une solution complète de télé-diffusion.

Parmi les points à noter dans les messages : chaque essaim transmet un flot d'octets et un seul (cf. l'avertissement ci-dessus sur les containers). Un essaim a un identificateur (swarm ID), échangé dans les messages HANDSHAKE. Ces messages contiennent également d'autres paramètres (cf. section 7) comme la taille des morceaux (chunks) ou comme la fonction exacte utilisée pour l'arbre de Merkle. Le flot d'octets est en effet découpé en morceaux, chacun ayant un identificateur (chunk ID). Cet identificateur est un paramètre des messages HAVE, REQUEST et DATA. Ainsi, un message DATA contient un morceau, et l'identificateur de ce morceau. Cela permet au pair de savoir où il en est et s'il lui manque quelque chose.

J'ai parlé plus haut du message INTEGRITY qui contient un condensat cryptographique d'un sous-arbre de l'arbre de Merkle correspondant au contenu transmis. Les messages INTEGRITY ne sont pas signés donc ils ne protègent que contre les accidents, pas contre un pair malveillant. Il existe des messages SIGNED_INTEGRITY qui, eux, sont signés (cf. sections 5 et 6.1). À noter que, dans ce cas, la clé publique est dans l'identificateur de l'essaim, encodée en suivant le format des DNSKEY de DNSSEC.

Les messages REQUEST, mentionnés plus haut, servent à demander une partie du flot de données. Contrairement à BitTorrent, ils ne sont pas indispensables : un pair peut vous envoyer des morceaux que vous n'avez pas explicitement demandé. C'est logique pour PPSPP, qui est prévu pour le ruissellement : PPSPP est plus push que pull.

La section 4 explique le mécanisme d'adressage des morceaux. On n'est en effet pas obligé de les désigner un par un. On peut utiliser des intervalles (« du morceau N1 au morceau N2 »), des octets (« tous les morceaux qui composent le premier million d'octets ») ou bien des bin numbers. Un bin number est un mécanisme très astucieux permettant de désigner un intervalle d'octets presque quelconque avec un seul nombre. Je vous laisse lire la section 4.2 du RFC pour une explication complète. (Si quelqu'un de courageux peut ensuite en faire un article sur les bin numbers pour Wikipédia... Actuellement, il n'y en a pas.)

La section 12 de notre RFC intéressera tout particulièrement les administrateurs système et réseau. Elle couvre les problèmes opérationnels avec PPSPP. Par exemple, comme avec tout protocole pair-à-pair, un pair PPSPP a intérêt à choisir des pairs « proches » (entre guillemets car il n'est pas évident de définir « proche »). Le protocole ALTO du RFC 7285 peut aider à mieux choisir ses pairs. Mais il faut bien dire que, l'expérience concrète avec PPSPP manquant encore, on est un peu ici dans des zones inexplorées.

La section 13 du RFC, elle, se consacre aux questions de sécurité. D'abord, la vie privée : comme BitTorrent, PPSPP expose à chaque pair l'adresse IP des autres pairs (sauf si on utilise Tor, ce qui ne sera pas forcément simple) et on ne peut donc pas tellement cacher à ses pairs son intérêt pour tel ou tel contenu. À noter que PPSPP ne fournit pas de mécanisme pour protéger la confidentialité du contenu. Si on veut distribuer du contenu à accès restreint, on le chiffre avant, ou bien on utilise IPsec ou DTLS.

Ensuite, le risque d'attaques par réflexion, puisque PPSPP tournera typiquement sur UDP. Si un attaquant ment sur son adresse IP, peut-il déclencher l'envoi de données massives vers un innocent ? A priori, non, en raison de l'usage d'un mécanisme analogue aux ISN (Initial Sequence Number) de TCP. La communication nécessite la connaissance de nombres nommés channel ID et ils sont choisis aléatoirement (RFC 4960). Un attaquant ne peut donc pas les connaitre (cf. section 5.1.3) s'il a triché sur son adresse IP (puisqu'il ne recevra pas le message lui communiquant le channel ID à utiliser : en d'autres termes, PPSPP teste la « routabilité »).

Une version, apparemment assez expérimentale, de ce protocole a été mise en œuvre en logiciel libre, dans libswift. Une autre, écrite en Erlang est le projet Swirl.


Téléchargez le RFC 7574


L'article seul

RFC 7567: IETF Recommendations Regarding Active Queue Management

Date de publication du RFC : Juillet 2015
Auteur(s) du RFC : F. Baker (Cisco Systems), G. Fairhurst (University of Aberdeen)
Réalisé dans le cadre du groupe de travail IETF aqm
Première rédaction de cet article le 12 juillet 2015


L'AQM (Active Queue Management) désigne l'ensemble des techniques utilisées par un routeur pour gérer les files d'attente de paquets attendant de partir. La technique triviale est de faire passer les paquets en FIFO et de refuser de nouveaux paquets quand la file d'attente est pleine. Mais il existe plein d'autres techniques possibles, qui forment l'AQM. Ce nouveau RFC résume les recommandations de l'IETF sur l'AQM. Notamment, il n'y a plus de méthode privilégiée, comme l'était RED précédemment (dans l'ancien RFC 2309).

Petit rappel sur IP d'abord (section 1 du RFC) : IP (RFC 791 ou RFC 2460) est un protocole sans état (chaque paquet est routé indépendamment des autres) et donc sans connexion. Cela rend les routeurs bien plus efficaces (ils n'ont pas besoin d'avoir de mémoire), cela permet de changer de route facilement, cela permet de survivre à la perte ou au redémarrage d'un routeur. L'extrême robustesse de l'Internet le montre tous les jours. En revanche, une des faiblesses de ce mécanisme sans connexion est sa sensibilité aux fortes charges : si un routeur congestionné commence à perdre des paquets car ses liens de sortie sont saturés, les machines vont réémettre, envoyant davantage de paquets, aggravant la situation et ainsi de suite jusqu'à la fusion du réseau (le fameux Internet meltdown, cf. RFC 896 et RFC 970). Ce phénomène a été plusieurs fois observés dans les années 1980 sur le cœur de l'Internet. Il est depuis confiné aux marges de l'Internet, par l'applications de meilleures techniques dans les routeurs, mais il menace en permanence de réapparaitre.

Le RFC 2309, publié en 1998, est le dernier qui fasse le point sur le problème de la congestion et ses conséquences. Sa principale recommandation concrète était de déployer massivement une technique de gestion des files d'attente, RED (« Internet routers should implement some active queue management [...] The default mechanism for managing queue lengths to meet these goals in FIFO queues is Random Early Detection (RED). Unless a developer has reasons to provide another equivalent mechanism, we recommend that RED be used. ») Mais, depuis 1998, l'Internet a évolué, notamment par la demande plus forte de limitation de la latence. La recommandation du RFC 2309 ne semble plus aussi opportune. (Et RED s'est avéré difficile à configurer en pratique.)

Tout le travail n'est pas à faire du côté des routeurs. Le problème de la congestion et le risque de fusion sont tellement sérieux, surtout depuis les grandes pannes des années 1980, que beaucoup d'efforts ont été dépensés pour les traiter. C'est ainsi que Van Jacobson a développé les règles (« Congestion Avoidance and Control » dans le SIGCOMM Symposium proceedings on Communications architectures and protocols en 1988) que doit suivre TCP pour éviter que ce dernier n'aggrave la congestion : en cas de perte de paquets, TCP ne doit pas réémettre bêtement comme un porc mais au contraire se calmer, arrêter d'envoyer des paquets à la vitesse maximale, pour donner une chance aux files d'attente des routeurs de se vider. Ces règles sont aujourd'hui documentées dans le RFC 5681. Elles s'appliquent aux machines terminales de l'Internet, alors que notre RFC 7567 concerne les routeurs, qui ont aussi leur rôle à jouer. Les machines terminales ne peuvent pas tout, d'autant plus que toutes ne sont pas bien élevées : il y a des programmes mal écrits ou malveillants qui sont connectés au réseau, cf. la section 5. Des travaux sont en cours pour gérer le cas de machines qui ne réagissent pas à la congestion et continuent à émettre au maximum (cf. RFC 6789).

Mais le risque d'écroulement du réseau sous l'effet de la congestion n'est pas le seul. Il faut aussi penser à la latence. Si on augmente la taille des files d'attente dans les routeurs, pour diminuer le risque d'avoir à jeter des paquets, on augmente aussi la latence, car vider ces files prendra du temps. (L'augmentation excessive de la taille des files d'attentes est connue sous le nom de bufferbloat, voir aussi la section 2.3.)

La section 2 décrit en détail le problème de la gestion des files d'attente dans un routeur de l'Internet. La méthode traditionnelle, la plus simple, est connue sous le nom de tail drop : la queue a une taille finie, lorsqu'elle est pleine, on arrête d'accepter des paquets, point. Cela veut dire que les premiers paquets jetés sont les derniers arrivés. Cette méthode est simple à programmer mais elle a plusieurs inconvénients :

  • Tail drop ne signale la congestion aux machines terminales (en jetant les paquets) que lorsque la file d'attente est pleine. Si la file reste en permanence à 50-80 % pleine, aucun paquet ne sera jeté, les machines terminales continueront à émettre au même rythme, alors que le fait que la file soit plus qu'à moité pleine aura un effet négatif sur la latence.
  • Cette technique ne garantit pas l'égalité des différents flots de communication : dans certains cas, un seul flot peut monopoliser la queue.
  • Elle a aussi la propriété qu'elle tend à synchroniser les différentes machines qui partagent le même goulet d'étranglement (Floyd, S. et V. Jacobsen, « The Synchronization of Periodic Routing Messages »).

On pourrait réduire certains de ces problèmes (notamment le premier) en réduisant la taille de la file d'attente. Mais celle-ci est indispensable dans le cas d'augmentation brusque de trafic : le rythme d'arrivée des paquets n'est pas constant, il y a des moments où tout le monde parle en même temps (Leland, W., Taqqu, M., Willinger, W., et D. Wilson, « On the Self-Similar Nature of Ethernet Traffic (Extended Version) », IEEE/ACM Transactions on Networking), et les files d'attente sont là pour lisser ces soubresauts. Idéalement, on voudrait une queue vide en temps normal, qui ne se remplisse que pendant les pics de trafic. L'algorithme tail drop a l'inconvénient de créer souvent des queues pleines en permanence, au détriment de la latence.

Mais il y a d'autres algorithmes. Le random drop on full jette, lorsque la file est pleine, non pas le dernier paquet mais un paquet au hasard. Cela évite la monopolisation de la file par un seul flot de données mais cela ne résout pas le problème des files toujours pleines. Même chose pour le head drop qui consiste à jeter le premier paquet et non pas le dernier. La bonne solution est donc de ne pas attendre que la file soit pleine pour agir. C'est cette idée qui est à la base de l'AQM. En jetant des paquets avant que la file ne soit remplie (ou bien en les marquant avec ECN, cf. RFC 3168), on va dire indirectement aux machines terminales de ralentir, et on évitera ainsi les files complètement pleines, sauf en cas de brusque pic de trafic.

AQM est donc un concept proactif. Il permet de :

  • Jeter moins de paquets,
  • Réduire l'occupation des files d'attente, et donc la latence, pour le plus grand plaisir des applications interactives,
  • Éviter la monopolisation par un seul flot,
  • Réduire la synchronisation (par l'usage de choix aléatoires).

Tout cela est très bien si les applications utilisent toutes TCP, protocole habitué à réagir à la congestion (en diminuant son débit), et qui protège l'Internet contre les abus. Tant qu'il n'y a que TCP, avec des algorithmes conformes aux recommandations du RFC 5681, tout le monde partage le réseau en bonne intelligence et sans catastrophe, et chacun obtient une part égale de la capacité.

Mais il n'y a pas que TCP dans l'Internet, certains applications utilisent, par exemple, UDP (conseil personnel au passage : le programmeur débutant qui ne connait pas bien les problèmes de congestion devrait n'utiliser que TCP ou un équivalent comme SCTP, afin d'éviter d'écrouler le réseau). On peut classer les flots de données non-TCP en trois catégories :

  • Flots amicaux avec TCP : ce sont ceux qui utilisent des algorithmes de contrôle de la congestion qui, en pratique, leur donnent un débit proche de celui d'un flot TCP (RFC 5348). Par exemple, ce sont des flots UDP envoyés par des applications dont les auteurs ont lu et appliqué le RFC 5405.
  • Flots qui ne réagissent pas à la congestion : ce sont ceux qui continuent à envoyer des paquets sans tenir compte des pertes ou des signalements ECN. Ce sont les « méchants ». Certaines applications de transport de la voix ou de la vidéo sont dans cette catégorie. Jusqu'à présent, la solution anti-congestion à l'IETF avait toujours été d'améliorer les applications. Comme on ne peut pas espérer que 100 % des applications soient bien élevées, il faudra un jour développer des solutions pour gérer ceux qui abusent.
  • Flots qui réagissent, mais pas aussi bien que TCP : ils ont un mécanisme de réaction à la congestion mais ce mécanisme est trop peu réactif, et ces flots prennent donc une part disproportionnée du trafic. Cela peut être le résultat d'une maladresse du programmeur (voir mon conseil plus haut : utilisez TCP, sauf si vous êtes vraiment très fort en contrôle de congestion). Mais cela peut être aussi délibéré, pour s'assurer une plus grosse part du gâteau. Par exemple, certaines mises en œuvre de TCP étaient plus agressives que la normale, peut-être pour que le vendeur puisse proclamer que son TCP était « plus rapide ». On est dans une problématique très proche de celle de nombreux problèmes écologiques : si peu de gens trichent, les tricheurs et les égoïstes ont un gros avantage. Mais s'ils entrainent les autres, une spirale de la triche se développe, jusqu'au point où c'est l'enfer pour tout le monde. Pour l'Internet, une telle spirale pourrait aller jusqu'au cas où il n'y aurait plus de réaction à la congestion du tout, chacun poussant ses octets au maximum, sans tenir compte de l'intérêt collectif.

La section 4 de notre RFC résume les recommandations actuelles :

  • Il faut faire de l'AQM,
  • Ce serait bien de ne pas seulement jeter les paquets mais aussi de pouvoir faire de l'ECN,
  • L'administrateur système ou réseaux ne devrait pas avoir à faire de réglages manuels (tuning), tout devrait s'ajuster automatiquement,
  • L'AQM doit répondre à la congestion effective, pas à ce que le routeur croit savoir sur l'application ou sur le protocole de transport (c'est également impératif pour la neutralité de l'Internet),
  • Le problème des flots délibérement égoïstes est très important, et nécessite davantage de recherche.

Le reste de la section 4 détaille chacune de ces recommandations.

Par exemple, la seconde vient du fait qu'il n'y avait au début qu'un seul moyen pour un routeur de signaler la congestion : jeter des paquets (ce qui était de toute façon nécessaire : quand il n'y a plus de place, il n'y a plus de place). L'ajout d'ECN, dans le RFC 3168, et les spécifications de son usage (voir par exemple le RFC 6679) ont ajouté un deuxième moyen, qui permet de réagir avant qu'on perde des paquets. (Le RFC note que retarder les paquets, ce que fait la file d'attente, peut aussi être vu comme un signal : l'augmentation du RTT va mener TCP à ajuster son débit.)

La recommandation comme quoi le tuning (par le biais de paramètres numériques qu'il faudrait ajuster pour obtenir l'effet idéal) ne doit pas être obligatoire est discutée en section 4.3. Elle vient de l'expérience ce certaines mises en œuvre d'AQM où le pauvre administrateur du routeur devait absolument fixer certains paramètres, alors qu'il manque de temps et qu'il n'est pas forcément expert en congestion. En environnement de production, il n'est pas réaliste d'espérer que le dit administrateur passe ses nuits à faire du tuning ; l'algorithme doit avoir des paramètres par défaut raisonnables et, pour le reste, doit s'ajuster tout seul, en tenant compte d'informations comme la capacité des interfaces du routeur, et de variables mesurées en cours de route comme la durée moyenne de séjour des paquets dans la file d'attente ou le pourcentage de paquets jetés. (Un des problèmes de RED est justement la difficulté à s'ajuster automatiquement.)

Cela n'interdit pas au programmeur de fournir des mécanismes permettant le tuning manuel (ainsi que des outils pour aider l'administrateur à prendre ses décisions) mais ces mécanismes ne doivent pas être indispensables.

Pour la recommandation d'objectivité (décider en fonction de ce qu'on observe, pas de ce qu'on suppose), il est utile de relire le RFC 7141. Par exemple, il ne faut pas tenir compte de la taille des paquets. De même, il ne faut pas supposer que toutes les applications utilisent TCP.

Enfin, sur la recommendation de continuer les recherches, la section 4.7 fournit un programme aux chercheurs qui se demandent sur quel sujet travailler : il reste encore beaucoup de travail.

La section 1.4 de notre RFC décrit les changements depuis le RFC 2309. Les deux plus importants sont :

  • La taille d'une file d'attente n'est plus forcément évaluée uniquement en octets. Elle peut l'être en temps passé par le paquet dans la queue.
  • L'algorithme RED n'est plus le seul recommandé pour gérer les files d'attente.

Téléchargez le RFC 7567


L'article seul

RFC 7562: Transport Layer Security (TLS) Authorization Using DTCP Certificate

Date de publication du RFC : Juillet 2015
Auteur(s) du RFC : D. Thakore (CableLabs)
Pour information
Première rédaction de cet article le 10 juillet 2015


Le protocole de sécurité TLS permet différents types d'autorisation et ce RFC en ajoute un nouveau, par la présentation d'un certificat DTCP. DTCP est un mécanisme de menottes numériques, et cette extension à TLS permet désormais « TLS pour les ayant-droits ».

DTCP, également connu sous le nom de 5C, est un système fermé. À l'heure actuelle, une version apparemment à jour de la spécification est disponible. Ce système DTCP est assez répandu dans des télévisions, des tablettes, des consoles de jeu... Les certificats DTCP (qui ne sont pas des certificats X.509) sont émis par DTLA (section 2.1 du RFC).

Le RFC 5878 spécifie l'extension de TLS à d'autres mécanismes d'autorisation. Et le RFC 4680 décrit l'ajout de données supplémentaires (le certificat) dans le message Handshake de TLS.

Le type d'autorisation IANA dtcp_authorization est désormais enregistré à l'IANA.


Téléchargez le RFC 7562


L'article seul

RFC 7504: SMTP 521 and 556 Reply Codes

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : J. Klensin
Chemin des normes
Première rédaction de cet article le 1 juillet 2015


Ce RFC enregistre officiellement deux nouveaux codes de retour SMTP (qui étaient déjà largement utilisés), 521 (« I do not accept mail ») et 556 (« The remote domain does not accept mail »). Tous les deux sont prévus pour le cas où un serveur ou un domaine n'acceptent jamais de courrier, en aucune circonstance (par opposition aux codes de rejet plus généraux comme 554).

Petit rappel au passage : les codes de retour SMTP, spécifiés dans la section 4.2 du RFC 5321, ont un premier chiffre qui indique notamment si l'erreur est temporaire (si le premier chiffre est un 4) ou permanente (si le premier chiffre est un 5). Dans le second cas, pas la peine de réessayer plus tard. Ici, le 521 dit bien « ne t'embête pas à revenir, demain, ce sera comme aujourd'hui, je n'accepterai jamais ton message »).

SMTP avait été prévu au début dans un monde où tout le monde acceptait du courrier. Dans les années 1980, toute station de travail Unix venait avec un sendmail activé qui pouvait recevoir des messages. Le paysage aujourd'hui est très différent (section 2 de notre RFC) avec un grand nombre de machines qui ne reçoivent pas de courrier. De même, certains domaines ne sont pas utilisés pour le courrier et il serait pratique de pouvoir indiquer cela à l'avance (RFC 7505).

Dans le premier cas (machine qui ne veut pas recevoir de courrier), le plus simple semble être de ne pas avoir de serveur SMTP du tout. Mais l'impossibilité de se connecter (réponse TCP RST, ou bien timeout, si le pare-feu jette les requêtes TCP) va être interprétée par le client SMTP comme temporaire, et celui-ci va alors réessayer pendant des jours. Si, par la suite d'une erreur de configuration, un client SMTP tente de se connecter à une machine sans serveur, il faudra donc attendre avant de détecter le problème. Avoir un simple serveur SMTP qui ne fait rien d'autre que dire tout de suite « arrête d'insister, ça ne sert à rien » pourrait être plus efficace.

Pour le second cas, le domaine qui n'a pas du tout de service de courrier, le RFC 7505 fournit un moyen simple de l'indiquer dans le DNS, avec le « MX nul ». Il ne manquait qu'un code de retour adapté, pour que le premier relais SMTP de l'utilisateur puisse dire « je ne peux pas envoyer de courrier à ce domaine, ils ne veulent pas ».

Le code 521 est décrit dans la section 3 du RFC. Il est renvoyé au début de la connexion puisqu'il décrit un refus général (pas d'exceptions). Si le refus du courrier est dû à certaines caractéristiques du courrier (par exemple l'emploi de tel émetteur), il ne faut pas utiliser 521 mais plutôt 554. Voici à quoi pourrait ressembler l'accueil d'un serveur SMTP simple, qui ne fait que rejeter imédiatement :

% telnet mail.example.net smtp
Trying 2001:db8:666::1...
Connected to mail.example.net.
Escape character is '^]'.
521 I hate everybody, do not come back
[Connexion fermée]

Le serveur peut clore la connexion immédiatement, ou bien la laisser ouverte et renvoyer des 521 systématiquement. Un message moins pittoresque pourrait être « Server does not accept mail ».

À noter que le code 521 avait déjà été décrit dans le RFC 1846 mais pas normalisé.

La section 4 décrit l'autre code, 556. Le premier code était prévu pour un serveur qui refusait le courrier, le second pour un relais qui essaie d'envoyer au serveur suivant mais découvre que le domaine de destination n'a pas l'intention d'accepter du courrier. Cette découverte se fait typiquement en voyant le « MX nul » du domaine en question (RFC 7505). En faisant une requête MX pour connaître le serveur suivant, le relais peut découvrir que le domaine n'accepte pas de courrier, et il renvoie alors un 556 à son client.

Les deux codes sont désormais enregistrés à l'IANA.


Téléchargez le RFC 7504


L'article seul

RFC 7505: A "Null MX" No Service Resource Record for Domains that Accept No Mail

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : J. Levine (Taughannock Networks), M. Delany (Apple)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF appsawg
Première rédaction de cet article le 1 juillet 2015


Comment indiquer qu'un domaine ne reçoit jamais de courrier ? Jusqu'à présent, il n'existait pas de mécanisme standard, permettant d'indiquer aux clients de ne pas perdre de temps à essayer d'écrire. Ce nouveau RFC indique une méthode, le « MX nul » qui consiste à mettre un point en partie droite de l'enregistrement MX.

Normalement, un logiciel de messagerie qui veut envoyer du courrier à bob@example.net va chercher dans le DNS l'enregistrement MX du domaine example.net. (Le processus exact est décrit dans le RFC 5321, section 5.1.) A priori, si on ne veut pas recevoir de courrier, il suffit de ne pas mettre d'enregistrement MX, non ? Malheureusement, ce n'est pas le cas : le RFC 5321 précise que, s'il n'y aucun MX, on essaie alors les adresses IP associées au nom (règle dite du « MX implicite »).

Or, il existe des domaines qui ne reçoivent pas de courrier, parce qu'ils sont seulement réservés sans intention d'être utilisés, ou bien parce qu'ils ne servent que pour le Web ou bien encore pour toute autre raison. Si un message tente de parvenir à ces domaines, la machine émettrice va perdre du temps à essayer des MX délibérement invalides (avant la norme de notre RFC 7505, des gens mettaient un MX pointant vers localhost) ou bien des adresses où aucun serveur SMTP n'écoute. Ce n'est pas joli. Et cela peut prendre du temps (lorsque la délivrance échoue, l'émetteur met en attente et réessaie) donc l'utilisateur qui s'est trompé de domaine ne sera prévenu que plusieurs jours plus tard, lorsque le serveur émetteur renoncera enfin.

Au contraire, avec le nouveau « MX nul », dit officiellement No Service MX, le rejet sera immédiat et l'utilisateur, notifié tout de suite, pourra corriger son erreur.

La syntaxe exacte du MX nul figure en section 3. On utilise l'enregistrement MX (RFC 1035, section 3.3.9), avec une partie droite comprenant une préférence égale à zéro et un nom de domaine (exchange, dans la terminologie du RFC 1035) vide (de longueur nulle), ce qui se note, en représentation texte, par un simple point. Voici un exemple :

% dig +short MX  internautique.fr 
0 .

Ce nom ne pouvait pas être un nom de machine légal, il n'y a pas de risque de confusion avec les MX actuels. (Les enregistrements SRV du RFC 2782 utilisent le même truc pour dire qu'il n'y a pas de service disponible à ce nom : « A Target of "." means that the service is decidedly not available at this domain. ».)

La section 4 liste les effets de l'utilisation du MX nul. Comme indiqué plus haut, il permet une réponse immédiate à l'utilisateur, lorsque celui-ci s'est trompé d'adresse (bob@example.net alors qu'il voulait écrire à bob@example.com). L'erreur SMTP à utiliser dans ce cas est 556 (Server does not accept mail, RFC 7504) avec comme code amélioré (codes définis dans le RFC 3643) le nouveau 5.1.10 Domain has null MX.

Le MX nul sert aussi si, par erreur ou par usurpation, un serveur tente d'envoyer du courrier avec une adresse d'émission qui est un domaine à MX nul : le récepteur peut rejeter tout de suite ce message, pour la raison qu'il ne pourrait de toute façon pas lui répondre (ou pas lui envoyer de DSN). C'est ainsi que procèdent beaucoup de serveurs de messagerie avec les adresse d'émission dont le domaine n'existe pas. Dans ce cas, les codes d'erreurs à utiliser sont 550 (mailbox unavailable) avec le code étendu 5.7.27 (Sender address has null MX). (Les nouveaux codes sont dans le registre IANA.)

Notez enfin que ce RFC concerne le cas où on ne reçoit pas de courrier. Si on veut dire qu'on n'en envoie pas, le plus simple est un enregistrement SPF -all.

Tous les hébergeurs DNS ne permettent pas encore de mettre un MX nul. Par exemple, l'un d'eux m'envoie promener « La valeur et/ou la priorité MX est incorrecte ».


Téléchargez le RFC 7505


L'article seul

RFC 7586: Scaling the Address Resolution Protocol for Large Data Centers (SARP)

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : Youval Nachum (Ixia), Linda Dunbar (Huawei), Ilan Yerushalmi, Tal Mizrahi (Marvell)
Expérimental
Première rédaction de cet article le 28 juin 2015


Le problème de passage à l'échelle de protocoles de recherche d'adresse MAC des voisins, les protocoles comme ARP, sont connus depuis un certain temps, et documentés dans le RFC 6820. Résumé en deux mots, dans un grand centre de données non partitionné en sous-réseaux IP, le trafic ARP peut représenter une partie significative du travail à effectuer par les machines. Ce nouveau RFC expose une des solutions pour faire face à ce problème : SARP (Scaling the Address Resolution Protocol) fait appel à des relais ARP qui peuvent générer localement la plupart des réponses.

Si le centre de données est rigoureusement découpé en sous-réseaux IP (par exemple un sous-réseau, et donc un routeur par baie), il n'y a pas de problème ARP : le trafic ARP reste local. Mais si on veut profiter de la souplesse que permet la virtualisation, par exemple en déplaçant des machines virtuelles d'un bout à l'autre du centre de données en gardant leur adresse IP, on doit alors propager les requêtes ARP sur une bien plus grande distance et les problèmes de passage à l'échelle apparaissent (RFC 6820). La mémoire consommée par la FDB (Filtering Data Base, la table des adresses MAC connues) augmente, ainsi que le temps de traitement de tous ces paquets ARP diffusés.

Les premières versions des brouillons ayant mené à ce RFC ne mentionnaient qu'ARP (RFC 826), protocole de résolution IP->MAC pour IPv4. Mais la version finale considère que le protocole marche aussi bien pour ND (RFC 4861), son équivalent pour IPv6. Seul le nom de la solution garde trace de cette préférence pour ARP. Dans le reste de cet article, je parlerais de ARP/ND.

L'idée de base de SARP est que chaque domaine d'accès (un groupe de machines proches, par exemple dans la même baie ou dans la même rangée) ait un relais (SARP proxy) qui connaisse les adresses MAC de tout le domaine, et réponde aux requêtes ARP/ND pour les autres domaines avec sa propre adresse MAC. Ainsi, la taille de la table ARP des machines du domaine reste proportionnelle à la taille du domaine d'accès, pas au nombre total de machines (comme ce serait le cas avec un réseau « plat » classique, entièrement en couche 2, et sans SARP).

Le relais SARP peut être l'hyperviseur d'un groupe de machines virtuelles (commutateur virtuel) ou bien il peut être dans un commutateur physique, ToR (Top of Rack) ou bien EoR (End of Row). En gros, le relais SARP est là où un domaine d'accès se connecte au cœur du réseau interne du centre de données. Ce doit être une grosse machine car elle va devoir stocker les adresses MAC de toutes les machines qui communiquent avec une machine d'un autre domaine d'accès. Et il peut aussi faire l'objet d'attaques délibérées (cf. section 4).

La section 3 de notre RFC décrit plus en détail le fonctionnement de SARP. Si la machine source et la destination sont dans le même domaine d'accès (même baie, ou même rangée, selon l'endroit où se trouve le commutateur), ARP/ND fonctionne comme d'habitude et SARP n'intervient pas. Si la machine de destination est dans un autre sous-réseau IP, on passe alors par le routeur, selon le mécanisme normal de la couche 3. Mais si la destination est dans le même sous-réseau IP, mais dans un domaine d'accès différent ? Le relais SARP voit alors passer la requête ARP/ND. Si la réponse est dans son cache (qui associe des adresses IP à des adresses MAC), il répond avec sa propre adresse MAC (ainsi, les machines du domaine d'accès local ne sont pas noyées par des milliers d'adresses MAC de tout le centre de données). Sinon, il transmet à tous les domaines d'accès qui peuvent avoir cette adresse IP puis relaie la réponse. Seuls les relais SARP ont un cache qui contient des adresses MAC de tout le centre de données. Les machines ordinaires n'ont que les adresses MAC de leur propre domaine d'accès.

Et pour transmettre un paquet de données ? La machine source, ayant reçu l'adresse MAC du relais SARP en réponse à sa requête ARP/ND va donc mettre sur le câble un paquet ayant pour adresse Ethernet de destination le relais SARP. Le relais SARP, utilisant son propre cache (qui, lui, est complet), remplace l'adresse MAC de destination par la « vraie », et l'adresse MAC source par la sienne (pour qu'une réponse puisse revenir), et remet le paquet sur le câble.

Un tel mécanisme fait que des opérations comme la migration d'une VM d'un bout à l'autre du centre de données sont complètement invisibles. Les mécanismes normaux de résolution feront tout le travail. Cela suppose toutefois que la machine qui se déplace (ou plutôt son hyperviseur qui, contrairement à la VM, est conscient du déplacement) émette tout de suite un paquet ARP gratuit ou un paquet ND non sollicité, pour que les caches soient mis à jour (autrement, la machine migrée restera injoignable le temps que l'entrée dans le cache expire).

Une conséquence de cette technique est que le relais SARP est absolument vital : s'il est en panne, plus rien ne marche, à part les communications locales à un domaine d'accès. Il vaut donc mieux en avoir plusieurs, pour chaque domaine d'accès.

Ce RFC n'a que le statut « Expérimental » car l'IESG n'est pas convaincue que ce soit la seule méthode. Le RFC 7342 liste un certain nombre d'autres techniques (pas forcément directement comparables à SARP). À noter que les approches de type overlay (RFC 7364) résolvent une partie du problème mais pas la question de la taille de la table des adresses MAC. Mais il y a les RFC 4664, RFC 925, RFC 4389 (ces deux derniers sont, à mon avis, proches de SARP), RFC 4541 et RFC 6575...


Téléchargez le RFC 7586


L'article seul

Dépanner un Raspberry Pi utilisé comme serveur

Première rédaction de cet article le 27 juin 2015


Parmi les joies de l'administration système, il y a le dépannage d'un serveur headless (sans console physique, ni écran ni clavier), lorsque ce dernier ne veut pas redémarrer. Comment faire sur un Raspberry Pi ?

(Si vous ne connaissez pas le Pi, il y a aussi un de mes articles.) Si le Pi est habituellement connecté à une télévision et à un clavier, on voit le processus de démarrage du système et on peut intervenir. Mais c'est plus facile à dire qu'à faire, car un Pi qui ne démarre pas et qui dit juste :

Requested init /bin/systemd failed (error -2)
kbd>

a de quoi laisser perplexe même l'administrateur système Unix expérimenté. Ce problème m'est arrivé avant-hier après une mise à jour d'Arch Linux. Ce système, en raison de ses rolling releases est évidemment plus vulnérable à ce genre de problèmes qu'un système très stable comme Debian, mais aucun système n'est 100 % à l'abri. Un jour ou l'autre, on se retrouve avec uniquement la diode rouge et le Pi qui n'est plus joignable en SSH.

Les gros serveurs dans les centres de données ont des cartes d'accès à distance comme les DRAC de Dell. Mais le Pi, très bon marché, n'a rien de tel. Brancher une télé, avec le câble HDMI, permet d'avoir au moins le message d'erreur. Curieusement, la plupart des articles qu'on trouve avec DuckDuckGo indiquent des méthodes compliquées pour réparer, avec des commandes tapées au clavier du Pi défaillant. Mais je trouve qu'il y a bien plus simple.

La méthode que j'ai utilisé la plupart du temps est simplement d'éteindre le Pi, de prendre la carte SD et de la mettre dans un PC Linux où on pourra réparer tranquillement. Bien sûr, cela nécessite d'avoir un PC sous la main mais je suppose que peu de gens ont un Pi sans aucun autre ordinateur.

Une fois la carte SD montée sur la machine Linux, on a alors un environnement Unix complet pour investiguer, et réparer. Cela va bien plus vite.

Et quel était le problème dans le cas cité plus haut ? Au cours de la mise à jour, Arch Linux avait mis dans les instructions de démarrage init=/bin/systemd alors que systemd était dans /lib/systemd. init est le premier programme en mode utilisateur qui est lancé par le noyau Linux du Pi, et l'erreur -2 voulait simplement dire qu'il n'était pas trouvé. Sur la carte SD montée sur un PC de secours, un ln -s /lib/systemd/systemd /bin a suffit à réparer, en mettant un lien symbolique depuis le nom utilisé vers le « vrai » nom. Une autre solution aurait évidemment été d'éditer le cmdline.txt (qui se trouve dans l'autre partition de la carte SD, la première, celle formatée en VFAT), et de remplacer init=/bin/systemd par init=/lib/systemd/systemd.


L'article seul

Fiche de lecture : La boîte à outils de la créativité

Auteur(s) du livre : Edward de Bono
Éditeur : Eyrolles
978-2-212-55658-2
Publié en 2004
Première rédaction de cet article le 27 juin 2015


C'est l'année dernière à Paris-Web que j'avais reçu ce livre. Après chaque conférence, l'orateur choisissait une personne du public qui avait posé une question particulièrement pertinente, et c'était moi (je suis désolé, j'ai oublié la question que j'avais posé). Mais je ne suis pas sûr que le choix des livres ait toujours été pertinent...

Ceci dit, sans Paris-Web, je n'aurais jamais pensé à lire ce livre. C'est un de ces ouvrages de consultant, écrit par un gourou qui passe son temps à expliquer à des gens comment être plus... efficace, productif, créatif, même. Je suis toujours surpris qu'on se moque des peuples premiers qui ont des sorciers pour faire venir la pluie ou faire en sorte que la chasse soit favorable, mais que des entreprises par ailleurs souvent sérieuses dépensent des sommes importantes pour payer ces gourous dont la seule compétence est le talent à faire croire qu'ils servent à quelque chose. À chaque fois, ils me font penser au sorcier Shadok à qui un sceptique reprochait de ne pas faire de miracles et qui répondait « 25 ans que je fais se lever le soleil tous les matins : pas un échec ». De nos jours, dans les pays riches du monde, on ne croit plus aux sorciers ou aux prêtres mais on n'est pas devenu plus intelligent pour autant : on croit aux gourous.

Pourtant, celui-ci fait des efforts pour qu'on évite de le prendre au sérieux. Il utilise plein d'exemples enfantins et j'ai du mal à croire qu'une assemblée de cadres supérieurs et de dirigeants, dans un grand hôtel international, ait pu suivre sans rire ses exercices de pseudo-psychologie avec les chapeaux jaunes et les chapeaux noirs...

Ce gourou est tellement convaincu de son importance qu'il n'a pas peur de lasser la patience de ses lecteurs avec ses diatribes contre les méchants plagiaires qui lui piquent ses remarquables idées (il y a vraiment des gourous secondaires, qui utilisent les chapeaux jaunes et les chapeaux noirs sans payer de droits d'auteurs ?) Pas une seconde, il ne se demande si celui qui a acheté (ou, dans mon cas, reçu) son livre n'a pas autre chose à faire que de lire ses plaintes.

Et, puisqu'on parle de fric et de droits, il est également significatif que de Bono parle pendant 450 pages de méthodes pour augmenter la « créativité » sans jamais s'interroger sur le but, sur le pourquoi. On rassemble des gens devant le gourou, il les fait travailler avec des exercices de l'école maternelle, mais jamais il ne les laisse ébrécher le tabou : on peut discuter des moyens pour atteindre le but (vendre plus de voitures, ou plus de hamburgers) mais jamais du but lui-même...

Preuve de son efficacité de vendeur, la page du Wikipédia francophone qui lui est consacrée est un article publicitaire « Ses techniques sont relativement simples d'usage et d'une bonne efficacité pratique » (le Wikipédia anglophone est plus prudent). Bref, une brochure commerciale pour ses activités de consultant, mais certainement pas un livre.


L'article seul

RFC 7568: Deprecating Secure Sockets Layer Version 3.0

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : R. Barnes, M. Thomson (Mozilla), A. Pironti (INRIA), A. Langley (Google)
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 26 juin 2015


Ce nouveau RFC formalise un point déjà bien connu des experts en sécurité : le dernier survivant de la famille SSL, SSL version 3, a de graves failles et ne doit pas être utilisé.

Il y a bien longtemps que SSL est dépassé, remplacé par TLS (même si des ignorants continuent de parler de SSL dès qu'ils voient un petit cadenas sur leur navigateur Web). Mais les vieux protocoles ne meurent pas facilement sur l'Internet. Manque de ressources humaines qualifiées, absence d'intérêt pour la sécurité, blocage par la direction financière qui demande quel est le ROI, des tas de raisons font que pas mal de serveurs acceptent encore le SSL v3. Celui-ci, décrit dans le RFC 6101 (mais qui avait été défini et déployé bien avant, en 1996, le RFC 6101 ne faisant que documenter longtemps après), devrait pourtant être abandonné définitivement, ne laissant que TLS (dont la version actuelle est la 1.2, en RFC 5246).

La première fin de SSL v3 était en 1999, avec la sortie de TLS, dans le RFC 2246. Le fait que SSL v3 soit toujours bien vivant aujourd'hui, plus de quinze ans après, donne une idée de l'ossification de l'Internet et du manque de réactivité des techniciens.

La section 3 de notre RFC résume la bonne pratique actuelle : NE PAS UTILISER SSL v3. Les clients ne doivent pas le proposer dans le ClientHello, ni les serveurs dans leur ServerHello.

Bien plus longue, la section 4 décrit pourquoi SSL v3 est cassé sans espoir de réparation. Première raison, qui a permis la faille POODLE (cf. un bon article d'explication pour tous), c'est que le remplissage en mode CBC n'est pas spécifié (et donc pas vérifiable par le pair). Autre faille, SSL v3 fait forcément du MAC-then-encrypt, ce qui est aujourd'hui considéré comme dangereux. TLS fait aussi du MAC-then-encrypt par défaut mais on peut le changer (RFC 7366) grâce aux extensions. Or, SSL v3 n'a pas la notion d'extensions.

Les algorithmes de chiffrement stream de SSL v3 ont tous des défauts sérieux, par exemple RC4 est désormais officiellement abandonné (RFC 7465). Question condensation, ce n'est pas mieux, certaines opérations de SSL v3 imposant MD5 (RFC 1321, abandonné par le RFC 6151).

L'échange de clés dans SSL v3 a aussi des failles permettant à un homme du milieu de se placer. Corrigées dans TLS par des extensions, elles ne sont pas corrigeables en SSL v3.

Toujours en raison de son manque d'extensibilité, SSL v3 ne peut pas avoir certaines des nouvelles fonctions développées depuis sa naissance. Pas d'algorithmes dans les modes AEAD (RFC 5246, section 6), pas de courbes elliptiques (RFC 4492), pas de reprise d'une session existante sans état sur le serveur (RFC 5077), pas de mode datagramme pour UDP (RFC 6347), pas de négociation de l'application utilisée (RFC 7301).

Comme le notait le texte d'accompagnement à l'IESG, où on doit indiquer les mises en œuvre du protocole, « Are there existing implementations of the protocol? Yes, and that's the problem;-) ». Ceci dit, une bonne partie des déploiements de TLS ont commencé à supprimer SSL v3. Logiquement, il devrait être retiré du code des bibliothèques TLS (alors que, encore aujourd'hui, la page d'accueil de GnuTLS se vante de gérer SSL v3). Espérons que ce RFC, qui n'apporte aucune information technique nouvelle, par son côté « officiel », contribue à faire bouger les choses.

Pour déterminer si un serveur accepte SSL v3, on peut utiliser le client d'OpenSSL :

% openssl s_client -connect www.bortzmeyer.org:443 -ssl3 
CONNECTED(00000003)
depth=0 CN = www.bortzmeyer.org
...
SSL handshake has read 2276 bytes and written 470 bytes
...
SSL-Session:
    Protocol  : SSLv3
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 8B815B79611AB6FB105E84AA3159A0E57D50BA61BEE33478BB5DFEAFD5E4979B

Ici, le serveur a accepté SSL v3 (handshake terminé, algorithme de chiffrement - DHE-RSA-AES256-SHA - sélectionné alors qu'on a forcé SSL v3). Si vous voulez savoir pourquoi ce serveur particulier accepte malheureusement SSL v3, voir à la fin de cet article.

Avec un qui n'a pas SSL v3, on voit :

% openssl s_client -connect www.example.net:443 -ssl3
CONNECTED(00000003)
3073382076:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:348:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
...
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 

Les messages d'OpenSSL, comme toujours, sont peu clairs, mais on peut voir que le handshake n'a pas abouti (très peu de données transmises), qu'aucun algorithme de chiffrement n'a été choisi et qu'aucune session n'a commencé (ID vide). Ce serveur est donc correct.

Notez que l'administrateur système est dépendant des logiciels utilisés et qu'il ne peut pas tout reprogrammer lui-même. Ainsi, GnuTLS a un module Apache, mod_gnutls, qui a une très sérieuse bogue (ancienne et jamais réparée) qui fait que SSLv3 n'est pas interdit, même quand la configuration le demande. Personnellement, je vais arrêter d'utiliser GnuTLS sur mes sites Web, pas à cause de la bibliothèque elle-même, qui est excellente, mais à cause de ce module Apache pas maintenu.


Téléchargez le RFC 7568


L'article seul

RFC 7590: Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : P. Saint-Andre (&yet), T. Alkemade
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF uta
Première rédaction de cet article le 25 juin 2015


Le groupe de travail UTA de l'IETF produit des recommandations pour un usage correct de TLS par les applications. En effet, indépendamment des forces et faiblesses propres de TLS, plusieurs problèmes de sécurité sont survenues en raison d'une mauvaise utilisation. Ce nouveau RFC traite le cas spécifique de l'utilisation de TLS par le protocole XMPP.

Les problèmes généraux identifiés par le groupe UTA avaient été documentés dans le RFC 7457 et les solutions généralistes, applicables à toutes les applications, dans le RFC 7525. Et pour le protocole XMPP, normalisé dans le RFC 6120 ? XMPP utilise TLS depuis au moins 1999. Les sections 5, 9 et 13 du RFC 6120 expliquent déjà comment faire du TLS avec XMPP. Mais notre nouveau RFC va plus loin et, dans l'esprit du manifeste XMPP/TLS , décide que XMPP doit suivre les recommandations plus strictes du RFC 7525, notamment concernant le choix des algorithmes de chiffrement.

La section 3 du RFC répète les recommandations du RFC 7525, que doivent désormais suivre les mises en œuvre de XMPP, notamment :

  • Toute mise en œuvre de XMPP doit avoir l'option <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> qui indique qu'elle est prête à démarrer TLS (RFC 6120, section 5.4.1 et quelques autres). Mais, comme cette option n'est pas elle-même protégée par TLS, elle peut être supprimée par un homme du milieu (attaque dite de stripping, RFC 7457, section 2.1). XMPP doit donc tenter de faire du TLS avec son partenaire, que cette option soit présente ou pas (le manifeste cité plus haut impose TLS, de toute façon).
  • La compression TLS étant désormais rejetée (RFC 7525, section 3.3), XMPP peut se rabattre sur la compression XMPP du XEP-0138.
  • XMPP a un mécanisme de reprise rapide des sessions (XEP-0198), on peut encore l'améliorer en le couplant avec la reprise de sessions de TLS.
  • En théorie (RFC 6125), un client XMPP devrait authentifier le serveur (et, de préférence, le serveur authentifier les autres serveurs). En pratique, ce n'est pas toujours le cas (avec Pidgin, un certificat à problèmes est signalé mais un seul clic suffit à l'accepter). Une des raisons pour lesquelles on ne peut pas imposer immédiatement une authentification généralisée est que les serveurs XMPP sont souvent hébergés dans un environnement multi-clients, chaque client hébergé ayant son propre nom de domaine et qu'un tel serveur devrait donc avoir un certificat pour chaque client, ou un certificat couvrant tous les clients. DANE résoudra peut-être le problème. En attendant, le RFC recommande fortement de préférer une connexion chiffrée et non authentifiée à une connexion en clair (se replier sur du trafic en clair parce que le certificat est invalide est absurde, mais courant). C'est par exemple ce que recommande le RFC 5386 pour le cas d'IPsec. Bref, « TLS tout le temps, authentification si possible » est le principe.
  • SNI (Server Name Indication, RFC 6066, section 3) est inutile en XMPP, l'attribut to suffit à indiquer le domaine concerné (l'attribut to envoyé avant TLS n'indique que le domaine, pas le destinataire).
  • En sécurité, il est bien connu que le point faible est l'utilisateur humain. La section 3.6 fait donc des recommandations pour les développeurs d'interface utilisateur : indiquer si la connexion avec le serveur est chiffrée par TLS, indiquer si l'authentification a réussi et, si oui, comment, permettre d'afficher l'algorithme de chiffrement utilisé et le certificat présenté, être averti si un certificat change (ce qu'on nomme parfois l'épinglage - pinning). Je viens de tester avec un Pidgin 2.10.10 et la seule de ces recommandations qui semble mise en œuvre est la possibilité d'afficher les certificats (menu Tools -> Certificates).

La section 5 rappelle que XMPP sur TLS chiffre aussi les informations de routage (contrairement à SMTP) et limite donc les fuites de méta-données. Elle revient aussi sur quelques limites de TLS : XMPP passe par plusieurs serveurs et, si ceux-ci sont piratés ou indiscrets, le chiffrement TLS, qui n'est pas de bout en bout, ne protège pas contre ceux qui ont le contrôle des serveurs. En termes moins gentils, si vous utilisez Google Talk, le chiffrement TLS avec Google Talk (qui marche bien) ne vous protège pas de PRISM. (À noter que notre RFC ne cite pas la solution de bout-en-bout OTR, qui existe mais est mal intégrée à XMPP.)

Je n'ai pas trouvé de liste de toutes les implémentations XMPP, avec leur degré de conformité à ce RFC.


Téléchargez le RFC 7590


L'article seul

RFC 7595: Guidelines and Registration Procedures for URI Schemes

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : D. Thaler (Microsoft), T. Hansen (AT&T Laboratories), T. Hardie (Google), L. Masinter (Adobe)
Réalisé dans le cadre du groupe de travail IETF appsawg
Première rédaction de cet article le 24 juin 2015


Ce n'est pas tous les jours qu'on enregistre un plan d'URI (le plan - scheme en anglais - est le premier composant d'un URI, la partie avant le premier deux-points). Ils sont peu nombreux et on voit rarement autre chose que le fameux http:. Mais, si jamais vous voulez ajouter un plan à la liste existante, ce RFC vous explique les règles d'enregistrement. Il remplace le RFC 4395.

Les plans d'URI sont normalisés dans le RFC 3986, section 3.1. Le plan est souvent appelé à tort « protocole » alors que, dans la grande majorité des cas, il n'a aucun rapport avec un protocole (voir la section 3.8 de notre RFC), et, même quand le nom du plan est celui d'un protocole (comme http:), il n'implique pas l'utilisation de ce protocole (un URI ne sert pas forcément à accéder à une ressource). 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 acct: du RFC 7565 ou le dict: du RFC 2229. La liste des plans enregistrés se trouve à l'IANA. 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 syntaxe et une signification qui dépendent du plan et un logiciel d'usage très général doit donc connaître ces plans et leurs particularités.

Il existe un registre des plans, qui permet aux développeurs de ces applications de trouver tous les plans en un endroit, et de limiter le risque de collision. La politique d'enregistrement est déliberement assez libérale pour éviter la prolifération de plans non-enregistrés.

Petite note d'internationalisation au passage : les plans sont les mêmes pour les URI (qui doivent s'écrire uniquement en ASCII) et les IRI du RFC 3987, qui peuvent utiliser Unicode (ce n'était pas clair dans le RFC précédent, le RFC 4395).

En section 3 de notre RFC, les règles à suivre. D'abord, la syntaxe générale des URI doit être respectée (ce qui est facile, elle est très générale). Par exemple, l'identificateur de fragment (ce qui suit le croisillon, cf. RFC 3986, section 3.5), garde la même sémantique (notamment le fait qu'il n'est utilisé que par le client, pas par le serveur Web), un nouveau plan d'URI ne peut pas utiliser cette syntaxe pour exprimer autre chose.

Est-ce que le nouveau plan d'URI est une bonne idée ? Pour que son enregistrement soit accepté, le plan doit présenter une utilité à long terme, répond la section 3.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. Et le Web contient autre chose que des clients et serveurs, il y a les relais, les caches, etc. (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. La définition d'un nouveau plan doit décrire la syntaxe de l'URI (rappelez-vous que la syntaxe générale des URI ne couvre qu'une petite partie des règles). La section 3.2 impose que le nouveau plan respecte les règles syntaxiques existantes. Par exemple 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). D'une manière générale, notre RFC déconseille l'utilisation de la barre oblique, sauf si on accepte des URI relatifs, pour éviter qu'un logiciel trop zélé n'ajoute en prime un traitement spécial pour . ou .. (souvent interprétés pour dire « ce niveau » ou « le niveau supérieur »).

Il faut bien sûr que le plan soit correctement et complètement défini (sections 3.3 à 3.5). 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:, où le modèle « accès à une ressource » ne s'applique pas) ? S'il existe une opération par défaut (« je lance mon navigateur Web sur example:foo-bar-42, que fait-il ? », elle doit être sûre, au sens où elle ne doit pas avoir d'effets de bord. Enfin, le cas des URI qui servent juste à faire correspondre à un identificateur non-URI est normalement plus simple, avec une définition assez évidente. C'est le cas par exemple des mid: du RFC 2392, qui transforment un Message-ID: du courrier électronique en URI.

On a parlé plus haut des IRI. La section 3.6 nous rappelle les principes d'internationalisation des URI, et donne des bons conseils (faire bien attention à ne pas autoriser plusieurs représentations d'un même caractère, cf. RFC 3986, section 2.5). Le RFC donne aussi de mauvais conseils comme de prétendre (sans donner un seul exemple) qu'il faut restreindre le plus possible le jeu de caractères autorisé, certains caractères étant « dangereux ».

Pendant qu'on parle de danger, la section 3.7 rappelle la nécessité de bien documenter les questions de sécurité et de vie privée liées au nouveau plan. C'est une des nouveautés par rapport à l'ancien RFC 4395 que cette mention de la vie privée. Cela reflète l'importance croissante accordée à ce problème à l'IETF : de nombreux RFC mentionnent désormais la vie privée et pas seulement la sécurité informatique traditionnelle.

Enfin, le plan doit recevoir un nom (section 3.8), qui soit à la fois assez court pour être pratique et assez long pour être descriptif (et ce nom doit suivre la syntaxe de la section 3.1 du RFC 3986 qui limite notamment à ASCII, même pour des IRI). 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 ».

Pour les plans privés, spécifiques à une organisation et non enregistrés, notre RFC recommande d'utiliser un nom de domaine inversé comme préfixe, afin de limiter les risques de collisions (sections 3.8 et 6). Si la société Example, titulaire du domaine example.com, veut un plan pour son système Foobar, elle utilisera donc com.example.foobar: comme plan d'URI. Cela évite toute collision avec une autre société qui aurait un Foobar. (Le RFC 4395 recommandait un tiret au lieu d'un point dans ce nom inversé.)

Ces règles de la section 3 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 4). Les enregistrements provisoires sont soumis à une politique plus libérale, « premier arrivé, premier servi ». Cela permet de demander que les plans privés soient, s'ils ne sont pas fabriqués à partir d'un nom de domaine comme l'exemple précédent, enregistrés de manière provisoire. Parmi les plans provisoires, au moment de cet article, bitcoin:, dtn: (cf. RFC 5050), etc.

Notez que, dans le registre des plans d'URI, outre les caractéristiques « permanent » et « provisoire », il y a aussi « historique » qui désigne les plans abandonnés (comme le fax: du RFC 2806).

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 7 (qui utilise les termes du RFC 5226 comme « examen par un expert » ou « premier arrivé, premier servi »). On remplit un formulaire (section 7.4 pour un formulaire vierge), il est examiné (dans la plupart des cas) sur une liste de diffusion comme uri-review@ietf.org, puis par un expert (section 7.2).

Une éventuelle mise à jour d'un enregistrement se fait par le même mécanisme (section 7.3).

Une des nouveautés de notre RFC, par rapport à son prédécesseur RFC 4395, est la création d'un plan d'URI qui sert à la documentation (dans l'esprit du RFC 5398 pour les numéros d'AS et RFC 2606 pour les noms de domaine). Si vous voyez un URI qui commence par example:, c'est... un exemple. Imaginons une base de données qui stocke des URI et qu'on montre un exemple d'export de cette base en JSON, on est sûr de ne pas entrer en conflit avec un vrai URI, et on n'a pas trop à se soucier de la syntaxe (le plan example: autorise tout), en utilisant ce plan :

{"uris":
   {"date": "2014-09-02 09:58:23+00:00",
    "uri": "example:do-some-thing#test"},
   {"date": "2015-06-24 16:11:09+00:00",
    "uri": "example:foo.bar"},
   ...
}

Le formulaire d'enregistrement de ce plan figure dans la section 8 de notre RFC, si vous envisagez d'enregistrer un plan et que vous voulez un exemple. Si vous voulez un vrai exemple récent, vous pouvez regarder la section 7 du RFC 7565, qui enregistrait acct:. (Pour les enregistrements provisoires, la demande est indiquée à partir du registre IANA.)

L'annexe A de notre RFC liste les changements qui se sont produits depuis le RFC 4395. Les plus importants, à mon avis, sont :

  • Fusion des registres permanent et provisoire en un seul registre, avec une colonne Status,
  • Libéralisation de l'enregistrement des plans provisoires (cf. RFC 5226), de « Examen par un expert » à « Premier arrivé, premier servi » (les plans permanents restent à « Examen par un expert »),
  • Ajout du plan example:,
  • Changement des conventions pour les préfixes des plans privés non enregistrés (point au lieu du tiret entre les composants du nom de domaine),
  • Diverses clarifications, par exemple sur le fait que tout plan d'URI s'aapplique aux IRI aussi bien qu'aux URI,
  • Ajout de la vie privée aux considérations sur la sécurité.

Il y avait eu d'autres idées pendant le développement de ce RFC, mais toutes n'ont pas été retenues. Par exemple, à l'IETF 90, nous avions discuté de faire des plans avec préfixes (coap+ws:, coap+sms:, etc, au lieu du simple coap: du RFC 7252), par analogie avec les types MIME structurés du RFC 6839.


Téléchargez le RFC 7595


L'article seul

Version 8 d'Unicode

Première rédaction de cet article le 19 juin 2015


Le 17 juin a vu la sortie d'une nouvelle version du jeu de caractères Unicode, la 8.0, pile un an après la précédente. On peut trouver une description des principaux changements en http://www.unicode.org/versions/Unicode8.0.0/ mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)

Pour explorer plus facilement la grande base Unicode, j'utilise un programme qui la convertit en SQL et permet ensuite de faire des analyses variées. Faisons quelques requêtes SQL :

ucd=> SELECT count(*) AS Total FROM Characters;
 total  
--------
 120737

Plus de 120 000 caractères. Lesquels ont été apportés par la version 8 ?


ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version;
...
 7.0     |  2834
 8.0     |  7716

7 716 nouveaux. Lesquels ?

ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='8.0';
 codepoint |                                    name                                    
-----------+----------------------------------------------------------------------------
...
 U+8B4     | ARABIC LETTER KAF WITH DOT BELOW
...
 U+13FB    | CHEROKEE SMALL LETTER YU
...
 U+11294   | MULTANI LETTER DDHA
...
 U+12488   | CUNEIFORM SIGN DA TIMES TAK4
...
 U+1D96D   | SIGNWRITING MOVEMENT-FLOORPLANE DOUBLE ALTERNATING WRIST FLEX
...
 U+1F32F   | BURRITO
 ...
 U+1F3FF   | EMOJI MODIFIER FITZPATRICK TYPE-6
 ...
 U+1F54C   | MOSQUE
 U+1F54D   | SYNAGOGUE
...

Comme on le voit, c'est varié. On trouve des écritures entièrement nouvelles comme le multani ou le système Sutton pour la langue des signes, des nouvelles lettres pour des écritures existantes (le « ARABIC LETTER KAF WITH DOT BELOW » est ajouté à l'alphabet arabe pour écrire des langues de l'Asie du Sud-Est), des nouveaux emojis (comme le burrito)... L'alphabet cherokee a connu un grand changement, il est désormais bicaméral et les minuscules du Cherokee viennent donc s'ajouter à Unicode (comme la U+13FB ci-dessus). Par contre, comme il ne s'est écrit qu'en majuscules pendant longtemps, l'algorithme d'uniformimisation de casse d'Unicode met le Cherokee en majuscules, et pas en minuscules comme pour toutes les autres écritures.

Si vous avez les bonnes polices de caractères, voici les caractères pris en exemple plus haut : ࢴ, ᏻ, 𑊔 𒒈, 𝥭, 🌯, (U+1F3FF a été omis, voir à la fin), 🕌, 🕍 ... (UniView n'a apparemment pas encore été mis à jour avec les données de la version 8).

Comme toujours depuis quelques versions d'Unicode, tout le monde s'excite sur les nouveaux emojis (si vous ne les avez pas encore sur votre ordinateur, voyez les jolis dessins sur ce site). Plutôt que de donner des listes pittoresques, avec des glyphes rigolos, je suggère fortement à mes lecteurs de lire l'excellent Unicode Technical Report #51 sur la gestion des emojis dans Unicode. Vous y apprendrez le pourquoi de ces caractères, et les règles qu'ils suivent dans Unicode, et comment enregister un nouvel emoji. À la lecture de ce rapport, vous saurez pourquoi le policier tue le crocodile (et pas le contraire), pourquoi un emoji dont le nom inclut BLACK n'est pas forcément noir, quelles sont toutes les formes possibles du shortcake...

Une nouveauté importante des emojis dans cette version 8 est la gestion de la couleur de peau. Traditionnellement, les personnages humains dans des emojis sont représentés avec une peau jaune vif. C'est considéré comme « neutre » (notez que les emojis sont nés au Japon...) Cela ne convient pas forcément à tout le monde et il y a une demande depuis longtemps pour permettre de représenter des gens à la peau rose ou noire. C'est possible avec la nouveauté des modificateurs d'emojis. Ce sont des caractères Unicode qui se placent après l'emoji et modifient la couleur de la peau du personnage. Ils sont cinq, correspondant aux cinq degrés de l'échelle de Fitzpatrick. Par exemple, si votre navigateur gère ces récents modificateurs, en mettant les deux caractères U+1F477 (CONSTRUCTION WORKER) et U+1F3FE (EMOJI MODIFIER FITZPATRICK TYPE-5), vous devriez voir un ouvrier à la peau sombre (mais pas complètement noire). Essayons d'abord sans le modificateur : 👷 et avec : 👷 🏾. (Au passage, ce caractère U+1F477 est cité dans le rapport #51 pour une autre raison politique : il est neutre du point de vue du genre et peut donc être représenté par un homme ou une femme.)

À noter deux limites des modificateurs : ils ne peuvent pas s'appliquer à chaque membre d'un groupe. Donc, dans U+1F46C TWO MEN HOLDING HANDS, les deux hommes ont forcément la même couleur de peau. Et, autre limite, les modificateurs ne peuvent changer que la couleur de la peau, pas d'autres caractéristiques comme la minceur.


L'article seul

RFC 7575: Autonomic Networking - Definitions and Design Goals

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm (Cisco Systems), B. Carpenter (Univ. of Auckland), S. Jiang (Huawei Technologies), L. Ciavaglia (Alcatel Lucent)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF nmrg
Première rédaction de cet article le 19 juin 2015


Ce nouveau RFC, issu de l'IRTF et donc assez futuriste, se penche sur les « réseaux autonomes » (autonomic networking), c'est-à-dire sur les réseaux qui se débrouillent tout seuls, sans administrateur réseaux, sans DSI, sans ICANN, etc. Un réseau autonome doit se configurer, s'optimiser, guérir des pannes et se protéger des attaques sans intervention humaine. Ce RFC n'explique pas comment les réaliser (c'est le début d'un programme de recherche) mais définit la terminologie et les buts à atteindre. Il a été publié en même temps que le RFC 7576, qui analysait les techniques existantes et leurs limites. (Le groupe de travail IETF ANIMA travaille sur les aspects plus concrets de ce sujet.)

La première description de tels réseaux autonomes date de 2001 (l'article de Kephart et Chess). L'idée est que toutes les boucles de régulation du système doivent être fermées, sans interaction avec l'extérieur (d'où l'adjectif « autonome »). IP lui-même a éte partiellement conçu pour fonctionner ainsi (la fameuse demi-légende de l'Internet prévu pour résister à une attaque nucléaire). Un protocole comme OSPF est autonome dans la mesure où il s'adapte tout seul aux changements de topologie. Toutefois, IP n'a jamais été complètement autonome et les évolutions qu'il a subi allaient plutôt dans le sens de mettre plus d'intelligence dans la configuration externe que dans le réseau lui-même. Est-ce grave ? Pour un grand réseau d'un Tier 1, on peut penser que son propriétaire préfère que le réseau n'ait pas trop d'autonomie (Skynet ?) et suive plutôt la politique configurée. Mais les réseaux autonomes sont tentants pour l'Internet des objets, quand on a un grand nombre de petites machines très simples, ensemble qui serait très difficile ou impossible à configurer avec les outils existants. Notre RFC estime que les deux approches (configuration extérieure centralisée, et fonctionnement réparti autonome) ont leurs avantages et inconvénients, et que pas mal de réseaux utiliseront une de ces deux approches pour certaines fonctions et la seconde pour les autres fonctions. Ne cherchez donc pas de réseau complètement autonome tout de suite.

De toute façon, l'approche autonome ne peut pas tout faire. Elle nécessite de découvrir tout seul un certain nombre de choses et la politique de gestion du réseau (qui peut s'en servir, pour quoi...) est un bon exemple de quelque chose qui ne peut pas être découvert, qui doit être configuré explicitement.

Les réseaux autonomes ont fait l'objet d'un très grand nombre d'études scientifiques et de publications (la section 7 du RFC contient des lectures, pour les gourmands, notamment trois synthèses de l'existant). Attention, on dit « autonome » et pas « automatique ». Il faut se gérer seul, pas juste dérouler automatiquement un script pré-établi par un humain (voir la section 2 sur les définitions). Par exemple, un système automatique doit être reprogrammé lorsque l'environnement change alors qu'on attend d'un réseau autonome qu'il s'adapte seul.

Donc, que veut-on d'un réseau autonome ? La section 3 décrit les buts. Le réseau doit être auto-géré ce qui se décline en :

  • Se configure tout seul. Les machines démarrent, se découvrent, trouvent les liens qui les relient et se mettent à les utiliser. Pas d'admin' pour avoir tapé des default_router=fe80::1.
  • Se guérit tout seul. Une pelleteuse arrache un câble ? Le réseau contourne le problème automatiquement (ceci marche dans l'Internet actuel : rappelez-vous qu'on a déjà certaines fonctions qui peuvent marcher de manière autonome).
  • S'optimise tout seul en trouvant la meilleure façon d'accomplir les tâches définies.
  • Se protège tout seul car le monde est hostile et cruel et des hackers chinois islamistes à cagoule vont attaquer le réseau.

Évidemment, en trichant, on peut définir tout réseau comme « autonome » si on élargit la définition pour inclure, par exemple, un contrôleur central (comme avec le SDN). Le RFC est donc plus spécifique : « tout seul » veut dire « en n'utilisant que des fonctions qui sont sur les machines terminales ». Comme dit l'Internationale, le réseau autonome n'a « ni Dieu, ni César, ni tribun[, ni contrôleur SDN] ».

Comme on ne peut pas envisager un Internet complètement autonome, ces réseaux autonomes vont devoir coexister avec les méthodes de gestion traditionnelles (comme Netconf). Cela peut nécessiter un mécanisme d'arbitrage si les deux méthodes sont en désaccord. Le RFC utilise un exemple tiré de l'aviation : un avion où le pilote automatique se coupe automatiquement si le vol sort d'une certaine plage de paramètres (par exemple si l'angle d'incidence est trop élevé). Toutefois, on peut aussi se dire qu'une crise n'est pas le meilleur moment pour passer brutalement le contrôle au pilote stressé et le RFC demande donc que les mécanismes autonomes ne se coupent pas tout seuls, même dans des situations non prévues.

Autre but de nos réseaux autonomes : qu'ils soient sûrs. On doit pouvoir, par exemple, empêcher un intrus de rejoindre le réseau, ce qui implique un certain mécanisme d'authentification, qui ne sera pas forcément totalement autonome (par exemple un certificat émis par une AC, une base d'utilisateurs centralisée, etc). Bref, il faudra sans doute de la cryptographie.

« Autonome » ne veut pas dire « isolé et sourd-muet » (sinon, ce ne serait pas un réseau). La machine doit communiquer avec des pairs mais aussi avec des autorités, comme cela qui lui communique le travail à faire, à qui la machine terminale transmet des rapports, des statistiques, etc. C'est ce qu'on nomme l'interface Nord (car placée en haut sur les schémas et tant pis pour l'Australie).

On a vu que le réseau n'est pas créé pour satisfaire les machines mais pour accomplir un certain travail. Il faudra donc un mécanisme pour informer les machines de ce travail, et des changements dans les définitions de ce travail. Ce mécanisme doit être de haut niveau, sinon, ce ne sera plus un réseau autonome, on retournerait à la configuration centralisée traditionnelle. Par exemple, le RFC demande que ce mécanisme n'expose pas la version d'IP utilisée (IPv4 ou IPv6) : cela doit rester un détail technique interne au réseau.

J'ai parlé plus haut de transmettre des rapports à l'autorité centrale. Il est évidemment nécessaire de prévenir les humains qui ont acheté et déployé ces machines de l'efficacité de celles-ci : le travail a-t-il été fait ? Mais, pour respecter le principe d'un réseau autonome, les rapports ne doivent pas porter sur des détails d'implémentation que le réseau doit résoudre lui-même (comme « le lien entre la machine X et la machine Y ne marche plus »). Il faut au contraire un mécanisme de communication abstraite, synthétisant l'information, pour ne pas écrouler l'autorité centrale sous les détails. Imaginons que l'autorité ait envoyé le but de haut niveau « économise l'énergie », le rapport devrait être du genre « 30 % de réduction de la consommation, obtenu en éteignant 40 % des ports réseau ». Pour résumer : les rapports devraient décrire le réseau globalement, pas machine par machine ou lien par lien.

Le RFC 7576 montre qu'il existe déjà un certain nombre de protocoles et de fonctions autonomes dans la famille IP. Mais le but du projet « réseaux autonomes » n'est pas uniquement d'empiler des solutions mais de les intégrer dans un cadre commun, qui reste à développer.

Enfin, « autonome » est un adjectif qu'on peut appliquer à toutes les couches. Par exemple, les commutateurs typiques aujourd'hui sont autonomes au niveau 2 (on les branche n'importe comment et ils font une topologie qui marche). Les routeurs peuvent en faire autant au niveau 3, comme vu avec l'exemple OSPF.

Un bon cahier des charges doit aussi avoir des non-buts : ce qu'on ne cherche pas à atteindre. C'est le rôle de la section 4 du RFC. Les non-buts sont :

  • Supprimer complètement tout opérateur humain (Skynet, encore). Les humains vont rester, mais en se concentrant sur des fonctions de haut niveau, comme la définition et la vérification des politiques.
  • Résoudre tous les problèmes. De temps en temps, il se produira un évènement dont le réseau ne saura pas se dépêtrer seul. Là encore, des humains devront intervenir. Ce sera au moins le cas pour les pannes matérielles, tant que les ordinateurs n'auront pas de périphériques leur permettant d'aller à la casse eux-même...
  • Supprimer tout contrôle central. Comme le note le RFC, la Direction Générale ne serait sans doute pas d'accord.

Enfin, notre RFC se termine par une description, en section 5, d'un modèle de référence des réseaux autonomes, reprenant les points vus précédemment.


Téléchargez le RFC 7575


L'article seul

RFC 7572: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : P. Saint-Andre (&yet), A. Houri (IBM), J. Hildebrand (Cisco Systems)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF stox
Première rédaction de cet article le 17 juin 2015


Ce court RFC décrit une correspondance entre deux protocoles standards de messagerie instantanée, SIP et XMPP. Cela permet de développer proprement des passerelles connectant ces deux mondes, autorisant ainsi Juliette, utilisatrice de XMPP, à parler avec son Roméo, qui utilise SIP. C'est aussi un exercice intellectuel rigolo, mais parfois difficile, comment faire se parler deux protocoles différents, qui n'ont pas exactement les mêmes sémantiques.

C'est vrai qu'on ne sait pas forcément que SIP (RFC 3261) est aussi un protocole de messagerie instantanée. On le voit plutôt uniquement comme un protocole de signalisation pour la téléphonie sur IP. Mais SIP sait bel et bien échanger de courts messages textes, grâce à l'extension MESSAGE du RFC 3428. Quant à XMPP (RFC 6120), ses capacités de messagerie instantanée sont spécifiées dans le RFC 6121. C'est pour des raisons historiques variées que l'IETF a deux protocoles standard de messagerie instantanée, sans compter l'ancêtre IRC.

Le concept de messagerie instantanée, à l'IETF, est décrit dans le RFC 2779. Le but est de communiquer, donc il serait ennuyeux que Roméo et Juliette ne puissent pas échanger simplement parce qu'ils ont fait des choix technologiques différents. Spécifier un mécanisme de passerelle entre ces deux protocoles peut se faire en développant une sémantique abstraite (elle existe déjà, dans le RFC 3860), puis en définissant une correspondance entre cette abstraction et chaque protocole (ce qui a été fait pour XMPP : RFC 3922). En pratique, c'est bien compliqué et notre nouveau RFC 7572 choisit une autre approche, définir une correspondance entre SIP et XMPP, sans intermédiaire. L'inconvénient est que cela ne se généralise pas à davantage de protocoles, l'avantage est que c'est simple à comprendre et à programmer. En pratique, cette approche est donc bien plus répandue.

Notre RFC repose sur un modèle simple, l'envoi de courts textes, les messages, de manière synchrone, entre deux entités (Roméo et Juliette dans les exemples du RFC), ce qui se nomme page mode. Il existe d'autres modèles comme celui de conversations stables sur une certaine durée (session mode) ou comme celui de communications à plus de deux participants. Le groupe de travail STOX de l'IETF est penché dessus et produira d'autres RFC sur ces modèles, comme le RFC 7573 sur les sessions. Notre RFC s'appuie sur le RFC 7247, qui définissait une architecture pour l'interconnexion de SIP et XMPP.

Donc, commençons par XMPP vers SIP (section 4). Un message XMPP est une strophe (stanza) XML <message/> de type normal (le type par défaut). Voici l'exemple envoyé par Juliette :


<message from='juliet@example.com/yn0cl4bnw0yr3vym'
         to='romeo@example.net'>
   <body>Art thou not Romeo, and a Montague?</body>
</message>

Si le domaine dans l'attribut to est un domaine SIP (section 5 du RFC 7247), le serveur XMPP que Juliette utilise va transmettre le message à une passerelle XMPP->SIP qui va traduire en SIP :


MESSAGE sip:romeo@example.net SIP/2.0
Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
To: sip:romeo@example.net
From: <sip:juliet@example.com;gr=yn0cl4bnw0yr3vym>;tag=12345
Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 35

Art thou not Romeo, and a Montague?

Notez que l'identificateur de ressource dans le JID (le JID nu est juliet@example.com, la ressource est yn0cl4bnw0yr3vym, cf. RFC 6120, section 1.4) a été traduit en GRUU (Globally Routable User Agent URIs, cf. RFC 5627) SIP.

Le serveur SIP de Roméo répondra automatiquement avec le code 200 (tout va bien) :

SIP/2.0 200 OK
Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
From: sip:juliet@example.com;tag=12345
To: sip:romeo@example.net;tag=vwxyz
Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
CSeq: 1 MESSAGE
Content-Length: 0

La correspondance entre les termes utilisés figure dans le tableau 1 dans cette section 4. Ainsi, le <body/> de XMPP est transformé en corps du message SIP, l'attribut to de XMPP qui indique le destinataire devient le champ To: de SIP, l'attribut xml:lang de XMPP (absent dans cet exemple) devient un champ Content-Language:, etc. Certaines valeurs n'ont pas de correspondance (comme l'attribut type de XMPP, inutilisé dans l'exemple).

En sens inverse, lorsque Roméo répond, il va utiliser SIP (avec l'extension du RFC 3428) et il va donc falloir traduire le SIP en XMPP. Sa réponse était (section 5 de notre RFC) :


MESSAGE sip:juliet@example.com SIP/2.0
Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
Max-Forwards: 70
To: sip:juliet@example.com
From: sip:romeo@example.net;tag=vwxyz
Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 44

Neither, fair saint, if either thee dislike.

Et la passerelle SIP->XMPP qu'utilisera le serveur SIP de Roméo traduira en :


<message from='romeo@example.net/dr4hcr0st3lup4c'
         to='juliet@example.com'>
  <body>Neither, fair saint, if either thee dislike.</body>
</message>

La correspondance entre les termes (tableau 2) est la même, mais inversée. Le champ To: est traduit en attribut to, le corps du message devient un élément XMPP <body>, etc. Notez que la passerelle connaissait le GRUU SIP (par un moyen non spécifié, peut-être parce qu'elle fait partie du serveur SIP) et l'a utilisé pour générer un JID complet avec identificateur de ressource (romeo@example.net/dr4hcr0st3lup4c).

Faire des passerelles entre deux protocoles indépendants, conçus de manière différente et sans coordination a toujours été délicat. Par exemple, la section 6 fait remarquer qu'il y a un problème... de taille. SIP met une limite de 1 300 octets aux messages (RFC 3428, section 8) alors que les RFC sur XMPP ne spécifient pas de limite. En pratique, les messages XMPP dépassent rarement cette taille et, de toute façon, les mises en œuvre effectives de XMPP ont souvent une limite (RFC 6120, section 13.12), mais plus élevée (au moins 10 000 octets doivent être acceptés, dit le RFC 6120). Si Juliette, qui utilise XMPP, essaie d'envoyer un message de 1 500 octets à son Roméo, la passerelle XMPP->SIP n'aura pas d'autre choix que de le rejeter, avec une erreur <policy-violation/>. (Des solutions plus sophistiquées existent, comme de passer en session mode mais notre RFC ne les spécifie pas.)

Autre cause d'incompatibilités possibles, mais en sens inverse, cette fois, les questions de format des données (section 7). Un message SIP peut contenir des données de n'importe quel type (dans les exemples ci-dessus, c'était toujours du text/plain mais ce n'est pas obligatoire). XMPP traitant le contenu de manière très différente, notre RFC impose aux passerelles SIP->XMPP de :

  • Accepter le contenu text/plain, comme dans les exemples ci-dessus, en le mettant dans le <body/> XMPP,
  • Accepter le contenu text/html en le transformant en XHTML qu'on met dans le <body/> XMPP (comme décrit dans le XEP-0071),
  • Faire ce qu'elle veut avec les autres types, aucune règle n'est spécifiée pour eux.

Et si on veut le dire autrement qu'en anglais ? Pas de problème, les deux protocoles permettent d'étiqueter le message avec la langue utilisée, et tous les deux permettent de transporter des caractères Unicode (en général en UTF-8). Si Roméo décide de parler tchèque :


MESSAGE sip:juliet@example.com SIP/2.0
Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
Max-Forwards: 70
To: sip:juliet@example.com
From: sip:romeo@example.net;tag=vwxyz
Call-ID: 5A37A65D-304B-470A-B718-3F3E6770ACAF
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 45
Content-Language: cs

Nic z obého, má děvo spanilá, nenávidíš-li jedno nebo druhé. 

La passerelle le traduira sans problème (j'ai utilisé ici les notations commençant par &#x mais ce n'est pas obligatoire, XMPP utilise XML et peut donc se servir d'UTF-8) :


<message from='romeo@example.net'
         to='juliet@example.com'
         xml:lang='cs'>
	 <body>
           Nic z ob&#x00E9;ho, m&#x00E1; d&#x011B;vo spanil&#x00E1;, nen&#x00E1;vid&#x00ED;&#x0161;-li jedno nebo druh&#x00E9;.
       </body>
</message>

Un mot sur la sécurité pour finir. L'introduction de la passerelle entre les deux protocoles ajoute évidemment quelques risques. Notamment, il est plus difficile de garantir une sécurité de bout en bout. Il existe des solutions standard peu déployées (RFC 3862 et RFC 3923) ou une solution non standard, OTR.

Parmi les serveurs qui mettent déjà en œuvre cette passerelle, on peut apparemment citer Cisco, Kamailio, ou AG Projects (dans Silk Server).


Téléchargez le RFC 7572


L'article seul

RFC 7556: Multiple Provisioning Domain Architecture

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : D. Anipko
Pour information
Réalisé dans le cadre du groupe de travail IETF mif
Première rédaction de cet article le 16 juin 2015


Ce RFC décrit une architecture nouvelle permettant de mieux gérer les machines ayant plusieurs connexions à l'Internet. On ne parle pas ici de gros routeurs ou serveurs connectés à plusieurs réseaux, non, un simple smartphone qui a à la fois le WiFi et la 4G est un exemple d'une machine qui a plusieurs interfaces. Et cela pose des sérieux problèmes avec l'Internet d'aujourd'hui, car, parfois, chaque interface va nécessiter des réglages différents. Notre nouvelle architecture aborde ce problème en définissant le PvD (ProVisioning Domain ou domaine d'avitaillement), un ensemble cohérent de réglages, qui sera attaché à chaque interface.

Pourquoi est-ce un problème d'avoir plusieurs interfaces actives ? Car certains réglages ne sont valables que pour une seule interface, alors que TCP/IP considérait au début que toutes les interfaces se valaient et pouvaient être utilisées. Par exemple, l'adresse IP obtenue sur une interface ne doit pas être utilisée comme adresse IP source sur une autre interface, de peur de se faire mordre par le RFC 2827. Le résolveur DNS obtenu sur une interface ne doit pas être utilisé pour une autre car il refusera probablement de répondre (RFC 5358). Et, même si les résolveurs DNS acceptaient tous les clients, il arrive qu'ils renvoient des données qui ne sont pas les mêmes pour tout le monde (par exemple pour un serveur qui n'est accessible que depuis un certain réseau). Le RFC 6418 décrit plus en détail le problème des interfaces multiples, et le RFC 6419 proposait déjà quelques solutions, chacune spécifique à une plate-forme donnée. Pour résumer (à l'extrême) le RFC 6418, les risques sont :

  • Incohérence entre les informations obtenues depuis les différentes interfaces (comme dans l'exemple DNS ci-dessus),
  • Risque de mélanger les informations obtenues sur différentes interfaces (tenter de résoudre le nom d'un relais avec le serveur DNS d'un autre opérateur...),
  • Usage non conforme à la politique d'un des réseaux (par exemple, téléchargement d'un jeu via le VPN de l'entreprise...)

Donc, pour résoudre ce genre de problème, on introduit le concept de PvD. Mais c'est quoi, un PvD (section 2) ? Un ProVisioning Domain est simplement un ensemble cohérent d'informations de configuration d'un réseau, pour une interface donnée. Cela comprend par exemple l'adresse IP à utiliser (ou le préfixe IP), les adresses IP des résolveurs DNS, le routeur par défaut, le proxy Web à utiliser, etc. Une machine PvD-aware sait gérer cette information (notamment en l'association à une interface et en gardant en mémoire que, par exemple, ce résolveur DNS est fait pour cette interface). Une application PvD-aware a du code pour gérer la coexistence de différents PvD.

Aujourd'hui, les PvD sont implicites. La machine connectée reçoit de l'information de configuration sur chaque interface, via des processus divers (DHCP, mais pas seulement), et cette information n'est pas groupée, sous l'étiquette d'un PvD donné. C'est à la machine PvD-aware de gérer une table de PvD en les nommant et en les associant à chaque interface. Par défaut, avec les PvD implicites, une interface = un PvD.

Mais il y aura plus tard des PvD explicites. Cette distinction entre PvD implicites et explicites est essentielle. L'idée est de développer via l'IETF des mécanismes (qui n'existent pas encore) pour communiquer à la machine des PvD explicites, regroupant sous un nom donné un jeu d'informations de configuration cohérentes. Par exemple, on peut imaginer une option DHCP qui indique le nom du PvD correspondant aux options de configuration contenues dans cette réponse DHCP (ce n'est qu'une hypothèse : le RFC liste d'autres possibilités, cf. section 3). Avec les PvD explicites, il n'y aura plus forcément une interface = un PvD. On pourra avoir plusieurs interfaces utilisant le même PvD (si elles sont gérées par la même organisation).

Cela impliquera un système (non encore défini) de nommage des PvD. Le « PvD ID » devra être unique (puisque le but est de différencier les informations de configuration de réseaux différents), par exemple en le tirant au hasard dans un espace de grande taille. Le PvD ID ne sera donc pas forcément lisible par un humain ; si on veut une telle lisibilité, il faudra développer une solution, par exemple de méta-données associées au PvD.

Un PvD peut être commun à plusieurs familles IP (par exemple IPv4 et IPv6) et comporter donc plusieurs adresses. C'est utile si certaines options ont un sens pour plusieurs familles (c'est le cas de la politique de sélection de l'adresse du RFC 7078). Pour les PvD implicites, utiliser un seul PvD pour toutes les familles présentes sur l'interface est la politique recommandée.

La section 3 examine quelques protocoles existants pour voir comment ils pourraient être modifiés pour transporter de l'information explicite sur les PvD. Aujourd'hui, la configuration des machines terminales est faite en général par DHCP (RFC 3315) ou RA (RFC 3971). Notons qu'elles ne sont pas sécurisées par défaut. Des solutions existent pour authentifier la machine qui émet la réponse DHCP ou RA mais authentification n'est pas autorisation : elle ne nous dit pas si cette machine est autorisée à annoncer explicitement tel PvD. Pour cela, il faudrait un moyen de signer les PvD.

Évidemment, si on ajoute des mécanismes de PvD à ces protocoles, cela devra être fait d'une manière compatible avec les machines existantes, qui ne sont pas PvD-aware. Pendant la phase de coexistence, il faudra peut-être dupliquer de l'information dans les réponses DHCP ou RA, pour satisfaire tout le monde.

La section 4 du RFC présente trois études de cas concrètes. La première est celle d'une machine mobile, un smartphone, par exemple. Il a une interface avec un réseau mobile, mettons 3G, et une interface WiFi. S'il est dehors, loin de tout hotspot, il n'aura qu'une interface active et donc un seul PvD : pas de difficultés. S'il s'approche d'un point d'accès WiFi et s'y connecte, le dilemme commence : quelle interface utiliser ? Android, par exemple, ne peut en utiliser qu'une à la fois et va donc cesser d'utiliser la 3G. Cela simplifie le modèle de connexion pour les développeurs mais n'est pas satisfaisant pour l'utilisateur. Il serait plus satisfaisant de pouvoir utiliser les deux, mais en respectant à chaque fois le PvD (qui peut être différent) de chaque interface.

Autre étude de cas, un VPN, qui peut être considéré comme une interface supplémentaire, quoique virtuelle, et un réseau à la maison, connecté à la fois à un FAI généraliste classique et à un service de VoD, avec une interface séparée qu'on n'utilise que pour la vidéo, et qui est donc décrite par un PvD différent.

La section 5 de notre RFC étudie plus en détail certains points spécifiques qui doivent être traités par un nœud PvD-aware. Par exemple, la résolution de noms, déjà citée plus haut, qui dépend fortement du PvD : un résolveur DNS n'est typiquement utilisable que par certains clients, et pas par le monde entier. En outre, les résultats d'une résolution de noms peuvent varier selon le résolveur interrogé (cas d'un service spécifique à un FAI, par exemple le MMS). La machine doit donc savoir quel PvD utiliser pour chaque nom, avec des règles du genre « pour tous les noms se terminant en ma-boîte.example, se servir du résolveur DNS du PvD du VPN de ma boîte ». Si plusieurs PvD correspondent à des FAI généralistes, pouvant servir pour tout accès à un serveur public, la machine PvD-aware peut faire les résolutions de noms en parallèle, et prendre le plus rapide, selon un approche identique à celle des globes oculaires heureux du RFC 6555.

Et puisqu'on parle de sélectionner le « meilleur » PvD, il faut rappeler que la connectivité au réseau local, tel qu'elle s'obtient lorsqu'une requête DHCP ou RA a réussi, ne garantit pas un bon accès à tout l'Internet. Le signal local peut être fort, le serveur DHCP très réactif... et la connexion ultérieure échouer. Il est donc prudent de tester les connexions obtenues, par exemple en essayant de se connecter à un amer bien connu.

On a vu qu'une application pouvait être PvD-aware si elle sait utiliser l'information sur les PvD pour prendre des décisions. La section 6 décrit les propriétés attendues de l'API qui permettra de développer ces applications. Dans le cas le plus simple, une application PvD-aware peut se limiter à n'utiliser qu'un seul PvD. C'est le cas d'une application MMS qui dépend d'un opérateur particulier et qui devra donc passer par l'interface correspondante. Un peu plus complexe serait une application qui exprime des exigences et des préférences, du genre « il me faut IPv6 » ou « je fais de la vidéo-conférence, je veux une faible latence » ou bien « je suis paranoïaque, je ne veux passer que par un PvD cité dans telle liste » ou encore « je ne suis pas pressé, il vaut mieux utiliser la connexion la moins chère ». Le système pourrait alors choisir, en regardant les informations obtenues pour chaque PvD, quel PvD utiliser. Dans le dernier cas (une application qui télécharge beaucoup, comme la mise à jour du système d'exploitation, ou comme une application pair-à-pair d'accès à la culture), un mécanisme de sélection automatique via le PvD simplifierait nettement la tâche de l'utilisateur en le dispensant d'options comme la « n'utiliser qu'avec la WiFi » qu'on trouve souvent sur les applications Android, qui veulent éviter de faire exploser le forfait de téléphonie mobile.

Enfin, les applications les plus avancées pourraient simplement obtenir la liste des PvD et leurs caractéristiques et faire leurs choix elles-mêmes. Ces choix ne seront pas forcément respectés par le système, qui peut avoir ses propres exigences (par exemple forcer la passage par le VPN de l'entreprise pour les connexions aux services de la dite entreprise).

Puisqu'on a parlé de sécurité (« je suis paranoïaque, je ne veux passer que par un PvD cité dans telle liste »), un mot sur les PvD de confiance ou pas (section 7). Par défaut, un PvD n'est pas « de confiance ». Si je me promène dans la rue et que je me connecte à un hotspot inconnu, le PvD associé ne sera pas considéré comme de confiance. Certains systèmes ou applications ne voudront se connecter à tel service que via un PvD de confiance. Mais attention : supposons qu'on ait une telle liste (le PvD du VPN de la boîte, le PvD d'un opérateur à qui on fait confiance, le réseau local à la maison...), il ne faut pas pour autant considérer que le PvD est ce qu'il annonce. Si le PvD de l'entreprise est 6a97f31e-34ec-4ef9-ba75-b1e3addd8222 (ce n'est pas la vraie syntaxe des PvD ID, qui n'est pas encore décidée), et que le serveur DHCP du hotspot annonce ce PvD ID, il ne faut pas pour autant lui faire confiance (voir aussi la section 8). Un PvD de confiance nécessite deux choses : une relation de confiance avec son opérateur, et un moyen de vérifier qu'il s'agit bien du PvD attendu. Ce moyen d'authentification peut passer par une signature du PvD ID, ou bien simplement par le mécanisme d'attachement au réseau : on peut décider que, si on est connecté à un réseau physique stable et sûr, l'annonce du PvD ID sur ce réseau peut être crue. À noter que le RFC fournit un autre exemple, où on fait confiance au réseau d'un opérateur mobile, ce qui ignore le risque des IMSI-catchers.

La section 8 revient d'ailleurs sur les problèmes de sécurité. Par exemple, même si le serveur DHCP ou RA est sûr, un attaquant a pu modifier les données en cours de route. On peut utiliser les techniques (très peu déployées en pratique) de l'option AUTH du RFC 3315, section 22.11, ou le SEND du RFC 3971.


Téléchargez le RFC 7556


L'article seul

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

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu