Planet Collab

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
Yesterday — January 22nd 2021General

RFC 8972: Simple Two-Way Active Measurement Protocol Optional Extensions

Le protocole STAMP, normalisé dans le RFC 8762, est un protocole pour piloter des mesures de performance vers un réflecteur qui renverra les paquets de test. Ce nouveau RFC étend STAMP pour ajouter un identificateur de session, et la possibilité d'ajouter des tas d'options sous forme de TLV.

Commençons par l'identificateur de session. Une session STAMP est normalement identifiĂ©e par le tuple classique {protocole (forcĂ©ment UDP), adresse IP source, adresse IP destination, port source, port destination}. Ce n'est pas toujours pratique donc notre RFC ajoute un identificateur explicite, le SSID (STAMP Session Identifier). Il fait deux octets et est choisi par l'envoyeur. Mais oĂč le mettre dans le paquet ? Le format original prĂ©voyait qu'une partie du paquet STAMP soit composĂ©e de zĂ©ros, et c'est dans cette partie qu'on logera le SSID. Donc, si, aprĂšs l'estimation de l'erreur de mesure, on trouve deux octets qui ne sont pas nuls, c'est le SSID.

La section 4 liste les TLV qui peuvent dĂ©sormais ĂȘtre ajoutĂ©s aux paquets STAMP. Ces TLV sont situĂ©s Ă  la fin du paquet STAMP. Ils commencent par une sĂ©rie de bits qui indiquent si le rĂ©flecteur connait le TLV en question, et si le rĂ©flecteur a dĂ©tectĂ© des problĂšmes par exemple un TLV Ă  la syntaxe incorrecte (cf. le registre IANA). Les principaux TLV sont :

  • Le type 1 permet de faire du remplissage, pour crĂ©er des paquets de la taille souhaitĂ©e,
  • Le type 2 demande au rĂ©flecteur des informations sur son adresse MAC et autres identificateurs,
  • Le type 3 demande une estampille temporelle (avec en prime indication de la mĂ©thode de synchronisation d'horloge utilisĂ©e, par exemple NTP),
  • Le type 8 permet de vĂ©rifier l'intĂ©gritĂ© du paquet par HMAC (voir la section 6 du RFC pour les dĂ©tails),
  • Etc.
Si cela ne suffit pas, d'autres types de TLV pourront ĂȘtre crĂ©Ă©s dans le futur et mis dans le registre IANA. La politique d'enregistrement (cf. RFC 8126) est « examen par l'IETF » pour la premiĂšre moitiĂ© de la plage disponible et « premier arrivĂ©, premier servi » ensuite.
Before yesterdayGeneral

RFC 8831: WebRTC Data Channels

Ce RFC décrit le canal de données (à l'exclusion de l'audio et de la vidéo) entre deux navigateurs Web se parlant avec WebRTC. Ce canal utilise le protocole de transport SCTP.

Le canal de donnĂ©es WebRTC est une modĂ©lisation d'un tuyau virtuel entre les deux parties qui communiquent, tuyau dans lequel circuleront les donnĂ©es. SCTP (RFC 4960) n'est pas utilisĂ© pour les donnĂ©es « multimĂ©dia » comme la vidĂ©o ou l'audio, mais seulement en cas de transfert d'autres donnĂ©es. On peut ainsi utiliser WebRTC pour se transmettre un fichier. (Je ne connais pas Ă  l'heure actuelle de service WebRTC permettant cela. Vous avez un exemple ?) Le multimĂ©dia, lui, passe via SRTP, les donnĂ©es nĂ©cessitant une plus grande fiabilitĂ© passent par SCTP lui-mĂȘme transportĂ© sur DTLS (RFC 6347) lui mĂȘme sur UDP. Du fait de cette encapsulation, vous ne verrez pas SCTP avec un logiciel comme Wireshark. La raison pour laquelle UDP est utilisé ? Permettre le passage des donnĂ©es mĂȘme Ă  travers le pire routeur NAT (cf. RFC 6951).

La section 3 de notre RFC décrit certains scénarios d'usage. Notons que dans certains, la fiabilité du canal de données n'est pas indispensable :

  • Un jeu en ligne, oĂč on est informĂ© des mouvements des autres joueurs,
  • Des notifications pendant une visioconfĂ©rence du genre « Mamadou a coupĂ© son micro »,
  • Des transferts de fichiers (pour l'anecdote, ce n'est pas le point oĂč les systĂšmes prĂ©cĂ©dant WebRTC, comme IRC ou XMPP, se dĂ©brouillaient le mieux
),
  • Le bavardage textuel entre les participants Ă  une visioconfĂ©rence.

La section 4, elle, décrit les exigences du canal de données. Notamment :

  • PossibilitĂ© d'avoir plusieurs canaux simultanĂ©s,
  • Transfert fiable des donnĂ©es (ce que la vidĂ©o, par exemple, n'exige pas),
  • ContrĂŽle de congestion (cf. RFC 8085),
  • Authentification et confidentialitĂ© (RFC 8826 et RFC 8827),
  • Ne pas laisser fuiter d'informations, comme l'adresse IP locale.

La section 5 décrit une solution à ces exigences, l'utilisation de SCTP sur DTLS. SCTP (RFC 4960) fournit (entre autres) le contrÎle de congestion (par contre, on n'utilise pas ses capacités de multihoming). Son encapsulation dans DTLS est décrite dans le RFC 8261. DTLS lui fournit authentification et confidentialité. L'utilisation d'ICE (RFC 8445) lui permet de passer à travers les routeurs NAT et certains pare-feux.

Petit dĂ©tail : le fait de mettre SCTP sur DTLS (et non pas le contraire comme dans le RFC 6083) fait que, si DTLS est mis en Ɠuvre dans l'espace utilisateur du systĂšme d'exploitation, SCTP devra l'ĂȘtre aussi. (Voir par exemple third_party/usrsctp/usrsctplib dans le code de Chromium, qui vient de https://github.com/sctplab/usrsctp.) Autre consĂ©quence de ce choix : SCTP ne recevra pas les messages ICMP associĂ©s, et il devra donc compter, pour la dĂ©couverte de la MTU du chemin, sur le RFC 4821.

Quelques extensions de SCTP sont nécessaires (section 6) comme celles du RFC 6525, du RFC 5061 (enfin, une partie d'entre elles) et du RFC 3758.

La section 6 décrit les détails protocolaires de l'ouverture du canal de données, puis de son utilisation et enfin de sa fermeture.

Pour les programmeurs, cette bibliothĂšque WebRTC met en Ɠuvre, entre autres, le canal de donnĂ©es.

RFC 8827: WebRTC Security Architecture

Le systÚme WebRTC permet des communications audio et vidéo entre deux navigateurs Web. Comme tout service Internet, il pose des problÚmes de sécurité (RFC 8826), et ce RFC étudie l'architecture générale de WebRTC, du point de vue de la sécurité, et comment résoudre les problÚmes.

D'abord, il faut réviser les généralités sur WebRTC (RFC 8825). WebRTC a pour but de permettre à deux utilisateurs ou utilisatrices de navigateurs Web de s'appeler et de bavarder en audio et vidéo. Pas besoin d'installer un logiciel de communication spécifique (comme le Skype de Microsoft, ou comme un softphone tel que Twinkle), il suffit d'un navigateur ordinaire. Pour permettre cela, WebRTC repose sur une API JavaScript normalisée par le W3C et sur un ensemble de protocoles normalisés par l'IETF, et résumés dans le RFC 8825. Si on prend l'exemple du service WebRTC FramaTalk, Alice et Bob visitent tous les deux https://framatalk.org/, récupÚrent du code JavaScript qui va utiliser l'API WebRTC pour accéder au micro et à la caméra, pendant que, derriÚre, FramaTalk va établir une communication entre eux, permettant à leurs navigateurs d'échanger du son et des images. Cet établissement de connexion (qui peut impliquer plusieurs serveurs, s'il y a fédération) n'est pas spécifié par WebRTC. (Il n'y a pas automatiquement d'interopérabilité entre services WebRTC.) Cela peut utiliser SIP (RFC 3261), par exemple.

Cela soulÚve plein de problÚmes de sécurité amusants, étudiés dans le RFC 8826, et que notre RFC 8827 tente de résoudre.

Toute solution de sĂ©curitĂ© dĂ©pend d'un modĂšle de confiance (section 3 de notre RFC). Si on ne fait confiance Ă  rien ni personne, on ne peut rĂ©soudre aucun problĂšme de sĂ©curitĂ©. Pour WebRTC, la racine de toute confiance est le navigateur. C'est lui qui devra faire respecter un certain nombre de rĂšgles. (En consĂ©quence de quoi, si le navigateur n'est pas de confiance, par exemple parce qu'il s'agit de logiciel non libre, ou bien parce que vous ĂȘtes sur une machine sur laquelle vous n'avez aucun contrĂŽle, par exemple un cybercafĂ©, tout est fichu.) Mais le navigateur ne suffit pas, il faut Ă©galement faire confiance Ă  des entitĂ©s extĂ©rieures, comme le site Web oĂč vous allez rĂ©cupĂ©rer le code JavaScript. Certaines de ces entitĂ©s peuvent ĂȘtre authentifiĂ©es par le navigateur, ce qui donne certaines garanties. Et d'autres, hĂ©las, ne le peuvent pas. Dans la premiĂšre catĂ©gorie, on trouve :

  • Les sites Web oĂč le navigateur vĂ©rifie un certificat, dans une connexion HTTPS. Vous vous connectez Ă  https://framatalk.org/ (notez le https), vous ĂȘtes sĂ»r que c'est bien Framasoft derriĂšre.
  • Les pairs WebRTC authentifiĂ©s par une technique comme DTLS-SRTP.
Le reste des entités avec qui on communique est considéré comme potentiellement malveillant, et il faut donc se méfier (mais, évidemment, dans la vie, on ne communique pas qu'avec des gens qu'on connait bien et à qui on fait confiance : ce serait trop limité).

Pour revenir aux entitĂ©s authentifiĂ©es, notez qu'on n'a parlĂ© que d'authentification, pas de confiance. La cryptographie permet de vĂ©rifier qu'on parle bien au diable, pas que le diable est honnĂȘte !

La section 4 rĂ©sume le fonctionnement gĂ©nĂ©ral de WebRTC, afin de pouvoir analyser sa sĂ©curitĂ©, et dĂ©finir une architecture de sĂ©curitĂ©. Notez que WebRTC permet pas mal de variantes et que le schĂ©ma prĂ©sentĂ© ici est un cas « typique », pas forcĂ©ment identique partout dans tous ses dĂ©tails. Donc, ici, Alice et Bob veulent se parler. Tous les deux utilisent un navigateur. Chacun va visiter le site Web du service qu'ils utilisent, mettons https://meet.example/ (en HTTPS, donc, avec authentification via un certificat). Ils rĂ©cupĂšrent un code JavaScript qui, appelant l'API WebRTC, va dĂ©clencher l'envoi d'audio et de vidĂ©o, transportĂ©s sur SRTP, lui-mĂȘme sur DTLS (les donnĂ©es en dehors du « multimĂ©dia » passent sur du SCTP sur DTLS). Avant d'autoriser l'accĂšs au micro et Ă  la camĂ©ra, chaque navigateur demandera l'autorisation Ă  son utilisat·eur·rice. Quant au fait que la machine en face accepte de recevoir (en direct, en pair-Ă -pair) ce dĂ©luge de donnĂ©es multimĂ©dia, la vĂ©rification sera faite par ICE (cf. RFC 8826, section 4.2). ICE n'intervient qu'Ă  la connexion initiale, des messages pĂ©riodiques seront nĂ©cessaires pendant la communication pour s'assurer qu'il y a toujours consentement Ă  recevoir. Pendant l'Ă©change de donnĂ©es audio et vidĂ©o, le site Web https://meet.example/ va assurer la signalisation et, par exemple, si Alice part, indiquer Ă  Bob qu'il n'y a plus personne en face (notez que cet Ă©change entre site Web et utilisateur ne se fait pas avec un protocole normalisĂ©). Notre RFC ajoute une possibilité : qu'Alice et Bob utilisent un fournisseur d'identitĂ©, permettant Ă  chacun d'identifier et d'authentifier l'autre (par exemple via OpenID Connect).

Ce cas oĂč les deux participant·e·s partagent le mĂȘme serveur est le cas le plus courant aujourd'hui (c'est ce que vous verrez si vous faites une visioconfĂ©rence via https://meet.jit.si/). Le RFC le complique ensuite lĂ©gĂšrement en introduisant de la fĂ©dĂ©ration : Alice et Bob se connectent Ă  des sites Web diffĂ©rents, mais qui ont un mĂ©canisme de fĂ©dĂ©ration commun. Les deux sites vont alors devoir s'Ă©changer de l'information de signalisation, utilisant des protocoles existants comme SIP ou XMPP (qui n'Ă©taient pas utilisĂ©s dans le cas initial).

ArmĂ©s de ces informations, nous pouvons lire la section 6, qui plonge dans les dĂ©tails techniques. D'abord, la securitĂ© de la connexion entre navigateur et site Web. Elle dĂ©pend de HTTPS (RFC 2818), de la vĂ©rification du certificat, bien sĂ»r (RFC 6125 et RFC 5280) et de la vĂ©rification de l'origine (RFC 6454). La sĂ©curitĂ© entre les pairs qui communiquent impose Ă©galement l'usage de la cryptographie et il faut donc utiliser SRTP (RFC 3711) sur DTLS (RFC 6347 et RFC 5763). Pas question de faire du RTP en clair directement sur UDP ! Le niveau de sĂ©curitĂ© (par exemple les paramĂštres TLS choisis) doivent ĂȘtre accessibles Ă  l'utilisateur.

Ensuite, la securitĂ© de l'accĂšs au micro et Ă  la camĂ©ra. Le site Web qu'on visite peut ĂȘtre malveillant, et le navigateur ne permet Ă©videmment pas Ă  du code JavaScript de ce site d'ouvrir silencieusement la camĂ©ra. Il demande donc la permission Ă  l'utilisateur, qui ne la donne que s'il Ă©tait vraiment en train de passer un appel. De mĂȘme, le navigateur doit afficher si micro et camĂ©ra sont utilisĂ©s, et ne doit pas permettre Ă  du code JavaScript de supprimer cet affichage.

Dans WebRTC, l'échange des données audio et vidéo se fait en pair-à-pair, directement entre Alice et Bob. Il y a donc le risque qu'un méchant envoie plein de données vidéo à quelqu'un qui n'a rien demandé (la section 9.3 détaille le risque de déni de service). Il faut donc vérifier le consentement à recevoir. Comme indiqué plus haut, cela se fait avec ICE (RFC 8445). Comme le consentement initial n'est pas éternel, et comme on ne peut pas se fier aux accusés de réception, que DTLS n'envoie pas, ni aux réponses (il n'y en a pas forcément, par exemple si on regarde juste une vidéo), il faut envoyer de temps en temps des nouveaux messages ICE (cf. RFC 7675).

Parmi les questions de sĂ©curitĂ© liĂ©es Ă  WebRTC, il en est une qui a fait beaucoup de bruit, celle de la vie privĂ©e, notamment le problĂšme de l'adresse IP qui est transmise au pair avec qui on communique. (Notez que le serveur du site Web oĂč on se connecter initialement verra toujours, lui, cette adresse IP, sauf si on utilise une technique comme Tor.) Notre RFC impose donc, en cas d'appel entrant, de ne pas commencer la nĂ©gociation ICE avant que l'utilisatrice n'ait dĂ©cidĂ© de rĂ©pondre Ă  l'appel, et que WebRTC permette de dĂ©cider de n'utiliser que TURN, qui ne communique pas l'adresse IP au pair puisqu'on ne se parle plus directement, mais via le relais TURN. Évidemment, cela se fait au dĂ©triment des performances (les dĂ©tails sont dans la section 9.2).

On a vu plus haut que les deux pairs qui communiquent peuvent dĂ©sirer s'authentifier (sans se fier au site Web qu'ils utilisent pour la signalisation), par exemple via des fournisseurs d'identitĂ© externes (comme FranceConnect ?) C'est notamment indispensable pour une fĂ©dĂ©ration puisque, dans ce cas, on n'a mĂȘme plus de site Web commun. La section 7 de notre RFC dĂ©taille ce cas. WebRTC ne normalise pas une technique unique (comme OAuth) pour cela (WebRTC est un cadre, pas vraiment un protocole, encore moins un systĂšme complet), mais fixe quelques principes. Notamment, l'utilisateur s'authentifie auprĂšs du fournisseur d'identitĂ©, pas auprĂšs du site Web de signalisation. Le navigateur Web doit donc faire attention Ă  tout faire lui-mĂȘme et Ă  ne pas laisser ce site Web interfĂ©rer avec ce processus.

Enfin, il reste des problÚmes de sécurité de WebRTC qui ne sont pas couverts par le RFC 8826 ni par les précédentes sections de notre RFC 8827. Ainsi, il est important que le code JavaScript téléchargé depuis le site Web du fournisseur de service WebRTC ne puisse pas directement fabriquer des messages chiffrés et signés pour DTLS, car il pourrait alors fabriquer de vraies/fausses signatures. Tout doit passer par le navigateur qui est le seul à pouvoir utiliser les clés de DTLS pour chiffrer et surtout signer.

Une bonne analyse de la sécurité de WebRTC se trouve en « A Study of WebRTC Security ».

RFC 8825: Overview: Real Time Protocols for Browser-Based Applications

WebRTC sert à faire communiquer en temps réel (avec audio et vidéo) deux navigateurs Web. Il est déjà largement déployé, ce RFC arrive bien aprÚs la bataille, et décrit les généralités sur WebRTC. Ce protocole est complexe et offre beaucoup de choix au concepteur d'applications.

En fait, WebRTC n'est pas vraiment un protocole. Deux applications utilisant WebRTC peuvent parfaitement ĂȘtre dans l'incapacitĂ© de communiquer. WebRTC est plutĂŽt un cadre (framework) dĂ©crivant des composants, parmi lesquels le concepteur d'applications choisira. Vu cette complexitĂ©, ce RFC 8825 est un point de dĂ©part nĂ©cessaire, pour comprendre l'articulation des diffĂ©rents composants. D'ailleurs, il y a un abus de langage courant : WebRTC dĂ©signe normalement uniquement l'API JavaScript normalisĂ©e par le W3C. La communication sur le rĂ©seau se nomme rtcweb, et c'est le nom de l'ex-groupe de travail Ă  l'IETF. Mais tout le monde fait cet abus de langage et moi aussi, j'utiliserai WebRTC pour dĂ©signer l'ensemble du systĂšme.

L'auteur du RFC est un « vieux de la vieille » et a vu passer beaucoup de protocoles. Il est donc logique qu'il commence par quelques rappels historiques en section 1. L'idĂ©e de faire passer de l'audio et de la vidĂ©o sur l'Internet est aussi ancienne que l'Internet lui-mĂȘme, malgrĂ© les prĂ©dictions pessimistes des telcos, qui avaient toujours prĂ©tendu que cela ne marcherait jamais. (La variante d'aujourd'hui est « si on ne nous laisse pas violer la neutralitĂ© du rĂ©seau, la vidĂ©o ne marchera jamais ».)

Mais c'est vrai que les dĂ©buts ont Ă©tĂ© laborieux, la capacitĂ© du rĂ©seau Ă©tant trĂšs insuffisante, et les processeurs trop lents. Ça s'est amĂ©liorĂ© par la suite. Mais si le matĂ©riel a progressĂ©, les protocoles continuaient Ă  manquer : il existe bien sĂ»r des protocoles standards pour traiter certains aspects de la communication (comme SIP - RFC 3261 - pour la signalisation) mais, pour une communication complĂšte, il faut un jeu de protocoles couvrant tous les aspects, de la signalisation Ă  l'encodage du flux vidĂ©o, en passant par les identificateurs Ă  utiliser (comme les adresses de courrier Ă©lectronique), et qu'on puisse compter sur ce jeu, de mĂȘme qu'on peut compter sur la disponibilitĂ© de clients et serveurs HTTP, par exemple. Comme le note l'auteur, « la Solution Universelle s'est avĂ©rĂ©e difficile Ă  dĂ©velopper ». (Cela a d'ailleurs laissĂ© un boulevard Ă  des entreprises privĂ©es, proposant un produit trĂšs fermĂ© et complĂštement intĂ©grĂ© comme le Skype de Microsoft.)

Depuis quelques annĂ©es, la disponibilitĂ© trĂšs rĂ©pandue de navigateurs Web ayant des possibilitĂ©s trĂšs avancĂ©es a changĂ© la donne. Plus besoin d'installer tel ou tel plugin, telle ou telle application, dĂ©sormais, les possibilitĂ©s qu'offre HTML5 sont largement rĂ©pandues, et accessibles en JavaScript via une API standard. Un groupe de travail du W3C dĂ©veloppe de nouvelles possibilitĂ©s et WebRTC peut donc ĂȘtre vu comme un effort commun du W3C et de l'IETF. C'est sur ces nouvelles possibilitĂ©s du navigateur que se fonde WebRTC (son cahier des charges figure dans le RFC 7478).

Notre RFC note que WebRTC change pas mal l'architecture des techniques de communication temps-réel et multimédia. Autant les solutions fondées sur SIP comptaient sur des éléments intermédiaires dans le réseau pour travailler (par exemple des ALG), autant WebRTC est nettement plus « bout en bout », et utilise la cryptographie pour faire respecter ce principe, bien menacé par les FAI.

Question histoire, WebRTC a lui-mĂȘme eu une histoire compliquĂ©e. La premiĂšre rĂ©union du groupe Ă  l'IETF a eu lieu en 2011, pour une fin prĂ©vue en 2012. En fait, il y a eu des retards, et mĂȘme une longue pĂ©riode d'arrĂȘt du travail. Ce RFC de survol de WebRTC, par exemple, a vu sa premiĂšre version publiĂ©e il y a huit ans. Le premier RFC du projet n'a Ă©tĂ© publiĂ© qu'en 2015. Globalement, ce fut l'un des plus gros efforts de l'IETF, mais pas le plus efficace en terme de rapiditĂ©. Le groupe de travail rtcweb a finalement Ă©tĂ© clos en aoĂ»t 2019, le travail Ă©tant terminĂ©.

La section 2 de notre RFC résume les principes de WebRTC : permettre une communication audio, vidéo et données la plus directe possible entre les deux participants. Ce RFC 8825 est la description générale, les protocoles effectifs figurent dans d'autres RFC comme le RFC 8832 pour le protocole de création du canal de données ou le RFC 8831 pour la communication via le canal de données. Techniquement, WebRTC a deux grandes parties :

La section 2 décrit également le vocabulaire, si vous voulez réviser des concepts comme la notion de protocole ou de signalisation.

La section 3 de notre RFC prĂ©sente l'architecture gĂ©nĂ©rale. Chaque navigateur WebRTC se connecte Ă  un serveur Web oĂč il rĂ©cupĂšre automatiquement un code JavaScript qui appelle les fonctions WebRTC, qui permettent d'accĂ©der au canal de donnĂ©es, ouvert avec l'autre navigateur, et aux services multimĂ©dia de son ordinateur local (le micro, la camĂ©ra, etc). On y voit notamment (figure 2) que les donnĂ©es (la voix, la vidĂ©o, etc) passent directement (enfin, presque, voir plus loin) entre les deux navigateurs, alors que la signalisation se fait entre les deux serveurs Web. On note, et c'est trĂšs important, que WebRTC ne gĂšre que le canal de donnĂ©es, pas celui de signalisation, qui peut utiliser SIP (RFC 3261), XMPP (RFC 6120) ou mĂȘme un protocole privĂ©. C'est entre autres pour cette raison que deux services WebRTC diffĂ©rents ne peuvent pas forcĂ©ment interopĂ©rer. Voici un schĂ©ma de WebRTC lorsque les deux parties se connectent au mĂȘme site Web (la signalisation est alors faite Ă  l'intĂ©rieur de ce site) :

Et ici une image d'une fĂ©dĂ©ration, oĂč les deux parties qui communiquent utilisent des services diffĂ©rents, mais qui se sont mis d'accord sur un protocole de signalisation :

Le canal de données nécessite déjà beaucoup de spécifications, notamment le transport et l'encodage du contenu. Il est spécifié dans le RFC 8831.

Le transport, justement (section 4 du RFC). Il faut envoyer les donnĂ©es Ă  l'autre navigateur, et assurer la retransmission des donnĂ©es perdues, le contrĂŽle de congestion, etc. Tout cela est dĂ©crit dans le RFC 8835. Ce RFC spĂ©cifie, pour transporter les donnĂ©es multimĂ©dia, l'utilisation de SRTP sur DTLS, lui-mĂȘme sur UDP (cf. RFC 8834). Des systĂšmes de relais comme TURN (RFC 5766) peuvent ĂȘtre nĂ©cessaires si les deux malheureux navigateurs Web soint coincĂ©s derriĂšre des middleboxes mĂ©chantes, NAT ou pare-feu par exemple.

Ce n'est pas tout d'avoir un protocole de transport. Il faut aussi dĂ©couper les donnĂ©es d'une maniĂšre comprĂ©hensible par l'autre bout (framing, section 5 de notre RFC). WebRTC utilise RTP (RFC 3550, et voir aussi le RFC 8083) et SRTP (RFC 3711 et RFC 5764). Le RFC 8834 dĂ©taille leur utilisation. La sĂ©curitĂ© est, elle, couverte dans les RFC 8826 et RFC 8827. L'Ă©tablissement du canal de donnĂ©es est normalisĂ© dans le RFC 8832 et le canal de donnĂ©es lui-mĂȘme dans le RFC 8831.

On le sait, les formats d'audio et de vidéo sont un problÚme compliqué, le domaine est pourri de brevets souvent futiles, et la variété des formats rend difficile l'interopérabilité. Notre RFC impose au minimum l'acceptation des codecs décrits dans le RFC 7874 pour l'audio (Opus est obligatoire) et RFC 7742 pour la vidéo (H.264 et VP8, aprÚs une longue lutte). D'autres codecs pourront s'y ajouter par la suite.

La section 7 mentionne la gestion des connexions, pour laquelle la solution officielle est le JSEP (JavaScript Session Establishment Protocol, RFC 8829).

La section 9 du RFC dĂ©crit les fonctions locales (l'accĂšs par le navigateur aux services de la machine qui l'hĂ©berge). Le RFC rappelle que ces fonctions doivent inclure des choses comme la suppression d'Ă©cho, la protection de la vie privĂ©e (demander l'autorisation avant d'accĂ©der Ă  la camĂ©ra
) Le RFC 7874 fournit des dĂ©tails. Ici, un exemple d'une demande d'autorisation par Firefox :

