Mon blog

Le RFC 8955 spécifie comment utiliser BGP pour diffuser des règles de filtrage (dites « FlowSpec ») aux routeurs. On voit facilement qu'une annonce de règles de filtrage maladroite ou malveillante pourrait faire bien des dégâts et c'est pour cela que le RFC 8955 insiste sur l'importance de valider ces annonces. Mais les règles de validation étaient trop strictes et ce nouveau RFC les adoucit légèrement.

Le changement ? Le RFC 8955 imposait que la machine qui annonce une règle de filtrage pour un préfixe de destination donné soit également le routeur suivant (next hop) pour le préfixe en question. Cela limitait l'annonce aux routeurs situés sur le trajet des données. En iBGP (BGP interne à un AS, où les routeurs qui annoncent ne sont pas toujours ceux qui transmettent les paquets), cette règle était trop restrictive. (Pensez par exemple à un réflecteur de routes interne, par exemple géré par le SOC, réflecteur qui n'est même pas forcément un routeur.)

La règle nouvelle, plus libérale, ne concerne que du iBGP, interne à un AS ou à une confédération d'AS (RFC 5065). Entre des AS gérés par des organisations différentes (par exemple un AS terminal informant son opérateur Internet de ses désirs de filtrage), la règle de validation reste inchangée.

Plus formellement, la section 6 du RFC 8955, sur la validation des annonces de filtrage, est modifiée, l'étape « l'annonceur doit être également l'annonceur de la meilleure route » devient « l'annonceur doit être l'annonceur de la meilleure route ou bien le chemin d'AS doit être vide (ou n'inclure que des AS de la confédération, s'il y en a une) ». Le RFC précise également que cette validation relâchée doit pouvoir être désactivée par l'administrateur réseaux (s'ielle sait qu'il n'y aura pas d'annonces de filtrage par un routeur qui n'est pas sur le chemin des paquets). Vous noterez plus bas que, pour l'instant, seul Huawei le permet.

Il y a également un léger changement des règles de validation du chemlin d'AS, pour les cas des serveurs de route (a priori, ils ne relaient pas ce genre d'annonces et peuvent donc les rejeter). Le RFC note que, même avec une validation stricte, certaines faiblesses de BGP permettent quand même dans certains cas à tort l'envoi de règles de filtrage. C'est un problème fondamental du RFC 8955, qui n'est donc pas nouveau.

Les nouvelles règles de ce RFC sont déjà largement mises en œuvre chez les routeurs.

Nous sommes désormais noyés sous les publications qui parlent de l'empreinte environnementale du numérique et notamment de l'Internet. Mais ce nouveau livre est plus approfondi que beaucoup de ces publications et contient des récits intéressants.

Au passage, je ne sais pas si quelqu'un a calculé l'empreinte environnementale des livres qui critiquent l'empreinte environnementale de l'Internet ☺. Plus sérieusement, une bonne partie de ces livres sont juste de l'anti-numérique primaire, par des auteurs nostalgiques d'un passé où seule une minorité d'experts pouvaient décider et s'exprimer, auteurs qui regrettent le bon vieux temps (ils critiquent le numérique mais jamais l'automobile). Ces défauts se retrouvent aussi dans le livre de Guillaume Pitron (par exemple quand il mentionne, même s'il n'insiste pas là-dessus, qu'il faudrait que des autorités décident des usages légitimes de l'Internet) mais heureusement cela ne fait pas la totalité du livre.

Donc, de quoi parle ce livre ? De beaucoup de choses mais surtout des conséquences environnementales et (à la fin) géopolitiques de l'usage de l'Internet. L'auteur insiste sur la matérialité du monde numérique : loin des discours marketing lénifiants sur le « virtuel » ou sur le « cloud », le monde numérique s'appuie sur la matière, des métaux rares, des centrales électriques fonctionnant au charbon ou au nucléaire, des centres de données énormes. Ce discours n'est pas très original, cet argument de la matérialité a été souvent cité ces dernières années mais le poids du discours commercial est tel que beaucoup d'utilisateurs du numérique n'ont pas encore conscience de cette matérialité. Et elle a des conséquences concrètes, notamment en matière environnementale. Le numérique consomme de l'énergie, ce qui a des conséquences (par exemple en matière de relâchement de gaz à effet de serre, qui contribuent au réchauffement planétaire) et des matériaux dont l'extraction se fait dans des conditions souvent terribles et pas seulement pour l'environnement, mais surtout pour les humains impliqués.

Quelle que soit la part réelle du numérique dans les atteintes à l'environnement (les chiffres qui circulent sont assez « doigt mouillé »), il n'y a pas de doute que, face à la gravité du changement climatique, tout le monde devra faire un effort, le numérique comme les autres. Des techniques frugales comme LEDBAT (RFC 6817) ou Gemini sont des briques utiles de cet effort (mais l'auteur ne les mentionne pas).

C'est après que les choses se compliquent. Qui doit agir, où et comment ? Le livre contient beaucoup d'informations intéressantes et de reportages variés et met en avant certaines initiatives utiles. C'est par exemple le cas du Fairphone, un ordiphone conçu pour limiter l'empreinte environnementale et sociale. Beaucoup de critiques ont été émises contre ce projet, notant que les objectifs n'étaient pas forcément atteints, mais je les trouve injustes : une petite société locale n'a pas les mêmes armes qu'un GAFA pour changer le monde, et ses efforts doivent être salués, il vaut mieux ne faire qu'une partie du chemin plutôt que de rester assis à critiquer. C'est à juste titre que le projet Fairphone est souvent cité dans le livre. (Sur ce projet, je recommande aussi l'interview d'Agnès Crepet dans la série audio « L'octet vert ».)

Ces reportages sont la partie la plus intéressante du livre et une bonne raison de recommander sa lecture. Il comprend également une partie géopolitique intéressante, détaillant notamment l'exploitation de plus en plus poussée de l'Arctique (à la fois rendue possible par le changement climatique, et l'aggravant) et les projets gigantesques et pas du tout bienveillants de la Chine. Même si beaucoup de projets (comme le câble Arctic Connect) se sont cassés la figure, bien d'autres projets leur succèdent.

Par contre, le livre ne tient pas les promesses de son sous-titre « Voyage au bout d'un like ». S'il explique rapidement que le simple fait de cliquer sur un bouton « J'aime » va mettre en action de nombreuses machines, parcourir un certain nombre de kilomètres, et écrire dans plusieurs bases de données, il ne détaille pas ce parcours et ne donne pas de chiffres précis. Il est vrai que ceux-ci sont très difficiles à obtenir, à la fois pour des raisons techniques (la plupart des équipements réseau ont une consommation électrique constante et donc déterminer « la consommation d'un Like » n'a donc guère de sens) et politiques (l'information n'est pas toujours disponible et le greenwashing contribue à brouiller les pistes). L'auteur oublie de rappeler la grande faiblesse méthodologique de la plupart des études sur la question, et des erreurs d'ordre de grandeur comme l'affirmation p. 157 que les États-Unis produisent… 640 tonnes de charbon par an n'aident pas à prendre aux sérieux les chiffres.

Mais le livre souffre surtout de deux problèmes : d'abord, il réduit l'utilisation de l'Internet au Like et aux vidéos de chat, souvent citées. D'accord, c'est amusant et, comme beaucoup d'utilisateurs, je plaisante moi-même souvent sur ce thème. Mais la réalité est différente : l'Internet sert à beaucoup d'activités, dont certaines sont cruciales, comme l'éducation, par exemple. L'auteur critique le surdimensionnement des infrastructures par les opérateurs, jugeant qu'il s'agit d'un gaspillage aux conséquences environementales lourdes. Mais il oublie que ce surdimensionnement est au contraire indispensable à la robustesse de l'Internet, comme on l'a bien vu pendant le confinement, avec l'augmentation du trafic (voir le RFC 9075). Outre les pandémies, on pourrait également citer les attaques par déni de service (la cybersécurité est absente du livre), qui sont une excellente raison de surdimensionner les infrastructures.

Et le deuxième problème ? Parce que l'auteur pourrait répondre qu'il est bien conscient de la coexistence d'usages « utiles » et « futiles » de l'Internet et qu'il suggère de limiter les seconds. C'est là qu'est le deuxième problème : qui va décider ? Personnellement, je pense que le sport-spectacle (par exemple les scandaleux jeux olympiques de Paris, monstruosité environnementale) est à bannir des réseaux (et du reste du monde, d'ailleurs). Mais je ne serais probablement pas élu avec un tel programme. Personne n'est d'accord sur ce qui est sérieux et ce qui est futile. Qui va décider ? Des phrases du livre comme le fait d'ajouter « sacro-sainte » devant chaque mention de la neutralité de l'Internet ont de quoi inquiéter. J'avais déjà relevé ce problème dans ma critique du dernier livre de Ruffin. Une décision démocratique sur les usages, pourquoi pas ; mais je vois un risque sérieux de prise de pouvoir par des sages auto-proclamés qui décideraient depuis leurs hauteurs de ce qui est bon pour le peuple ou pas.

Ce nouveau RFC décrit un profil du protocole ACME d'obtention de certificat, profil qui permet de déléguer la demande à un tiers. C'est surtout utile pour le cas où vous sous-traitez l'hébergement de votre site Web (par exemple sur un CDN) : le sous-traitant peut alors demander un certificat, avec sa clé privée à lui, pour un nom de domaine que vous contrôlez et prouver qu'il héberge bien le serveur pour ce nom. Serveurs et clients TLS n'ont pas besoin d'être modifiés (seuls les serveurs et clients ACME le seront), et, bien entendu, le titulaire du nom de domaine garde un complet contrôle et peut, par exemple, révoquer les certificats obtenus par ses sous-traitants.

Ce profil utilise lui-même le profil STAR (Short-Term, Automatically Renewed) décrit dans le RFC 8739 donc faites bien attention à avoir lu le RFC 8739 avant. Le cas typique d'utilisation de ce mécanisme de délégation est le CDN. Un webmestre (l'IdO pour Identifier Owner car il est titulaire du nom de domaine, mettons foobar.example) a un site Web et sous-traite tout ou partie du service à un CDN, appelé ici NDC pour Name Delegation Consumer (et la ressemblance entre les sigles CDN et NDC est volontaire). Le CDN devra pouvoir répondre aux requêtes HTTPS pour www.foobar.example et donc présenter un certificat au nom www.foobar.example. Avec ACME, l'IdO peut obtenir un tel certifiat mais il ne souhaite probablement pas transmettre la clé privée correspondante au NDC. La solution de notre RFC est d'utiliser une extension à ACME, permettant la délégation du nom. Le NDC pourra alors obtenir un certificat STAR (de courte durée de vie, donc) pour www.foobar.example. Pas besoin de partager une clé privée, ni de transmettre des secrets de longue durée de vie (les délégations sont révocables, et les certificats STAR ne durent pas longtemps, le NDC devra renouveller souvent et ça cessera en cas de révocation). C'est l'utilisation typique de la délégation mais d'autres sont possibles (par exemple avec des certificats ordinaires, non-STAR). Le RFC note que la solution de délégation ne modifie qu'ACME, et pas TLS, et qu'elle marche donc avec les clients et serveurs TLS actuels (contrairement à d'autres propositions qui sont étudiées).

Pour que la délégation fonctionne, l'IdO doit avoir un serveur ACME, auquel le NDC devra se connecter, et s'être mis d'accord avec le NDC sur les paramètres à utiliser. C'est donc une étape relativement nouvelle, l'utilisateur d'ACME typique n'ayant qu'un client ACME, seule l'AC a un serveur. Mais c'est quand même plus simple que de monter une AC. Le serveur ACME chez l'IdO ne signera pas de certificats, il relaiera simplement la requête. Quand le NDC aura besoin d'un certificat, il enverra une demande à l'IdO, qui la vérifiera et, devenant client ACME, l'IdO enverra une demande à l'AC. Si ça marche, l'IdO prévient le NDC, et celui-ci récupérera le certificat chez l'AC (par unauthenticated GET, RFC 8739, section 3.4).

Le protocole ACME gagne un nouveau type d'objet, les délégations, qui indiquent ce qu'on permet au NDC. Comme les autres objets ACME, elles sont représentées en JSON et voici un exemple :

{
     "csr-template": {
       "keyTypes": [
         {
           "PublicKeyType": "id-ecPublicKey",
           "namedCurve": "secp256r1",
           "SignatureType": "ecdsa-with-SHA256"
         }
       ],
       "subject": {
         "country": "FR",
         "stateOrProvince": "**",
         "locality": "**"
       },
       "extensions": {
         "subjectAltName": {
           "DNS": [
             "www.foobar.example"
           ]
         },
         "keyUsage": [
           "digitalSignature"
         ],
         "extendedKeyUsage": [
           "serverAuth"
         ]
         }
     }
}
  

(Les champs des extensions comme keyUsage sont dans un nouveau registre IANA ; on peut ajouter des champs, selon la politique « spécification nécessaire ».) Ici, le NDC est autorisé à demander des certificats ECDSA pour le nom www.foobar.example. Quand le NDC enverra sa requête de certificat à l'IdO, il devra inclure cet objet « délégation », que l'IdO pourra comparer avec ce qu'il a configuré pour ce NDC. Voici un exemple partiel, envoyé lors d'un POST HTTPS au serveur ACME de l'IdO :

   {
     "protected": base64url({
       "alg": "ES256",
       "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
       "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
       "url": "https://acme.ido.example/acme/new-order"
     }),
     "payload": base64url({
       "identifiers": [
         {
           "type": "dns",
           "value": "www.foobar.example"
         }
       ],
       "delegation":
         "https://acme.ido.example/acme/delegation/gm0wfLYHBen"
     }),
     "signature":    ...
  

(Le nouveau champ delegation a été placé dans le registre IANA.) Le NDC enverra ensuite le CSR, et l'IdO relaiera la requête vers le serveur ACME de l'AC (moins l'indication de délégation, qui ne regarde pas l'AC).

Quand on utilise un CDN, il est fréquent qu'on doive configurer un alias dans le DNS pour pointer vers un nom indiqué par l'opérateur du CDN. Voici par exemple celui de l'Élysée :

% dig CNAME www.elysee.fr 
...
;; ANSWER SECTION:
www.elysee.fr.		3600 IN	CNAME 3cifmt6.x.incapdns.net.
...

L'extension au protocole ACME spécifiée dans notre RFC permet au NDC d'indiquer cet alias dans sa requête, l'IdO peut alors l'inclure dans sa zone DNS.

Tous les serveurs ACME ne seront pas forcément capables de gérer des délégations, il faudra donc l'indiquer dans les capacités du serveur, avec le champ delegation-enabled (mis dans le registre IANA).

Comme indiqué plus haut, l'IdO peut arrêter la délégation quand il veut, par exemple parce qu'il change de CDN. Cet arrêt se fait par une interruption explicite de la demande STAR (RFC 8739, section 3.1.2). Si les certificats ne sont pas des STAR, le mécanisme à utiliser est la révocation normale des certificats.

Après cet examen du protocole, la section 3 de notre RFC décrit le comportement de l'AC. Il n'y a pas grand'chose à faire pour l'AC (le protocole est entre le NDC et l'IdO) à part à être capable d'accepter des récupérations non authentifiées de certificats (car le NDC n'a pas de compte à l'AC).

On a parlé plus haut du CSR. Il doit se conformer à un certain gabarit, décidé par l'IdO. Ce gabarit est évidemment au format JSON, comme le reste d'ACME. La syntaxe exacte est décrite avec le langage CDDL (RFC 8610) et figure dans l'annexe A ou bien, si vous préférez, avec le langage JSON Schema, utilisé dans l'annexe B. Voici l'exemple de gabarit du RFC :

  {
     "keyTypes": [
       {
         "PublicKeyType": "rsaEncryption",
         "PublicKeyLength": 2048,
         "SignatureType": "sha256WithRSAEncryption"
       },
       {
         "PublicKeyType": "id-ecPublicKey",
         "namedCurve": "secp256r1",
         "SignatureType": "ecdsa-with-SHA256"
       }
     ],
     "subject": {
       "country": "CA",
       "stateOrProvince": "**",
       "locality": "**"
     },
     "extensions": {
       "subjectAltName": {
         "DNS": [
           "abc.ido.example"
         ]
       },
       "keyUsage": [
         "digitalSignature"
       ],
       "extendedKeyUsage": [
         "serverAuth",
         "clientAuth"
       ]
     }
   }

Dans cet exemple, l'IdO impose au NDC un certificat RSA ou ECDSA et rend impérative (c'est le sens des deux astérisques) l'indication de la province et de la ville. L'IdO doit évidemment vérifier que le CSRT reçu se conforme bien à ce gabarit.

Le RFC présente (en section 5) quelques autres cas d'utilisation de cette délégation. Par exemple, un IdO peut déléguer à plusieurs CDN, afin d'éviter que la panne d'un CDN n'arrête tout. Avec la délégation, ça se fait tout seul, chacun des CDN est authentifié, et demande séparément son certificat.

Autre cas rigolo, celui où le CDN délègue une partie du service à un CDN plus petit. Le modèle de délégation ACME peut s'y adapter (le petit CDN demande un certificat au gros, qui relaie à l'IdO…), si les différentes parties sont d'accord.

Enfin, la section 7 du RFC revient sur les propriétés de sécurité de ces délégations. En gros, il faut avoir confiance en celui à qui on délègue car, pendant la durée de la délégation, il pourra faire ce qu'il veut avec le nom qu'on lui a délégué, y compris demander d'autres certificats en utilisant sa délégation du nom de domaine. Il existe quelques mesures techniques que l'IdO peut déployer pour empêcher le NDC de faire trop de bêtises. C'est le cas par exemple des enregistrements DNS CAA (RFC 8659) qui peuvent limiter le nombre d'AC autorisées (voir aussi le RFC 8657).

Je ne connais pas encore d'opérateur de CDN qui mette en œuvre cette solution.

IPv6 souffre de réseaux mal gérés qui se permettent de jeter les paquets ayant des caractéristiques normales, mais qui déplaisent à certains équipements réseau. C'est par exemple le cas des paquets utilisant les en-têtes d'extension. Pourquoi les paquets utilisant ces en-têtes sont-ils souvent jetés ?

Ces en-têtes d'extension (qui n'ont pas d'équivalent en IPv4) sont normalisés dans le RFC 8200, section 4. Ils servent à la fois à des fonctions de base d'IPv6 (comme la fragmentation) et à étendre le protocole si nécessaire. Mais, en pratique, on observe trop souvent que les paquets IPv6 utilisant ces en-têtes d'extension ne passent pas sur certains réseaux. Ce RFC vise à étudier pourquoi, et à expliquer les conséquences. Comme toujours quand on explique un phénomène (la délinquance, par exemple), des gens vont comprendre de travers et croire qu'on justifie le phénomène en question (« expliquer, c’est déjà vouloir un peu excuser », avait stupidement dit un ancien premier ministre français, à propos du terrorisme djihadiste). Le cas est d'autant plus fréquent qu'en français, « comprendre » est ambigu, car il peut désigner l'explication (qui est utile aussi bien aux partisans qu'aux adversaires d'un phénomène) que la justification. Bref, ce RFC explique pourquoi des paquets innocents sont détruits, il ne dit pas qu'il faut continuer à le faire !

La section 4 du RFC explique la différence entre l'en-tête d'un paquet IPv6 et celui d'un paquet de l'ancienne version. Dans les deux versions, le problème est de placer des options dans les en-têtes. Le gros changement est l'utilisation par IPv6 d'un en-tête de taille fixe (40 octets), suivi d'une liste chainée d'en-têtes d'extension permettant d'encoder ces options. Au contraire, IPv4 avait un en-tête de taille variable (entre 20 et 60 octets), avec un champ indiquant sa longueur, champ qu'il fallait lire avant d'accéder à l'en-tête. Le mécanisme d'IPv4 n'était ni pratique, ni rapide, mais celui d'IPv6 n'est pas plus satisfaisant : il faut lire toute la liste chainée (dont la longueur est quelconque et non limitée) si on veut accéder aux informations au-dessus de la couche 3. Ce n'est pas un problème pour les routeurs, à qui la couche 3 suffit (à part le cas de l'en-tête Hop-by-hop options), mais c'est ennuyeux pour les autres boitiers situés sur le chemin, comme les pare-feux. Les évolutions récentes d'IPv6 ont aidé, comme l'obligation que tous les en-têtes d'extension soient dans le premier fragment, si le datagramme est fragmenté (RFC 7112), ou comme l'imposition d'un format commun aux futurs en-têtes d'extension (dans le RFC 6564), mais l'analyse de la liste des en-têtes d'extension reste un travail pénible pour les machines.

Le problème est identifié depuis longtemps. Il est analysé dans l'Internet-Draft draft-taylor-v6ops-fragdrop, dans draft-wkumari-long-headers, dans draft-kampanakis-6man-ipv6-eh-parsing, dans draft-ietf-opsec-ipv6-eh-filtering mais aussi dans des RFC, le RFC 7113 et le RFC 8900. Cela a mené à plusieurs changements dans la norme, je vous renvoie aux RFC 5722, RFC 7045, RFC 8021, etc. Plusieurs changements ont été intégrés dans la dernière révision du RFC principal de la norme, le RFC 8200. Ainsi, celui-ci dispense désormais les routeurs de chercher un éventuel en-tête d'extension Hop-by-hop options.

Parallèlement à ces analyses du protocole, diverses études ont porté sur le phénomène des paquets jetés s'ils contenaient des en-têtes d'extension. Cela a été documenté dans « Discovering Path MTU black holes on the Internet using RIPE Atlas », dans « IPv6 Extension Headers in the Real World v2.0 », également dans « Dealing with IPv6 fragmentation in the DNS » et « Measurement of IPv6 Extension Header Support » ainsi que dans le RFC 7872.

Comment est-ce que les équipements intermédiaires du réseau fonctionnent, et pourquoi est-ce que les en-têtes d'extension IPv6 peuvent parfois les défriser ? La section 6 du RFC rappelle l'architecture de ces machines. Un routeur de cœur de réseau est très différent de l'ordinateur de base, avec son processeur généraliste et sa mémoire de grande taille, ce qui le rend lent, mais souple. Au contraire, la transmission des paquets par le routeur est en général faite par du matériel spécialisé, ASIC ou NPU. (Vous pouvez consulter des explications dans l'exposé fait à l'IETF « Modern Router Architecture for Protocol Designers » et dans l'article « Modern router architecture and IPv6 ».) Avant de transmettre un paquet reçu sur l'interface de sortie, le routeur doit trouver quelle interface utiliser. Une méthode courante est de prendre les N premiers octets du paquet et de les traiter dans une TCAM ou une RLDRAM, où se fera la détermination du saut suivant (et donc de l'interface de sortie). Le choix du nombre N est crucial : plus il est petit, plus le routeur pourra traiter de paquets, mais moins il aura d'information sur le paquet. (En pratique, on observe des N allant de 192 à 384 octets.) Du fait qu'un routeur se limite normalement à la couche Réseau, et que l'en-tête IPv6 a une taille fixe, envoyer simplement les 40 octets de cet en-tête devrait suffire. Mais lisez plus loin : certains routeurs ou autres équipements intermédiaires sont configurés pour regarder au-delà, et voudraient des informations de la couche Transport, plus dure à atteindre.

Une solution, pour les routeurs qui ne lisent qu'un nombre limité d'octets avant de prendre une décision, est de lire les en-têtes d'extension un par un, et de réinjecter le reste du paquet dans le dispositif de traitement. Ça se nomme la recirculation, c'est plus lent, mais ça marche quelle que soit la longueur de la chaîne des en-têtes d'extension.

Comme le routeur comprend toujours un processeur généraliste (ne serait-ce que pour faire tourner les fonctions de contrôle comme SSH et les protocoles de routage), une autre solution serait d'envoyer à ce processeur les paquets « compliqués » (mais lire le RFC 6192 d'abord). L'énorme différence de performance entre le processeur généraliste et les circuits spécialisés fait que ce ne serait pas une solution réaliste sauf pour un trafic très modéré. (Le RFC note que certains routeurs ont trois dispositifs de traitement des paquets, et pas seulement deux comme présenté plus haut : outre le processeur généraliste, qui ne leur sert qu'aux fonctions de contrôle, et des circuits matériels spécialisés, ils ont un dispositif logiciel de transmission des paquets. Plus souple que les circuits spécialisés, il n'est pas forcément plus rapide que le processeur généraliste mais, au moins, il n'interfère pas avec les fonctions de contrôle.)

Bon, on l'a déjà dit, mais cela vaut la peine de le répéter : à part le cas (agaçant) de l'en-tête Hop-by-hop options, un routeur, équipement de couche 3 n'a normalement aucun besoin d'aller regarder tous les en-têtes d'extension (qui sont presque tous pour la machine terminale de destination uniquement). Encore moins de faire du DPI et d'aller chercher des informations dans les couches 4 à 7. Mais la section 7 du RFC explique pourquoi certains routeurs le font quand même (il s'agit d'une description de leurs pratiques, pas une approbation ; beaucoup des raisons données sont mauvaises).

D'abord, la répartition de charge et l'ECMP. Si un routeur peut faire passer un paquet via deux interfaces différentes, laquelle choisir ? Alterner (un coup à gauche, un coup à droite) augmenterait la probabilité d'une arrivée des paquets dans le désordre. On préfère la prédictabilité : tous les paquets d'un même flot doivent suivre le même chemin. Comment déterminer le « flot », notion parfois un peu floue ? En restant dans les couches basses, on peut utiliser uniquement les adresses IP de source et de destination mais elles ne sont pas assez discriminantes. En IPv6, on peut en théorie utiliser l'étiquette de flot (normalisé dans le RFC 6437, ainsi que les RFC 6438 et RFC 7098 pour son utilisation) mais elle n'est pas toujours présente, en partie (encore !) par la faute de middleboxes qui, ignorant ce concept d'étiquette de flot, jetaient les paquets qui en avaient une. (Voir les articles de I. Cunha, «  IPv4 vs IPv6 load balancing in Internet routes » et J. Jaeggli, «  IPv6 flow label: misuse in hashing ».) En pratique, les systèmes qui ont besoin d'identifier les flots utilisent plutôt une heuristique : le tuple à cinq élements {protocole de transport, adresse IP source, adresse IP destination, port source, port destination}. Ce n'est pas parfait mais, en pratique, cela marche à peu près. On voit que cela nécessite d'accéder à de l'information de la couche Transport, les ports. (Cette heuristique a d'autres limites : par exemple elle ne marche pas si une partie de la couche Transport est chiffrée, comme c'est le cas avec QUIC.)

Autre cas où un boitier intermédiaire ressent le besoin d'accéder aux informations des couches supérieures, les ACL. La plupart des pare-feux permettent d'utiliser comme critère de filtrage les numéros de ports, ce qui va nécessiter d'analyser la chaine des en-têtes d'extension IPv6 pour parvenir à la couche Transport. Entre les pare-feux mal faits qui cherchent les informations de la couche Transport immédiatement après l'en-tête fixe (car le programmeur a tout simplement sauté la partie du RFC qui parlait des en-têtes d'extension) et les difficultés posées par le fait, qu'avant le RFC 6564, les en-têtes d'extension inconnus étaient impossibles à analyser, on voit qu'arriver à la couche Transport n'est pas si facile que ça (le RFC dit qu'il est plus compliqué d'analyser IPv6 qu'IPv4, ce qui est très contestable ; mais ce n'est en effet pas plus facile). Cela peut avoir des conséquences en terme de sécurité, par exemple si un méchant ajoute des en-têtes d'extension dans l'espoir que ses paquets ne soient pas correctement identifiés (cf. RFC 7113).

Autre exemple, le réassemblage des paquets fragmentés nécessite un état (mémoriser les fragments en cours de réassemblage), ce qui peut être fatal à la mémoire du pare-feu, notamment en cas d'attaque. Pour les coûts de ce filtrage, voir l'article d'E. Zack « Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests ». Cette difficulté peut encourager les pare-feux à jeter les paquets ayant des en-têtes d'extension, surtout si un administrateur réseaux ignorant dit bien fort « ces en-têtes d'extension ne servent à rien de toute façon » (RFC 7872).

Un problème proche est celui de la protection contre les attaques par déni de service. Filtrer avec les adresses IP peut être fait rès efficacement (cf. RFC 5635) mais ne marche pas, par exemple si l'adresse IP source est usurpée. Une des méthodes utilisées alors est de repérer un motif récurrent dans les paquets envoyés par l'attaquant, et de filtrer sur ce motif (vous pouvez lire ici un exemple avec le DNS). Là encore, des informations au-delà de la couche Réseau sont nécessaires. Toujours en sécurité, les NIDS ont aussi besoin de plus d'informations que ce que fournit la couche Réseau.

Et, bien sûr, comme toute complexité, les en-têtes d'extension augmentent les risques de sécurité, d'autant plus qu'il y a un cercle vicieux : comme ils sont peu utilisés, le code qui les traite est peu testé, donc il y a des bogues, donc ils sont peu utilisés, etc.

Donc, un certain nombre de machines intermédiaires, qui assurent des fonctions allant au-delà de ce que fait un « simple » routeur, ont des problèmes avec les en-têtes d'extension IPv6 et choisissent souvent la solution de facilité, qui est de les jeter systématiquement.

Le protocole NTP utilisait traditionnellement un port bien connu, 123, comme source et comme destination. Cela facilite certaines attaques en aveugle, lorsque l'attaquant ne peut pas regarder le trafic, mais sait au moins quels ports seront utilisés. Pour compliquer ces attaques, ce RFC demande que NTP utilise des numéros de ports aléatoires autant que possible.

NTP est un très vieux protocole (sa norme actuelle est le RFC 5905 mais sa première version date de 1985, dans le RFC 958). Dans son histoire, il a eu sa dose des failles de sécurité. Certaines des attaques ne nécessitaient pas d'être le chemin entre deux machines qui communiquent car elles pouvaient se faire en aveugle. Pour une telle attaque, il faut deviner un certain nombre de choses sur la communication, afin que les paquets de l'attaquant soient acceptés. Typiquement, il faut connaitre les adresses IP source et destination, ainsi que les ports source et destination et le key ID de NTP (RFC 5905, section 9.1). NTP a plusieurs modes de fonctionnement (RFC 5905, sections 2 et 3). Certains nécessitent d'accepter des paquets non sollicités et, dans ce cas, il faut bien écouter sur un port bien connu, en l'occurrence 123. Mais ce n'est pas nécessaire dans tous les cas et notre RFC demande donc qu'on n'utilise le port bien connu que si c'est nécessaire, au lieu de le faire systématiquement comme c'était le cas au début de NTP et comme cela se fait encore trop souvent (« Usage Analysis of the NIST Internet Time Service »). C'est une application à NTP d'un principe général sur l'Internet, documenté dans le RFC 6056 : n'utilisez pas de numéros de port statiques ou prévisibles. Si on suit ce conseil, un attaquant en aveugle aura une information de plus à deviner, ce qui gênera sa tâche. Le fait d'utiliser un port source fixe a valu à NTP un CVE, CVE-2019-11331.

La section 3 du RFC résume les considérations à prendre en compte. L'idée de choisir aléatoirement le port source pour faire face aux attaques en aveugle est présente dans bien d'autres RFC comme le RFC 5927 ou le RFC 4953. Elle est recommandée par le RFC 6056. Un inconvénient possible (mais mineur) est que la sélection du chemin en cas d'ECMP peut dépendre du port source (calcul d'un condensat sur le tuple à cinq élements {protocole, adresse IP source, adresse IP destination, port source, port destination}, avant d'utiliser ce condendat pour choisir le chemin) et donc cela peut affecter les temps de réponse, troublant ainsi NTP, qui compte sur une certaine stabilité du RTT. D'autre part, le port source aléatoire peut gêner certaines stratégies de filtrage par les pare-feux : on ne peut plus reconnaitre un client NTP à son port source. Par contre, un avantage du port source aléatoire est que certains routeurs NAT sont suffisamment bogués pour ne pas traduire le port source s'il fait partie des ports « système » (inférieurs à 1 024), empêchant ainsi les clients NTP situés derrière ces routeurs de fonctionner. Le port source aléatoire résout le problème.

Assez de considérations, passons à la norme. Le RFC 5905, section 9.1, est modifié pour remplacer la supposition qui était faite d'un port source fixe par la recommandation d'un port source aléatoire.

Cela ne pose pas de problème particulier de mise en œuvre. Par exemple, sur un système POSIX, ne pas faire de bind() sur la prise suffira à ce que les paquets associés soient émis avec un port source aléatoirement sélectionné par le système d'exploitation.

À propos de mise en œuvre, où en sont les logiciels actuels ? OpenNTPD n'a jamais utilisé le port source 123 et est donc déjà compatible avec la nouvelle règle. Même chose pour Chrony. Par contre, à ma connaissance, ntpd ne suit pas encore la nouvelle règle.

Les grands AS ont tellement de routeurs BGP qu'ils ne peuvent pas connecter chaque routeur à tous les autres. On utilise alors souvent des réflecteurs de route, un petit nombre de machines parlant BGP auxquelles tout le monde se connecte, et qui redistribuent les routes externes apprises. Mais une machine BGP ne redistribue que les routes qu'elle utiliserait elle-même. Or, le réflecteur risque de faire un choix en fonction de sa position dans le réseau, qui n'est pas la même que celle du routeur « client ». Les routeurs risquent donc d'apprendre du réflecteur des routes sous-optimales (la route optimale étant typiquement celle qui amène à la sortie le plus vite possible, en application de la méthode de la patate chaude). Ce RFC définit une extension de BGP qui va permettre de sélectionner des routes spécifiques à un client, ou à un groupe de clients.