Parmi les logiciels qui permettent de faire du WebRTC, on peut citer Jitsi, qui est derriĂšre le service Framatalk, mais qui est Ă©galement accessible via d'autres services comme https://meet.jit.si/.

Regarder du trafic WebRTC avec un logiciel comme Wireshark est frustrant, car tout est chiffré. Pour Jitsi, on voit beaucoup de STUN, pour contourner les problÚmes posés par le NAT, puis du DTLS évidemment impossible à décrypter.

Il y a de nombreux autres logiciels avec WebRTC. C'est le cas par exemple de PeerTube mais attention, seul l'Ă©change de vidĂ©o entre pairs qui regardent au mĂȘme moment utilise WebRTC (plus exactement WebTorrent, qui utilise WebRTC). La rĂ©cupĂ©ration de la vidĂ©o depuis le serveur se fait en classique HTTPS.

Si vous voulez voir une session WebRTC, le mieux est d'utiliser un service comme https://appr.tc/, qui journalise tout, et d'activer la console de Firefox. Vous voyez alors :

Console (Webdeveloper tools) Firefox
9.569: Initializing; server= undefined.
    
Puis l'établissement des canaux nécessaires :
37.252: Opening signaling channel.
39.348: Joined the room.
39.586: Retrieved ICE server information.
39.927: Signaling channel opened.
39.930: Registering signaling channel.
39.932: Signaling channel registered.
    
Là, Firefox vous demande l'autorisation d'utiliser micro et caméra, que vous acceptez :
44.452: Got access to local media with mediaConstraints:
  '{"audio":true,"video":true}'
44.453: User has granted access to local media.
    