Un petit rappel : un réflecteur de routes (route reflector) fonctionne sur iBGP (Internal BGP), à l'intérieur d'un AS, alors que les serveurs de routes (route server) font de l'eBGP (External BGP), par exemple sur un point d'échange. Ces réflecteurs sont décrits dans le RFC 4456. Ils ne sont pas la seule méthode pour distribuer l'information sur les routes externes à l'intérieur d'un grand AS, mais c'est quand même la solution la plus fréquente.

Le RFC 4456 notait déjà que, vu les coûts attribués aux liens internes à l'AS, le réflecteur ne choisirait pas forcément les mêmes routes que si on avait utilisé un maillage complet. Le routage « de la patate chaude » (qui consiste à essayer de faire sortir le paquet de son réseau le plus vite possible, pour que ce soit un autre qui l'achemine) risque donc de ne pas aussi bien marcher : le point de sortie lorsqu'on utilise le réflecteur sera peut-être plus éloigné que si on avait le maillage complet, surtout si le réflecteur est situé en dehors du chemin habituel des paquets et n'a donc pas la même vision que les routeurs « normaux ». Or, c'est un cas fréquent. Le réflecteur choisira alors des routes qui sont optimales pour lui, mais qui ne le sont pas pour ces routeurs « normaux ».

La solution ? Permettre à l'administrateur réseaux de définir une localisation virtuelle pour le réflecteur, à partir de laquelle il fera ses calculs et choisira ses routes, au lieu d'utiliser sa localisation physique. Cette localisation virtuelle sera une adresse IP. Le réflecteur peut avoir plusieurs de ces localisations virtuelles, adaptées à des publics différents. Bref, le texte du RFC 4271 qui concerne la sélection de la meilleure route (section 9.1.2.2 du RFC 4271) est modifié pour remplacer « en fonction du saut suivant » par « en fonction de l'adresse IP configurée dans le réflecteur ».

Pour que cela marche, il faut que le réflecteur ait une vue complète du réseau, pour pouvoir calculer des coûts à partir de n'importe quel point du réseau. C'est possible avec les IGP à état des liens comme OSPF, ou bien avec BGP-LS (RFC 7752).

Et si le réflecteur a plusieurs clients ayant des desiderata différents, par exemple parce qu'ils sont situés à des endroits différents ? Dans ce cas, il doit faire tourner plusieurs processus de décision, chacun configuré avec une localisation vituelle différente.

Les principales marques de routeurs mettent déjà en œuvre ce RFC, comme on peut le voir sur la liste des implémentations. Du côté des logiciels qui ne sont pas forcément installés sur des routeurs, il semble que BIRD ne sache pas encore faire comme décrit dans ce RFC.

Traditionnellement, le transfert d'une zone DNS depuis le serveur maitre vers ses esclaves se fait en clair. Si l'authentification et l'intégrité sont protégées, par exemple par TSIG, le transfert en clair ne fournit pas de confidentialité. Or on n'a pas forcément envie qu'un tiers puisse lire l'entièreté de la zone. Ce RFC normalise un transfert de zones sur TLS, XoT (zone transfer over TLS). Il en profite pour faire quelques ajustement dans l'utilisation de TCP pour les transferts de zone.

Le RFC fait quarante-deux pages mais le principe est très simple. Au lieu de faire le transfert de zones (aussi nommé AXFR, RFC 5936) directement sur TCP, on le fait sur du TLS, comme le fait DoT (RFC 7858). Le reste du RFC est consacré à des détails pratiques, mais le concept tient en une seule phrase.

Le DNS sur TLS est normalisé depuis cinq ans, mais il ne couvre officiellement que la communication entre la machine terminale et le résolveur. Bien que des essais aient été faits pour communiquer en TLS avec des serveurs faisant autorité, rien n'est encore normalisé. Mais, au fait, est-ce que les transferts de zone ont vraiment besoin de confidentialité ? Le RFC 9076 ne traite pas le problème, le renvoyant aux RFC 5936 (la norme du transfert de zones, qui parle de la possibilité de restreindre ce transfert à des machines autorisées) et au RFC 5155 (qui parle des risques d'énumération de tous les noms d'une zone). Certes, le DNS étant public, tout le monde peut interroger les serveurs faisant autorité, et connaitre ainsi les données associées à un nom de domaine, mais il faut pour cela connaitre les noms. Si les petites zones n'ont rien de secret (elles ne contiennent que l'apex et www), si certaines zones sont publiques (la racine, par exemple), pour les autres zones, leur responsable ne souhaite pas forcément qu'on ait accès à tous les noms. Certains peuvent être le nom d'une personne (le-pc-de-henri.zone.example), et donc être des données personnelles, à protéger (le RFC note bien sûr que c'est une mauvaise pratique, mais elle existe), certains noms peuvent renseigner sur les activités et les projets d'une entreprise. Bref, il peut être tout à fait raisonnable de ne pas vouloir transmettre la zone en clair.

À noter qu'une surveillance du réseau pendant un transfert de zones fait en clair n'est pas la seule façon de trouver tous les noms. Une autre technique est l'énumération, utilisant par exemple les enregistrement NSEC de DNSSEC. Les enregistrement NSEC3 du RFC 5155 ont été conçus pour limiter ce risque (mais pas le supprimer ; le projet NSEC5 va essayer de résoudre le problème mais c'est loin d'être garanti).

Comment sécurise-t-on les transferts de zone aujourd'hui ? Les TSIG du RFC 8945 protègent l'intégrité mais pas la confidentialité. Vous pouvez trouver des détails pratiques sur la sécurisation des transferts de zone, combinant TSIG et ACL, dans un document du NIST en anglais et un document de l'ANSSI en français. On peut aussi en théorie utiliser IPsec entre maitre et esclaves mais cela semble irréaliste. D'où l'idée de base de ce nouveau RFC : mettre le transfert de zones sur TLS. Après tout, on utilise déjà TLS pour sécuriser la communication entre le client final et le résolveur : le protocole DoT, normalisé dans le RFC 7858.

Notre RFC introduit quelques nouveaux acronymes rigolos :

• XFR : couvre à la fois AXFR (RFC 5936) et IXFR (transferts incrémentaux, RFC 1995). Donc, XFR-over-TLS, c'est un transfert de zones, complet ou incrémental, sur TLS.
• XoT : acronyme pour XFR-over-TLS.
• AXoT : AXFR sur TLS.
• IXoT : IXFR sur TLS.

Pour la terminologie liée à la vie privée, voir le RFC 6973.

La section 3 du RFC spécifie le modèle de menace : on veut protéger le transfert de zones contre l'espionnage par un tiers, mais on n'essaie pas de cacher l'existence de la zone, ou le fait que telle machine soit serveur faisant autorité pour la zone. En effet, ces informations peuvent être obtenues facilement en interrogeant le DNS ou, dans le cas d'un maitre caché, en regardant le trafic réseau, sans même en décrypter le contenu.

Les principes de conception de XoT ? Fournir de la confidentialité et de l'authentification grâce à TLS, mais aussi en profiter pour améliorer les performances. Un certain nombre de programmes DNS ne peuvent pas, par exemple, utiliser la même connexion TCP pour plusieurs transferts de zone (même si le RFC 5936 le recommande). Il est difficile de résoudre ce problème sans casser les programmes existants et pas encore mis à jour. Par contre, XoT étant nouveau, il peut spécifier dès le début certains comportements qui améliorent les performances, comme l'utilisation d'une seule connexion pour plusieurs transferts.

Petit rappel de comment fonctionne le transfert de zones (RFC 5936, si vous voulez tous les détails). D'abord, le fonctionnement le plus courant : le serveur maitre (ou primaire) envoie un NOTIFY (RFC 1996) à ses esclaves (ou secondaires). Ceux-ci envoient une requête de type SOA au maitre puis, si le numéro de série récupéré est supérieur au leur, ils lancent l'AXFR sur TCP. Il y a des variations possibles : si le maitre n'envoie pas de NOTIFY ou bien s'ils sont perdus, les esclaves testent quand même de temps en temps le SOA (paramètre Refresh du SOA). Autre variante possible : les esclaves peuvent utiliser IXFR (RFC 1995) au lieu de AXFR pour ne transférer que la partie de la zone qui a changé. Et ils peuvent avoir à se rabattre en AXFR si le maitre ne gérait pas IXFR. Et les messages IXFR peuvent être sur UDP ou sur TCP (en pratique, BIND, NSD et bien d'autres font toujours l'IXFR sur TCP). Bref, il y a plusieurs cas. Les messages NOTIFY et SOA ne sont pas considérés comme sensibles du point de vue de la confidentialité et XoT ne les protège pas.

Maintenant, avec XoT, comment ça se passera (section 6 du RFC) ? Une fois le transfert de zones décidé (via SOA, souvent précédé du NOTIFY), le client (qui est donc le serveur secondaire) doit établir une connexion TLS (1.3 minimum), en utilisant ALPN, avec le nom dot (on notera que c'est donc le même ALPN pour XoT et pour DoT, l'annexe A du RFC explique ce choix). Le port est par défaut le classique 853 de DoT. Le client authentifie le serveur via les techniques du RFC 8310. Le serveur vérifie le client, soit avec des mécanismes TLS (plus sûrs mais plus compliqués à mettre en œuvre), soit avec les classiques ACL. Le client TLS (le serveur DNS esclave) fait ensuite de l'IXFR ou du AXFR classique sur ce canal TLS. Le serveur doit être capable d'utiliser les codes d'erreur étendus du RFC 8914.

Voilà, c'est tout. Maintenant, quelques détails pratiques. D'abord, rappelez-vous qu'il n'existe pas à l'heure actuelle de norme pour du DoT entre résolveur et serveur faisant autorité. Mais il y a des expériences en cours. Ici, par exemple, je fais du DoT avec un serveur faisant autorité pour facebook.com :

% kdig +tls @a.ns.facebook.com.  SOA facebook.com   
;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
...
;; ANSWER SECTION:
facebook.com.       	3600	IN	SOA	a.ns.facebook.com. dns.facebook.com. 1631273358 14400 1800 604800 300

;; Received 86 B
;; Time 2021-09-10 13:35:44 CEST
;; From 2a03:2880:f0fc:c:face:b00c:0:35@853(TCP) in 199.0 ms

Mais on pourrait imaginer des serveurs faisant autorité qui ne fournissent pas ce service, pas encore normalisé, mais qui veulent faire du XoT. Est-ce possible de réserver TLS aux transferts de zone, mais sans l'utiliser pour les requêtes « normales » ? Oui, et dans ce cas le serveur doit répondre REFUSED à ces requêtes normales, avec le code d'erreur étendu 21 (Not supported). Ceci dit, il est difficile de dire comment réagiront les clients ; ils risquent d'ignorer le code d'erreur étendu et de recommencer bêtement (ou au contraire d'arrêter complètement d'utiliser le serveur).

Le but de XoT est de protéger le contenu de la zone contre les regards indiscrets. Mais comme vous le savez, TLS ne dissimule pas la taille des données qui passent entre ses mains et l'observation de cette taille peut donner des informations à un observateur, par exemple la taille des mises à jour en IXFR indique l'activité d'une zone. Le RFC suggère donc de remplir les données. Cela peut nécessiter d'envoyer des réponses vides, ce qui était interdit par les précédents RFC mais est maintenant autorisé.

Et les différentes formes de parallélisme des requêtes que permet le DNS sur TCP (et donc DoT) ? Elles sont décrites dans le RFC 7766. Si elles sont nécessaires pour exploiter le DNS de manière satisfaisante, elles ne sont pas forcément utiles pour XoT et notre RFC explique qu'on n'est pas forcé, par exemple, de permettre le pipelining (envoi d'une nouvelle requête quand la réponse à la précédente n'est pas encore arrivée) quand on fait du XoT. Par contre, comme avec tous les cas où on utilise du DNS sur TCP, il est recommandé de garder les connexions ouvertes un certain temps, par exemple en suivant le RFC 7828.

J'ai parlé plus haut de l'authentification dans une session XoT. La section 9 du RFC revient en détail sur cette question. Quels sont les mécanismes existants pour authentifier un transfert de zones ? Ils diffèrent par les services qu'ils rendent :