Le navigateur peut alors utiliser ICE (RFC 8445) pour trouver le bon moyen de communiquer avec le pair (dans mon test, les deux pairs Ă©taient sur le mĂȘme rĂ©seau local, et s'en aperçoivent, ce qui permet une communication directe par la suite) :
44.579: Creating RTCPeerConnnection with:
  config: '{"rtcpMuxPolicy":"require","bundlePolicy":"max-bundle","iceServers":[{"urls":["stun:74.125.140.127:19302","stun:[2a00:1450:400c:c08::7f]:19302"]},{"urls":["turn:74.125.140.127:19305?transport=udp","turn:[2a00:1450:400c:c08::7f]:19305?transport=udp","turn:74.125.140.127:19305?transport=tcp","turn:[2a00:1450:400c:c08::7f]:19305?transport=tcp"],"username":"CP/Bl+UXXXXXXX","credential":"XXXXXXXXXXX=","maxRateKbps":"8000"}],"certificates":[{}]}';
  constraints: '{"optional":[]}'.
44.775: Created PeerConnectionClient
    
On peut alors négocier les codecs à utiliser (ici VP9) :
44.979: Set remote session description success.
44.980: Waiting for remote video.
44.993: No preference on audio receive codec.
44.993: Prefer video receive codec: VP9
    
Et, ici, on voit passer le descripteur de session (section 7 de notre RFC), au format SDP (RFC 4566 et RFC 3264, et notez la blague entre SDP et le film 300) :
    
44.997: C->WSS: {"sdp":"v=0\r\no=mozilla...THIS_IS_SDPARTA-60.5.1 6947646294855805442 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 23:80:53:8A:DD:D7:BF:77:B5:C7:4E:0F:F4:6D:F2:FB:B8:EE:59:D1:91:6A:F5:21:11:22:C0:E3:E0:ED:54:39\r\na=group:BUNDLE 0 1\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 126\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=fmtp:111 maxplaybackrate=48000;stereo=1;useinbandfec=1\r\na=fmtp:126 0-15\r\na=ice-pwd:bb7169d301496c0119c5ea3a69940a55\r\na=ice-ufrag:3d465335\r\na=mid:0\r\na=msid:{d926a161-3011-48af-9236-06e15377dfea} {a2597b07-7e80-47fe-8542-761dd93efb94}\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=rtpmap:126 telephone-event/8000/1\r\na=setup:active\r\na=ssrc:2096893919 cname:{e60fd6dc-6c2d-4132-bb6a-1178e1611d16}\r\nm=video 9 UDP/TLS/RTP/SAVPF 98\r\nc=IN IP4 0.0.0.0\r\na=recvonly\r\na=extmap:2 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=fmtp:98 max-fs=12288;max-fr=60\r\na=ice-pwd:bb7169d301496c0119c5ea3a69940a55\r\na=ice-ufrag:3d465335\r\na=mid:1\r\na=rtcp-fb:98 nack\r\na=rtcp-fb:98 nack pli\r\na=rtcp-fb:98 ccm fir\r\na=rtcp-fb:98 goog-remb\r\na=rtcp-mux\r\na=rtpmap:98 VP9/90000\r\na=setup:active\r\na=ssrc:4025254123 cname:{e60fd6dc-6c2d-4132-bb6a-1178e1611d16}\r\n","type":"answer"}
Et c'est bon, tout marche :
45.924: Call setup time: 1399ms.
   

Du fait de son caractÚre pair-à-pair (les données sont échangées, autant que le NAT le permet, directement entre les navigateurs), WebRTC soulÚve des questions de vie privée. Votre correspondant va voir votre adresse IP. Le point est discuté plus longuement dans le RFC 8826. (PeerTube met en bas un mot d'avertissement à ce sujet.)

WebRTC est prĂ©sent depuis pas mal d'annĂ©es dans tous les navigateurs graphiques comme Firefox, Chrome ou Edge. CĂŽtĂ© bibliothĂšques, il existe de nombreuses mises en Ɠuvre de WebRTC comme OpenWebRTC (abandonnĂ© depuis) ou comme l'implĂ©mentation de rĂ©fĂ©rence. Il y a Ă©galement du WebRTC dans des serveurs comme Asterisk, WebEx ou MeetEcho (ce dernier Ă©tant utilisĂ© par l'IETF pour ses rĂ©unions Ă  distance). Mais rappelez-vous que WebRTC n'est pas un ensemble cohĂ©rent permettant l'interopĂ©rabilitĂ©. Vous pouvez avoir deux services WebRTC qui n'arrivent pas Ă  interagir, et ce n'est pas une bogue, c'est un choix de conception.

Et, pour finir, quelques lectures et activités supplémentaires :

RFC 8832: WebRTC Data Channel Establishment Protocol

Ce RFC est un des composants de WebRTC. Il spécifie comment on établit le canal de communication des données entre deux pairs WebRTC.

WebRTC est résumé dans le RFC 8825 et la notion de « canal de communication de données » est dans le RFC 8831. Ces données sont protégées par DTLS et transportées en SCTP (RFC 8261).

Le principe est de connecter deux flux de données WebRTC, un entrant et un sortant, pour faire un seul canal bi-directionnel. Le protocole est simple, reposant sur seulement deux messages, un DATA_CHANNEL_OPEN envoyé sur le flux sortant, auquel le pair WebRTC répond par un DATA_CHANNEL_ACK qui va arriver sur le flux entrant. Pour éviter les ouvertures simultanées (un protocole à deux messages n'est pas trÚs robuste), le client DTLS utilise des flux ayant un identificateur (stream identifier) pair, et le serveur des flux à identificateurs impairs. Le format de ces deux messages est décrit dans la section 5 du RFC.

Les paquets SCTP contiennent un PPID (Payload Protocol IDentifier, RFC 4960, section 3.3.1 et 14.4) qui indique le protocole applicatif qui utilise SCTP. Dans le cas de notre protocole d'Ă©tablissement de canal WebRTC, DCEP (Data Channel Establishement Protocol), le PPID vaut 50 (et figure dans le registre IANA sous le nom de WebRTC DCEP).

RFC 8863: Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)

Le protocole ICE, normalisé dans le RFC 8445 permet de découvrir et de choisir, quand on est coincé derriÚre un routeur NAT, les adresses IP que vos correspondants verront. Parfois, au début du processus ICE, il n'y a pas d'adresses acceptables. Au lieu de renoncer tout de suite, ce nouveau RFC modifie le RFC 8445 pour demander qu'on patiente un peu : des adresses IP acceptables peuvent apparaitre par la suite.

RĂ©sumons le fonctionnement de base d'ICE. ICE sert lorsqu'une des deux machines qui correspondent a le malheur d'ĂȘtre derriĂšre du NAT : le but est de choisir une paire d'adresses IP, pour les deux machines qui correspondent. ICE compte sur des protocoles comme STUN pour la dĂ©couverte d'adresses possibles. Ensuite, il teste ces adresses et rĂ©ussit lorsque la communication a pu s'Ă©tablir avec l'autre machine. Un effet de bord de ce processus est qu'il « crĂ©e » parfois de nouvelles adresses IP possibles, qu'il faut donc ajouter Ă  la liste et tester. Le problĂšme que rĂ©sout notre nouveau RFC est que ces nouvelles adresses peuvent ĂȘtre dĂ©tectĂ©es trop tard, alors qu'ICE a dĂ©jĂ  renoncĂ© Ă  trouver une paire qui marche. La solution ? Attendre un peu, mĂȘme si la liste des paires candidates est vide, ou qu'aucune des paires d'adresses de la liste n'a marchĂ©.

La section 3 de notre RFC note que le problĂšme n'est pas si frĂ©quent en pratique car ICE est lent ; cela prend du temps d'Ă©tablir la liste des paires d'adresses IP possibles, et de les tester, d'autant plus qu'on ne reçoit pas forcĂ©ment tout de suite un rejet, il faut souvent attendre la fin du dĂ©lai de garde. Bref, la plupart du temps, les nouvelles adresses apparaissant en cours de route auront le temps d'ĂȘtre intĂ©grĂ©es Ă  la liste des paires Ă  tester. Il y a toutefois quelques cas oĂč le risque d'Ă©chec complet existe. Par exemple, si une machine purement IPv6 essaie de contacter une machine purement IPv4, aucune paire d'adresses IP satisfaisante ne sera trouvĂ©e, menant ICE Ă  renoncer tout de suite. Or, si le rĂ©seau local de la machine IPv6 avait NAT64, la connexion reste possible, il faut juste tester et apprendre ainsi qu'une solution existe. Cela demande un peu de patience.

La section 4 formalise la solution : un chronomĂštre global est crĂ©Ă©, le PAC timer (PAC pour Patiently Awaiting Connectivity) et mis en route au tout dĂ©but du processus ICE. ICE ne doit pas renoncer, mĂȘme s'il croit ne plus avoir de solutions, avant que ce chronomĂštre n'ait mesurĂ© au moins 39,5 secondes (cette durĂ©e vient du RFC 5389, section 7.2.1, mais peut ĂȘtre modifiĂ©e dans certains cas).

RFC 8973: DDoS Open Threat Signaling (DOTS) Agent Discovery

Le protocole DOTS, normalisé dans les RFC 8811, RFC 8782 et RFC 8783, sert à coordonner la réponse à une attaque par déni de service, entre la victime de l'attaque (le client DOTS) et un service d'atténuation de l'attaque (le serveur DOTS). Mais comment le client trouve-t-il son serveur ? Il peut y avoir une configuration manuelle, mais ce RFC propose aussi des moyens automatiques, basés sur un choix de plusieurs techniques, dont DHCP et NAPTR.

Attention, cela permet de trouver le serveur, mais pas le fournisseur du service d'atténuation. Car il faut un accord (souvent payant) avec ce fournisseur, et un échange de mécanismes d'authentification. Cette partie doit se faire manuellement. Le protocole de notre RFC prend ensuite le relais.

Notez aussi qu'il n'y a pas un seul moyen de découverte du serveur. La section 3 du RFC explique en effet que, vu la variété des cas d'utilisation de DOTS, on ne peut pas s'en tirer avec un seul mécanisme. Parfois le client a un CPE géré par le FAI, sur lequel on peut s'appuyer pour trouver le serveur DOTS, et parfois pas. Parfois, il faudra utiliser les résolveurs DNS d'un opérateur et parfois ce ne sera pas nécessaire. Parfois l'atténuateur est le FAI et parfois pas. Bref, il faut plusieurs solutions.

Voyons d'abord la procĂ©dure gĂ©nĂ©rale (section 4). Personnellement, je pense que le client DOTS doit donner la prioritĂ© aux configurations manuelles (DOTS est un systĂšme de sĂ©curitĂ©, un strict contrĂŽle de ce qui se passe est prĂ©fĂ©rable). Mais le RFC ne dĂ©crit pas les choses ainsi. Il expose trois mĂ©canismes, le premier, qualifiĂ© de configuration explicite, Ă©tant composĂ© de deux techniques trĂšs diffĂ©rentes, la configuration manuelle ou bien DHCP. À noter au passage que la configuration manuelle peut indiquer le nom ou l'adresse IP mais, si elle indique l'adresse IP, le nom sera quand mĂȘme obligatoire car il servira pour la vĂ©rification du certificat.

L'ordre des préférences entre ces mécanismes est imposé, pour que le résultat de la découverte soit prédictible. D'abord l'explicite (manuel ou DHCP, section 5), puis la résolution de service (section 6) puis la découverte de service (section 7).

PremiĂšre technique automatique Ă  utiliser, DHCP (section 5). Ce protocole va ĂȘtre utilisĂ© pour rĂ©cupĂ©rer le nom du serveur DOTS (le nom et pas seulement l'adresse IP car on en aura besoin pour authentifier la session TLS). Avec DHCPv6 (RFC 8415), l'option DHCP pour rĂ©cupĂ©rer le nom est 141 en IPv6 et 147 pour IPv4. Une autre option permet de rĂ©cupĂ©rer les adresses IP du serveur DOTS.

DeuxiĂšme technique, la rĂ©solution de service. Il faut partir d'un nom, qui peut ĂȘtre configurĂ© manuellement ou bien obtenu par DHCP. Ce n'est pas le nom du serveur DOTS, contrairement au cas en DHCP pur, mais celui du domaine dans lequel le client DOTS se « trouve ». On va alors utiliser S-NAPTR (RFC 3958) sur ce nom, pour obtenir les noms des serveurs. L'Ă©tiquette Ă  utiliser est DOTS pour le service (enregistrĂ© Ă  l'IANA) et signal (RFC 8782) ou data (RFC 8783) pour le protocole (Ă©galement Ă  l'IANA). Par exemple si le client DOTS est dans le domaine example.net, il va faire une requĂȘte DNS de type NAPTR. Si le domaine comportait un enregistrement pour le service DOTS, il est choisi, et on continue le processus (compliqué !) de NAPTR ensuite. Si on cherche le serveur pour le protocole de signalisation, on pourrait avoir successivement quatre requĂȘtes DNS :

example.net.   IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net.

signal.example.net. IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net.

_dots-signal._udp.example.net.  IN SRV   0 0 5000 a.example.net.

a.example.net.   IN AAAA  2001:db8::1    
  

TroisiĂšme technique, la dĂ©couverte de service (DNS-SD) du RFC 6763. On cherche alors un enregistrement de type PTR dans _dots-signal.udp.example.net. Il nous donnera un nom pour lequel on fera une requĂȘte SRV.

DOTS servant en cas d'attaque, il faut prévoir la possibilité que l'attaquant tente de perturber ou de détourner ce mécanisme de découverte du serveur. Par exemple, on sait que DHCP n'est pas spécialement sécurisé (euphémisme !). D'autre part, DOTS impose TLS, il faut donc un nom à vérifier dans le certificat (oui, on peut mettre des adresses IP dans les certificats mais c'est rare). Quant aux techniques reposant sur le DNS, le RFC conseille d'utiliser DNSSEC, ce qui semble la moindre des choses pour une technique de sécurité. Il suggÚre également de faire la résolution DNS via un canal sûr par exemple avec DoT (RFC 7858) ou DoH (RFC 8484).

Apparemment, il existe au moins une mise en Ɠuvre de DOTS qui inclut les procĂ©dures de dĂ©couverte de notre RFC, mais j'ignore laquelle.

RFC 8965: Applicability of the Babel Routing Protocol

Comme tout bon protocole, le protocole de routage Babel, normalisĂ© dans le RFC 8966 ne fait pas de miracles et ne marche pas dans tous les cas. Il est donc utile de savoir quels sont les cas oĂč Babel est efficace et utile. Ce RFC s'applique Ă  identifier et documenter les crĂ©neaux pour Babel.

C'est qu'il en existe beaucoup de protocoles de routage internes Ă  un AS. Le RFC cite OSPF (RFC 5340) et IS-IS (RFC 1195), qui ont la faveur des grands rĂ©seaux gĂ©rĂ©s par des professionnels, mais je trouve que Babel se situe plutĂŽt du cĂŽtĂ© de protocoles prĂ©vus pour des rĂ©seaux moins organisĂ©s, comme Batman ou RPL (RFC 6550). Je vous laisse lire le RFC 8966 pour voir comment fonctionne Babel. Disons juste que c'est un protocole Ă  vecteur de distances (comme RIP - RFC 2453 - mais sans ses inconvĂ©nients) et qui considĂšre la faisabilitĂ© de chaque route potentielle avant de l'ajouter, supprimant ainsi le risque de boucles. En refusant des routes qui pourraient peut-ĂȘtre crĂ©er une boucle, le risque est la famine, l'absence de route pour une destination, risque dont Babel se protĂšge avec un mĂ©canisme de numĂ©ro de sĂ©quence dans les annonces.

La section 2 de notre RFC explicite les caractĂ©ristiques de Babel, les bonnes et les mauvaises. D'abord, la simplicitĂ©. Babel est conceptuellement simple, ce qui facilite les analyses du protocole, et aussi sa mise en Ɠuvre. Comme le note le RFC, Babel peut ĂȘtre expliquĂ© en un micro-siĂšcle. Et question programmation, le RFC cite une mise en Ɠuvre de Babel rĂ©alisĂ©e en deux nuits (le RFC ne dit pas ce que le ou la programmeur·e faisait de jour
)

Ensuite, la résistance. Babel ne dépend que de quelques propriétés simples du réseau et peut donc fonctionner dans un large éventail de situations. Babel demande juste que les métriques soient strictement monotones croissantes (emprunter le chemin A puis le B, doit forcément coûter strictement plus cher que de juste prendre le chemin A, autrement des boucles pourraient se former) et distributives à gauche (cf. « Metarouting » de Griffin et Sobrinho). En revanche, Babel n'exige pas un transport fiable (les paquets ont le droit de se perdre, ou de doubler un autre paquet) et n'exige pas que la communication soit transitive (dans les liens radio, il peut arriver que A puisse joindre B et B puisse parler à C, sans que pour autant A puisse communiquer directement avec C). Des protocoles comme OSPF (RFC 5340) ou IS-IS sont bien plus exigeants de ce point de vue.

Babel est extensible : comme dĂ©taillĂ© dans l'annexe C du RFC 8966, le protocole Babel peut ĂȘtre Ă©tendu. Cela a Ă©tĂ© fait, par exemple, pour permettre du routage en fonction de la source (draft-ietf-babel-source-specific) ou bien du routage en fonction du RTT (draft-ietf-babel-rtt-extension). Il y a aussi des extensions qui n'ont pas (encore ?) Ă©tĂ© dĂ©ployĂ©es comme du routage en fonction des frĂ©quences radio (draft-chroboczek-babel-diversity-routing) ou en fonction du ToS (draft-chouasne-babel-tos-specific).

Mais Babel a aussi des défauts, notamment :

  • Babel envoie pĂ©riodiquement des messages, mĂȘme quand il n'y a eu aucun changement. Cela permet de ne pas dĂ©pendre d'un transport fiable des paquets mais c'est du gaspillage lorsque le rĂ©seau est stable. Un grand rĂ©seau trĂšs stable et bien gĂ©rĂ© a donc plutĂŽt intĂ©rĂȘt Ă  utiliser des protocoles comme OSPF, pour diminuer le trafic dĂ» au routage. À l'autre extrĂ©mitĂ©, certains rĂ©seaux de machines contraintes (par exemple tournant uniquement sur batterie) n'auront pas intĂ©rĂȘt Ă  utiliser un protocole comme Babel, qui consomme de l'Ă©nergie mĂȘme quand le rĂ©seau n'a pas changĂ©.
  • Avec Babel, chaque routeur connait toute la table de routage. Si des routeurs sont limitĂ©s en mĂ©moire, cela peut ĂȘtre un problĂšme, et des protocoles comme AODV (RFC 3561), RPL (RFC 6550) ou LOADng sont peut-ĂȘtre plus adaptĂ©s.
  • Babel peut ĂȘtre lent Ă  rĂ©cupĂ©rer lorsqu'il fait de l'agrĂ©gation de prĂ©fixes, et qu'une route plus spĂ©cifique est retirĂ©e.

Babel a connu plusieurs dĂ©ploiements dans le monde rĂ©el (section 3). Certains de ces dĂ©ploiements Ă©taient dans des rĂ©seaux mixtes, mĂȘlant des parties filaires, routant sur le prĂ©fixe, et des parties radio, avec du routage mesh sur les adresses IP. Babel a aussi Ă©tĂ© dĂ©ployĂ© dans des overlays, en utilisant l'extension tenant compte du RTT, citĂ©e plus haut. Il a aussi Ă©tĂ© utilisĂ© dans des rĂ©seaux purement mesh. Voir Ă  ce sujet les articles « An experimental comparison of routing protocols in multi hop ad hoc networks » et « Real-world performance of current proactive multi-hop mesh protocols ». Ces rĂ©seaux utilisent traditionnellement plutĂŽt des protocoles comme OLSR (RFC 7181). Enfin, Babel a Ă©tĂ© dĂ©ployĂ© dans des petits rĂ©seaux non gĂ©rĂ©s (pas d'administrateur systĂšme).

Et la sĂ©curitĂ©, pour finir (section 5). Comme tous les protocoles Ă  vecteur de distance, Babel reçoit l'information de ses voisins. Il faut donc leur faire confiance, un voisin menteur peut annoncer ce qu'il veut. En prime, si le rĂ©seau sous-jacent n'est pas lui-mĂȘme sĂ©curisĂ© (par exemple si c'est du WiFi sans WPA), il n'y a mĂȘme pas besoin d'ĂȘtre routeur voisin, toute machine peut tripoter les paquets.

Pour empĂȘcher cela, il y a deux solutions cryptographiques, dans les RFC 8967 (la solution la plus simple) et RFC 8968 (plus complexe mais plus sĂ»re et qui fournit en prime de la confidentialitĂ©). La solution avec le MAC, normalisĂ©e dans le RFC 8967, est celle recommandĂ©e car elle convient mieux au caractĂšre de la plupart des rĂ©seaux utilisant Babel. (Le RFC n'en parle apparamment pas, mais notez qu'authentifier le voisin ne rĂ©sout pas complĂštement le problĂšme. On peut ĂȘtre authentifiĂ© et mentir.)

Enfin, si on n'utilise pas de solution de confidentialitĂ©, un observateur peut dĂ©duire des messages Babel la position d'un routeur WiFi qui se dĂ©placerait, ce qui peut ĂȘtre considĂ©rĂ© comme un problĂšme.

Sinon, pour creuser cette question de l'applicabilité de Babel, vous pouvez lire le texte, trÚs vivant, « Babel does not care ».

RFC 8968: Babel Routing Protocol over Datagram Transport Layer Security

Le protocole de routage Babel, normalisĂ© dans le RFC 8966, n'offre par dĂ©faut aucune sĂ©curitĂ©. Notamment, il n'y a aucun moyen d'authentifier un routeur voisin, ni de s'assurer que les messages suivants viennent bien de lui. Sans mĂȘme parler de la confidentialitĂ© de ces messages. Si on veut ces services, ce RFC fournit un moyen : sĂ©curiser les paquets Babel avec DTLS.

La sĂ©curitĂ© est Ă©videmment souhaitable pour un protocole de routage. Sans elle, par exemple, une mĂ©chante machine pourrait dĂ©tourner le trafic. Cela ne veut pas dire qu'on va toujours employer une solution de sĂ©curitĂ©. Babel (RFC 8966) est conçu entre autres pour des rĂ©seaux peu ou pas gĂ©rĂ©s, par exemple un Ă©vĂ©nement temporaire oĂč chacun apporte son PC et oĂč la connectivitĂ© se fait de maniĂšre ad hoc. Dans un tel contexte, dĂ©ployer de la sĂ©curitĂ© ne serait pas facile. Mais, si on y tient, Babel fournit dĂ©sormais deux mĂ©canismes de sĂ©curitĂ© (cf. RFC 8966, section 6), l'un, plutĂŽt simple et ne fournissant pas de confidentialitĂ©, est dĂ©crit dans le RFC 8967, l'autre, bien plus complet, figure dans notre RFC et repose sur DTLS (qui est normalisĂ© dans le RFC 6347). DTLS, version datagramme de TLS, fournit authentification, intĂ©gritĂ© et confidentialitĂ©.

L'adaptation de DTLS Ă  Babel est dĂ©crite dans la section 2 du RFC. Parmi les problĂšmes, le fait que DTLS soit trĂšs asymĂ©trique (client-serveur) alors que Babel est pair-Ă -pair, et le fait que DTLS ne marche qu'en unicast alors que Babel peut utiliser unicast ou multicast. Donc, chaque routeur Babel doit ĂȘtre un serveur DTLS, Ă©coutant sur le port 6699 (qui n'est pas le 6696 du Babel non sĂ©curisĂ©). Le routeur Babel continue Ă  Ă©couter sur le port non chiffrĂ©, et, lorsqu'il entend un nouveau routeur s'annoncer en multicast, il va tenter de communiquer en DTLS avec lui. Puisque DTLS, comme TLS, est client-serveur, il faut dĂ©cider de qui sera le client et qui sera le serveur : le routeur de plus faible adresse sera le client (par exemple, fe80::1:2 est infĂ©rieure Ă  fe80::2:1. Le serveur diffĂ©rencie les sessions DTLS par le port source ou par les connection identifiers du draft draft-ietf-tls-dtls-connection-id. Comme avec le Babel non chiffrĂ©, les adresses IPv6 utilisĂ©es doivent ĂȘtre des adresses locales au lien. Client et serveur doivent s'authentifier, en suivant les mĂ©thodes TLS habituelles (chacun doit donc avoir un certificat).

Une fois que la session DTLS est en marche, les paquets Babel unicast passent sur cette session et sont donc intĂ©gralement (du premier au dernier octet) protĂ©gĂ©s par le chiffrement. Pour que la sĂ©curitĂ© fournie par DTLS soit ne soit pas compromise, le routeur ne doit plus envoyer Ă  son voisin de paquets sur le port non chiffrĂ©, Ă  part des paquets Hello qui sont transmis en multicast (pour lequel DTLS ne marche pas) et qui permettent de dĂ©couvrir d'Ă©ventuels nouveaux voisins (la rĂšgle exacte est un peu plus compliquĂ©e, regardez le RFC). On ne peut donc plus envoyer d'information en multicast (Ă  part les Hello). En rĂ©ception, un nƓud Babel sĂ©curisĂ© doit ignorer les paquets non protĂ©gĂ©s par DTLS, sauf l'information de type Hello.

Une stricte sĂ©curitĂ© nĂ©cessite qu'un routeur Babel sĂ©curisĂ© n'accepte plus de voisins qui ne gĂšrent pas DTLS, et ignore donc tous leurs paquets sauf ceux qui contiennent un TLV Hello. Autrement, les communications non sĂ©curisĂ©es ficheraient en l'air la confidentialitĂ© de l'information. Si on veut une sĂ©curitĂ© plus relaxĂ©e, un nƓud peut faire tourner les deux versions du protocole, sĂ©curisĂ©e et non sĂ©curisĂ©e, mais alors, exige le RFC, uniquement sur des interfaces rĂ©seau diffĂ©rentes.

Comme toutes les fois oĂč on rajoute des donnĂ©es, on risque de dĂ©passer la MTU. La section 3 du RFC nous rappelle qu'il faut Ă©viter d'envoyer des paquets qui seront fragmentĂ©s et donc qu'il faut Ă©viter de fabriquer des paquets qui, aprĂšs chiffrement, seraient plus gros que la MTU.

Rien n'est parfait en ce bas monde et l'ajout de DTLS, s'il rĂ©sout quelques problĂšmes de sĂ©curitĂ©, ne fait pas tout, et mĂȘme parfois ajoute des ennuis. La section 5 du RFC rappelle ainsi qu'un mĂ©chant pourrait tenter des nĂ©gociations DTLS nombreuses avec une machine afin de la faire travailler pour rien (une variante de Slowloris). Limiter le nombre de connexions par client n'aiderait pas puisqu'il pourrait toujours mentir sur son adresse IP.

MĂȘme en faisant tourner Babel sur DTLS, les messages de type Hello peuvent toujours ĂȘtre envoyĂ©s sans protection, et donc manipulĂ©s Ă  loisir. Un routeur Babel doit donc toujours ĂȘtre capable d'utiliser des Hello unicast et protĂ©gĂ©s.

Et puis bien sĂ»r, limitation classique de TLS, authentifier un routeur voisin et sĂ©curiser la communication avec lui ne signifie pas que ce voisin est honnĂȘte ; il peut toujours mentir, par exemple en annonçant des routes vers des prĂ©fixes qu'il ne sait en fait pas joindre.

À ma connaissance, il n'existe pas encore de mise en Ɠuvre de ce RFC.

RFC 8966: The Babel Routing Protocol

Le travail sur les protocoles de routage ne désarme pas, motivé à la fois par les avancées de la science et par les nouvelles demandes (par exemple pour les réseaux ad hoc). Ainsi Babel est un protocole de routage, de la famille des protocoles à vecteur de distance, qui vise notammment à réduire drastiquement les probabilités de boucle. Il avait été décrit originellement dans le RFC 6126 ; ce nouveau RFC ne change pas fondamentalement le protocole Babel (quoique certains changements ne seront pas compris par les vieilles versions) mais il a désormais le statut de norme, et des solutions de sécurité plus riches. Ce manque de sécurité était la principale critique adressée à Babel.

Il y a deux familles de protocole de routage, ceux Ă  vecteur de distance comme l'ancĂȘtre RIP et ceux Ă  Ă©tats des liens comme OSPF (RFC 2328). Ce dernier est aujourd'hui bien plus utilisĂ© que RIP, et Ă  juste titre. Mais les problĂšmes de RIP n'ont pas forcĂ©ment la mĂȘme ampleur chez tous les membres de sa famille, et les protocoles Ă  vecteurs de distance n'ont pas dit leur dernier mot.

Babel s'inspire de protocoles de routage plus rĂ©cents comme DSDV. Il vise Ă  ĂȘtre utilisable, Ă  la fois sur les rĂ©seaux classiques, oĂč le routage se fait sur la base du prĂ©fixe IP et sur les rĂ©seaux ad hoc, oĂč il n'y a typiquement pas de regroupement par prĂ©fixe, oĂč le routage se fait sur des adresses IP « à plat » (on peut dire que, dans un rĂ©seau ad hoc, chaque nƓud est un routeur).

L'un des principaux inconvénients du bon vieux protocole RIP est sa capacité à former des boucles lorsque le réseau change de topologie. Ainsi, si un lien entre les routeurs A et B casse, A va envoyer les paquets à un autre routeur C, qui va probablement les renvoyer à A et ainsi de suite (le champ « TTL » pour IPv4 et « Hop limit » dans IPv6 a précisement pour but d'éviter qu'un paquet ne tourne sans fin). Babel, lui, évitera les boucles la plupart du temps mais, en revanche, il ne trouvera pas immédiatement la route optimale entre deux points. La section 1.1 du RFC spécifie plus rigoureusement les propriétés de Babel.

Babel peut fonctionner avec diffĂ©rentes mĂ©triques pour indiquer les coĂ»ts de telle ou telle route, le protocole lui-mĂȘme Ă©tant indĂ©pendant de la mĂ©trique utilisĂ©e (cf. annexe A du RFC pour des conseils sur les choix). D'ailleurs, je vous recommande la lecture de l'Internet-Draft draft-chroboczek-babel-doesnt-care, pour mieux comprendre la philosophie de Babel.

Autre particularitĂ© de Babel, les associations entre deux machines pourront se faire mĂȘme si elles utilisent des paramĂštres diffĂ©rents (par exemple pour la valeur de l'intervalle de temps entre deux « Hello » ; cf. l'annexe B pour une discussion du choix de ces paramĂštres, les compromis que ce choix implique entre intensitĂ© du trafic et dĂ©tection rapide des changements, et les valeurs recommandĂ©es pour ces paramĂštres). Le RFC annonce ainsi que Babel est particuliĂšrement adaptĂ© aux environnements « sans-fil » oĂč certaines machines, devant Ă©conomiser leur batterie, devront choisir des intervalles plus grands, ou bien aux environnements non gĂ©rĂ©s, oĂč chaque machine est configurĂ©e indĂ©pendamment.

Je l'ai dit, rien n'est parfait en ce bas monde, et Babel a des limites, décrites en section 1.2. D'abord, Babel envoie périodiquement toutes les informations dont il dispose, ce qui, dans un réseau stable, mÚne à un trafic total plus important que, par exemple, OSPF (qui n'envoie que les changements). Ensuite, Babel a des mécanismes d'attente lorsqu'un préfixe disparait, qui s'appliquent aux préfixes plus généraux. Ainsi, lorsque deux préfixes deviennent agrégés, l'agrégat n'est pas joignable immédiatement.

Comment Babel atteint-il ses merveilleux objectifs ? La section 2 détaille les principes de base du protocole, la 3 l'échange de paquets et la 4 l'encodage d'iceux. Commençons par les principes. Babel est fondé sur le bon vieil algorithme de Bellman-Ford, tout comme RIP. Tout lien entre deux points A et B a un coût (qui n'est pas forcément un coût monétaire, c'est un nombre qui a la signification qu'on veut, cf. section 3.5.2). Le coût est additif (la somme des coûts d'un chemin complet faisant la métrique du chemin, section 2.1 et annexe A), ce qui veut dire que Métrique(A -> C) - pour une route passant par B >= Coût(A -> B) + Coût(B -> C). L'algorithme va essayer de calculer la route ayant la métrique le plus faible.

Un nƓud Babel garde trace de ses voisins nƓuds en envoyant pĂ©riodiquement des messages Hello et en les prĂ©venant qu'ils ont Ă©tĂ© entendus par des messages IHU (I Heard You). Le contenu des messages Hello et IHU permet de dĂ©terminer le coĂ»t.

Pour chaque source (d'un prĂ©fixe, pas d'un paquet), le nƓud garde trace de la mĂ©trique vers cette source (lorsqu'un paquet tentera d'atteindre le prĂ©fixe annoncĂ©) et du routeur suivant (next hop). Au dĂ©but, Ă©videmment la mĂ©trique est infinie et le routeur suivant indĂ©terminĂ©. Le nƓud envoie Ă  ses voisins les routes qu'il connait. Si celle-ci est meilleure que celle que connait le voisin, ce dernier l'adopte (si la distance Ă©tait infinie - route inconnue, toute route sera meilleure).

L'algorithme « naïf » ci-dessus est ensuite amélioré de plusieurs façons : envoi immédiat de nouvelles routes (sans attendre l'émission périodique), mémorisation, non seulement de la meilleure route mais aussi de routes alternatives, pour pouvoir réagir plus vite en cas de coupure, etc.

La section 2.3 rappelle un problĂšme archi-connu de l'algorithme de Bellman-Ford : la facilitĂ© avec laquelle des boucles se forment. Dans le cas d'un rĂ©seau simple comme celui-ci  A annonce une route de mĂ©trique 1 vers S, B utilise donc A comme routeur suivant, avec une mĂ©trique de 2. Si le lien entre S (S = source de l'annonce) et A casse  comme B continue Ă  publier une route de mĂ©trique 2 vers S, A se met Ă  envoyer les paquets Ă  B. Mais B les renvoie Ă  A, crĂ©ant ainsi une boucle. Les annonces ultĂ©rieures ne rĂ©solvent pas le problĂšme : A annonce une route de mĂ©trique 3, passant par B, B l'enregistre et annonce une route de mĂ©trique 4 passant par A, etc. RIP rĂ©sout le problĂšme en ayant une limite arbitraire Ă  la mĂ©trique, limite qui finit par ĂȘtre atteinte et stoppe la boucle (mĂ©thode dite du « comptage Ă  l'infini »).

Cette mĂ©thode oblige Ă  avoir une limite trĂšs basse pour la mĂ©trique. Babel a une autre approche : les mises Ă  jour ne sont pas forcĂ©ment acceptĂ©es, Babel teste pour voir si elles crĂ©ent une boucle (section 2.4). Toute annonce est donc examinĂ©e au regard d'une condition, dite « de faisabilité ». Plusieurs conditions sont possibles. Par exemple, BGP utilise la condition « Mon propre numĂ©ro d'AS n'apparaĂźt pas dans l'annonce. ». (Cela n'empĂȘche pas les micro-boucles, boucles de courte durĂ©e en cas de coupure, cf. RFC 5715.) Une autre condition, utilisĂ©e par DSDV et AODV (RFC 3561), repose sur l'observation qu'une boucle ne se forme que lorsqu'une annonce a une mĂ©trique moins bonne que la mĂ©trique de la route qui a Ă©tĂ© retirĂ©e. En n'acceptant que les annonces qui amĂ©liorent la mĂ©trique, on peut donc Ă©viter les boucles. Babel utilise une rĂšgle un peu plus complexe, empruntĂ©e Ă  EIGRP, qui tient compte de l'histoire des annonces faites par le routeur.

Comme il n'y a pas de miracles en routage, cette idĂ©e de ne pas accepter n'importe quelle annonce de route a une contrepartie : la famine. Celle-ci peut se produire lorsqu'il existe une route mais qu'aucun routeur ne l'accepte (section 2.5). EIGRP rĂ©sout le problĂšme en « rĂ©dĂ©marrant » tout le rĂ©seau (resynchronisation globale des routeurs). Babel, lui, emprunte Ă  DSDV une solution moins radicale, en numĂ©rotant les annonces, de maniĂšre strictement croissante, lorsqu'un routeur dĂ©tecte un changement dans ses liens. Une route pourra alors ĂȘtre acceptĂ©e si elle est plus rĂ©cente (si elle a un numĂ©ro de sĂ©quence plus Ă©levĂ©), et un routeur Babel peut demander explicitement aux autres routeurs d'incrĂ©menter ce nombre, pour accĂ©lĂ©rer la convergence. Ce numĂ©ro n'est par contre pas utilisĂ© pour sĂ©lectionner la meilleure route (seule la mĂ©trique compte pour cela), uniquement pour voir si une annonce est rĂ©cente.

À noter que tout se complique s'il existe plusieurs routeurs qui annoncent originellement la mĂȘme route (section 2.7 ; un exemple typique est la route par dĂ©faut, annoncĂ©e par tous les routeurs ayant une connexion extĂ©rieure). Babel gĂšre ce problĂšme en associant Ă  chaque prĂ©fixe l'identitĂ© du routeur qui s'est annoncĂ© comme origine et considĂšre par la suite ces annonces comme distinctes, mĂȘme si le prĂ©fixe est le mĂȘme. ConsĂ©quence : Babel ne peut plus garantir qu'il n'y aura pas de boucle (Babel essaie de construire un graphe acyclique mais l'union de plusieurs graphes acycliques n'est pas forcĂ©ment acyclique). Par contre, il pourra dĂ©tecter ces boucles a posteriori et les Ă©liminer plus rapidement qu'avec du comptage vers l'infini.

Notez aussi que chaque routeur Babel est libre de rejeter les routes qui lui semblent déraisonnables, comme 127.0.0.1/32, sans affecter le fonctionnement du protocole (le détail de cette question du filtrage des routes est dans l'annexe C.)

VoilĂ  pour les principes. Et le protocole ? La section 3 le dĂ©crit. Chaque routeur a une identitĂ© sur huit octets (le plus simple est de prendre l'adresse MAC d'une des interfaces). Les messages sont envoyĂ©s dans des paquets UDP et encodĂ©s en TLV. Le paquet peut ĂȘtre adressĂ© Ă  une destination unicast ou bien multicast. Les TLV peuvent contenir des sous-TLV dans leur partie Valeur.

Un routeur Babel doit se souvenir d'un certain nombre de choses (section 3.2), notamment :

  • Le numĂ©ro de sĂ©quence, qui croĂźt strictement,
  • La liste des interfaces rĂ©seau oĂč parler le protocole,
  • La liste des voisins qu'on a entendus,
  • La liste des sources (routeurs qui ont Ă©tĂ© Ă  l'origine de l'annonce d'un prĂ©fixe). Elle sert pour calculer les critĂšres d'acceptation (ou de rejet) d'une route. Babel consomme donc plus de mĂ©moire que RIP, qui ne connait que son environnement immĂ©diat, alors qu'un routeur Babel connaĂźt tous les routeurs du rĂ©seau.
  • Et bien sĂ»r la table des routes, celle qui, au bout du compte, sera utilisĂ©e pour la transmission des paquets.
Les prĂ©fixes annoncĂ©s sont sans rapport avec la version du protocole IP utilisĂ©e pour transporter l'annonce. Un prĂ©fixe IPv4 peut donc ĂȘtre envoyĂ© en IPv6. Le RFC recommande de faire tourner Babel sur IPv6, mĂȘme si le rĂ©seau est en partie en IPv4.

Les messages Babel ne bĂ©nĂ©ficient pas d'une garantie de dĂ©livrance (c'est de l'UDP, aprĂšs tout), mais un routeur Babel peut demander Ă  ses voisins d'accuser rĂ©ception (section 3.3). La dĂ©cision de le demander ou pas dĂ©coule de la politique locale de chaque routeur. Si un routeur ne demande pas d'accusĂ© de rĂ©ception, l'envoi pĂ©riodique des routes permettra de s'assurer que, au bout d'un certain temps, tous les routeurs auront toute l'information. Les accusĂ©s de rĂ©ception peuvent toutefois ĂȘtre utiles en cas de mises Ă  jour urgentes dont on veut ĂȘtre sĂ»r qu'elles ont Ă©tĂ© reçues.

Comment un nƓud Babel trouve t-il ses voisins ? La section 3.4 dĂ©crit ce mĂ©canisme. Les voisins sont dĂ©tectĂ©s par les messages Hello qu'ils Ă©mettent. Les messages IHU (I Heard You) envoyĂ©s en sens inverse permettent notamment de s'assurer que le lien est bien bidirectionnel.

Les dĂ©tails de la maintenance de la table de routage figurent en section 3.5. Chaque mise Ă  jour envoyĂ©e par un nƓud Babel est un quintuplet {prĂ©fixe IP, longueur du prĂ©fixe, ID du routeur, numĂ©ro de sĂ©quence, mĂ©trique}. Chacune de ces mises Ă  jour est Ă©valuĂ©e en regard des conditions de faisabilité : une distance de faisabilitĂ© est un doublet {numĂ©ro de sĂ©quence, mĂ©trique} et ces distances sont ordonnĂ©es en comparant d'abord le numĂ©ro de sĂ©quence (numĂ©ro plus Ă©levĂ©e => distance de faisabilitĂ© meilleure) et ensuite la mĂ©trique (oĂč le critĂšre est inverse). Une mise Ă  jour n'est acceptĂ©e que si sa distance de faisabilitĂ© est meilleure.

Si la table des routes contient plusieurs routes vers un prĂ©fixe donnĂ©, laquelle choisir et donc rĂ©annoncer aux voisins (section 3.6) ? La politique de sĂ©lection n'est pas partie intĂ©grante de Babel. Plusieurs mises en Ɠuvre de ce protocole pourraient faire des choix diffĂ©rents. Les seules contraintes Ă  cette politique sont qu'il ne faut jamais rĂ©annoncer les routes avec une mĂ©trique infinie (ce sont les retraits, lorsqu'une route n'est plus accessible), ou les routes infaisables (selon le critĂšre de faisabilitĂ© citĂ© plus haut). Si les diffĂ©rents routeurs ont des politiques diffĂ©rentes, cela peut mener Ă  des oscillations (routes changeant en permanence) mais il n'existe pas Ă  l'heure actuelle de critĂšres scientifiques pour choisir une bonne politique. On pourrait imaginer que le routeur ne garde que la route avec la mĂ©trique le plus faible, ou bien qu'il privilĂ©gie la stabilitĂ© en gardant la premiĂšre route sĂ©lectionnĂ©e, ou encore qu'il prenne en compte des critĂšres comme la stabilitĂ© du routeur voisin dans le temps. En attendant les recherches sur ce point, la stratĂ©gie conseillĂ©e est de privilĂ©gier la route de plus faible mĂ©trique, en ajoutant un petit dĂ©lai pour Ă©viter de changer trop souvent. Notez que la mĂ©thode de calcul des mĂ©triques n'est pas imposĂ©e par Babel : tant que cette mĂ©thode obĂ©it Ă  certains critĂšres, notamment de monotonie, elle peut ĂȘtre utilisĂ©e.

Une fois le routeur dĂ©cidĂ©, il doit envoyer les mises Ă  jour Ă  ses voisins (section 3.7). Ces mises Ă  jour sont transportĂ©es dans des paquets multicast (mais peuvent l'ĂȘtre en unicast). Les changements rĂ©cents sont transmis immĂ©diatement, mais un nƓud Babel transmet de toute façon la totalitĂ© de ses routes Ă  intervalles rĂ©guliers. Petite optimisation : les mises Ă  jour ne sont pas transmises sur l'interface rĂ©seau d'oĂč la route venait, mais uniquement si on est sĂ»r que ladite interface mĂšne Ă  un rĂ©seau symĂ©trique (un Ethernet filaire est symĂ©trique mais un lien WiFi ad hoc ne l'est pas forcĂ©ment).

Un routeur Babel peut toujours demander explicitement des annonces de routes Ă  un voisin (section 3.8). Il peut aussi demander une incrĂ©mentation du numĂ©ro de sĂ©quence, au cas oĂč il n'existe plus aucune route pour un prĂ©fixe donnĂ© (problĂšme de la famine, section 3.8.2.1).

La section 4 spĂ©cifie l'encodage des messages Babel sur le rĂ©seau. C'est un paquet UDP, envoyĂ© Ă  une adresse multicast (ff02::1:6 ou 224.0.0.111) ou bien unicast, avec un TTL de 1 (puisque les messages Babel n'ont jamais besoin d'ĂȘtre routĂ©s), et un port source et destination de 6696. En IPv6, les adresses IP de source et de destination unicast sont locales au lien et en IPv4 des adresses du rĂ©seau local.

Les donnĂ©es envoyĂ©es dans le message sont typĂ©es et la section 4.1 liste les types possibles, par exemple interval, un entier de 16 bits qui sert Ă  reprĂ©senter des durĂ©es en centisecondes (rappelez-vous que, dans Babel, un routeur informe ses voisins de ses paramĂštres temporels, par exemple de la frĂ©quence Ă  laquelle il envoie des Hello). Plus complexe est le type address, puisque Babel permet d'encoder les adresses par diffĂ©rents moyens (par exemple, pour une adresse IPv6 locale au lien, le prĂ©fixe fe80::/64 peut ĂȘtre omis). Quant Ă  l'ID du routeur, cet identifiant est stockĂ© sur huit octets.

Ensuite, ces donnĂ©es sont mises dans des TLV, eux-mĂȘme placĂ©s derriĂšre l'en-tĂȘte Babel, qui indique un nombre magique (42...) pour identifier un paquet Babel, un numĂ©ro de version (aujourd'hui 2) et la longueur du message. (La fonction babel_print_v2 dans le code de tcpdump est un bon moyen de dĂ©couvrir les diffĂ©rents types et leur rĂŽle.) Le message est suivi d'une remorque qui n'est pas comptĂ©e pour le calcul de la longueur du message, et qui sert notamment pour l'authentification (cf. RFC 8967). La remorque, une nouveautĂ© qui n'existait pas explicitement dans le RFC 6126, est elle-mĂȘme composĂ©e de TLV. Chaque TLV, comme son nom l'indique, comprend un type (entier sur huit bits), une longueur et une valeur, le corps, qui peut comprendre plusieurs champs (dĂ©pendant du type). Parmi les types existants :

  • 0 et 1, qui doivent ĂȘtre ignorĂ©s (ils servent si on a besoin d'aligner les TLV),
  • 2, qui indique une demande d'accusĂ© de rĂ©ception, comme le Echo Request d'ICMP (celui qui est utilisĂ© par la commande ping). Le rĂ©cepteur doit rĂ©pondre par un message contenant un TLV de type 3.
  • 4, qui dĂ©signe un message Hello. Le corps contient notamment le numĂ©ro de sĂ©quence actuel du routeur. Le type 5 dĂ©signe une rĂ©ponse au Hello, le IHU, et ajoute des informations comme le coĂ»t de la liaison entre les deux routeurs.
  • 6 sert pour transmettre l'ID du routeur.
  • 7 et 8 servent pour les routes elles-mĂȘmes. 7 dĂ©signe le routeur suivant qui sera utilisĂ© (next hop) pour les routes portĂ©es dans les TLV de type 8. Chaque TLV Update (type 8) contient notamment un prĂ©fixe (avec sa longueur), un numĂ©ro de sĂ©quence, et une mĂ©trique.
  • 9 est une demande explicite de route (lorsqu'un routeur n'a plus de route vers un prĂ©fixe donnĂ© ou simplement lorsqu'il est pressĂ© et ne veut pas attendre le prochain message). 10 est la demande d'un nouveau numĂ©ro de sĂ©quence.
Les types de TLV sont stockés dans un registre IANA. On peut en ajouter à condition de fournir une spécification écrite (« Spécification nécessaire », cf. RFC 8126). Il y a aussi un registre des sous-TLV.

Quelle est la sĂ©curitĂ© de Babel ? La section 6 dit franchement qu'elle est, par dĂ©faut, Ă  peu prĂšs inexistante. Un mĂ©chant peut annoncer les prĂ©fixes qu'il veut, avec une bonne mĂ©trique pour ĂȘtre sĂ»r d'ĂȘtre sĂ©lectionnĂ©, afin d'attirer tout le trafic.

En IPv6, une protection modérée est fournie par le fait que les adresses source et destination sont locales au lien. Comme les routeurs IPv6 ne sont pas censés faire suivre les paquets ayant ces adresses, cela garantit que le paquet vient bien du réseau local. Une raison de plus d'utiliser IPv6.

Ce manque de sĂ©curitĂ© dans le Babel original du RFC 6126 avait suscitĂ© beaucoup de discussions Ă  l'IETF lors de la mise de Babel sur le chemin des normes (voir par exemple cet examen de la direction de la sĂ©curitĂ©). Normalement, l'IETF exige de tout protocole qu'il soit raisonnablement sĂ©curisĂ© (la rĂšgle figure dans le RFC 3365). Certaines personnes s'Ă©taient donc vigoureusement opposĂ©es Ă  la normalisation officielle de Babel tant qu'il n'avait pas de solution de sĂ©curitĂ© disponible. D'autres faisaient remarquer que Babel Ă©tait quand mĂȘme dĂ©ployable pour des rĂ©seaux fermĂ©s, « entre copains », mĂȘme sans sĂ©curitĂ©, mais les critiques pointaient le fait que tĂŽt ou tard, tout rĂ©seau fermĂ© risque de se retrouver ouvert. D'un autre cĂŽtĂ©, sĂ©curiser des rĂ©seaux « ad hoc », par exemple un lot de machines mobiles qui se retrouvent ensemble pour un Ă©vĂ©nement temporaire, est un problĂšme non encore rĂ©solu.

Un grand changement de notre RFC est de permettre la signature des messages. Deux mécanismes existent, décrits dans les RFC 8967 (signature HMAC, pour authentifier, la solution la plus légÚre) et RFC 8968 (DTLS, qui fournit en plus la confidentialité). (Notons que, en matiÚre de routage, la signature ne résout pas tout : c'est une chose d'authentifier un voisin, une autre de vérifier qu'il est autorisé à annoncer ce préfixe.)

J'ai parlé plus haut de la détermination des coûts des liens. L'annexe A du RFC contient des détails intéressants sur cette détermination. Ainsi, contrairement aux liens fixes, les liens radio ont en général une qualité variable, surtout en plein air. Déterminer cette qualité est indispensable pour router sur des liens radio, mais pas facile. L'algorithme ETX (décrit dans l'article de De Couto, D., Aguayo, D., Bicket, J., et R. Morris, « A high-throughput path metric for multi-hop wireless networks ») est recommandé pour cela.

L'annexe D est consacrée aux mécanismes d'extension du protocole, et reprend largement le RFC 7557, qu'elle remplace. Babel prévoyait des mécanismes d'extension en réservant certaines valeurs et en précisant le comportement d'un routeur Babel lors de la réception de valeurs inconnues. Ainsi :

  • Un paquet Babel avec un numĂ©ro de version diffĂ©rent de 2 doit ĂȘtre ignorĂ©, ce qui permet de dĂ©ployer une nouvelle future version de Babel sans que ses paquets ne cassent les implĂ©mentations existantes,
  • Un TLV de type inconnu doit ĂȘtre ignorĂ© (section 4.3), ce qui permet d'introduire de nouveaux types de TLV en Ă©tant sĂ»r qu'ils ne vont pas perturber les anciens routeurs,
  • Les donnĂ©es contenues dans un TLV au-delĂ  de sa longueur indiquĂ©e, ou bien les donnĂ©es prĂ©sentes aprĂšs le dernier TLV, devaient, disait le RFC 7557 qui reprenait le RFC 6126, Ă©galement ĂȘtre silencieusement ignorĂ©es (au lieu de dĂ©clencher une erreur). Ainsi, une autre voie d'extension Ă©tait possible, pour glisser des donnĂ©es supplĂ©mentaires. Cette voie est dĂ©sormais utilisĂ©e par les solutions de signature comme celle du RFC 8966.
Quelles sont donc les possibilitĂ©s d'extensions propres ? Cela commence par une nouvelle version du protocole (l'actuelle version est la 2), qui utiliserait des numĂ©ros 3, puis 4... Cela ne doit ĂȘtre utilisĂ© que si la nouvelle version est incompatible avec les prĂ©cĂ©dentes et ne peut pas interopĂ©rer sur le mĂȘme rĂ©seau.

Moins radicale, une extension de la version 2 peut introduire de nouveaux TLV (qui seront ignorĂ©s par les mises en Ɠuvre anciennes de la version 2). Ces nouveaux TLV doivent suivre le format de la section 4.3. De la mĂȘme façon, on peut introduire de nouveaux sous-TLV (des TLV contenus dans d'autres TLV, dĂ©crits en section 4.4).

Si on veut ajouter des donnĂ©es dans un TLV existant, en s'assurant qu'il restera correctement analysĂ© par les anciennes mises en Ɠuvre, il faut jouer sur la diffĂ©rence entre la taille explicite (explicit size) et la taille effective (natural size) du TLV. La taille explicite est celle qui est indiquĂ© dans le champ Length spĂ©cifiĂ© dans la section 4.3. La taille effective est celle dĂ©duite d'une analyse des donnĂ©es (plus ou moins compliquĂ©e selon le type de TLV). Comme les implĂ©mentations de Babel doivent ignorer les donnĂ©es situĂ©es aprĂšs la taille explicite, on peut s'en servir pour ajouter des donnĂ©es. Elles doivent ĂȘtre encodĂ©es sous forme de sous-TLV, chacun ayant type, longueur et valeur (leur format exact est dĂ©crit en section 4.4).

Enfin, aprÚs le dernier TLV (Babel est transporté sur UDP, qui indique une longueur explicite), on peut encore ajouter des données, une « remorque ». C'est ce que fait le RFC 8966.

Bon, mais alors quel mĂ©canisme d'extension choisir ? La section 4 fournit des pistes aux dĂ©veloppeurs. Le choix de faire une nouvelle version est un choix drastique. Il ne devrait ĂȘtre fait que si la nouvelle version est rĂ©ellement incompatible avec la prĂ©cĂ©dente.

Un nouveau TLV, ou bien un nouveau sous-TLV d'un TLV existant est la solution Ă  la plupart des problĂšmes d'extension. Par exemple, si on veut mettre de l'information supplĂ©mentaire aux mises Ă  jour de routes (TLV Update), on peut crĂ©er un nouveau TLV « Update enrichi » ou bien un sous-TLV de Update qui contiendra l'information supplĂ©mentaire. Attention, les consĂ©quences de l'un ou l'autre choix ne seront pas les mĂȘmes. Un TLV « Update enrichi » serait totalement ignorĂ© par un Babel ancien, alors qu'un TLV Update avec un sous-TLV d'« enrichissement » verrait la mise Ă  jour des routes acceptĂ©e, seule l'information supplĂ©mentaire serait perdue.

Il existe désormais, pour permettre le développement d'extensions, un registre IANA des types de TLV et un des sous-TLV (section 5 du RFC) et plusieurs extensions s'en servent déjà.

Enfin, l'annexe F du RFC rĂ©sume les changements depuis le premier RFC, le RFC 6126, qui documentait la version 2 de Babel. On reste en version 2 car le protocole de notre RFC reste essentiellement compatible avec le prĂ©cĂ©dent. Il y a toutefois trois fonctions de ce protocole qui pourraient crĂ©er des problĂšmes sur un rĂ©seau oĂč certaines machines sont restĂ©es au RFC 6126 :

  • Les messages de type Hello en unicast sont une nouveautĂ©. L'ancien RFC ne les mentionnait pas. Cela peut entrainer une mauvaise interprĂ©tation des numĂ©ros de sĂ©quence (qui sont distincts en unicast et multicast).
  • Les messages Hello peuvent dĂ©sormais avoir un intervalle entre deux messages qui est nul, ce qui n'existait pas avant.
  • Les sous-TLV obligatoires n'existaient pas avant et leur utilisation peut donc ĂȘtre mal interprĂ©tĂ©e par les vieilles mises en Ɠuvre de Babel.
Bref, si on veut dĂ©ployer le Babel de ce RFC dans un rĂ©seau oĂč il reste de vieilles mises en Ɠuvre, il faut prendre garde Ă  ne pas utiliser ces trois fonctions. Si on prĂ©fĂšre mettre Ă  jour les vieux programmes, sans toutefois y intĂ©grer tout ce que contient notre RFC, il faut au minimum ignorer (ou bien gĂ©rer correctement) les Hello en unicast, ou bien avec un intervalle nul, et il faut ignorer un TLV qui contient un sous-TLV obligatoire mais inconnu.

Il y a d'autres changements depuis le RFC 6126 mais qui ne sont pas de nature à affecter l'interopérabilité ; voyez le RFC pour les détails.

Vous pourrez trouver plus d'informations sur Babel en lisant le RFC, ou bien sur la page Web officielle. Si vous voulez approfondir la question des protocoles de routage, une excellente comparaison a Ă©tĂ© faite par David Murray, Michael Dixon et Terry Koziniec dans « An Experimental Comparison of Routing Protocols in Multi Hop Ad Hoc Networks » oĂč ils comparent Babel (qui l'emporte largement), OLSR (RFC 7181) et Batman (ce dernier est dans le noyau Linux officiel). Notez aussi que l'IETF a un protocole standard pour ce problĂšme, RPL, dĂ©crit dans le RFC 6550. Si vous aimez les vidĂ©os, l'auteur de Babel explique le protocole en anglais.

Qu'en est-il des mises en Ɠuvre de ce protocole ? Il existe une implĂ©mentation d'exemple, babeld, assez Ă©prouvĂ©e pour ĂȘtre disponible en paquetage dans plusieurs systĂšmes, comme babeld dans Debian ou dans OpenWrt, plateforme trĂšs souvent utilisĂ©e pour des routeurs libres (cf. https://openwrt.org/docs/guide-user/services/babeld). babeld ne met pas en Ɠuvre les solutions de sĂ©curitĂ© des RFC 8966 ou RFC 8967. Une autre implĂ©mentation se trouve dans Bird. Si vous voulez Ă©crire votre implĂ©mentation, l'annexe E contient plusieurs conseils utiles, accompagnĂ©s de calculs, par exemple sur la consommation mĂ©moire et rĂ©seau. Le RFC proclame que Babel est un protocole relativement simple et, par exemple, l'implĂ©mentation de rĂ©fĂ©rence contient environ 12 500 lignes de C.

NĂ©anmoins, cela peut ĂȘtre trop, une fois compilĂ©, pour des objets (le RFC cite les fours Ă  micro-ondes...) et l'annexe E dĂ©crit donc des sous-ensembles raisonnables de Babel. Par exemple, une mise en Ɠuvre passive pourrait apprendre des routes, sans rien annoncer. Plus utile, une mise en Ɠuvre « parasite » n'annonce que la route vers elle-mĂȘme et ne retransmet pas les routes apprises. Ne routant les paquets, elle ne risquerait pas de crĂ©er des boucles et pourrait donc omettre certaines donnĂ©es, comme la liste des sources. (Le RFC liste par contre ce que la mise en Ɠuvre parasite doit faire.)

Toujours cÎté programmes, tcpdump et Wireshark savent afficher les paquets Babel.

RFC 8967: Message Authentication Code (MAC) Authentication for the Babel Routing Protocol

Le protocole de routage Babel, normalisé dans le RFC 8966, avait à l'origine zéro sécurité. N'importe quelle machine pouvait se dire routeur et annoncer ce qu'elle voulait. Le RFC 7298 avait introduit un mécanisme d'authentification. Ce nouveau RFC le remplace avec un nouveau mécanisme. Chaque paquet est authentifié par HMAC, et les routeurs doivent donc partager une clé secrÚte.

Comme, par défaut, Babel croit aveuglément ce que ses voisins lui racontent, un méchant peut facilement, par exemple, détourner du trafic (en annonçant une route de plus forte préférence). Le problÚme est bien connu mais n'a pas de solution simple. Par exemple, Babel permet à la fois de l'unicast et du multicast, le second étant plus difficile à protéger. Une solution de sécurité, DTLS, spécifiée pour Babel dans le RFC 8968, résout le problÚme en ne faisant que de l'unicast. Notre RFC choisit une autre solution, qui marche pour l'unicast et le multicast. Chaque paquet est authentifié par un MAC attaché au paquet, calculé entre autres à partir d'une clé partagée.

La solution dĂ©crite dans ce RFC implique que tous les routeurs connectĂ©s au rĂ©seau partagent la clĂ© secrĂšte, et que tous ces routeurs soient eux-mĂȘmes de confiance (l'authentification n'implique pas l'honnĂȘtetĂ© du routeur authentifiĂ©, point trĂšs souvent oubliĂ© quand on parle d'authentification
) En pratique, c'est un objectif difficile Ă  atteindre, il nĂ©cessite un rĂ©seau relativement bien gĂ©rĂ©. Pour un rassemblement temporaire oĂč tout le monde partage sa connectivitĂ©, faire circuler ce mot de passe partagĂ© sera difficile.

Ce mécanisme a par contre l'avantage de ne pas nécessiter que les horloges soient correctes ou synchronisées, et ne nécessite pas de stockage de données permanent (ce qui serait contraignant pour, par exemple, certains objets connectés).

Pour que tout marche bien et qu'on soit heureux et en sécurité, ce mécanisme d'authentification compte sur deux pré-requis :

  • Une fonction MAC sĂ©curisĂ©e (Ă©videmment), c'est-Ă -dire qu'on ne puisse pas fabriquer un MAC correct sans connaitre la clĂ© secrĂšte,
  • Que les nƓuds Babel arrivent Ă  ne pas rĂ©pĂ©ter certaines valeurs qu'ils transmettent. Cela peut se faire avec un gĂ©nĂ©rateur alĂ©atoire correct (RFC 4086) mais il existe aussi d'autres solutions pour gĂ©nĂ©rer des valeurs uniques, non rĂ©utilisables.
En échange de ces garanties, le mécanisme de ce RFC garantit l'intégrité des paquets et le rejet des rejeux (dans certaines conditions, voir le RFC).

La section 2 du RFC rĂ©sume trĂšs bien le protocole : quand un routeur Babel envoie un paquet sur une des interfaces oĂč la protection MAC a Ă©tĂ© activĂ©e, il calcule le MAC et l'ajoute Ă  la fin du paquet. Quand il reçoit un paquet sur une des interfaces oĂč la protection MAC a Ă©tĂ© activĂ©e, il calcule le MAC et, s'il ne correspond pas Ă  ce qu'il trouve Ă  la fin du paquet, le paquet est jetĂ©. Simple, non ? Mais c'est en fait un peu plus compliquĂ©. Pour protĂ©ger contre les attaques par rejeu, la machine qui Ă©met doit maintenir un compteur des paquets envoyĂ©s, le PC (Packet Counter). Il est inclus dans les paquets envoyĂ©s et protĂ©gĂ© par le MAC.

Ce PC ne protÚge pas dans tous les cas. Par exemple, si un routeur Babel vient de démarrer, et n'a pas de stockage permanent, il ne connait pas les PC de ses voisins et ne sait donc pas à quoi s'attendre. Dans ce cas, il doit ignorer le paquet et mettre l'émetteur au défi de répondre à un numnique qu'il envoie. Le voisin répond en incluant le numnique et son nouveau PC, prouvant ainsi qu'il ne s'agit pas d'un rejeu.

Petite difficultĂ©, en l'absence de stockage permanent, le PC peut revenir en arriĂšre et un PC ĂȘtre rĂ©utilisĂ©. Outre le PC, il faut donc un autre nombre, l'index. Celui-ci n'est, comme le numnique utilisĂ© dans les dĂ©fis, jamais rĂ©utilisĂ©. En pratique, un gĂ©nĂ©rateur alĂ©atoire est une solution raisonnable pour fabriquer numniques et index.

La section 3 du RFC dĂ©crit les structures de donnĂ©es qu'il faut utiliser pour mettre en Ɠuvre ce protocole. La table des interfaces (RFC 8966, section 3.2.3), doit ĂȘtre enrichie avec une indication de l'activation de la protection MAC sur l'interface, et la liste des clĂ©s Ă  utiliser (Babel permet d'avoir plusieurs clĂ©s, notamment pour permettre le remplacement d'une clĂ©, et le rĂ©cepteur doit donc les tester toutes). Il faut Ă©galement ajouter Ă  la table des interfaces l'index et le PC dĂ©crits plus haut.

Quant Ă  la table des (routeurs) voisins (RFC 8966, section 3.2.4), il faut y ajouter l'index et le PC de chaque voisin, et le numnique.

Enfin la section 4 dĂ©taille le fonctionnement. Comment calculer le MAC (avec un pseudo-en-tĂȘte), oĂč mettre le TLV qui indique le PC, et celui qui contient la ou les MAC (dans la remorque, c'est-Ă -dire la partie du paquet aprĂšs la longueur explicite), etc. La section 6 fournit quant Ă  elle le format exact des TLV utilisĂ©s : le MAC TLV qui stocke le MAC, le PC TLV qui indique le compteur, et les deux TLV qui permettent de lancer un dĂ©fi et d'obtenir une rĂ©ponse, pour se resynchroniser en cas d'oubli du compteur. Ils ont Ă©tĂ© ajoutĂ©s au registre IANA.

Les gens de l'opĂ©rationnel aimeront la section 5, qui dĂ©crit comment dĂ©ployer initialement cette option, et comment effectuer un changement de clĂ©. Pour le dĂ©ploiement initial, il faut configurer les machines dans un mode oĂč elles signent mais ne vĂ©rifient pas les paquets entrants (il faut donc que les implĂ©mentations aient un tel mode). Cela permet de dĂ©ployer progressivement. Une fois tous les routeurs ainsi configurĂ©s, on peut activer le mode normal, avec signature et vĂ©rification. Pour le remplacement de clĂ©s, on ajoute d'abord la nouvelle clĂ© aux routeurs, qui signent donc avec les deux clĂ©s, l'ancienne et la nouvelle, puis, une fois que tous les routeurs ont la nouvelle clĂ©, on retire l'ancienne.

Un petit bilan de la sĂ©curitĂ© de ce mĂ©canisme, en section 7 : d'abord un rappel qu'il est simple et qu'il ne fournit que le minimum, l'authentification et l'intĂ©gritĂ© des paquets. Si on veut d'avantage, il faut passer Ă  DTLS, avec le RFC 8968. Ensuite, certaines valeurs utilisĂ©es doivent ĂȘtre gĂ©nĂ©rĂ©es sans que l'attaquant puisse les deviner, ce qui nĂ©cessite, par exemple, un gĂ©nĂ©rateur de nombres alĂ©atoires sĂ©rieux. D'autant plus que la taille limitĂ©e de certaines valeurs peut permettre des attaques Ă  la force brute. Si, par exemple, les clĂ©s dĂ©rivent d'une phrase de passe, il faut une bonne phrase de passe, plus une fonction de dĂ©rivation qui gĂȘne ces attaques, comme PBKDF2 (RFC 2898), bcrypt ou scrypt (RFC 7914).

Et, comme toujours, il y a la lancinante menace des attaques par déni de service, par exemple en envoyant des paquets délibérement conçus pour faire faire des calculs cryptographiques inutiles aux victimes. C'est pour limiter leurs conséquences que, par exemple, Babel impose de limiter le rythme d'envoi des défis, pour éviter de s'épuiser à défier un attaquant.

Je n'ai pas vu quelles mises en Ɠuvre de Babel avaient ce mĂ©canisme. il ne semble pas dans la version officielle de babeld, en tout cas, mĂȘme si il y a du code dans une branche sĂ©parĂ©e. Et ce n'est pas encore dans une version officielle de BIRD mais le code est dĂ©jĂ  Ă©crit.

Le RFC ne dĂ©crit pas les changements depuis le RFC 7298 car il s'agit en fait d'un protocole diffĂ©rent, et incompatible (ce ne sont pas les mĂȘmes TLV, par exemple).

Merci Ă  Juliusz Chroboczek pour sa relecture.

happyDomain, pour gérer ses noms de domaine facilement

Le logiciel happyDomain (ou happyDNS) est une interface Web permettant de gérer ses noms de domaine. Pourquoi ? Comment ? Quand est-ce qu'on mange ?

Voyons le pourquoi d'abord. Avoir un nom de domaine Ă  soi est crucial pour une prĂ©sence en ligne, qu'on soit une association, un particulier ou une entreprise. Si on n'a pas son propre nom de domaine, par exemple parce qu'on communique uniquement sur Facebook, on est Ă  la merci d'une sociĂ©tĂ© qui peut changer ses algorithmes, voire vous virer du jour au lendemain. Et, dans ce cas, une fois trouvĂ© un autre hĂ©bergement, il faudra prĂ©venir tous vos visiteurs de la nouvelle adresse Web. Les noms de domaine permettent au contraire la stabilitĂ© de l'adresse que vous communiquez. Mais pour que ce nom de domaine fonctionne, il faut des serveurs DNS qui rĂ©pondent aux requĂȘtes des visiteurs, et il faut indiquer Ă  ces serveurs DNS les informations techniques indispensables comme l'adresse IP de votre serveur Web. Une solution simple est de confier toutes ces tĂąches Ă  l'organisation (par exemple le bureau d'enregistrement) oĂč vous avez achetĂ© le nom de domaine. Certes, vous dĂ©pendez d'un seul acteur mais, si l'intermĂ©diaire est honnĂȘte, le nom de domaine est Ă  vous et, si vous changez d'intermĂ©diaire, vous n'aurez pas Ă  recommencer le travail de communication sur votre adresse Web. À l'autre extrĂ©mitĂ© du spectre des solutions est l'hĂ©bergement de vos propres serveurs DNS, dans lesquels vous rentrez vous-mĂȘme les informations nĂ©cessaires. C'est ce que je fais pour le domaine bortzmeyer.org oĂč se trouve ce blog mais cela nĂ©cessite quelques compĂ©tences techniques et surtout du temps. MĂȘme si vous ĂȘtes un professionnel des serveurs Internet, vous n'avez pas forcĂ©ment le temps et l'envie de vous en occuper vous-mĂȘme.

Il peut aussi y avoir des solutions intermĂ©diaires entre « tout sous-traiter » et « tout faire soi-mĂȘme ». C'est lĂ  que se situe le projet happyDomain (Ă  l'origine happyDNS), le « Comment » de mon introduction. À terme, le projet veut couvrir plusieurs aspects de la gestion de noms de domaines mais, ici, je vais parler de ce qui est immĂ©diatement disponible, Ă  savoir une interface perfectionnĂ©e et agrĂ©able pour gĂ©rer les informations que les serveurs DNS distribueront au monde entier. (Mais rappelez-vous que d'autres possibilitĂ©s sont prĂ©vues.) Une telle interface est souvent fournie par les hĂ©bergeurs DNS mais je trouve qu'elles sont souvent de mĂ©diocre qualitĂ©, par exemple parce qu'elles ne permettent pas d'indiquer tous les types d'information nĂ©cessaires. Et, souvent, ces interfaces sont soit trop complexes pour les utilisateurs, soit trop limitĂ©es en ne permettant pas de faire des choses non triviales. En outre, comme elles sont dĂ©pendantes de l'hĂ©bergeur DNS, changer d'hĂ©bergeur nĂ©cessite de tout rĂ©apprendre. happyDomain, au contraire, vous rend indĂ©pendant de l'hĂ©bergeur.

Le principe est le suivant : si votre hébergeur est dans la liste des hébergeurs reconnus, vous configurez un accÚs à cet hébergeur (typiquement via son API) et vous pouvez ensuite gérer le contenu de votre domaine via happyDomain. Si vous changez d'hébergeur, ou si vous en avez plusieurs, pas besoin de réapprendre.

Ici, je vais utiliser Gandi. Dans l'interface de Gandi, le menu ParamÚtres puis Sécurité du compte permet de configurer une clé d'API que l'on indiquera à happyDomain :

On voit alors dans happyDomain ses domaines et on peut les importer dans la base de happyDomain. On peut ensuite les gérer, ajouter des enregistrements, en retirer, etc. Il y a plein de bonnes idées de présentation, par exemple les alias, les surnoms d'un nom sont visualisés de maniÚre claire et pas avec des termes techniques trÚs trompeurs comme « CNAME » :

D'une maniÚre générale, le but de happyDomain est de présenter une vision de plus haut niveau des modifications DNS, pour pouvoir se concentrer sur le contenu et pas sur des détails subtils de syntaxe. Ce n'est pas encore réalisé partout (ainsi, pour l'enregistrement SPF, il faut encore utiliser la syntaxe SPF qui est assez rébarbative) mais c'est un but sympa.

Les modifications qu'on veut faire sont bien représentées, lorsqu'on valide :

J'apprécie également le fait qu'on dispose d'un historique de ses contenus DNS, et qu'on ait plusieurs présentations possibles du contenu.

Je m'aperçois que je n'ai pas encore parlé des auteurs d'happyDomain. Ce n'est pas moi, je n'ai participé que comme donneur de conseils (c'est moins fatigant), les félicitations vont donc à Pierre-Olivier et à toute l'équipe qui a travaillé. J'avais écrit un article sur l'hébergement DNS qui a été partiellement une source d'inspiration pour happyDomain, mais, pour l'instant, la partie « hébergement » n'est pas encore développée. Mais le projet démarre déjà trÚs bien.

RFC 9003: Extended BGP Administrative Shutdown Communication

Ce nouveau RFC normalise un mécanisme pour transmettre un texte en langue naturelle à un pair BGP afin de l'informer sur les raisons pour lesquelles on coupe la session. Il remplace le RFC 8203, notamment en augmentant la longueur maximale du message, afin de faciliter les messages en Unicode.

Le protocole de routage BGP offre un mĂ©canisme de coupure propre de la session, le message NOTIFICATION avec le code Cease (RFC 4271, section 6.7). En prime, le RFC 4486 ajoutait Ă  ce code des sous-codes permettant de prĂ©ciser les raisons de la coupure. Une coupure volontaire et manuelle aura typiquement les sous-codes 2 (Administrative Shutdown), 3 (Peer De-configured) ou 4 (Administrative Reset). (Ces sous-codes sont enregistrĂ©s Ă  l'IANA.) Et enfin le RFC 8203, dĂ©jĂ  citĂ©, ajoutait Ă  ces sous-codes du texte libre, oĂč on pouvait exprimer ce qu'on voulait, par exemple « [#56554] Coupure de toutes les sessions BGP au DE-CIX pour mise Ă  jour logicielle, retour dans trente minutes ». Notre RFC ne modifie que lĂ©gĂšrement cette possibilitĂ© introduite par le RFC 8203, en augmentant la taille maximale du texte envoyĂ©.

Bien sĂ»r, la raison de la coupure peut ĂȘtre connue par d'autres moyens. Cela a pu ĂȘtre, par exemple, pour une session au travers d'un point d'Ă©change, un message envoyĂ© sur la liste du point d'Ă©change, annonçant la date (en UTC, j'espĂšre !) et la raison de la coupure. De tels message se voient rĂ©guliĂšrement sur les listes, ici au France-IX :

      
Date: Wed, 16 Dec 2020 11:54:21 +0000
From: Jean Bon <jbon@operator.example>
To: <paris@members.franceix.net>
Subject: [FranceIX members] [Paris] AS64530 [REF056255] Temporary shut FranceIX sessions

Hi France-IX members,

This mail is to inform you that we are going to shut down all our
sessions on France-IX' Paris POP on 2021-01-05 08:00:00 UTC for 30
minutes, in order to upgrade the router.

Please use the ticket number [REF056255] for every correspondance about
this action.


    
Mais quand la coupure effective se produit, on a parfois oubliĂ© le message d'avertissement, ou bien on a du mal Ă  le retrouver. D'oĂč l'importance de pouvoir rappeler les informations importantes dans le message de coupure, qui, espĂ©rons-le, sera affichĂ© quelque part chez le pair, ou bien journalisĂ© par syslog.

La section 2 dĂ©crit le format exact de ce mĂ©canisme. La chaĂźne de caractĂšres envoyĂ©e dans le message BGP NOTIFICATION doit ĂȘtre en UTF-8. Sa taille maximale est de 255 octets (ce qui ne fait pas 255 caractĂšres, attention). À part ces exigences techniques, son contenu est laissĂ© Ă  l'apprĂ©ciation de l'envoyeur.

La section 3 de notre RFC ajoute quelques conseils opérationnels. Par exemple, si vous utilisez un systÚme de tickets pour suivre vos tùches, mettez le numéro du ticket correspondant à l'intervention de maintenance dans le message. Vos pairs pourront ainsi plus facilement vous signaler à quoi ils font référence.

Attention Ă  ne pas agir aveuglĂ©ment sur la seule base d'un message envoyĂ© par BGP, notamment parce que, si la session BGP n'Ă©tait pas sĂ©curisĂ©e par, par exemple, IPsec, le message a pu ĂȘtre modifiĂ© en route.

L'annexe B du RFC résume les principaux changements depuis le RFC 8203. Le plus important est que la longueur maximale du message passe de 128 à 255 octets, notamment pour ne pas défavoriser les messages qui ne sont pas en ASCII. Comme l'avait fait remarquer lors de la discussion un opérateur du MSK-IX, si la phrase « Planned work to add switch to stack. Completion time - 30 minutes » fait 65 octets, sa traduction en russe aurait fait 119 octets.

Échec de RPZ à l'IETF

RPZ (Response Policy Zones) est une technologie permettant de configurer les mensonges d'un résolveur DNS. Il était prévu de la normaliser à l'IETF mais le projet a finalement échoué. Pourquoi ?

Un rĂ©solveur DNS est censĂ© transmettre fidĂšlement les rĂ©ponses envoyĂ©es par les serveurs faisant autoritĂ©. S'il ne le fait pas, on parle de rĂ©solveur menteur ou, pour employer le terme plus corporate du RFC 8499, de « rĂ©solveur politique ». De tels rĂ©solveurs menteurs sont utilisĂ©s pour de nombreux usages, du blocage de la publicitĂ© (par exemple avec Pi-hole) Ă  la censure Ă©tatique ou privĂ©e. L'administrateur d'un tel rĂ©solveur menteur peut configurer la liste des domaines oĂč un mensonge sera fait Ă  la main. Mais c'est Ă©videmment un long travail que de suivre les changements d'une telle liste. Il peut ĂȘtre prĂ©fĂ©rable de sous-traiter ce travail. RPZ (Response Policy Zones) est conçu pour faciliter cette sous-traitance.

Pour les principes techniques de RPZ, je vous laisse lire mon article technique, ou bien regarder le site « officiel ». RPZ est mis en Ɠuvre dans plusieurs logiciels rĂ©solveurs comme BIND, Unbound (depuis la version 1.10, cf. cet article) ou Knot.

Comme RPZ est là pour permettre la communication entre le fournisseur de listes de mensonges et le résolveur, il serait intéressant techniquement qu'il soit normalisé. Un effort a donc été fait à l'IETF pour cela. Sur l'excellent DataTracker de l'IETF, vous pouvez suivre l'histoire de ce projet depuis 2016 : d'abord une contribution individuelle, draft-vixie-dns-rpz, puis aprÚs adoption par un groupe de travail de l'IETF, une version de groupe (qu'on reconnait à son nom commençant par draft-ietf-NOMDUGROUPE), draft-ietf-dnsop-dns-rpz puis, aprÚs une interruption d'une année, à nouveau un retour à la contribution individuelle, draft-vixie-dnsop-dns-rpz, finalement abandonnée depuis aujourd'hui plus de deux ans.

Pourquoi cet échec ? Notez d'abord que l'IETF ne documente pas explicitement les échecs. Il n'y a pas eu de décision officielle « on laisse tomber », avec un texte expliquant pourquoi. Il s'agit plutÎt d'un document qui a eu à faire face à tellement de problÚmes que plus personne n'avait envie de travailler dessus.

Quels Ă©taient ces problĂšmes ? Commençons par le plus gros, le problĂšme politique. Beaucoup de gens ne sont pas d'accord avec la censure faite via le DNS et craignaient que RPZ n'aide les mĂ©chants davantage que les gentils. À ce problĂšme politique (tout le monde n'Ă©tant pas d'accord sur la lĂ©gitimitĂ© de la censure) s'ajoutait un problĂšme classique lors des dĂ©bats politico-techniques, celui de la neutralitĂ© de la technique (j'en ai parlĂ© dans mon livre, p. 148 et suivantes de l'Ă©dition papier). Le dĂ©bat est rĂ©current Ă  l'IETF et peut se simplifier en deux positions opposĂ©es :

  • Nous normalisons juste des techniques, les gens peuvent ensuite les utiliser pour le bien ou pour le mal et, de toute façon, si l'IETF ne normalise pas cette technique dans un RFC, elle sera utilisĂ©e quand mĂȘme, et peut-ĂȘtre normalisĂ©e par des organismes moins scrupuleux comme l'UIT.
  • Nous ne pouvons pas nier les consĂ©quences des dĂ©cisions que nous prenons (RFC 8890), tout est politique (RFC 8280), et un RFC sera interprĂ©tĂ© comme une approbation ou quasi-approbation par l'IETF.
Pris entre ces deux positions, le document a ainsi été adopté par le groupe de travail DNSOP, puis abandonné, aprÚs de longues et parfois vigoureuses discussions.

Une autre raison de la non-normalisation de RPZ est peut-ĂȘtre le fait qu'en pratique, ce protocole n'a Ă©tĂ© adoptĂ© que par des acteurs commerciaux. Je n'ai pas trouvĂ© de flux RPZ librement accessible, par exemple avec une liste de domaines liĂ©s Ă  la publicitĂ© (ce serait bien pratique pour les bloquer). Peut-ĂȘtre https://block.energized.pro/ ? Mais, s'ils ont bien le format RPZ, ils ne rendent pas ces flux accessibles en AXFR, ce qui complique leur mise Ă  jour.

Un problĂšme supplĂ©mentaire est Ă©galement survenu dans la discussion : le contrĂŽle du changement. Normalement, une fois un protocole publiĂ© par l'IETF, c'est l'IETF qui gouverne les Ă©volutions futures. Or, ici, les auteurs originaux de RPZ avaient Ă©crit dans le document qu'ils gardaient le contrĂŽle et pouvaient donc empĂȘcher telle ou telle Ă©volution de la norme. En contradiction avec les rĂšgles de l'IETF, cette mention a contribuĂ© Ă  l'Ă©chec de RPZ dans le groupe de travail. Il aurait quand mĂȘme pu ĂȘtre publiĂ© en RFC non-IETF mais le projet est finalement mort d'Ă©puisement.

RFC 8955: Dissemination of Flow Specification Rules

Lorsqu'on a un grand rĂ©seau compliquĂ©, diffuser Ă  tous les routeurs des rĂšgles de filtrage, par exemple pour faire face Ă  une attaque par dĂ©ni de service, peut ĂȘtre complexe. Il existe des logiciels permettant de gĂ©rer ses routeurs collectivement mais ne serait-il pas plus simple de rĂ©utiliser pour cette tĂąche les protocoles existants et notamment BGP ? AprĂšs tout, des rĂšgles de filtrage sont une forme de route. On profiterait ainsi des configurations existantes et de l'expĂ©rience disponible. C'est ce que se sont dit les auteurs de ce RFC. « FlowSpec » (nom officieux de cette technique) consiste Ă  diffuser des rĂšgles de traitement du trafic en BGP, notamment Ă  des fins de filtrage. Ce RFC remplace le RFC FlowSpec original, le RFC 5575, le texte ayant sĂ©rieusement changĂ© (mais le protocole est presque le mĂȘme).

Les routeurs modernes disposent en effet de nombreuses capacitĂ©s de traitement du trafic. Outre leur tĂąche de base de faire suivre les paquets, ils peuvent les classifier, limiter leur dĂ©bit, jeter certains paquets, etc. La dĂ©cision peut ĂȘtre prise en fonction de critĂšres tels que les adresses IP source et destination ou les ports source et destination. Un flot (flow) est donc dĂ©fini comme un tuple rassemblant les critĂšres d'acceptation d'un paquet IP. Notre RFC 8955 encode ces critĂšres dans un attribut NLRI (Network Layer Reachability Information est dĂ©crit dans la section 4.3 du RFC 4271) BGP, de maniĂšre Ă  ce qu'ils puissent ĂȘtre transportĂ©s par BGP jusqu'Ă  tous les routeurs concernĂ©s. Sans FlowSpec, il aurait fallu qu'un humain ou un programme se connecte sur tous les routeurs et y rentre l'ACL concernĂ©e.

Pour reconnaitre les paquets FlowSpec, ils sont marqués avec le SAFI (concept introduit dans le RFC 4760) 133 pour les rÚgles IPv4 (et IPv6 grùce au RFC 8956) et 134 pour celles des VPN.

La section 4 du RFC donne l'encodage du NLRI. Un message UPDATE de BGP est utilisĂ©, avec les attributs MP_REACH_NLRI et MP_UNREACH_NLRI du RFC 4760 et un NLRI FlowSpec. Celui-ci compte plusieurs couples {type, valeur} oĂč l'interprĂ©tation de la valeur dĂ©pend du type (le type est codĂ© sur un octet). Voici les principaux types :

  • Type 1 : prĂ©fixe de la destination, reprĂ©sentĂ© par un octet pour la longueur, puis le prĂ©fixe, encodĂ© comme traditionnellement en BGP (section 4.3 du RFC 4271). Ainsi, le prĂ©fixe 10.0.1.0/24 sera encodĂ© (notĂ© en hexadĂ©cimal) 01 18 0a 00 01 (type 1, longueur 24 - 18 en hexa - puis le prĂ©fixe dont vous noterez que seuls les trois premiers octets sont indiquĂ©s, le dernier n'Ă©tant pas pertinent ici).
  • Type 2 : prĂ©fixe de la source (lors d'une attaque DoS, il est essentiel de pouvoir filtrer aussi sur la source).
  • Type 3 : protocole (TCP, UDP, etc).
  • Types 4, 5 et 6 : port (source ou destination ou les deux). LĂ  encore, c'est un critĂšre trĂšs important lors du filtrage d'une attaque DoS. Attention, cela suppose que le routeur soit capable de sauter les en-tĂȘtes IP (y compris des choses comme ESP) pour aller dĂ©coder TCP ou UDP. Tous les routeurs ne savent pas faire cela (en IPv6, c'est difficile).
  • Type 9 : options activĂ©es de TCP, par exemple uniquement les paquets RST.
Tous les types de composants sont enregistrés à l'IANA.

Une fois qu'on a cet arsenal, Ă  quoi peut-on l'utiliser ? La section 5 dĂ©taille le cas du filtrage. Autrefois, les rĂšgles de filtrage Ă©taient assez statiques (je me souviens de l'Ă©poque oĂč tous les rĂ©seaux en France avaient une ACL, installĂ©e manuellement, pour filtrer le rĂ©seau de l'EPITA). Aujourd'hui, avec les nombreuses DoS qui vont et viennent, il faut un mĂ©canisme bien plus dynamique. La premiĂšre solution apparue a Ă©tĂ© de publier via le protocole de routage des prĂ©fixes de destination Ă  refuser. Cela permet mĂȘme Ă  un opĂ©rateur de laisser un de ses clients contrĂŽler le filtrage, en envoyant en BGP Ă  l'opĂ©rateur les prĂ©fixes, marquĂ©s d'une communautĂ© qui va dĂ©clencher le filtrage (Ă  ma connaissance, aucun opĂ©rateur n'a utilisĂ© cette possibilitĂ©, en raison du risque qu'une erreur du client ne se propage). De toute façon, c'est trĂšs limitĂ© en cas de DoS (par exemple, on souhaite plus souvent filtrer sur la source que sur la destination). Au contraire, le mĂ©canisme FlowSpec de ce RFC donne bien plus de critĂšres de filtrage.

Cela peut d'ailleurs s'avĂ©rer dangereux : une annonce FlowSpec trop gĂ©nĂ©rale et on bloque du trafic lĂ©gitime. C'est particuliĂšrement vrai si un opĂ©rateur accepte du FlowSpec de ses clients : il ne faut pas permettre Ă  un client de filtrer les autres. D'oĂč la procĂ©dure suggĂ©rĂ©e par la section 6, qui demande de n'accepter les NLRI FlowSpec que s'ils contiennent un prĂ©fixe de destination, et que ce prĂ©fixe de destination est routĂ© vers le mĂȘme client qui envoie le NLRI. Ainsi, un client ne peut pas dĂ©clencher le filtrage d'un autre puisqu'il ne peut influencer que le filtrage des paquets qui lui sont destinĂ©s.

Au fait, en section 5, on a juste vu comment indiquer les critĂšres de classification du trafic qu'on voulait filtrer. Mais comment indiquer le traitement qu'on veut voir appliquĂ© aux paquets ainsi classĂ©s ? (Ce n'est pas forcĂ©ment les jeter : on peut vouloir ĂȘtre plus subtil.) FlowSpec utilise les communautĂ©s Ă©tendues du RFC 4360. La valeur sans doute la plus importante est 0x8006, traffic-rate, qui permet de spĂ©cifier un dĂ©bit maximal pour les paquets qui correspondent aux critĂšres mis dans le NLRI. Le dĂ©bit est en octets/seconde. En mettant zĂ©ro, on demande Ă  ce que tous les paquets classĂ©s soient jetĂ©s. (Mais on peut aussi indiquer des paquets/seconde, c'est une nouveautĂ© de ce RFC.) Les autres valeurs possibles permettent des actions comme de modifier les bits DSCP du trafic classĂ©.

Comme toutes les armes, celle-ci peut ĂȘtre dangereuse pour celui qui la manipule. La section 12 est donc la bienvenue, pour avertir de ces risques. Par exemple, comme indiquĂ© plus haut, si on permet aux messages FlowSpec de franchir les frontiĂšres entre AS, un AS maladroit ou mĂ©chant risque de dĂ©clencher un filtrage chez son voisin. D'oĂč l'importance de la validation, n'accepter des rĂšgles FlowSpec que pour les prĂ©fixes de l'AS qui annonce ces rĂšgles.

Ensuite, comme tous les systÚmes de commande des routeurs à distance, FlowSpec permet de déclencher un filtrage sur tous les routeurs qui l'accepteront. Si ce filtrage est subtil (par exemple, filtrer tous les paquets plus grands que 900 octets), les problÚmes qui en résultent seront difficiles à diagnostiquer.

FlowSpec a jouĂ© un rĂŽle important dans la panne Level 3 / CenturyLink d'aoĂ»t 2020. Et, avant cela, dans la panne CloudFlare du 3 mars 2013, oĂč des critĂšres incorrects (une taille de paquet supĂ©rieure au maximum permis par IP) avaient Ă©tĂ© envoyĂ©s Ă  tous les routeurs. Ce n'est pas une bogue de FlowSpec : tout mĂ©canisme de diffusion automatique de l'information Ă  N machines diffĂ©rentes a le mĂȘme problĂšme potentiel. Si l'information Ă©tait fausse, le mĂ©canisme de diffusion transmet l'erreur Ă  tous... (Dans le monde des serveurs Unix, le mĂȘme problĂšme peut se produire avec des logiciels comme Chef ou Puppet. Lisez un cas rigolo avec Ansible.) Comme le prĂ©vient notre RFC : « When automated systems are used, care should be taken to ensure the correctness of the automated system. » Toutefois, contrairement Ă  ce que laisse entendre le RFC, il n'y a pas que les processus automatiques qui injectent des erreurs : les humains le font aussi.

Si vous voulez en apprendre plus sur FlowSpec :

Si vous vous intéressez à l'utilisation de BGP lors d'attaques par déni de service, vous pouvez aussi consulter les RFC 3882 et RFC 5635.

Les changements depuis la norme originale, le RFC 5575, sont résumés dans l'annexe B. Parmi les principaux :

  • Le RFC 7674 a Ă©tĂ© intĂ©grĂ© ici, et n'est donc plus d'actualitĂ©,
  • Les comparaisons entre les valeurs indiquĂ©es dans les rĂšgles FlowSpec et les paquets qu'on voit passer sont dĂ©sormais spĂ©cifiĂ©es plus strictement, avec du code d'exemple (en Python) dans l'annexe A,
  • Les actions fondĂ©es sur le trafic peuvent dĂ©sormais s'exprimer en nombre de paquets et plus seulement en nombre d'octets (certaines attaques par dĂ©ni de service sont dangereuses par leur nombre de paquets, mĂȘme si ces paquets sont petits).

FlowSpec est utilisĂ© depuis dix ans et de nombreuses mises en Ɠuvre existent (cf. la liste). Sur les Juniper, on peut consulter leur documentation en ligne.

RFC 8956: Dissemination of Flow Specification Rules for IPv6

Il existe un mĂ©canisme de diffusion des rĂšgles de filtrage IP, FlowSpec, normalisĂ© dans le RFC 8955. Ce mĂ©canisme permet d'utiliser BGP pour envoyer Ă  tous les routeurs d'un AS les mĂȘmes rĂšgles, ce qui est trĂšs pratique, par exemple pour bloquer une attaque sur tous les routeurs d'entrĂ©e du domaine. Le FlowSpec original ne gĂ©rait qu'IPv4, voici son adaptation Ă  IPv6.

En fait, il n'y avait pas grand'chose Ă  faire. AprĂšs tout, IPv6 n'est pas un nouveau protocole, juste une nouvelle version du mĂȘme protocole IP. Des concepts cruciaux, comme la dĂ©finition d'un prĂ©fixe en prĂ©fixe/longueur, ou comme la rĂšgle du prĂ©fixe le plus spĂ©cifique restent les mĂȘmes. Ce RFC est donc assez simple. Il ne reprend pas l'essentiel du RFC 8955, il ajoute juste ce qui est spĂ©cifique Ă  IPv6. (À l'IETF, il avait Ă©tĂ© proposĂ© de fusionner les deux documents mais, finalement, il y a un RFC gĂ©nĂ©rique + IPv4, le RFC 8955, et un spĂ©cifique Ă  IPv6, notre RFC 8956.)

Petit rappel sur FlowSpec : les rĂšgles de filtrage sont transportĂ©es en BGP, les deux routeurs doivent annoncer la capacitĂ© « multi-protocole » (les capacitĂ©s sont dĂ©finies dans le RFC 5492) dĂ©finie dans le RFC 4760, la famille de l'adresse (AFI pour Address Family Identifier) est 2 (qui indique IPv6) et le SAFI (Subsequent Address Family Identifier) est le mĂȘme qu'en IPv4, 133.

Le gros de notre RFC (section 3) est l'Ă©numĂ©ration des diffĂ©rents types d'identifiant d'un trafic Ă  filtrer. Ce sont les mĂȘmes qu'en IPv4 mais avec quelques adaptations. Ainsi, le type 1, « prĂ©fixe de destination » permet par exemple de dire Ă  ses routeurs « jette Ă  la poubelle tout ce qui est destinĂ© Ă  2001:db:96b:1::/64 ». Son encodage ressemble beaucoup Ă  celui en IPv4 mais avec un truc en plus, le dĂ©calage (offset) depuis le dĂ©but de l'adresse. Avec un dĂ©calage de 0, on est dans le classique prĂ©fixe/longueur mais on peut aussi ignorer des bits au dĂ©but de l'adresse avec un dĂ©calage non-nul.

Le type 3, « protocole de niveau supĂ©rieur » est l'un de ceux dont la dĂ©finition IPv6 est la plus diffĂ©rente de celle d'IPv4. En effet, IPv6 a les en-tĂȘtes d'extension (RFC 8200, section 4), une spĂ©cificitĂ© de cette version. Le champ « Next header » d'IPv6 (RFC 8200, section 3) n'a pas la mĂȘme sĂ©mantique que le champ « Protocole » d'IPv4 puisqu'il peut y avoir plusieurs en-tĂȘtes avant celui qui indique le protocole de couche 4 (qui sera typiquement TCP ou UDP). Le choix de FlowSpec est que le type 3 dĂ©signe le dernier champ « Next header », celui qui identifie le protocole de transport, ce qui est logique, c'est bien lĂ -dessus qu'on veut filtrer, en gĂ©nĂ©ral. Rappelez-vous au passage que d'analyser les en-tĂȘtes d'extension IPv6 pour arriver au protocole de transport n'est hĂ©las pas trivial. Et il y a d'autres piĂšges, expliquĂ©s dans les RFC 7112 et RFC 8883.

Autre type d'identifiant qui est diffĂ©rent en IPv6, le type 7, ICMP. Si le protocole est trĂšs proche, les types et les codes ne sont en effet pas les mĂȘmes. Ainsi, l'un des types les plus cĂ©lĂšbres, Echo Request, utilisĂ© par ping, vaut 8 en IPv4 et 138 en IPv6.

Les autres types se comportent en IPv6 exactement comme en IPv4. Par exemple, si vous voulez dire Ă  vos routeurs de filtrer sur le port, les types 4, 5 et 6, dĂ©diĂ©s Ă  cet usage, ont le mĂȘme encodage et la mĂȘme sĂ©mantique qu'en IPv4 (ce qui est logique, puisque le port est un concept de couche 4).

FlowSpec est aujourd'hui largement mis en Ɠuvre dans les logiciels de routage, y compris en IPv6. Vous pouvez consulter à ce sujet le rapport de mise en Ɠuvre. Si vous voulez jouer avec FlowSpec, le code Python d'exemple de l'annexe A est disponible en ligne.

Developing and running an Internet crawler

I've just developed and now runs an Internet crawler. Yes, the sort of bots that goes around and gather content. But not a Web crawler. This is for Gemini. Here are a few lessons learned.

If you don't know Gemini, there is no Wikipedia page yet, so you have to go to the official site. Basically, Gemini is born from a disenchantment: the Web is technically too complicated, it is now impossible to write a browser from scratch and because of that the competition is very limited. This technical complexity does not even serve the interests of the users: it creates distractions (such as videos automatically starting), it encourages Web sites authors to focus on the look, not on the content, and it adds a lot of opportunities for surveillance. Gemini relies on a simpler protocol, with no extensions, and a simpler format.

Today, the "geminispace" is quite small. This makes easy and reasonable to write a crawler to explore it completely. This is what I did with the Lupa program, which is now live on one of my machines. The goal of this crawler is not to be used for a search engine (unlike the crawler used in the Gemini search engine gus.guru) but to do statistics and to survey the geminispace. You can see the results on Gemini at the URI gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi. If you don't have a Gemini client yet, here is what it looks like, seen with the Lagrange client :

Now, what is the current state of the geminispace?

  • 506 capsules (a Gemini capsule is a single host, a bit like a Web site) are known but Lupa could reach only 415 of them. (Gemini is quite experimental and many capsules are short-lived. Also, some links are examples and point to non-existing capsules.)
  • The biggest capsule, both by the number of URIs it hosts and by the number of bytes it contains, is gemini.spam.works. Its content is mostly old files, some distributed on Usenet a long time ago. The second capsule by the number of bytes is my own gemini.bortzmeyer.org because it contains a mirror of RFCs.
  • The question of certificates is touchy. Gemini suggests the use of self-signed certificates, augmented with TOFU, but not everyone agrees. Today, 17 % of the known capsules use a certificate issued by Let's Encrypt, the rest being probably self-signed.
  • As it is for the Web, a same machine, with one IP address can host several "virtual hosts", several capsules. We observed 371 different IP addresses, among which 17 % use a modern protocol, IPv6. The IP address with the greatest number of "virtual hosts" is at Linode and is used for public hosting of Gemini capsules, hence its huge number of virtual hosts.
  • Each capsule is identified by a domain name. Which TLD are used for these names? The most popular is .online but this is because the same very common Gemini hosting service hosts many capsules under its name in .online, which skews the results. After that, the most popular TLDs are .com, .org, .net and .space.
  • 64,000 URIs are known but we got only 50,000 of them. Lupa follows the robots.txt exclusion system (more on that later) which means that some capsules or some parts of capsules cannot be crawled. Also, Lupa has a limit on how many URIs to get from a single capsule.
  • The most common media types (60 % of the total) is of course text/gemini alias "gemtext", the reference format for Gemini. Plain text comes after, with 30 %. Remember that Gemini is young and a lot of content has been produced by mirroring existing content, which is often in plain text. There are even 2 % of the URIs which are in HTML, which is surprising. Only 0.3 % are in Markdown, which should be more in the Gemini spirit than HTML.
  • The Gemini protocol allows servers to tag the resources with the language they're written in. The vast majority of the resources does not use this feature, maybe because they're written in English and assume it is the world's default? Among the tagged resources, the most common language is English, then French, then (but far after) Spanish.
Keep in mind that no crawler could explore everything. If there are capsules out here which are not linked from the capsules we know, they won't be retrieved.

What are the issues when running a crawler on the geminispace? Since bots can create a serious load on some servers, a well-behaved bot is supposed to limit itself, and to follow the preferences expressed by the server. Unfortunately, there is no proper standard to express these preferences. The Web uses robots.txt but it is not really standardized. The original specification is very simple (may be too simple), and many robots.txt files use one or another form of extensions, such as the Allow: directive or globbing. (IETF is currently trying to standardize robots.txt.) Because of that, you can never be sure that your robots.txt will be interpreted as you want. This is even worse in the geminispace where it is not clear or specified if robots.txt apply and, if so, which variant.

Another big problem when running a bot is the variety of network problems you can encounter. The simplest case is when a server replies with some Gemini error code (51 for "resource not found", the equivalent of the famous HTTP 404) or when it rejects Gemini connections right away (TCP RST for instance). But many servers react in much stranger ways: timeout when connecting (no response, not even a rejection), accepting the TCP connection but no response to the start of the TLS negotiation, accepting the TLS session but no response afterwards to the Gemini request, etc. A lot of network operations can leave your bot stuck forever, or make it run in an endless loop (for instance never-ending redirections). It is very important to use defensive programming and to plan for the worst. And to set a limit to everything (size of the resources, number of resources per capsule, etc). It is a general rule of programming that a simple implementation which does 90 % of the job will be done quickly (may be 10 % of the total time of the project), but a real implementation able to handle 100 % of the job will take much longer. This is even more so when managing a crawler.

RFC 8970: IMAP4 Extension: Message Preview Generation

Le protocole IMAP d'accÚs aux boites aux lettres (RFC 3501) continue à évoluer et reçoit de nouvelles extensions. Celle normalisée dans ce RFC permet au client IMAP, le MUA, de ne récupérer qu'une partie du message, afin d'afficher un avant-gout de celui-ci à l'utilisateur humain, qui pourra ainsi mieux choisir s'il veut lire ce message ou pas.

Il y a dĂ©jĂ  des clients de messagerie qui prĂ©sentent le dĂ©but du message mais, sans l'extension de ce RFC, cela nĂ©cessite de tout rĂ©cupĂ©rer (un FETCH BODYSTRUCTURE pour savoir quelle partie MIME rĂ©cupĂ©rer, suivi d'un FETCH BODY, et sans possibilitĂ© de les exĂ©cuter en parallĂšle) avant de ne sĂ©lectionner qu'une partie. Au contraire, avec l'extension PREVIEW (« avant-gout »), c'est le serveur IMAP qui va sĂ©lectionner cet avant-gout. Avantages : une prĂ©sĂ©lection qui est identique sur tous les clients, moins de travail pour le client et surtout moins de donnĂ©es transmises. Avant, le client Ă©tait forcĂ© de rĂ©cupĂ©rer beaucoup de choses car il ne pouvait pas savoir Ă  l'avance combien d'octets rĂ©colter avant de gĂ©nĂ©rer l'avant-gout. Si le message Ă©tait du texte brut, OK, mais si c'Ă©tait de l'HTML, il pouvait ĂȘtre nĂ©cessaire de ramasser beaucoup d'octets de formatage et de gadgets avant d'en arriver au vrai contenu. (Ou bien, il fallait procĂ©der progressivement, rĂ©cupĂ©rant une partie du message, puis, si nĂ©cessaire, une autre, ce qui augmentait la latence.)

Donc, concrÚtement, comment ça se passe ? La section 3 de notre RFC décrit l'extension en détail. Elle a la forme d'un attribut PREVIEW qui suit la commande FETCH (RFC 3501, section 6.4.5). Voici un exemple, la commande étant étiquetée MYTAG01 :

Client :    
MYTAG01 FETCH 1 (PREVIEW)

Serveur :
* 1 FETCH (PREVIEW "Bonjour, voulez-vous gagner plein d'argent rapidement ?")
MYTAG01 OK FETCH complete.
  
IdĂ©alement, le serveur renvoie toujours le mĂȘme avant-gout pour un message donnĂ© (mais le RFC ne l'impose pas car cela peut ĂȘtre difficile dans certains cas, par exemple en cas de mise Ă  jour du logiciel du serveur, qui change l'algorithme de gĂ©nĂ©ration des avant-gouts).

La syntaxe formelle de l'attribut PREVIEW est en section 6 du RFC.

Le format de l'avant-gout est forcément du texte brut, encodé en UTF-8, et ne doit pas avoir subi d'encodages baroques comme Quoted-Printable. Sa longueur est limitée à 256 caractÚres (caractÚres Unicode, pas octets, attention si vous programmez un client et que votre tampon est trop petit).

Le contenu de l'avant-gout est typiquement composĂ© des premiers caractĂšres du message. Cela implique qu'il peut contenir des informations privĂ©es et il ne doit donc ĂȘtre montrĂ© qu'aux clients qui sont autorisĂ©s Ă  voir le message complet.

Parfois, le serveur ne peut pas générer un avant-gout, par exemple si le message est chiffré avec OpenPGP (RFC 4880) ou bien si le message est entiÚrement binaire, par exemple du PNG. Dans ces cas, le serveur est autorisé à renvoyer une chaßne de caractÚres vide.

Si le serveur gĂ©nĂšre un avant-gout lui-mĂȘme (du genre « Image de 600x600 pixels, prise le 18 dĂ©cembre 2020 », en utilisant les mĂ©tadonnĂ©es de l'image), il est recommandĂ© qu'il choisisse la langue indiquĂ©e par l'extension LANGUAGE (RFC 5255).

Comme l'avant-gout n'est pas forcément indispensable pour l'utilisateur, le RFC suggÚre (section 4) de le charger en arriÚre-plan, en affichant la liste des messages sans attendre tous ces avant-gouts.

Le serveur IMAP qui sait générer ces avant-gouts l'annonce via la capacité PREVIEW, qui est notée dans le registre des capacités. Voici un exemple :

Client :
MYTAG01 CAPABILITY

Serveur :
* CAPABILITY IMAP4rev1 PREVIEW
MYTAG01 OK Capability command completed.

Client :
MYTAG02 FETCH 1 (RFC822.SIZE PREVIEW)

Serveur :
* 1 FETCH (RFC822.SIZE 5647 PREVIEW {200}
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Curabitur aliquam turpis et ante dictum, et pulvinar dui congue.
ligula nullam
)
MYTAG02 OK FETCH complete. 
  

Attention si vous mettez en Ɠuvre cette extension, elle nĂ©cessite davantage de travail du serveur, donc un client mĂ©chant pourrait surcharger ledit serveur. Veillez bien Ă  authentifier les clients, pour retrouver le mĂ©chant (section 7 du RFC).

Cette extension est dĂ©jĂ  mise en Ɠuvre dans Dovecot et Cyrus.

RFC 8953: Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report

Voici le compte-rendu de la deuxiÚme édition de l'atelier CARIS (Coordinating Attack Response at Internet Scale), un atelier de l'ISOC consacré à la défense de l'Internet contre les différentes attaques possibles, par exemple les dDoS. Cet atelier s'est tenu à Cambridge en mars 2019. Par rapport au premier CARIS, documenté dans le RFC 8073, on note l'accent mis sur les conséquences du chiffrement, désormais largement répandu.

Les problÚmes de sécurité sur l'Internet sont bien connus. C'est tous les jours qu'on entend parler d'une attaque plus ou moins réussie contre des infrastructures du réseau. Ainsi, Google a été victime d'une grosse attaque en 2017 (mais qui n'a été révélée que des années aprÚs). Mais, pour l'instant, nous n'avons pas de solution miracle. L'idée de base des ateliers CARIS est de rassembler aussi bien des opérateurs de réseau, qui sont « sur le front » tous les jours, que des chercheurs, des fournisseurs de solutions de défense, et des CSIRT, pour voir ensemble ce qu'on pouvait améliorer. Pour participer, il fallait avoir soumis un article, et seules les personnes dont un article était accepté pouvait venir, garantissant un bon niveau de qualité aux débats, et permettant de limiter le nombre de participants, afin d'éviter que l'atelier ne soit juste une juxtaposition de discours.

La section 2 du RFC présente les quatorze papiers qui ont été acceptés. On les trouve en ligne.

Le but de l'atelier Ă©tait d'identifier les points sur lesquels des progrĂšs pourraient ĂȘtre faits. Par exemple, tout le monde est d'accord pour dire qu'on manque de professionnel·le·s compĂ©tent·e·s en cybersĂ©curitĂ© mais il ne faut pas espĂ©rer de miracles : selon une Ă©tude, il manque trois millions de personnes dans ce domaine et il n'y a simplement aucune chance qu'on puisse les trouver Ă  court terme. Plus rĂ©aliste, l'atelier s'est focalisĂ© sur le dĂ©ploiement du chiffrement (TLS 1.3, normalisĂ© dans le RFC 8446, le futur QUIC, et pourquoi pas le TCPcrypt du RFC 8548), dĂ©ploiement qui peut parfois gĂȘner la dĂ©tection de problĂšmes, et sur les mĂ©canismes de dĂ©tection et de prĂ©vention. Une importance particuliĂšre Ă©tait donnĂ©e au passage Ă  l'Ă©chelle (on ne peut plus traiter chaque attaque individuellement et manuellement, il y en a trop).

Bon, maintenant, les conclusions de l'atelier (section 4). PremiĂšre session, sur l'adoption des normes. C'est une banalitĂ© Ă  l'IETF que de constater que ce n'est pas parce qu'on a normalisĂ© une technique de sĂ©curitĂ© qu'elle va ĂȘtre dĂ©ployĂ©e. Beaucoup de gens aiment rĂąler contre l'insĂ©curitĂ© de l'Internet mais, dĂšs qu'il s'agit de dĂ©penser de l'argent ou du temps pour dĂ©ployer les solutions de sĂ©curitĂ©, il y a moins d'enthousiasme. (J'Ă©cris cet article au moment de la publication de la faille de sĂ©curitĂ© SadDNS. Cela fait plus de dix ans qu'on a une solution opĂ©rationnelle contre la famille d'attaques dont SadDNS fait partie, DNSSEC et, pourtant, DNSSEC n'est toujours pas dĂ©ployĂ© sur la plupart des domaines.) Commençons par un point optimiste : certaines des technologies de sĂ©curitĂ© de l'IETF ont Ă©tĂ© largement dĂ©ployĂ©es, comme SSL (RFC 6101), remplacĂ© il y a quinze ans par TLS (RFC 8446). L'impulsion initiale venait clairement du secteur du commerce Ă©lectronique, qui voulait protĂ©ger les numĂ©ros des cartes de crĂ©dit. LiĂ© Ă  TLS, X.509 (RFC 5280) est aussi un succĂšs. Cette fois, l'impulsion initiale est plutĂŽt venue des États. (X.509 doit ĂȘtre une des trĂšs rares normes UIT survivantes sur l'Internet.)

Moins directement liĂ© Ă  la sĂ©curitĂ©, SNMP (RFC 3410) est aussi un succĂšs, mĂȘme s'il est en cours de remplacement par les techniques autour de YANG comme RESTCONF. Toujours pour la gestion de rĂ©seaux, IPfix (RFC 7011) est Ă©galement un succĂšs, largement mis en Ɠuvre sur beaucoup d'Ă©quipements rĂ©seau.

Par contre, il y a des semi-Ă©checs et des Ă©checs. Le format de description d'incidents de sĂ©curitĂ© IODEF (RFC 7970) ne semble pas trĂšs rĂ©pandu. (Il a un concurrent en dehors de l'IETF, STIX - Structured Threat Information eXpression, qui ne semble pas mieux rĂ©ussir.) IODEF est utilisĂ© par des CSIRT mais souffre de son niveau de dĂ©tail (beaucoup d'opĂ©rationnels veulent des synthĂšses, pas des donnĂ©es brutes) et, comme toutes les techniques d'Ă©change d'information sur les questions de sĂ©curitĂ©, souffre Ă©galement des problĂšmes de confiance qui grippent la circulation de l'information. Autre technique de sĂ©curitĂ© excellente mais peu adoptĂ©e, DANE (RFC 7671). MalgrĂ© de nombreux efforts de promotion (comme https://internet.nl, le blog que vous lisez a une note de 93 %, car la configuration TLS est tolĂ©rante) et mĂȘme avec une reconnaissance lĂ©gale partielle en Allemagne, DANE reste trĂšs minoritaire.

Un autre cas fameux de non-succĂšs, mĂȘme s'il n'est pas directement liĂ© Ă  la sĂ©curitĂ©, est IPv6 (RFC 8200).

DeuxiÚme session, les protocoles nouveaux. L'atelier s'est penché sur le format MUD (Manufacturer Usage Description, RFC 8520) qui pourrait aider à boucher une petite partie des trous de sécurité de l'Internet des objets. Il a également travaillé l'échange de données et les problÚmes de confiance qu'il pose. Comme à CARIS 1, plusieurs participants ont noté que cet échange de données reste gouverné par des relations personnelles. La confiance ne passe pas facilement à l'échelle. L'échange porte souvent sur des IOC et un standard possible a émergé, MISP.

Une fois le problÚme détecté, il reste à coordonner la réaction, puisque l'attaque peut toucher plusieurs parties. C'est encore un domaine qui ne passe guÚre à l'échelle. L'Internet n'a pas de mécanisme (technique mais surtout humain) pour coordonner des centaines de victimes différentes. Des tas d'obstacles à la coordination ont été mentionnés, des outils trop difficiles à utiliser en passant par les obstacles frontaliers à l'échange, les obligations légales qui peuvent interdire l'échange de données, et bien sûr le problÚme récurrent de la confiance. Vous vous en doutez, pas plus qu'au premier atelier, il n'y aura eu de solution parfaite découverte pendant les sessions.

La session sur la surveillance a vu plusieurs discussions intĂ©ressantes. Ce fut le cas par exemple du problĂšme de la rĂ©putation des adresses IP. Ces adresses sont souvent des IOC et on se les Ă©change souvent, ce qui soulĂšve des questions liĂ©es Ă  la vie privĂ©e. (Un des papiers de l'atelier est « Measured Approaches to IPv6 Address Anonymization and Identity Association », de David Plonka et Arthur Berger , qui explique la difficultĂ© de l'« anonymisation » des adresses IP si on veut qu'elles restent utiles pour les opĂ©rationnels.) L'exploitation correcte de ces adresses IP nĂ©cessite de connaitre les plans d'adressage utilisĂ©s (si une adresse IPv6 se comporte mal, faut-il bloquer tout le prĂ©fixe /64 ? Tout le /48 ?). Il n'y a pas de ressources publiquement disponibles Ă  ce sujet, qui permettrait de connaitre, pour une adresse IP donnĂ©e, l'Ă©tendue du prĂ©fixe englobant. (Je ne parle Ă©videmment pas du routage, pour lequel ces bases existents, mais de la responsabilitĂ©.) Une des suggestions Ă©tait d'Ă©tendre les bases des RIR. Une autre Ă©tait de crĂ©er une nouvelle base. Le problĂšme est toujours le mĂȘme : comment obtenir que ces bases soient peuplĂ©es, et correctement peuplĂ©es ?

Une des questions amusantes lorsqu'on essaie de dĂ©boguer un problĂšme de communication entre deux applications est de savoir quoi faire si la communication est chiffrĂ©e. Il n'est Ă©videmment pas question de rĂ©clamer une porte dĂ©robĂ©e pour court-circuiter le chiffrement, cela crĂ©erait une Ă©norme faille de sĂ©curitĂ©. Mais alors comment faire pour savoir ce qui se dit ? On a besoin de la coopĂ©ration de l'application. Mais toutes les applications ne permettent pas facilement de journaliser les informations importantes et, quand elles le font, ce n'est pas dans un format cohĂ©rent. D'oĂč une suggestion lors de l'atelier de voir s'il ne serait pas envisageable de mettre cette fonction dans les compilateurs, pour avoir un mĂ©canisme de journalisation partout disponibles.

Pendant qu'on parle de chiffrement, une autre question est celle de l'identification d'une machine ou d'un protocole par le fingerprinting, c'est-à-dire en observant des informations non chiffrées (taille des paquets, temps de réponse, variations permises par le protocole, etc). Le fingerprinting pose évidemment des gros risques pour la vie privée et beaucoup de travaux sur des protocoles récents (comme QUIC) visaient à limiter son efficacité.

Pour rĂ©sumer l'atelier (section 6 du RFC), plusieurs projets ont Ă©tĂ© lancĂ©s pour travailler sur des points soulevĂ©s dans l'atelier. À suivre, donc.

❌