• Authentification de la source des données DNS.
• Authentification du correspondant (qui n'est pas forcément la source des données).
• Confidentialité.

Les mécanismes possibles sont :

• TSIG (RFC 8945) ; utiisant des clés partagées (ce qui n'est pas pratique), il permet d'authentifier la source des données.
• SIG(0) (RFC 2931) ; utilisant de la cryptographie asymétrique, il permet d'authentifier la source des données. Ceci dit, il n'est quasiment jamais mis en œuvre dans les programmes DNS.
• TLS en mode « opportuniste » (sans authentification) ; il ne garantit rien, sauf peut-être contre un observateur passif.
• TLS en mode strict (obligation d'authentification du serveur par le client, RFC 8310) ; cela permet l'authentification du correspondant, et la confidentialité (mais ne garantit pas que le correspondant est la vraie source des données).
• TLS mutuel ; le client s'authentifie également.
• ACL fondées sur l'adresse IP ; très répandu, ce mécanisme permet au serveur d'« authentifier » le client. Une faiblesse pour le cas de XoT : le serveur doit accepter l'établissement de la session TLS avant de savoir s'il s'agit de XoT ou de DNS ordinaire sur TLS.
• ZONEMD (RFC 8976) ; ce n'est pas vraiment une technique d'authentification mais elle peut être utile, en combinaison avec XoT.

Quelles sont les mises en œuvres actuelles de XoT ? Une liste existe. Actuellement, il n'y a guère que NSD qui permet le XoT mais le travail est en cours pour d'autres. Voyons comment faire du XoT avec NSD. On télécharge la dernière version (XoT est apparu en 4.3.7), on la compile (pas besoin d'options particulières) et on la configure, par exemple ainsi :

server:
       port: 7053
       ...
       tls-service-key: "server.key"
       tls-service-pem: "server.pem"
       # No TLS service if the port is not explicit in an interface definition
       ip-address: 127.0.0.1@7153
       tls-port: 7153

zone:
        name: "fx"
        zonefile: "fx"
	# NSD 4.3.7 (september 2021) : not yet a way to restrict XoT
        provide-xfr: 127.0.0.1 NOKEY 
  

Ainsi configuré, NSD va écouter sur le port 7153 en TLS. Notons qu'il n'y a pas de moyen de configurer finement : il accepte forcément XoT et les requêtes « normales ». De même, on ne peut pas obliger un client DNS à n'utiliser que XoT. Testons avec kdig, un client DNS qui accepte TLS, d'abord une requête normale :

    
% kdig +tls @localhost -p 7153 SOA fx 
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 11413
...
;; ANSWER SECTION:
fx.                 	600	IN	SOA	ns1.fx. root.fx. 2021091201 604800 86400 2419200 86400
...
;; Time 2021-09-12 11:06:39 CEST
;; From 127.0.0.1@7153(TCP) in 0.2 ms

  

Parfait, tout marche. Et le transfert de zones ?

% kdig +tls @localhost -p 7153 AXFR fx
;; AXFR for fx.
fx.                 	600	IN	SOA	ns1.fx. root.fx. 2021091201 604800 86400 2419200 86400
...
;; Received 262 B (1 messages, 9 records)
;; Time 2021-09-12 11:07:25 CEST
;; From 127.0.0.1@7153(TCP) in 2.3 ms

  

Excellent, nous faisons du XoT. Wireshark nous le confirme :

% tshark -d tcp.port==7153,tls -i lo port 7153
...
4 0.001200185    127.0.0.1 → 127.0.0.1    TLSv1 439 Client Hello
...
6 0.006305031    127.0.0.1 → 127.0.0.1    TLSv1.3 1372 Server Hello, Change Cipher Spec, Application Data, Application Data, Application Data, Application Data
...
10 0.007385823    127.0.0.1 → 127.0.0.1    TLSv1.3 140 Application Data
  

Dans ce cas, on utilisait NSD comme serveur primaire, recevant les clients XoT. Il peut aussi fonctionner comme serveur secondaire et il est alors client XoT. Je n'ai pas testé mais John Shaft l'a fait et en gros la configuration ressemble à :

tls-auth:
   name: un-nom-pour-identifier-ce-bloc
   auth-domain-name: nom-du-serveur-principal
zone:
   ...
   request-xfr: AXFR 2001:db8::1 NOKEY un-nom-pour-identifier-ce-bloc
  

YANG est le langage standard à l'IETF pour décrire des modèles de données, afin de, par exemple, gérer automatiquement des ressources. Ce RFC décrit le module YANG iana-dns-class-rr-type, qui rassemble les définitions des types d'enregistrements DNS.

YANG est normalisé dans le RFC 7950, et d'innombrables RFC décrivent des modules YANG pour de nombreux protocoles. YANG est utilisé par des protocoles de gestion à distance de ressources, comme RESTCONF (RFC 8040) ou NETCONF (RFC 6241). Mais ce RFC est le premier qui va utiliser YANG pour le DNS. L'un des objectifs (à long terme pour l'instant) est d'utiliser RESTCONF ou un équivalent pour gérer des serveurs DNS, résolveurs ou serveurs faisant autorité. (C'est un très vieux projet que cette gestion automatisée et normalisée des serveurs DNS.) Un mécanisme standard de gestion des serveurs nécessite un modèle de données commun, et c'est là que YANG est utile. Notre RFC est encore loin d'un modèle complet, il ne définit que le socle, le type des données que le DNS manipule. C'est la version YANG de deux registres IANA, celui des types d'enregistrements DNS et celui des classes (même si ce dernier concept est bien abandonné aujourd'hui).

Le registre IANA pour le DNS contient treize sous-registres. Le RFC n'en passe que deux en YANG, les classes et les types d'enregistrement. Les autres devront attendre un autre RFC. Les types d'enregistrement sont modélisés ainsi :

typedef rr-type-name {
    type enumeration {
      enum A {
        value 1;
        description
          "a host address";
        reference
          "RFC 1035";
      }
      enum NS {
        value 2;
        description
          "an authoritative name server";
...
  

Et les classes (mais, rappelez-vous, seule la classe IN compte aujourd'hui) :

typedef dns-class-name {
    type enumeration {
      enum IN {
        value 1;
        description
          "Internet (IN)";
        reference
          "RFC 1035";
      }
      enum CH {
        value 3;
        description
          "Chaos (CH)";
        reference
          "D. Moon, 'Chaosnet', A.I. Memo 628, Massachusetts Institute of
Technology Artificial Intelligence Laboratory, June 1981.";
}
...
  

Le module YANG complet se retrouve dans le registre IANA (créé par le RFC 6020).

Le module YANG devra suivre l'actuel registre IANA, qui utilise un autre format. Pour faciliter la synchronisation, le RFC contient une feuille de style XSLT pour convertir l'actuel format, qui est la référence, vers le format YANG. La feuille de style est dans l'annexe A du RFC mais vous avez une copie ici. Voici comment produire et vérifier le module YANG :

% wget https://www.iana.org/assignments/dns-parameters/dns-parameters.xml

% xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml > iana-dns-class-rr-type.yang

% pyang iana-dns-class-rr-type.yang
  

Le moteur XSLT xsltproc fait partie de la libxslt. Le vérificateur YANG Pyang est distribué via GitHub mais on peut aussi l'installer avec pip (pip install pyang).

En général, en informatique, on essaie de diminuer la consommation de mémoire et de processeur des programmes, afin de les rendre plus efficaces. Mais il y a aussi des cas où on va tenter de réduire délibérement l'efficacité d'un programme. C'est le cas des fonctions de condensation qui sont utilisées en sécurité : on ne veut pas faciliter la tâche de l'attaquant. Ainsi, Argon2, spécifié dans ce RFC est volontairement très consommatrice de mémoire et d'accès à cette mémoire. Elle peut être utilisée pour condenser des mots de passe, ou pour des sytèmes à preuve de travail.

L'article original décrivant Argon2 est « Argon2: the memory-hard function for password hashing and other applications » et vous pouvez également lire « Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications ». Notre RFC reprend la description officielle, mais en s'orientant davantage vers les programmeurs et programmeuses qui devront mettre en œuvre cette fonction. Argon2 est conçu pour être memory-hard, c'est-à-dire faire souvent appel à la mémoire de la machine. Cela permet notamment aux ordinateurs classiques de tenir tête aux systèmes à base d'ASIC. (Par exemple, nombreuses sont les chaînes de blocs utilisant des preuves de travail. La fonction utilisée par Bitcoin, SHA-256, conçue pour être simple et rapide, n'est pas memory-hard et le résultat est qu'il y a belle lurette qu'un ordinateur, même rapide, n'a plus aucune chance dans le minage de Bitcoin. Seules les machines spécialisées peuvent rester en course, ce qui contribue à centraliser le minage dans peu de fermes de minage.) Argon2 est donc dur pour la mémoire, comme décrit dans l'article « High Parallel Complexity Graphs and Memory-Hard Functions ». À noter qu'Argon2 est très spécifique à l'architecture x86.

Argon2 se décline en trois variantes, Argon2id (celle qui est recommandée par le RFC), Argon2d et Argon2i. Argon2d a des accès mémoire qui dépendent des données, ce qui fait qu'il ne doit pas être employé si un attaquant peut examiner ces accès mémoire (attaque par canal auxiliaire). Il convient donc pour du minage de cryptomonnaie mais pas pour une carte à puce, que l'attaquant potentiel peut observer en fonctionnement. Argon2i n'a pas ce défaut mais est plus lent, ce qui ne gêne pas pour la condensation de mots de passe mais serait un problème pour le minage. Argon2id, la variante recommandée, combine les deux et est donc à la fois rapide et résistante aux attaques par canal auxiliaire. (Cf. « Tradeoff Cryptanalysis of Memory-Hard Functions », pour les compromis à faire en concevant ces fonctions dures pour la mémoire.) Si vous hésitez, prenez donc Argon2id. La section 4 du RFC décrit plus en détail les paramètres des variantes, et les choix recommandés.

Argon repose sur une fonction de condensation existante (qui n'est pas forcément dure pour la mémoire) et le RFC suggère Blake (RFC 7693).

La section 3 du RFC décrit l'algorithme mais je n'essaierai pas de vous le résumer, voyez le RFC.

La section 5 contient des vecteurs de test si vous voulez programmer Argon2 et vérifier les résultats de votre programme.

La section 7 du RFC revient en détail sur certaines questions de sécurité, notamment l'analyse de la résistance d'Argon2, par exemple aux attaques par force brute.

Quand un FAI modifie la configuration de son réseau IPv6, les routeurs chez les clients finaux, les CPE, ne retransmettent pas toujours rapidement ce changement, ce qui mène parfois à des problèmes de connectivité. Ce RFC décrit ce que doivent faire ces CPE pour minimiser les conséquence négatives d'une rénumérotation d'un réseau.

Le problème est documenté dans le RFC 8978 : par exemple, lorsqu'un routeur chez M. Toutlemonde (une « box ») redémarre et « oublie » sa configuration réseau précédente, si elle a changé chez le FAI entretemps, les machines du réseau local de M. Toutlemonde risquent de continuer à utiliser pendant un certain une ancienne configuration, désormais invalide. Comment éviter cela ?

Notre RFC se penche surtout sur le cas où le routeur de M. Toutlemonde a appris son préfixe IPv6 depuis le FAI via la délégation de préfixe DHCP du RFC 8415, et qu'il retransmet l'information sur ce préfixe dans le réseau local avec le SLAAC du RFC 4862 (via les RA, Router Advertisements, RFC 4861) ou bien DHCP. Les machines terminales sur le réseau local peuvent aussi agir (ce sera dans un futur RFC) mais l'actuel RFC ne concerne que les routeurs. Il consiste en une série d'exigences auxquelles doivent se prêter les routeurs, exigences qui s'ajoutent à celles déjà présentes dans le RFC 7084 ou bien qui modifient des exigences de ce RFC 7084.

Beaucoup de ces exigences nécessitent un mécanisme de stockage d'informations sur le routeur, stockage qui doit survivre aux redémarrages, ce qui ne sera pas évident pour tous les routeurs. Ainsi, le RFC demande que, du côté WAN, le routeur utilise toujours le même identificateur (IAID, Identity Association IDentifier, RFC 8415, section 4.2) en DHCP (pour essayer de garder le même préfixe). Certains routeurs choisissent apparemment l'IAID au hasard à chaque démarrage, ce qui leur obtient un nouveau préfixe. Il vaut mieux le garder, mais cela nécessite qu'il puisse être stocké et mémorisé même en cas de redémarrage. Comme tous les routeurs n'ont pas de mécanisme de stockage stable, les exigences du RFC sont exprimées (dans le langage du RFC 2119) par un SHOULD et pas un MUST.

Autre exigence, qui relève du bon sens, le routeur ne doit pas, lorsqu'il utilise un préfixe du côté LAN (le réseau local), utiliser une durée de vie plus longue (options Preferred Lifetime et Valid Lifetime du message d'information sur le préfixe envoyé par le routeur, RFC 4861, section 4.6.2) que celle qu'il a lui-même appris en DHCP côté WAN. On ne doit pas promettre ce qu'on ne peut pas tenir, la durée du bail DHCP s'impose au routeur et aux annonces qu'il fait sur le réseau local.

Enfin, le routeur ne doit pas, au redémarrage, envoyer systématiquement un abandon du préfixe appris en DHCP (message DHCP RELEASE). Certains routeurs font apparemment cela, ce qui risque de déclencher une renumérotation brutale (RFC 8978).

Lorsque le préfixe change, le routeur devrait aussi signaler cela sur le réseau local. Là encore, cela impose une mémoire, un stockage stable. Il doit se souvenir de ce qu'il a reçu, et annoncé, précédemment, pour pouvoir annoncer sur le réseau local que ces anciens préfixes ne doivent plus être utilisés (cela se fait en annonçant ces préfixes, mais avec une durée de vie nulle). Dans un monde idéal, le routeur sera prévenu des changements de préfixe parce que le FAI réduira la durée de vie de ses baux DHCP, permettant un remplacement ordonné d'un préfixe par un autre. Dans la réalité, on a parfois des renumérotations brutales, sans préavis (RFC 8978). Le routeur doit donc également gérer ces cas.

Tous les gens qui gèrent des réseaux IPv4 savent comment les sécuriser (normalement…). Et pour IPv6 ? Si ce n'est pas un protocole radicalement différent, il a quand même quelques particularités de sécurité. Ce RFC donne des conseils pratiques et concrets sur la sécurisation de réseaux IPv6. (Je le répète, mais c'est juste une nouvelle version d'IP : l'essentiel du travail de sécurisation est le même en v4 et en v6.)

Les différences entre IPv4 et IPv6 sont subtiles (mais, en sécurité, la subtilité compte, des petits détails peuvent avoir de grandes conséquences). Ceci dit, le RFC a tendance à les exagérer. Par exemple, il explique que la résolution d'adresses de couche 3 en adresses de couche 2 ne se fait plus avec ARP (RFC 826) mais avec NDP (RFC 4861). C'est vrai, mais les deux protocoles fonctionnent de manière très proche et ont à peu près les mêmes propriétés de sécurité (en l'occurrence, aucune sécurité). Plus sérieusement, le remplacement d'un champ d'options de taille variable dans IPv4 par les en-têtes d'extension d'IPv6 a certainement des conséquences pour la sécurité. Le RFC cite aussi le cas du NAPT (Network Address and Port Translation, RFC 2663). Souvent appelée à tort NAT (car elle ne traduit pas que l'adresse mais également le port), cette technique est très utilisée en IPv4. En IPv6, on ne fait pas de traduction ou bien on fait du vrai NAT, plus précisement du NPT (Network Prefix Translation, RFC 6296) puisqu'on change le préfixe de l'adresse. La phrase souvent entendue « en IPv6, il n'y a pas de NAT » est doublement fausse : c'est en IPv4 qu'on n'utilise pas le NAT, mais le NAPT, et on peut faire de la traduction d'adresses en IPv6 si on veut. NAT, NAPT ou NPT ne sont évidemment pas des techniques de sécurité mais elles peuvent avoir des conséquences pour la sécurité. Par exemple, toute traduction d'adresse va complexifier le réseau, ce qui introduit des risques. Autre facteur nouveau lié à IPv6 : la plupart des réseaux vont devoir faire de l'IPv4 et de l'IPv6 et les différentes techniques de coexistence de ces deux versions peuvent avoir leur propre impact sur la sécurité (RFC 4942).

La section 2 du RFC est le gros morceau du RFC ; c'est une longue liste de points à garder en tête quand on s'occupe de la sécurité d'un réseau IPv6. Je ne vais pas tous les citer, mais en mentionner quelques-uns qui donnent une bonne idée du travail du ou de la responsable de la sécurité.

D'abord, l'adressage. Aux débuts d'IPv6, l'idée était que les spécificités d'IPv6 comme le SLAAC allaient rendre la renumérotation des réseaux tellement triviale qu'on pourrait changer les adresses souvent. En pratique, ce n'est pas tellement le cas (RFC 7010) et il faut donc prêter attention à la conception de son adressage : on aura du mal à en changer. Heureusement, c'est beaucoup plus facile qu'en IPv4 : l'abondance d'adresses dispense des astuces utilisées en IPv4 pour essayer d'économiser chaque adresse. Par exemple, on peut donner à tous ses sous-réseaux la même longueur de préfixe, quelle que soit leur taille, ce qui simplifie bien les choses (le RFC 6177 est une lecture instructive). Comme en IPv4, les adresses peuvent être liées au fournisseur d'accès (PA, Provider Allocated) ou bien obtenues indépendamment de ce fournisseur (PI, Provider Independent). Le RFC 7381 discute ce cas. Cela peut avoir des conséquences de sécurité. Par exemple, les adresses PA sont en dernier ressort gérées par l'opérateur à qui il faudra peut-être demander certaines actions. Et ces adresses PA peuvent pousser à utiliser la traduction d'adresses, qui augmente la complexité. (D'un autre côté, les adresses PI sont plus difficiles à obtenir, surtout pour une petite organisation.) Ah, et puis, pour les machines terminales, le RFC 7934 rappelle à juste titre qu'il faut autoriser ces machines à avoir plusieurs adresses (il n'y a pas de pénurie en IPv6). Une des raisons pour lesquelles une machine peut avoir besoin de plusieurs adresses est la protection de la vie privée (RFC 8981).

Les gens habitués à IPv4 demandent souvent quel est l'équivalent du RFC 1918 en IPv6. D'abord, de telles adresses privées ne sont pas nécessaires en IPv6, où on ne manque pas d'adresses. Mais si on veut, on peut utiliser les ULA (Unique Local Addresses) du RFC 4193. Par rapport aux adresses privées du RFC 1918, elles ont le gros avantage d'être uniques, et donc d'éviter toute collision, par exemple quand deux organisations fusionnent leurs réseaux locaux. Le RFC 4864 décrit comment ces ULA peuvent être utilisés pour la sécurité.

Au moment de concevoir l'adressage, un choix important est celui de donner ou non des adresses IP stables aux machines. (Ces adresses stables peuvent leur être transmises par une configuration statique, ou bien en DHCP.) Les adresses stables facilitent la gestion du réseau mais peuvent faciliter le balayage effectué par un attaquant pendant une reconnaissance préalable. Contrairement à ce qu'on lit parfois encore, ce balayage est tout à fait possible en IPv6, malgré la taille de l'espace d'adressage, même s'il est plus difficile qu'en IPv4. Le RFC 7707 explique les techniques de balayage IPv6 possibles. Même chose dans l'article « Mapping the Great Void ». Bref, on ne peut pas compter sur la STO et donc, adresses stables ou pas, les machines connectées à l'Internet peuvent être détectées, et doivent donc être défendues.

Cela n'empêche pas de protéger la vie privée des utilisateurs en utilisant des adresses temporaires pour contacter l'extérieur. L'ancien système de configuration des adresses par SLAAC était mauvais pour la vie privée puisqu'il utilisait comme partie locale de l'adresse (l'IID, Interface IDentifier) l'adresse MAC, ce qui permettait d'identifier une machine même après qu'elle ait changé de réseau. Ce système est abandonné depuis longtemps (RFC 8064) au profit d'adresses aléatoires (RFC 8981). Ceci dit, ces adresses aléatoires posent un autre problème : comme elles changent fréquemment, elles ne permettent pas à l'administrateur réseau de suivre les activités d'une machine (c'est bien leur but), et on ne peut plus utiliser de mécanismes comme les ACL. Une solution possible est d'utiliser des adresses qui sont stables pour un réseau donné mais qui ne permettent pas de suivre une machine quand elle change de réseau, les adresses du RFC 7217. C'est dans beaucoup de cas le meilleur compromis. (Le RFC 7721 contient des détails sur les questions de sécurité liées aux adresses IP.)

On peut aussi couper SLAAC (cela peut se faire à distance avec des annonces RA portant le bit M) et n'utiliser que DHCP mais toutes les machines terminales n'ont pas un client DHCP.

En parlant de DHCP, lui aussi pose des problèmes de vie privée (décrits dans le RFC 7824) et si on veut être discret, il est recommandé d'utiliser le profil restreint défini dans le RFC 7844.

Après les adresses, la question des en-têtes d'extension, un concept nouveau d'IPv6. En IPv4, les options sont placées dans l'en-tête, qui a une longueur variable, ce qui complique et ralentit son analyse. En IPv6, l'en-tête a une longueur fixe (40 octets) mais il peut être suivi d'un nombre quelconque d'en-têtes d'extension (RFC 8200, section 4). Si on veut accéder à l'information de couche 4, par exemple pour trouver le port TCP, il faut suivre toute la chaîne d'en-têtes. Ce système était conçu pour être plus facile et plus rapide à analyser que celui d'IPv4, mais à l'usage, ce n'est pas le cas (le RFC estime même que le système d'IPv6 est pire). En partie pour cette raison, certains nœuds intermédiaires jettent tous les paquets IPv6 contenant des en-têtes d'extension (RFC 7872). D'autres croient que la couche Transport suit immédiatement l'en-tête, sans tenir compte de la possibilité qu'il y ait un en-tête d'extension, ce qui fausse leur analyse. L'en-tête d'extension Hop-by-hop options était particulièrement problématique, car devant être traité par tous les routeurs (le RFC 8200 a adouci cette règle).

Pour faciliter la tâche des pare-feux, plusieurs règles ont été ajoutées aux en-têtes d'extension depuis les débuts d'IPv6 : par exemple le premier fragment d'un datagramme doit contenir la totalité des en-têtes d'extension.

À l'interface d'IPv6 et de la couche 2, on trouve quelques problèmes supplémentaires. D'abord, concernant la résolution d'adresses IP en adresses MAC, pour laquelle IPv6 utilise le protocole NDP (Neighbor Discovery Protocol, RFC 4861). NDP partage avec ARP un problème fondamental : n'importe quelle machine du réseau local peut répondre ce qu'elle veut. Par exemple, si une machine demande « qui est 2001:db8:1::23:42:61 ? », toutes les machines locales peuvent techniquement répondre « c'est moi » et donner leur adresse MAC. Ce problème et quelques autres analogues sont documentés dans les RFC 3756 et RFC 6583. DHCP pose le même genre de problèmes, toute machine peut se prétendre serveur DHCP et répondre aux requêtes DHCP à la place du serveur légitime. Pour se prémunir contre les attaques faites par des machines envoyant de faux RA, on peut aussi isoler les machines, par exemple en donnant un /64 à chacune, ou bien en configurant commutateurs ou points d'accès Wifi pour bloquer les communications de machine terminale à machine terminale (celles qui qui ne sont pas destinées au routeur). Le RFC recommande le RA guard du RFC 6105.

Et sur les mobiles ? Un lien 3GPP est un lien point-à-point, l'ordiphone qui est à un bout ne peut donc pas parler aux autres ordiphones, même utilisant la même base. On ne peut parler qu'au routeur (GGSN - GPRS Gateway Support Node, ou bien PGW - Packet GateWay). Pour la même raison, il n'y a pas de résolution des adresses IP et donc pas de risque liés à cette résolution. Ce mécanisme empêche un grand nombre des attaques liées à NDP. Si vous voulez en apprendre plus à ce sujet, il faut lire le RFC 6459.

Le multicast peut être dangereux sur un réseau local, puisqu'il permet d'écrire à des machines qui n'ont rien demandé. Certains réseaux WiFi bloquent le multicast. En IPv6, cela empêche des actions néfastes comme de pinguer ff01::1 (l'adresse multicast qui désigne toutes les machines du réseau local), mais cela bloque aussi des protocoles légitimes comme mDNS (RFC 6762).

Compte-tenu de la vulnérabilité du réseau local, et des risques associés, il a souvent été proposé de sécuriser l'accès à celui-ci et IPv6 dispose d'un protocole pour cela, SEND, normalisé dans le RFC 3971, combiné avec les CGA du RFC 3972. Très difficile à configurer, SEND n'a connu aucun succès, à part dans quelques environnements ultra-sécurisés. On ne peut clairement pas compter dessus.

Voyons maintenant la sécurité du plan de contrôle : les routeurs et le routage (RFC 6192). Les problèmes de sécurité sont quasiment les mêmes en IPv4 et en IPv6, la principale différence étant le mécanisme d'authentification pour OSPF. Un routeur moderne typique sépare nettement le plan de contrôle (là où on fait tourner les protocoles comme OSPF, mais aussi les protocoles de gestion comme SSH qui sert à configurer le routeur) et le plan de transmission, là où se fait la transmission effective des paquets. Le second doit être très rapide, car il fonctionne en temps réel. Il utilise en général du matériel spécialisé, alors que le plan de contrôle est la plupart du temps mis en œuvre avec un processeur généraliste, et un système d'exploitation plus classique. Pas toujours très rapide, il peut être submergé par un envoi massif de paquets. Le plan de contrôle ne gère que les paquets, relativement peu nombreux, qui viennent du routeur ou bien qui y arrivent, le plan de transmission gérant les innombrables paquets que le routeur transmet, sans les garder pour lui. Chaque paquet entrant est reçu sur l'interface d'entrée, le routeur consulte une table qui lui dit quel est le routeur suivant pour ce préfixe IP, puis il envoie ce paquet sur l'interface de sortie. Et le tout très vite.

Notre RFC conseille donc de protéger le plan de contrôle en bloquant le plus tôt possible les paquets anormaux, comme des paquets OSPF qui ne viendraient pas d'une adresse locale au lien, ou les paquets BGP qui ne viennent pas d'un voisin connu. (Mais, bien sûr, il faut laisser passer l'ICMP, essentiel au déboguage et à bien d'autres fonctions.) Pour les protocoles de gestion, il est prudent de jeter les paquets qui ne viennent pas du réseau d'administration. (Tout ceci est commun à IPv4 et IPv6.)

Protéger le plan de contrôle, c'est bien, mais il faut aussi protéger le protocole de routage. Pour BGP, c'est pareil qu'en IPv4 (lisez le RFC 7454). Mais OSPF est une autre histoire. La norme OSPFv3 (RFC 4552) comptait à l'origine exclusivement sur IPsec, dont on espérait qu'il serait largement mis en œuvre et déployé. Cela n'a pas été le cas (le RFC 8504 a d'ailleurs supprimé cette obligation d'IPsec dans IPv6, obligation qui était purement théorique). Le RFC 7166 a pris acte de l'échec d'IPsec en créant un mécanisme d'authentification pour OSPFv3. Notre RFC recommande évidemment de l'utiliser.

Sinon, les pratiques classiques de sécurité du routage tiennent toujours. Ne pas accepter les routes « bogons » (conseil qui n'est plus valable en IPv4, où tout l'espace d'adressage a été alloué), celles pour des adresses réservées (RFC 8190), etc.

Pas de sécurité sans surveillance (c'est beau comme du Ciotti, ça) et journalisation. En IPv6 comme en IPv4, des techniques comme IPFIX (RFC 7011), SNMP (RFC 4293), etc sont indispensables. Comme en IPv4, on demande à son pare-feu, son serveur RADIUS (RFC 2866) et à d'autres équipements de journaliser les évènements intéressants. À juste titre, et même si ça va chagriner les partisans de la surveillance massive, le RFC rappelle que, bien que tout cela soit très utile pour la sécurité, c'est dangereux pour la vie privée, et que c'est souvent, et heureusement, encadré par des lois comme le RGPD. Administrateur réseaux, ne journalise pas tout, pense à tes responsabilités morales et légales !

Bon, mais cela, c'est commun à IPv4 et IPv6. Qu'est-ce qui est spécifique à IPv6 ? Il y a le format textuel canonique des adresses, normalisé dans le RFC 5952, qui permet de chercher une adresse sans ambiguité. Et la mémoire des correspondances adresses IP adresses MAC dans les routeurs ? Elle est très utile à enregistrer, elle existe aussi en IPv4, mais en IPv6 elle est plus dynamique, surtout si on utilise les adresses favorables à la vie privée du RFC 8981. Le RFC recommande de la récupérer sur le routeur au moins une fois toutes les 30 secondes. Et le journal du serveur DHCP ? Attention, en IPv6, du fait de l'existence de trois mécanismes d'allocation d'adresses (DHCP, SLAAC et statique) au lieu de deux en IPv4, le journal du serveur DHCP ne suffit pas. Et puis il ne contiendra pas l'adresse MAC mais un identificateur choisi par le client, qui peut ne rien vous dire. (Ceci dit, avec les machines qui changent leur adresse MAC, DHCPv4 a un problème du même genre.) En résumé, associer une adresse IP à une machine risque d'être plus difficile qu'en IPv4.

Une autre spécificité d'IPv6 est l'existence de nombreuses technologies de transition entre les deux protocoles, technologies qui apportent leurs propres problèmes de sécurité (RFC 4942). Normalement, elles n'auraient dû être que temporaires, le temps que tout le monde soit passé à IPv6 mais, comme vous le savez, la lenteur du déploiement fait qu'on va devoir les supporter longtemps, les réseaux purement IPv6 et qui ne communiquent qu'avec d'autres réseaux IPv6 étant une petite minorité. La technique de coexistence la plus fréquente est la double pile, où chaque machine a à la fois IPv4 et IPv6. C'est la plus simple et la plus propre, le trafic de chaque version du protocole IP étant natif (pas de tunnel). Avec la double pile, l'arrivée d'IPv6 n'affecte pas du tout IPv4. D'un autre côté, il faut donc gérer deux versions du protocole. (Anecdote personnelle : quand j'ai commencé dans le métier, IP était très loin de la domination mondiale, et il était normal, sur un réseau local, de devoir gérer cinq ou six protocoles très différents. Prétendre que ce serait une tâche insurmontable de gérer deux versions du même protocole, c'est considérer les administrateurs réseaux comme très paresseux ou très incompétents.) L'important est que les politiques soient cohérentes, afin d'éviter, par exemple, que le port 443 soit autorisé en IPv4 mais bloqué en IPv6, ou le contraire. (C'est parfois assez difficile à réaliser sans une stricte discipline : beaucoup de pare-feux n'ont pas de mécanisme simple pour indiquer une politique indépendante de la version du protocole IP.)

Notez que certains réseaux peuvent être « double-pile » sans que l'administrateur réseaux l'ait choisi, ou en soit conscient, si certaines machines ont IPv6 activé par défaut (ce qui est fréquent et justifié). Des attaques peuvent donc être menées via l'adresse locale au lien même si aucun routeur du réseau ne route IPv6.

Mais les plus gros problèmes de sécurité liés aux techniques de coexistence/transition viennent des tunnels. Le RFC 6169 détaille les conséquences des tunnels pour la sécurité. Sauf s'ils sont protégés par IPsec ou une technique équivalente, les tunnels permettent bien des choses qui facilitent le contournement des mesures de sécurité. Pendant longtemps, l'interconnexion entre réseaux IPv6 isolés se faisait via des tunnels, et cela a contribué aux légendes comme quoi IPv6 posait des problèmes de sécurité. Aujourd'hui, ces tunnels sont moins nécessaires (sauf si un réseau IPv6 n'est connecté que par des opérateurs archaïques qui n'ont qu'IPv4).

Les tunnels les plus dangereux (mais aussi les plus pratiques) sont les tunnels automatiques, montés sans configuration explicite. Le RFC suggère donc de les filtrer sur le pare-feu du réseau, en bloquant le protocole IP 41 (ISATAP - RFC 5214, 6to4 - RFC 3056, mais aussi 6rd - RFC 5969 - qui, lui, ne rentre pas vraiment dans la catégorie « automatique »), le protocole IP 47 (ce qui bloque GRE, qui n'est pas non plus un protocole « automatique ») et le port UDP 3544, pour neutraliser Teredo - RFC 4380. D'ailleurs, le RFC rappelle plus loin que les tunnels statiques (RFC 2529), utilisant par exemple GRE (RFC 2784), sont plus sûrs (mais IPsec ou équivalent reste recommandé). 6to4 et Teredo sont de toute façon très déconseillés aujourd'hui (RFC 7526 et RFC 3964).

Et les mécanismes de traduction d'adresses ? On peut en effet traduire des adresses IPv4 en IPv4 (le traditionnel NAT, qui est plutôt du NAPT en pratique, puisqu'il traduit aussi le port), ce qui est parfois présenté à tort comme une fonction de sécurité, mais on peut aussi traduire de l'IPv4 en IPv6 ou bien de l'IPv6 en IPv6. Le partage d'adresses que permettent certains usages de la traduction (par exemple le CGNAT) ouvre des problèmes de sécurité bien connus. Les techniques de traduction d'IPv4 en IPv6 comme NAT64 - RFC 6146 ou 464XLAT - RFC 6877 apportent également quelques problèmes, décrits dans leurs RFC.

J'ai parlé plus haut du fait que les systèmes d'exploitation modernes ont IPv6 et l'activent par défaut. Cela implique de sécuriser les machines contre les accès non voulus faits avec IPv6. Du classique, rien de spécifique à IPv6 à part le fait que certains administrateurs système risqueraient de sécuriser les accès via IPv4 (avec un pare-feu intégré au système d'exploitation, par exemple) en oubliant de le faire également en IPv6.

Tous les conseils donnés jusqu'à présent dans cette section 2 du RFC étaient communs à tous les réseaux IPv6. Les sections suivantes s'attaquent à des types de réseau spécifiques à certaines catégories d'utilisateurs. D'abord (section 3), les « entreprises » (en fait, toutes les organisations - RFC 7381, pas uniquement les entreprises capitalistes privées, comme le terme étatsunien enterprise pourrait le faire penser). Le RFC contient quelques conseils de sécurité, proches de ce qui se fait en IPv4, du genre « bloquer les services qu'on n'utilise pas ». (Et il y a aussi le conseil plus évident : bloquer les paquets entrants qui ont une adresses IP source interne et les paquets sortants qui ont une adresse IP source externe.)

Et pour les divers opérateurs (section 4 du RFC) ? C'est plus délicat car ils ne peuvent pas, contrairement aux organisations, bloquer ce qu'ils ne veulent pas (sauf à violer la neutralité, ce qui est mal). Le RFC donne des conseils de sécurisation BGP (identiques à ceux d'IPv4) et RTBH (RFC 5635). Il contient également une section sur l'« interception légale » (le terme politiquement correct pour les écoutes et la surveillance). Légalement, les exigences (et les problèmes qu'elles posent) sont les mêmes en IPv4 et en IPv6. En IPv4, le partage d'adresses, pratique très répandue, complique sérieusement la tâche des opérateurs quand ils reçoivent un ordre d'identifier le titulaire de telle ou telle adresse IP (RFC 6269). En IPv6, en théorie, la situation est meilleure pour la surveillance, une adresse IP n'étant pas partagée. Par contre, l'utilisateur peut souvent faire varier son adresse au sein d'un préfixe /64.

Quand au réseau de l'utilisateur final, il fait l'objet de la section 5. Il n'y a pas actuellement de RFC définitif sur la délicate question de la sécurité de la maison de M. Michu. Notamment, les RFC 6092 et RFC 7084 ne prennent pas position sur la question très sensible de savoir si les routeurs/pare-feux d'entrée de ce réseau devraient bloquer par défaut les connexions entrantes. La sécurité plaiderait en ce sens mais ça casserait le principe de bout en bout.

Voilà, nous avons terminé cette revue du long RFC. Je résumerai mon opinion personnelle en disant : pour la plupart des questions de sécurité, les ressemblances entre IPv4 et IPv6 l'emportent sur les différences. La sécurité n'est donc pas une bonne raison de retarder la migration si nécessaire vers IPv6. J'ai développé cette idée dans divers exposés et articles.

IMAP, protocole d'accès distant à des boites aux lettres n'est pas juste un protocole, c'est tout un écosystème, décrit dans de nombreux RFC. Celui-ci est le socle de la version actuelle d'IMAP, la « 4rev2 ». Elle remplace la précédente version, « 4rev1 » (normalisée dans le RFC 3501). Le principal changement est sans doute une internationalisation plus poussée pour les noms de boites aux lettres et les en-têtes des messages.

Les protocoles traditionnels du courrier électronique, notamment SMTP ne permettaient que d'acheminer le courrier jusqu'à destination. Pour le lire, la solution la plus courante aujourd'hui est en mode client/serveur, avec IMAP, qui fait l'objet de notre RFC. IMAP ne permet pas d'envoyer du courrier, pour cela, il faut utiliser le RFC 6409. IMAP fonctionne sur un modèle où les messages ont plutôt vocation à rester sur le serveur, et où les clients peuvent, non seulement les récupérer mais aussi les classer, les détruire, les marquer comme lus, etc. IMAP permet de tout faire à distance.

Pour apprendre IMAP, il vaut mieux ne pas commencer par le RFC, qui est très riche. (La lecture du RFC 2683 est recommandée aux implémenteurs.) Pourtant, le principe de base est simple. IMAP est client/serveur. Le client se connecte en TCP au serveur, sur le port 143, et envoie des commandes sous forme de texte, comme avec SMTP. Il s'authentifie avec la commande LOGIN, choisit une boite aux lettres avec la commande SELECT, récupère un message avec la commande FETCH. IMAP peut aussi utiliser du TLS implicite, sur le port 993. Voici un exemple de session. Notons tout de suite, c'est un point très important du protocole IMAP, que chaque commande est précédée d'une étiquette (tag, voir les sections 2.2.1 et 5.5 du RFC) arbitraire qui change à chaque commande et qui permet d'associer une réponse à une commande, IMAP permettant d'envoyer plusieurs commandes sans attendre de réponse. Les réponses portent l'étiquette correspondante, ou bien un astérisque s'il s'agit d'un message du serveur non sollicité. Ici, le serveur utilise le logiciel Archiveopteryx :

% telnet imap.example.org imap     
Trying 192.0.2.23...
Connected to imap.example.org.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN COMPRESS=DEFLATE ID LITERAL+ STARTTLS] imap.example.org Archiveopteryx IMAP Server
com1 LOGIN stephane vraimentsecret
com1 OK [CAPABILITY IMAP4rev1 ACL ANNOTATE BINARY CATENATE CHILDREN COMPRESS=DEFLATE CONDSTORE ESEARCH ID IDLE LITERAL+ NAMESPACE RIGHTS=ekntx STARTTLS UIDPLUS UNSELECT URLAUTH] done
com2 SELECT INBOX
* 189 EXISTS
* 12 RECENT
* OK [UIDNEXT 1594] next uid
* OK [UIDVALIDITY 1] uid validity
* FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
* OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft \Seen \*)] permanent flags
com2 OK [READ-WRITE] done

Le serveur préfixe ses réponses par OK si tout va bien, NO s'il ne pas réussi à faire ce qu'on lui demande et BAD si la demande était erronnée (commande inconnue, par exemple). Ici, avec l'étiquette A2 et un Dovecot :

A2 CAVAPAS
A2 BAD Error in IMAP command CAVAPAS: Unknown command (0.001 + 0.000 secs).
  

Si le serveur n'est accessible qu'en TLS implicite (TLS démarrant automatiquement au début, sans STARTTLS), on peut utiliser un client TLS en ligne de commande, comme celui de GnuTLS :

% gnutls-cli -p 993 imap.maison.example
- Certificate[0] info:
- subject `CN=imap.maison.example', issuer `CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc.', serial 0x02e9bf, RSA key 2048 bits, signed using RSA-SHA512, activated `2020-12-14 14:47:42 UTC', expires `2022-12-14 14:47:42 UTC', pin-sha256="X21ApSVQ/Qcb5Q8kgL/YqlH2XuEco/Rs2X2EgkvDEdI="
 ...
- Status: The certificate is trusted. 
- Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)

[À partir d'ici, on fait de l'IMAP]

* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.
A1 LOGIN stephane vraimenttropsecret
A1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY STATUS=SIZE SAVEDATE LITERAL+ NOTIFY SPECIAL-USE] Logged in
A2 SELECT INBOX
...
* 0 EXISTS
* 0 RECENT
A2 OK [READ-WRITE] Select completed (0.002 + 0.000 + 0.001 secs).
...
A14 FETCH 1 (BODY.PEEK[HEADER.FIELDS (SUBJECT)])
* 1 FETCH (BODY[HEADER.FIELDS (SUBJECT)] {17}
Subject: Test

)
A14 OK Fetch completed (0.007 + 0.000 + 0.006 secs).
  

Les commandes IMAP, comme FETCH dans l'exemple ci-dessus, sont décrites dans la section 6 du RFC. Pour tester son serveur IMAP, on peut aussi utiliser fetchmail et lui demander d'afficher toute la session avec -v -v :

 % fetchmail -v -v -u MYLOGIN imap.1and1.fr 
Enter password for MYLOGIN@imap.1and1.fr: 
fetchmail: 6.3.6 querying imap.1and1.fr (protocol auto) at Tue Apr 15 12:00:27 2008: poll started
fetchmail: 6.3.6 querying imap.1and1.fr (protocol IMAP) at Tue Apr 15 12:00:27 2008: poll started
Trying to connect to 212.227.15.141/143...connected.
fetchmail: IMAP< * OK IMAP server ready H mimap3 65564
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ ID STARTTLS CHILDREN QUOTA IDLE NAMESPACE UIDPLUS UNSELECT SORT AUTH=LOGIN AUTH=PLAIN
fetchmail: IMAP< A0001 OK CAPABILITY finished.
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK Begin TLS negotiation.
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Premium Server CA
fetchmail: Server CommonName: imap.1and1.fr
fetchmail: imap.1and1.fr key fingerprint: 93:13:99:6A:3F:23:73:C3:00:37:4A:39:EE:22:93:AB
fetchmail: IMAP> A0003 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ ID CHILDREN QUOTA IDLE NAMESPACE UIDPLUS UNSELECT SORT AUTH=LOGIN AUTH=PLAIN
fetchmail: IMAP< A0003 OK CAPABILITY finished.
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: imap.1and1.fr: upgrade to TLS succeeded.
fetchmail: IMAP> A0004 LOGIN "m39041005-1" *
fetchmail: IMAP< A0004 OK LOGIN finished.
fetchmail: selecting or re-polling default folder
fetchmail: IMAP> A0005 SELECT "INBOX"

En IMAP, un message peut être identifié par un UID (Unique Identifier) ou par un numéro. Le numéro n'est pas global, il n'a de sens que pour une boite donnée, et il peut changer, par exemple si on détruit des messages. L'UID, lui, est stable, au moins pour une session (et de préférence pour toutes). Les messages ont également des attributs (flags). Ceux qui commencent par une barre oblique inverse comme \Seen (indique que le message a été lu), \Answered (on y a répondu), etc, sont obligatoires, et il existe également des attributs optionnels commençant par un dollar comme $Junk (spam). Les fonctions de recherche d'IMAP pourront utiliser ces attributs comme critères de recherche. Les attributs optionnels (keywords) sont listés dans un registre IANA, et on peut en ajouter (le RFC 5788 explique comment).

IMAP a des fonctions plus riches, notamment la possibilité de chercher dans les messages (section 6.4.4 du RFC), ici, on extrait les messages de mai 2007, puis on récupère le sujet du premier message, par son numéro :

com10 SEARCH since 1-May-2007 before 31-May-2007
* SEARCH 12
com10 OK done
com11 FETCH 1 (BODY.PEEK[HEADER.FIELDS (SUBJECT)])
* 1 FETCH (BODY[HEADER.FIELDS (Subject)] {17}
Subject: Rapport sur les fonctions de vue dans Archiveopteryx

)
com11 OK done
  

IMAP 4rev2 est complètement internationalisé et, par exemple, peut gérer des en-têtes en UTF-8, comme décrits dans le RFC 6532, ce qui est une des améliorations par rapport à 4rev1.

Vous noterez dans les réponses CAPABILITY montrées plus haut, que le serveur indique la ou les versions d'IMAP qu'il sait gérer. Il peut donc annoncer 4rev1 et 4rev2, s'il est prêt à gérer les deux. Le client devra utiliser la commande ENABLE pour choisir. S'il choisit 4rev2, le serveur pourra utiliser les nouveautés de 4rev2, notamment dans le domaine de l'internationalisation (noms de boites en UTF-8, alors que 4rev1 savait tout juste utiliser un bricolage basé sur UTF-7).

IMAP 4rev2 est compatible avec 4rev1 (un logiciel de la précédente norme peut interagir avec un logiciel de la nouvelle). Il peut même interagir avec l'IMAP 2 du RFC 1776 (IMAP 3 n'a jamais été publié), cf. RFC 2061.

L'annexe E résume les principaux changements depuis le RFC 3501, qui normalisait IMAP 4rev1 :

• Messages plus grands (taille stockée sur 63 bits et plus seulement 32). Un serveur qui accepte les messages de plus de quatre gigoctets devra donc les masquer aux clients 4rev1 (ou bien trouver une autre stratégie).
• UTF-8 pour les noms de boites et les sujets des messages.
• Incorporation de nombreuses extensions précédemment séparées, trop nombreuses pour que je les cite toutes. Il y a par exemple le BINARY du RFC 3516 ou le LIST-EXTENDED du RFC 5258.
• Beaucoup de clarifications du texte.
• Abandon de certaines choses, aussi, comme le code de réponse UNSEEN de la commande SELECT.
• Application des progrès de la cryptanalyse, donc remplacement de MD5 par SHA-256.
• Suppression de la convention du préfixe « X- », en application du RFC 6648.

La réalisation d'un client ou d'un serveur IMAP soulève plein de problèmes pratiques, que la section 5 de notre RFC traite. Par exemple, les noms des boites aux lettres peuvent être en Unicode, plus précisément le sous-ensemble d'Unicode du RFC 5198 (cela n'était pas possible en 4rev1). Un logiciel doit donc s'attendre à rencontrer de tels noms.

IMAP est mis en œuvre dans de nombreux serveurs comme Dovecot, Courier, ou Archiveopteryx, déjà cité (mais qui semble abandonné). Mais, comme vous l'avez vu dans les exemples de session IMAP cités plus haut, la version de notre RFC, « 4rev2 » n'a pas encore forcément atteint tous les logiciels.

Côté client, on trouve du IMAP dans beaucoup de logiciels, des webmails, des MUA classiques comme mutt, des MUA en ligne de commande comme fetchmail, très pratique pour récupérer son courrier. (Si vous écrivez un logiciel IMAP à partir de zéro, ce RFC recommande la lecture préalable du RFC 2683.)

Il existe également des bibliothèques toutes faites pour programmer son client IMAP à son goût comme imaplib pour Python. Voici un exemple d'un court programme Python qui se connecte à un serveur IMAP, sélectionne tous les messages et les récupère. On note que la bibliothèque a choisi de rester très proche du vocabulaire du RFC :

import imaplib

# Unlike what the documentation says, "host" has no proper default.
connection = imaplib.IMAP4_SSL(host='localhost')                                                                                            
connection.login("stephane", "thisissecret")
connection.select() # Select the default mailbox
typee, data = connection.search(None, "ALL")
for num in data[0].split():
    # Fetches the whole message
    # "RFC822" est le terme traditionnel mais le format des messages
    # est désormais dans le RFC 5322.
    typ, data = connection.fetch(num, '(RFC822)')
    print('Message %s\n%s\n' % (num, data[0][1]))
connection.close()
connection.logout()

Traditionnellement, le routage dans l'Internet se fait sur la base de l'adresse IP de destination. Mais on peut aussi envisager un routage où l'adresse IP source est prise en compte. Ce nouveau RFC étend le protocole de routage Babel en lui ajoutant cette possibilité.

Babel, normalisé dans le RFC 8966 est un protocole de routage à vecteur de distance. Il est prévu par défaut pour du routage IP traditionnel, où le protocole de routage construit une table de transmission qui associe aux préfixes IP de destination le routeur suivant (next hop). Un paquet arrive dans un routeur ? Le routeur regarde dans sa table le préfixe le plus spécifique qui correspond à l'adresse IP de destination (utilisant pour cela une structure de données comme, par exemple, le Patricia trie) et, lorsqu'il le trouve, la table contient les coordonnées du routeur suivant. Par exemple, si une entrée de la table dit que 2001:db8:1:fada::/64 a pour routeur suivant fe80::f816:3eff:fef2:47db%eth0, un paquet destiné à 2001:db8:1:fada::bad:1234 sera transmis à ce fe80::f816:3eff:fef2:47db, sur l'interface réseau eth0. Cette transmission classique a de nombreux avantages : elle est simple et rapide, et marche dans la plupart des cas.

Mais ce mécanisme a des limites. On peut vouloir prendre en compte d'autres critères que l'adresse de destination pour la transmission d'un paquet. Un exemple où un tel critère serait utile est le multihoming. Soit un réseau IP qui est connecté à plusieurs opérateurs, afin d'assurer son indépendance et pour faire face à un éventuel problème (technique ou commercial) chez l'un des opérateurs. La méthode officielle pour cela est d'acquérir des adresses indépendantes du fournisseur et de faire router ces adresses par les opérateurs auxquels on est connectés (par exemple en leur parlant en BGP). Mais avoir de ces adresses PI (Provider-Independent) est souvent difficile. Quand on est passionnée, on y arrive mais ce n'est pas vraiment accessible à tout le monde. On se retrouve donc en général avec des adresses dépendant du fournisseur. C'est par exemple le cas de loin le plus courant pour le particulier, la petite association ou la PME. Dans ce cas, le multihoming est compliqué. Mettons que les deux fournisseurs d'accès se nomment A et B et que chacun nous fournisse un préfixe d'adresses IP. Si une machine interne a deux adresses IP, chacune tirée d'un des préfixes, et qu'elle envoie vers l'extérieur un paquet ayant comme adresse source une adresse de B, que se passe-t-il ? Si le paquet est envoyé via le fournisseur B, tout va bien. Mais s'il est envoyé via le fournisseur A, il sera probablement jeté par le premier routeur de A, puisque son adresse IP source ne sera pas une adresse du fournisseur (RFC 3704 et RFC 8704). Pour éviter cela, il faudrait pouvoir router selon l'adresse IP source, envoyant les paquets d'adresse source A vers le fournisseur A et ceux ayant une adresse source B vers B. En gros, soit l'information de routage influe sur le choix de l'adresse source, soit c'est le choix de l'adresse source qui influe sur le routage. On ne peut pas faire les deux, ou alors on risque une boucle de rétroaction. Ce RFC choisit la deuxième solution.

La première solution serait que la machine émettrice choisisse l'adresse IP source selon que les adresses de destination soient routées vers A ou vers B. Le RFC 3484 explique comment le faire en séquentiel et le RFC 8305 le fait en parallèle (algorithme dit des « globes oculaires heureux »). Mais les systèmes actuels ne savent typiquement pas le faire et, de toute façon, cela ne réglerait pas le cas où le routage change pendant la vie d'une connexion TCP. TCP, contrairement à QUIC ou SCTP, ne supporte pas qu'une adresse IP change en cours de route, sauf à utiliser les extensions du RFC 8684. Une dernière solution serait de laisser les applications gérer cela (cf. RFC 8445) mais on ne peut pas compter que toutes les applications le fassent. Bref, le routage tenant compte de la source reste souvent la meilleure solution.

À part le cas du multihoming, d'autres usages peuvent tirer profit d'un routage selon la source. Ce routage peut simplifier la configuration des tunnels. Il peut aussi être utile dans le cas de l'anycast. Lorsqu'on utilise du routage classique, fondé uniquement sur la destination, il est difficile de prédire quels clients du groupe anycast seront servis par quelle instance du groupe. Cela rend la répartition de charge compliquée (il faut jouer avec les paramètres des annonces BGP, par exemple) et cela pose des problèmes aux protocoles avec état, comme TCP, où un même client doit rester sur la même instance du groupe anycast. (Des utilisations de l'anycast pour des services sans état, comme le DNS sur UDP, n'ont pas ce problème.) Au contraire, avec du routage fait selon la source, chaque instance anycast peut annoncer sa route avec le ou les préfixes IP qu'on veut que cette instance serve.

D'ailleurs, si vous voulez en savoir plus sur le routage selon la source (ou SADR Source-Address Dependent Routing, également appelé SSR pour Source-Specific Routing), vous pouvez lire l'article détaillé des auteurs du RFC, « Source-Specific Routing ». On peut aussi noter que ce routage dépendant de la source n'est pas la même chose qu'un routage décidé par la source (source routing), qui indiquerait une liste de routeurs par où passer. Ici, chaque routeur reste maitre du saut suivant (sur le routage décidé par la source, voir RFC 8354, et un exemple dans le RFC 6554).

Bon, le routage tenant compte de la source est intéressant, OK. Mais, avant de s'y lancer, il faut faire attention à un petit problème, la spécificité des routes. Lorsqu'on route uniquement selon la destination, et que plusieurs routes sont possibles, la règle classique d'IP est celle de la spécificité. La route avec le préfixe le plus spécifique (le plus long) gagne. Mais que se passe t-il si on ajoute l'adresse source comme critère ? Imaginons qu'on ait deux routes, une pour la destination 2001:db8:0:1::/64 et s'appliquant à toutes les sources et une autre route pour toutes les destinations (route par défaut), ne s'appliquant qu'à la source 2001:db8:0:2::/64. On va noter ces deux routes sous forme d'un tuple (destination, source) donc, ici, (2001:db8:0:1::/64, ::/0) et (::/0, 2001:db8:0:2::/64). Pour un paquet venant de 2001:db8:0:2::1 et allant en 2001:db8:0:1::1, quelle est la route la plus spécifique ? Si on considère la spécificité de la destination d'abord, la route choisie sera la (2001:db8:0:1::/64, ::/0). Mais si on regarde la spécificité de la source en premier, ce sera l'autre route, la (::/0, 2001:db8:0:2::/64) qui sera adoptée. Doit-on laisser chaque machine libre de faire du destination d'abord ou du source d'abord ? Non, car tous les routeurs du domaine doivent suivre la même règle, autrement des boucles pourraient se former, un paquet faisant du ping-pong éternel entre un routeur « destination d'abord » et un routeur « source d'abord ». Babel impose donc une règle : pour déterminer la spécificité d'une route, on regarde la destination d'abord. Le choix n'est pas arbitraire, il correspond à des topologies réseau typique, avec des réseaux locaux pour lesquelles on a une route spécifique, et une route par défaut pour tout le reste.

Un autre point important est celui du système de transmission des paquets. Il faut en effet rappeler que le terme « routage » est souvent utilisé pour désigner deux choses très différentes. La première est le routage à proprement parler (routing en anglais), c'est-à-dire la construction des tables de transmission, soit statiquement, soit avec des protocoles de routage comme Babel. La seconde est la transmission effective des paquets qui passent par le routeur (forwarding en anglais). Si on prend un routeur qui tourne sur Unix avec le logiciel babeld, ce dernier assure bien le routage au sens strict (construire les tables de routage grâce aux messages échangés avec les autres routeurs) mais c'est le noyau Unix qui s'occupe de la transmission. Donc, si on veut ajouter des fonctions de routage tenant compte de la source, il ne suffit pas de le faire dans le programme qui fait du Babel, il faut aussi s'assurer que le système de transmission en est capable, et avec la bonne sémantique (notamment l'utilisation de la destination d'abord pour trouver la route la plus spécifique). Si Babel, avec les extensions de ce RFC, tourne sur un système qui ne permet pas cela, il faut se résigner à ignorer les annonces spécifiques à une source. (Pour des systèmes comme Linux, qui permet le routage selon la source mais avec une mauvaise sémantique, puisqu'il utilise la source d'abord pour trouver la route la plus spécifique, la section V-B de l'article des auteurs cité plus haut fournit un algorithme permettant de créer des tables de transmission correctes.)

Le passage du routage classique au routage tenant compte de la source nécessite de modifier les structures de données du protocole de routage, ici Babel (section 3 du RFC). Les différentes structures de données utilisées par une mise en œuvre de Babel doivent être modifiées pour ajouter le préfixe de la source, et plusieurs des TLV dans les messages que s'échangent les routeurs Babel doivent être étendus avec un sous-TLV (RFC 8966, section 4.4) qui contient un préfixe source. La section 5 du RFC détaille les modifications nécessaires du protocole Babel. Les trois types de TLV qui indiquent un préfixe de destination, Updates, Route Requests et Seqno, doivent désormais transporter en plus un sous-TLV indiquant le préfixe source, marqué comme obligatoire (RFC 8966, section 4.4), de façon à ce qu'une version de Babel ne connaissant pas le routage selon la source n'accepte pas des annonces incomplètes. Si une annonce ne dépend pas de l'adresse IP source, il ne faut pas envoyer un sous-TLV avec le préfixe ::/0 mais au contraire ne pas mettre de sous-TLV (les autres versions de Babel accepteront alors l'annonce).

Ainsi, des versions de Babel gérant les extensions de notre RFC 9079 et d'autres qui ne les gèrent pas (fidèles au RFC 8966) pourront coexister sur le même réseau, sans que des boucles de routage ne se forment. En revanche, comme la notion de sous-TLV obligatoire n'est apparue qu'avec le RFC 8966, les vieilles versions de Babel, qui suivent l'ancien RFC 6126, ne doivent pas être sur le même réseau que les routeurs à routage dépendant de la source.

Le nouveau sous-TLV Source Prefix a le type 128 et sa valeur comporte un préfixe d'adresses IP, encodé en {longueur, préfixe}.

Notez que si les routeurs qui font du routage selon la source n'annoncent que des routes ayant le sous-TLV indiquant un préfixe source, les routeurs qui ne gèrent pas ce routage selon la source, et qui ignorent donc cette annonce, souffriront de famine : il n'y aura pas de routes vers certaines destinations, conduisant le routeur à jeter les paquets. Il peut donc être prudent, par exemple, d'avoir une route par défaut sans condition liée à la source, pour ces routeurs qui ignorent cette extension.

Question sécurité, il faut signaler (section 9 du RFC), que cette extension au routage apporte davantage de souplesse, et que cela peut nécessiter une révision des règles de sécurité, si celles-ci supposaient que tous les paquets vers une destination donnée suivaient le même chemin. Ainsi, le filtrage des routes (RFC 8966, annexe C) pourra être inutile si des routes spécifiques à une source sont présentes. Autre supposition qui peut être désormais fausse : une route spécifique à une machine de destination (host route, c'est-à-dire un préfixe /128) n'est plus forcément obligatoire, une autre route pour certaines sources peut prendre le dessus.

Au moins deux mises en œuvre de cette extension existent, dans babeld depuis la version 1.6 (en IPv6 seulement), et dans BIRD depuis la 2.0.2.

Merci à Juliusz Chroboczek pour sa relecture, et pour ses bonnes remarques sur le choix entre le routage selon la source et les autres solutions.

Ce RFC décrit FFV1, un encodage de flux vidéo sans pertes, et sans piège connu, par exemple de brevet.

Certains encodages vidéo font perdre de l'information, c'est-à-dire que, après décompression, on ne retrouve pas tout le flux original. Ces encodages avec pertes tirent profit des limites de l'œil humain (on n'encode pas ce qui ne se voit pas) mais peut poser des problèmes dans certains cas. Par exemple, si on veut stocker une vidéo sur le long terme, il est certainement préférable qu'elle soit aussi « authentique » que possible, et donc encodée sans pertes. Les organisations qui font de l'archivage sur le long terme (comme l'INA) ont tout intérêt à privilégier un format sans pertes et libre, qui sera encore utilisable dans 50 ans, plutôt que de choisir les derniers gadgets à la mode. Si on souhaite faire analyser cette vidéo par autre chose qu'un œil humain, par exemple un programme qui souhaite avoir la totalité des informations, là encore, le « sans perte » est nécessaire. FFV1 est sans perte, pour le plus grand bénéfice de l'archivage et de la science. C'est le premier codec sans perte documenté par l'IETF.

FFV1 ne date pas d'aujourd'hui, et le RFC traite d'un coup trois versions de FFV1 (section 4.2.1) :

• La version 0, qui date de 2006,
• la version 1, de 2009,
• la version 2 qui n'était qu'expérimentale et n'a pas été officiellement utilisée,
• la version 3, la dernière, en 2013.

Le nom FFV1 veut dire « FF Video 1 » et FF est une référence à FFmpeg, le programme de référence (qui a largement précédé la spécification officielle) dont le nom venait de Fast Forward (avance rapide).

Je ne vais pas vous décrire les algorithmes de FFV1, ça dépasse largement mes compétences. Comme le note le RFC, il faut d'abord connaitre le codage par intervalle, et le modèle YCbCr. Je vous renvoie donc à l'article en français d'un des auteurs et bien sûr au RFC lui-même. FFV1 utilise souvent des techniques un peu anciennes, pour éviter les problèmes de brevet.

Le RFC utilise du pseudo-code pour décrire l'encodage FFV1. Ce pseudo-code particulier est assez proche de C. Vous verrez donc du pseudo-code du genre :

    
for (i = 0; i < quant_table_set_count; i++) {      
  states_coded                                     
  if (states_coded) {                              
      for (j = 0; j < context_count[ i ]; j++) {   
          for (k = 0; k < CONTEXT_SIZE; k++) {     
              initial_state_delta[ i ][ j ][ k ]   
          }                                        
      }                                            
  }
}

  

Le type de média video/FFV1 a été enregistré à l'IANA pour les flux encodés en FFV1.

FFV1 décrit un encodage d'un flux vidéo, pas un format de conteneur. Le flux en question doit donc être inclus dans un conteneur, par exemple aux formats AVI, NUT ou Matroska (section 4.3.3 pour les détails de l'inclusion dans chaque format).

Comme pour tout codec utilisé sur le grand méchant Internet, un programme qui lit du FFV1 doit être paranoïaque et ne doit pas supposer que le flux vidéo est forcément correct. Même si le contenu du fichier est délibérement malveillant, le décodeur ne doit pas allouer de la mémoire à l'infini ou boucler sans fin (ou, pire encore, exécuter du code arbitraire par exemple parce qu'il y aura eu un débordement de pile ; FFV1 lui-même ne contient pas de code exécutable). Le RFC (section 6) donne l'exemple d'un calcul de taille d'une image où on multiplie la largeur par la hauteur, sans plus de précautions. Si cela provoque un dépassement d'entier, des tas de choses vilaines peuvent arriver. Un exemple de précaution : FFmpeg a été soumis à des flux FFV1 corrects et à des données aléatoires, tout en étant examiné par Valgrind et le vérificateur de Clang et aucun accès mémoire anormal n'a été détecté.

Question mises en œuvre, FFV1 est suffisamment ancien pour que de nombreux programmes sachent le décoder. L'implémentation de référence est FFmpeg (qui sait aussi encoder en FFV1). Il y a également un décodeur en Go, développé en même temps que la spécification et il y a aussi MediaConch dont le développement a permis de détecter des incohérences entre le projet de spécification et certains programmes. La spécification elle-même a été développée sur GitHub si vous voulez suivre son histoire, et son futur (une version 4 est prévue).

Comme exemple d'une vidéo encodée en FFV1, j'ai pris les 20 premières secondes de mon exposé au FOSDEM 2021. Le fichier (pour 20 secondes de vidéo !) fait 60 mégaoctets : la compression sans perte est évidemment moins efficace que si on accepte les pertes. Le fichier a été produit par FFmpeg (ffmpeg -i retro_gemini.webm -vcodec ffv1 -level 3 -to 00:00:20 retro_gemini.mkv, notez que, si FFV1 lui-même est sans perte, si vous encodez en FFV1 à partir d'un fichier déjà comprimé avec perte, vous ne recupérez évidemment pas ce qui a été perdu). mediainfo vous montre son contenu :

% mediainfo retro_gemini.mkv 
General
...
Format                                   : Matroska
Movie name                               : Gemini, a modern protocol that looks retro
...
DATE                                     : 2021-02-07
EVENT                                    : FOSDEM 2021
SPEAKERS                                 : Stéphane Bortzmeyer

Video
ID                                       : 1
Format                                   : FFV1
Format version                           : Version 3.4
Codec ID                                 : V_MS/VFW/FOURCC / FFV1
Duration                                 : 20 s 0 ms
Bit rate mode                            : Variable
Bit rate                                 : 25.7 Mb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Compression mode                         : Lossless
...
  

Ou bien avec ffprobe :

% fprobe -show_format -show_streams retro_gemini.mkv
...
  Input #0, matroska,webm, from 'retro_gemini.mkv':
  Metadata:
    title           : Gemini, a modern protocol that looks retro
    DATE            : 2021-02-07
...
[STREAM]
index=0
codec_name=ffv1
codec_long_name=FFmpeg video codec #1
codec_type=video
codec_time_base=1/25
codec_tag_string=FFV1
width=1280
height=720
...
  

Merci à Jérôme Martinez pour sa relecture attentive.

Lorsqu'on authentifie un serveur TLS (par exemple un serveur DoT) avec DANE, le client TLS doit utiliser un résolveur DNS validant et tenir compte de son résultat (données validées ou pas), ce qui n'est pas toujours facile, ni même possible dans certains environnements. Ce RFC propose une solution pour cela : une extension à TLS, dnssec_chain, qui permet au serveur TLS d'envoyer l'ensemble des enregistrements DNS pertinents au client, le dispensant ainsi de solliciter un résolveur validant. Toute la cuisine de vérification peut ainsi se faire sans autre canal que TLS.

TLS (normalisé dans les RFC 5246 et RFC 8446) fournit un canal de communication sécurisé, si on a authentifié le serveur situé en face. La plupart du temps, on authentifie via un certificat PKIX (RFC 5280). Dans certains cas, ce n'est pas facile d'utiliser PKIX. Par exemple, pour DoT (RFC 7858), le résolveur DoT n'est typiquement connu que par une adresse IP, alors que le certificat ne contient en général qu'un nom (oui, le RFC 8738 existe, mais n'est pas toujours activé par les autorités de certification). Les serveurs DoT sont souvent authentifiables par DANE (RFC 6698 et RFC 7671). Par exemple, mon résolveur DoT public, dot.bortzmeyer.fr, est authentifiable avec DANE (regardez les données TLSA de _853._tcp.dot.bortzmeyer.fr). Mais DANE dépend de la disponibilité d'un résolveur DNS validant. Diverses raisons font que le client TLS peut avoir du mal à utiliser un résolveur validant, et à récupérer l'état de la validation (toutes les API de résolution de noms ne donnent pas accès à cet état). L'article « Discovery method for a DNSSEC validating stub resolver » donne des informations sur ces difficultés. Bref, devoir récupérer ces enregistrements DANE de manière sécurisée peut être un problème. Et puis utiliser le DNS pour récupérer des données permettant d'authentifier un résolveur DNS pose un problème d'œuf et de poule.

D'où l'idée centrale de ce RFC : le client TLS demande au serveur de lui envoyer ces enregistrements. Le client n'a plus « que » à les valider à partir d'une clé de confiance DNSSEC (typiquement celle de la racine, commune à tout le monde). Le serveur peut aussi, s'il n'utilise pas DANE, renvoyer la preuve de non-existence de ces enregistrements, le client saura alors, de manière certaine, qu'il peut se rabattre sur un autre mécanisme d'authentification. L'extension TLS de notre RFC peut servir à authentifier un certificat complet, ou bien une clé brute (RFC 7250). Dans ce dernier cas, cette extension protège en outre contre les attaques dites « Unknown Key-Share ».

Notez le statut de ce RFC : cette spécification est pour l'instant expérimentale, elle n'a pas vraiment réuni de consensus à l'IETF, mais elle fait partie des solutions proposées pour sécuriser DoT, dans le RFC 8310 (section 8.2.2).

Bon, maintenant, l'extension elle-même (section 2). C'est une extension TLS (ces extensions sont spécifiées dans la section 4.2 du RFC 8446), elle est nommée dnssec_chain et enregistrée dans le registre IANA, avec le code 59. Son champ de données (extension_data) vaut, dans le ClientHello, le port de connexion et, dans le ServerHello, un ensemble d'enregistrements DNS au format binaire du DNS (pour TLS 1.2 ; en 1.3, cet ensemble est attaché au certificat du serveur). Dans le langage de description des données TLS, cela donne, du client vers le serveur :

struct {
    uint16 PortNumber;
} DnssecChainExtension;
  

Et du serveur vers le client :

struct {
    uint16 ExtSupportLifetime;
    opaque AuthenticationChain<1..2^16-1>
} DnssecChainExtension;    
  

(Le ExtSupportLifetime indique que le serveur s'engage à continuer à gérer cette extension pendant au moins ce temps - en heures. Si ce n'est plus le cas avant l'expiration du délai, cela peut indiquer une usurpation par un faux serveur.) Cette extension est donc une forme, assez spéciale, de « DNS sur TLS ». Le client ne doit pas oublier d'envoyer un SNI (RFC 6066), pour que le serveur sache quel nom va être authentifié et donc quels enregistrements DNS renvoyer. Quant au serveur, s'il ne gère pas cette extension, il répond au client avec un ServerHello n'ayant pas l'extension dnssec_chain. Même chose si le serveur accepte l'extension mais, pour une raison ou pour une autre, n'a pas pu rassembler tous les enregistrements DNS.

Et pourquoi le client doit-il indiquer le port auquel il voulait se connecter ? Le serveur le connait, non ? Mais ce n'est pas forcément le cas, soit parce qu'il y a eu traduction de port quelque part sur le chemin, soit parce que le client a été redirigé, par exemple via le type d'enregistrement SVCB. Le port indiqué par le client doit être le port original, avant toute traduction ou redirection.

Revenons à la « chaine », l'ensemble d'enregistrements DNS qui va permettre la validation DANE. Le format est le format binaire habituel du DNS, décrit dans le RFC 1035, section 3.2.1. L'utilisation de ce format, quoiqu'il soit inhabituel dans le monde TLS, permet, entre autres avantages, l'utilisation des bibliothèques logicielles DNS existantes. Le RFC recommande d'inclure dans l'ensemble d'enregistrements une chaine complète, y compris la racine et incluant donc les clés DNSSEC de celle-ci (enregistrements DNSKEY), même si le client les connait probablement déjà. Cela donne par exemple la chaine suivante, pour le serveur www.example.com écoutant sur le port 443. Notez qu'on inclut les signatures (RRSIG) :

• _443._tcp.www.example.com TLSA
• RRSIG(_443._tcp.www.example.com TLSA)
• example.com. DNSKEY
• RRSIG(example.com DNSKEY)
• example.com DS
• RRSIG(example.com DS)
• com DNSKEY
• RRSIG(com DNSKEY)
• com DS
• RRSIG(com DS)
• . DNSKEY
• RRSIG(. DNSKEY)

(L'exemple suppose que _443._tcp.www.example.com et example.com sont dans la même zone.) Voilà, avec tous ces enregistrements, le client peut, sans faire appel à un résolveur DNS validant, vérifier (s'il a confiance dans la clé de la racine) l'authenticité de l'enregistrement DANE (type TLSA) et donc le certificat du serveur. De la même façon, si on n'a pas d'enregistrement TLSA, le serveur peut envoyer les preuves de non-existence (enregistrements NSEC ou NSEC3). Bon, évidemment, dans ce cas, c'est moins utile, autant ne pas gérer l'extension dnssec_chain… Face à ce déni, le client TLS n'aurait plus qu'à se rabattre sur une autre méthode d'authentification.

Le serveur TLS construit la chaine des enregistrements comme il veut, mais pour l'aider, la section 3 du RFC fournit une procédure possible, à partir d'interrogations du résolveur de ce serveur. Une autre possibilité, plus simple pour le serveur, serait d'utiliser les requêtes chainées du RFC 7901 (mais qui n'ont pas l'air très souvent déployées aujourd'hui).

Comme tous les enregistrements DNS, ceux inclus dans l'extension TLS dnssec_chain ont une durée de vie. Et les signatures DNSSEC ont une période de validité (en général plus longue que la durée de vie). Le serveur TLS qui construit l'ensemble d'enregistrements qu'il va renvoyer peut donc mémoriser cet ensemble, dans la limite du TTL et de l'expiration des signatures DNSSEC. Le client TLS peut lui aussi mémoriser ces informations, dans les mêmes conditions.

On a vu plus haut que les données de l'extension TLS incluaient un ExtSupportLifetime qui indiquait combien de temps le client pouvait s'attendre à ce que le serveur TLS continue à gérer cette extension. Car le client peut épingler (pinning) cette information. Cela permet de détecter certaines attaques (« ce serveur gérait l'extension dnssec_chain et ce n'est maintenant plus le cas ; je soupçonne un détournement vers un serveur pirate »). Cet engagement du serveur est analogue au HSTS de HTTPS (RFC 6797) ; dans les deux cas, le serveur s'engage à rester « sécurisé » pendant un temps minimum (mais pas infini, car on doit toujours pouvoir changer de politique). À noter que « gérer l'extension dnssec_chain » n'est pas la même chose que « avoir un enregistrement TLSA », on peut accepter l'extension mais ne pas avoir de données à envoyer (il faudra alors envoyer la preuve de non-existence mentionnée plus haut). Bien sûr, le client TLS est libre de sa politique. Il peut aussi décider d'exiger systématiquement l'acceptation de l'extension TLS dnssec_chain (ce qui, aujourd'hui, n'est réaliste que si on ne parle qu'à un petit nombre de serveurs).

Si un serveur gérait l'extension dnssec_chain mais souhaite arrêter, il doit bien calculer son coup : d'abord réduire ExtSupportLifetime à zéro puis attendre que la durée annoncée dans le précédent ExtSupportLifetime soit écoulée, afin que tous les clients aient arrêté de l'épingler comme serveur à dnssec_chain. Il peut alors proprement stopper l'extension (cf. section 10 du RFC).

Un petit problème se pose si on fait héberger le serveur TLS chez un tiers. Par exemple, imaginons que le titulaire du domaine boulanger.example ait un serveur chez la société JVL (Je Vous Loge) et que server.boulanger.example soit un alias (enregistrement de type CNAME) vers clients.jvl.example. Le client TLS va envoyer server.boulanger.example comme SNI. Il ne sera pas pratique du tout pour JVL de coordonner la chaine d'enregistrements DNS et le certificat. Il est donc conseillé que l'enregistrement TLSA du client soit lui aussi un alias vers un enregistrement TLSA de l'hébergeur. Cela pourrait donner (sans les signatures, pour simplifier la liste) :

• server.boulanger.example CNAME (vers clients.jvl.example)
• _443._tcp.server.boulanger.example CNAME (vers _dane443.node1.jvl.example)
• clients.jvl.example AAAA
• _dane443.node1.jvl.example TLSA

Les deux premiers enregistrements sont gérés par l'hébergé, les deux derniers par l'hébergeur. (La section 9 du RFC explique pourquoi l'enregistrement TLSA de l'hébergeur n'est pas en _443._tcp…)

Comme dit plus haut, le client TLS est maitre de sa politique : il peut exiger l'extension TLS, il peut l'accepter si elle existe, il peut l'ignorer. Si l'authentification par DANE échoue mais que celle par PKIX réussit, ou le contraire, c'est au client TLS de décider, en fonction de sa politique, ce qu'il fait.

Est-ce que le serveur TLS qui gère cette extension doit envoyer la chaine complète de certificats ? S'il veut pouvoir également être identifié avec PKIX, oui. Si non, s'il se contente de DANE et plus précisément de DANE-EE ou DANE-TA (ces deux termes sont définis dans le RFC 7218), il peut envoyer uniquement le certificat du serveur (pour DANE-EE).

Question mise en œuvre, l'excellente bibliothèque ldns a (je n'ai pas testé…) tout ce qu'il faut pour générer et tester ces chaines d'enregistrements DNS. Si vous voulez développer du code pour gérer cette extension, l'annexe A du RFC contient des vecteurs de test qui vous seront probablement bien utiles.

Vous trouvez que le courrier électronique, c'est vieux et ringard, et que les réseaux sociaux avec leurs possibilités de réaction (« J'aime ! », « Je partage ! », « Je rigole ! »), c'est mieux ? Et bien, vous n'êtes pas le seul ou la seule. Ce nouveau RFC normalise un mécanisme pour mettre des réactions courtes et impulsives dans le courrier électronique.

L'idée de base est que, si ce RFC plait et est mis en œuvre par les auteurs de MUA, on verra près du message qu'on lit un menu avec des émojis, et on cliquera dessus, et l'émetteur du message verra sur son propre MUA le message qu'il a envoyé accompagné de ces réactions. (Le RFC ne normalise pas une apparence particulière à ces réactions, cf. section 5.2 pour des idées qui ne sont que des suggestions.)

Bien sûr, on peut déjà répondre à un message avec des émojis dans le corps de la réponse. Mais l'idée est de structurer cette réaction pour permettre une utilisation plus proche de celle des réseaux sociaux, au lieu que la réaction soit affichée comme un message comme les autres. Liée au message originel, cette structuration permettra, par exemple, au MUA de l'émetteur originel de voir le nombre de Likes de son message… (Quant à savoir si c'est utile, c'est une autre histoire…)

Techniquement, cela fonctionnera avec la combinaison des en-têtes Content-Disposition: et In-Reply-To:. Voici un exemple montrant le format d'une réaction (négative…) à un message (le 12345@example.com) :

    
To: author@example.com
From: recipient@example.org
Date: Today, 29 February 2021 00:00:10 -800
Message-id: 56789@example.org
In-Reply-To: 12345@example.com
Subject: Re: Meeting
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: Reaction

👎

  

(Si vous n'avez pas les bons émojis sur votre système, le caractère en question était le pouce vers le bas.) Recevant cette réponse, le MUA de l'auteur (author@example.com) peut rechercher le message 12345@example.com et afficher que recipient@example.org n'est pas enthousiaste.

Le paramètre Reaction pour l'en-tête Content-Disposition: (RFC 2183) a été ajouté au registre IANA.

Le texte dans la partie MIME qui a l'en-tête Content-Disposition: Reaction est une ligne d'émojis. On peut utiliser les séquences d'émojis. Tous les émojis sont utilisables mais le RFC en liste cinq qui sont particulièrement importants car considérés comme la base, le minimum que devrait reconnaitre tout MUA :

• 👍 (pouce vers le haut, approbation),
• 👎 (pouce vers le bas, désapprobation),
• 😀 (bonheur)
• ☹ (mécontentement)
• 😢 (larme)

Notez que le concept de séquence d'émojis n'est pas simple. Ce concept permet d'éviter de normaliser des quantités astronomiques d'émojis, en autorisation la combinaison d'émojis. Il est utilisé entre autres pour les drapeaux nationaux, ainsi le drapeau libanais sera 🇱🇧 (U+1F1F1 qui indique le L du code pays ISO 3166 et U+1F1E7 qui indique le B). Le RFC rappelle qu'écrire du code dans son application pour gérer ces séquences n'est pas raisonnable et qu'il vaut mieux utiliser une bibliothèque Unicode existante.

Les sections 4 et 5 du RFC donnent quelques idées aux auteurs de MUA sur la gestion de ces réactions. Normalement, l'IETF normalise des protocoles, pas des interfaces utilisateur. Mais cela n'interdit pas de parler un peu d'UX dans le RFC, comme indiqué plus haut. En outre, l'interface utilisateur vers le courrier est typiquement assez différente de celle des réseaux sociaux où ce concept de réaction existe. Ainsi, le RFC ne tranche pas sur la question de savoir s'il faut envoyer la réaction uniquement à l'auteur original du message, ou bien à tous les destinataires. Ou bien s'il faut envoyer un message contenant juste la partie Réaction ou si on peut la combiner avec un autre contenu. Et que faire si, depuis la même adresse, on reçoit plusieurs réactions, éventuellement contradictoires ? Ne garder que la dernière (attention, le courrier électronique ne conserve pas l'ordre d'envoi) ? Les additionner ?

Toujours en UX, le RFC note que la réception d'une image dépend beaucoup du récepteur. (Et, contrairement à ce que laisse entendre le RFC, ce n'est pas juste une question de « culture », des personnes de la même « culture » peuvent comprendre différemment la même image.) Il faut donc faire attention aux réactions, qui peuvent être mal comprises. (Ceci dit, c'est exactement pareil avec le texte seul.) Et, comme toujours sur l'Internet, cette possibilité pourra ouvrir de nouveaux problèmes de sécurité (utilisation pour l'hameçonnage ?).

Le bundling est le rassemblement de plusieurs noms de domaine dans un seul lot (bundle) qui va être traité comme un nom unique pour des opérations comme l'enregistrement du nom ou son transfert à un autre titulaire. Il est surtout pratiqué par les registres qui ont beaucoup de noms en écriture chinoise. Ce RFC décrit une extension au protocole d'avitaillement EPP pour pouvoir traiter ces lots.

Le problème n'existe pas qu'en chinois mais ce sont surtout les sinophones qui se sont manifestés à ce sujet, en raison de la possibilité d'écrire le même mot en écriture traditionnelle ou en écriture simplifiée (on parle de variantes : l'ensemble des variantes forme le lot). Pour prendre un exemple non-chinois, PIR avait décidé qu'un nom dans .ngo et dans .ong devaient être dans le même lot. Un registre qui décide que ces deux termes sont équivalents et doivent être gérés ensemble (par exemple, appartenir au même titulaire) les regroupent dans un lot (bundle, ou parfois package). C'est la politique suggérée dans les RFC 3743 et RFC 4290, et le RFC 6927 décrit les pratiques existantes. Par exemple, certains registres peuvent n'autoriser qu'une variante par lot, et bloquer les autres (empêcher leur enregistrement), tandis que d'autres enregistreront tous les noms ensemble. Sans compter bien sûr les registres qui n'ont pas de système de lot du tout. Notre nouveau RFC 9095 ne prend pas position sur ce sujet délicat, il décrit juste un moyen technique de manipuler ces lots avec EPP (RFC 5731).

Les variantes dans un même lot n'ont pas forcément tout en commun. Un registre peut par exemple décider que l'enregistrement des variantes doit être fait par le même titulaire mais qu'un nom du lot peut ensuite être transféré à un autre titulaire. Notre RFC se limite au cas strict où les membres du lot ont presque tous leurs attributs (titulaires, contacts, date d'expiration, peut-être serveurs de noms et, pourquoi pas, clés DNSSEC) en commun.

La lecture du RFC nécessite un peu de terminologie spécifique, décrite dans sa section 2. Par exemple, le RDN (Registered Domain Name) est celui qui a été demandé par le titulaire lors de l'enregistrement, et le BDN (Bundled Domain Name) est un nom qui a été inclus dans le lot, en fonction des règles du registre. Par exemple, si un registre décidait que tout nom avec des traits d'union était équivalent au même nom sans traits d'union, et qu'un titulaire enregistre tarte-poireaux.example (le RDN), alors tartepoireaux.example et tarte-poi-reaux.example seraient des BDN, membres du même lot que le RDN. Dans le modèle de notre RFC, les métadonnées comme la date d'expiration ou comme l'état du domaine sont attachées au RDN, les BDN du lot partageant ces métadonnées.

Notons aussi que le RFC n'envisage que le cas de lots assez petits (par exemple le nom en écriture chinoise traditionnelle et celui en écriture chinoise simplifiée). L'exemple que je donnais avec le trait d'union ne rentre pas tellement dans le cadre de ce RFC car le nombre de BDN est alors beaucoup plus élevé et serait difficile à gérer. (Amusez-vous à calculer combien de variantes de tartepoireaux.example existeraient si un décidait que le trait d'union n'est pas significatif.)

Dans l'extension EPP décrite dans ce RFC, le RDN est représenté (section 5 du RFC) en Unicode (le « U-label ») ou bien en ASCII (le « A-label », la forme « punycodée »). L'élement XML est <b-dn:rdn> (où b-dn est un préfixe possible pour l'espace de noms XML de notre RFC, urn:ietf:params:xml:ns:epp:b-dn). Si le RDN est représenté en ASCII, un attribut XML uLabel permet d'indiquer la version Unicode du nom. Cela donnerait, par exemple, <b-dn:rdn uLabel="实例.example">xn--fsq270a.example</b-dn:rdn>.

Enfin, la section 6 décrit les commandes et réponses EPP pour notre extension. La commande <check> n'est pas modifiée dans sa syntaxe mais le RFC impose que, si un nom qui fait partie d'un lot est envoyé dans la question, la réponse doit contenir le RDN et le BDN. Pour un RDN en sinogrammes, on aurait ainsi la version en écriture traditionnelle et en écriture simplifiée (ici, le nom est disponible à l'enregistrement) :

<response>
  <result code="1000">
    <msg>Command completed successfully</msg>
  </result>
  <resData>
    <domain:chkData
      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:cd>
         <domain:name avail="1">
          xn--fsq270a.example</domain:name>
        </domain:cd>
        <domain:cd>
          <domain:name avail="1">
            xn--fsqz41a.example
          </domain:name>
          <domain:reason>This associated domain name is
            a produced name based on bundle name policy.
          </domain:reason>
        </domain:cd>
    </domain:chkData>
...

  

La commande <info> n'est pas non plus modifiée mais sa réponse l'est, par l'ajout d'un élément <bundle> qui décrit le lot :

<response>
  <result code="1000">
    <msg>Command completed successfully</msg>
  </result>
  <resData>
    <domain:infData
      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:name>xn--fsq270a.example</domain:name>
      <domain:roid>58812678-domain</domain:roid>
      <domain:status s="ok"/>
...
    </domain:infData>
  </resData>
  <extension>
    <b-dn:infData
      xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn">
      <b-dn:bundle>
        <b-dn:rdn uLabel="实例.example">
          xn--fsq270a.example
        </b-dn:rdn>
        <b-dn:bdn uLabel="實例.example">
          xn--fsqz41a.example
        </b-dn:bdn>
      </b-dn:bundle>
    </b-dn:infData>
  </extension>

  

Quand on crée un domaine qui fait partie d'un lot, la commande <create> doit inclure une extension indiquant que le client EPP connait la gestion de lots, et la réponse à <create> lui donnera le BDN. D'une manière analogue, la commande <delete> détruira tout le lot et l'indiquera dans la réponse. La commande <update> fonctionne sur le même principe : elle modifie le RDN et indique dans sa réponse le BDN affecté. La syntaxe complète de cette extension EPP figure dans la section 7 du RFC, sous forme d'un schéma W3C. Par ailleurs, cette extension est enregistrée dans le registre des extensions EPP (celui créé par le RFC 7451).

Un petit mot sur la sécurité, car de nombreux adversaires de l'internationalisation, notamment anglophones, ont critiqué les noms de domaine en Unicode, les accusant de tous les maux : les auteurs du RFC notent que des noms en chinois sont enregistrés depuis plus de quinze ans, et qu'aucun problème particulier n'a été signalé.

Questions mises en œuvre de ce RFC, les registres chinois (comme .cn ou .tw) suivent les principes de ce RFC (l'enregistrement d'un lot) depuis longtemps. CNNIC déploie cette extension EPP. En dehors de la sinophonie, PIR utilise les lots pour .ngo et .ong. Et cette extension EPP est mise en œuvre dans Net::DRI.

Et, comme souvent, il y a un brevet de Verisign sur la technique décrite dans ce RFC. Je ne l'ai pas lu mais il y a des chances qu'il soit sans mérite, comme beaucoup de brevets logiciels.