Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

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


RFC 9156: DNS Query Name Minimisation to Improve Privacy

Date de publication du RFC : Novembre 2021
Auteur(s) du RFC : S. Bortzmeyer (AFNIC), R. Dolmans (NLnet Labs), P. Hoffman (ICANN)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 19 novembre 2021


Protéger la vie privée sur l'Internet nécessite au moins deux techniques : chiffrer les données en transit pour éviter leur lecture par des tiers et minimiser les données qu'on envoie, pour éviter les abus par les récepteurs des données. Ce deuxième point, pourtant bien mis en avant dans la loi Informatique & Libertés ou dans le RGPD est souvent oublié. Ce RFC applique ce principe au DNS : il ne faut pas envoyer aux serveurs faisant autorité le nom de domaine complet mais seulement la partie du nom de domaine qui lui est strictement nécessaire pour répondre, le minimum. Cette norme succède au RFC 7816, qui était purement expérimental alors que cette minimisation de la requête (QNAME minimisation) est désormais une norme. Le principal changement est la recommandation d'utiliser le type de données A (adresse IPv4) et plus NS (serveurs de noms).

Ce principe de minimisation, qui devrait être central dans toute approche de la protection de la vie privée est également exposé dans le RFC 6973, section 6.1. Le DNS violait ce principe puisque, traditionnellement, un résolveur DNS qui recevait une demande d'information sur www.foobar.example transmettait aux serveurs faisant autorité la question complète, alors que, par exemple, les serveurs faisant autorité pour la racine ne connaissent que les TLD et que leur demander simplement des informations sur le TLD .example aurait suffi. (Voir le RFC 7626 pour une analyse complète des relations entre le DNS et la vie privée.) Cette tradition (qui ne s'appuyait sur aucune norme technique) est remise en cause par la QNAME minimisation qui demande au contraire qu'on n'envoie aux serveurs faisant autorité que le nom minimal (example à la racine, foobar.example aux serveurs du TLD .example, etc).

Cette minimisation est unilatérale, elle ne nécessite qu'un changement des résolveurs, sans toucher aux serveurs faisant autorité puisqu'elle ne change pas le protocole DNS. Depuis la sortie du RFC 7816, en 2016, elle a été largement déployée (si le résolveur que vous utilisez ne le fait pas, réclamez-le à votre service informatique !).

Le précédent RFC sur cette technique, le RFC 7816 avait le statut d'expérimentation alors que notre RFC 9156 est désormais une norme. En effet, une expérience considérable a été accumulée depuis le RFC 7816, qui a été mis en œuvre dans pratiquement tous les résolveurs, et souvent activé. Le FUD souvent entendu comme quoi la QNAME minimisation allait tuer Internet et des chatons a été largement réfuté. Les leçons tirées sont documentées dans « DNSThought QNAME minimisation results. Using Atlas probes », « Maximizing Qname Minimization: A New Chapter in DNS Protocol Evolution », « Measuring Query Name Minimization » et « A First Look at QNAME Minimization in the Domain Name System ».

Maintenant, la pratique, comment fait-on de la QNAME minimisation ? La question envoyée par le résolveur au serveur faisant autorité comprend un QNAME (Query Name, le nom demandé) et un QTYPE (Query Type, le type de données, par exemple serveur de courrier, adresse IP, texte libre, etc). Avec la QNAME minimisation, le nom doit être le nom le plus court possible. Quand le résolveur interroge un serveur racine, il n'envoie comme QNAME que le TLD, par exemple. Trouver « le plus court possible » n'est pas forcément trivial en raison des coupures de zone. Dans un nom comme miaou.foo.bar.example, foo.bar.example et bar.example font peut-être partie de la même zone (et ont donc les mêmes serveurs faisant autorité) et peut-être pas. Rien dans la syntaxe du nom ne l'indique. Contrairement à une idée fausse et répandue, il n'y a pas forcément une coupure de zone pour chaque point dans le nom. Trouver les coupures de zone est expliqué dans le RFC 2181, section 6. Un résolveur qui valide avec DNSSEC doit savoir trouver ces coupures, pour savoir à qui demander les enregistrements de type DS. Les autres (mais quelle idée, en 2021, d'avoir un résolveur qui ne valide pas) doivent s'y mettre. Si, par exemple, foo.bar.example et bar.example sont dans la même zone, le résolveur qui veut trouver des données associées à miaou.foo.bar.example va envoyer le QNAME example à la racine, puis bar.example au serveur du TLD, puis miaou.foo.bar.example au serveur de bar.example. (Avant la QNAME minimisation, il aurait envoyé le QNAME miaou.foo.bar.example à tout le monde.)

Cela, c'était pour le QNAME. Et le QTYPE ? On peut choisir celui qu'on veut (à l'exception de ceux qui ne sont pas dans la zone, comme le DS), puisque les délégations de zones ne dépendent pas du type. Mais, et c'est un sérieux changement depuis le RFC 7816, notre RFC recommande le type A (ou AAAA), celui des adresses IP, et plus le type NS (les serveurs de noms), que recommandait le RFC 7816. Deux raisons à ce changement :

  • Certaines middleboxes boguées jettent les questions DNS portant sur des types qu'elles ne connaissent pas. Le type A passe à coup sûr.
  • Le but de la QNAME minimisation étant la protection de la vie privée, il vaut mieux ne pas se distinguer et, notamment, ne pas dire franchement qu'on fait de la QNAME minimisation (les requêtes explicites pour le type NS étaient rares). Un serveur faisant autorité, ou un surveillant qui espionne le trafic, ne peut donc pas déterminer facilement si un client fait de la QNAME minimisation.

Vous voyez ici le schéma de la résolution DNS sans la QNAME minimisation puis avec : resolution-dns-sans-qnamemin resolution-dns-avec-qnamemin

Dans certains cas, la QNAME minimisation peut augmenter le nombre de requêtes DNS envoyées par le résolveur. Si un nom comporte dix composants (ce qui arrive dans des domaines ip6.arpa), il faudra dans certains cas dix requêtes au lieu de deux ou trois. Les RFC 8020 et RFC 8198 peuvent aider à diminuer ce nombre, en permettant la synthèse de réponses par le résolveur. Une autre solution est de ne pas ajouter un composant après l'autre en cherchant le serveur faisant autorité mais d'en mettre plusieurs d'un coup, surtout après les quatre premiers composants.

Un algorithme complet pour gérer la QNAME minimisation figure dans la section 3 du RFC.

Notez que, si vous voulez voir si votre résolveur fait de la QNAME minimisation, vous pouvez utiliser tcpdump pour voir les questions qu'il pose mais il y a une solution plus simple, la page Web de l'OARC (dans les DNS features).

Un test avec les sondes RIPE Atlas semble indiquer que la QNAME minimisation est aujourd'hui largement répandue (les deux tiers des résolveurs utilisés par ces sondes) :

% blaeu-resolve --requested 1000 --type TXT   qnamemintest.internet.nl 
["hooray - qname minimisation is enabled on your resolver :)!"] : 651 occurrences 
["no - qname minimisation is not enabled on your resolver :("] : 343 occurrences 
Test #33178767 done at 2021-11-05T14:41:02Z
  

Comme son prédécesseur, ce RFC utilise (prétend Verisign) un brevet. Comme la plupart des brevets logiciels, il n'est pas fondé sur une réelle invention (la QNAME minimisation était connue bien avant le brevet).

Ah, et vous noterez que le développement de ce RFC, par trois auteurs, a été fait sur FramaGit.


Téléchargez le RFC 9156


L'article seul

RFC 9141: Updating References to the IETF FTP Service

Date de publication du RFC : Novembre 2021
Auteur(s) du RFC : R. Danyliw (Software Engineering Institute)
Chemin des normes
Première rédaction de cet article le 19 novembre 2021


L'IETF distribuait un certain nombre de documents en FTP anonyme. Ce service, ftp.ietf.org, va être interrompu. Mais un certain nombre de RFC continuent à le citer comme source. Comme on ne peut pas modifier un RFC après publication, notre RFC 9141 fait la liste des mises à jour à lire pour corriger ces RFC et indiquer la nouvelle source des documents.

FTP, qui avait été le premier protocole de transfert de fichiers de l'Internet, avant même l'adoption de TCP/IP, a été pendant longtemps le principal moyen de copier des fichiers à travers le réseau. Une de ces fonctions, le FTP anonyme (qui n'était en fait pas anonyme du tout) permettait d'accéder aux fichiers, lorsque le serveur le voulait bien, sans avoir de compte sur le serveur. D'immenses archives de logiciels, de documents, d'images, ont été ainsi distribuées pendant des années. Aujourd'hui, FTP n'est guère plus utilisé (entre autres parce qu'il fonctionne en clair, cf. la section 4 sur la sécurité) et maintenir un service FTP anonyme n'a plus guère de sens. D'où la décision de l'IETF en 2020 de fermer le sien (cf. l'annonce). Le plan élaboré à cette occasion (une lecture recommandée sur les détails de cette décision, par exemple les statistiques d'utilisation) notait qu'il y avait trente RFC qui référençaient ce service, le dernier, le RFC 7241, datant de 2014. Tous ces RFC sont donc formellement mis à jour par notre RFC 9141. (Comme le note GuB, « C'est pire que légifrance cette histoire ».)

Par exemple, le RFC 2077 dit « Copies of RFCs are available on: ftp://ftp.isi.edu/in-notes/ » alors qu'il faudra désormais lire « Copies of RFCs are available on: https://www.rfc-editor.org/rfc/ ».

Voici par exemple, pour la nostalgie, le fonctionnement du serveur en novembre 2021, avant sa fermeture. On cherche les archives indiquées par le RFC 5098, et qui sont désormais en https://www.ietf.org/ietf-ftp/ietf-mail-archive/ipcdn/ :

% ncftp ftp.ietf.org    
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).

Copyright (c) 1992-2011 by Mike Gleason.
All rights reserved.

Connecting to 4.31.198.44...                                                                                                            
FTP server ready
Logging in...                                                                                                                           
Anonymous access granted, restrictions apply
Logged in to ftp.ietf.org.                                                                                                              
ncftp / > ls
charter/                         ietf/                            internet-drafts/                 slides/
concluded-wg-ietf-mail-archive/  ietf-mail-archive/               review/                          status-changes/
conflict-reviews/                ietf-online-proceedings/         rfc/                             yang/
ncftp / > 
ncftp / > cd ietf-mail-archive/ipcdn
ncftp /ietf-mail-archive/ipcdn > ls
...
1996-12               1999-07.mail          2001-09.mail          2003-11.mail          2006-01.mail          2008-03.mail
1997-01               1999-08.mail          2001-10.mail          2003-12.mail          2006-02.mail          2008-04.mail
1997-02               1999-09.mail          2001-11.mail          2004-01.mail          2006-03.mail          2008-05.mail
1997-03               1999-10.mail          2001-12.mail          2004-02.mail          2006-04.mail          2008-06.mail
...
  

Téléchargez le RFC 9141


L'article seul

L'offre d'hébergement nua.ge

Première rédaction de cet article le 16 novembre 2021


Je viens de tester un peu l'offre d'hébergement de serveurs Internet Nua.ge de la société Oxeva. Voici quelques retours d'expérience.

(J'ai bénéficié sans frais d'une offre gratuite de lancement mais notez que, pour en profiter, il faut laisser son adresse de courrier et son numéro de carte de crédit. Ceci dit, une panne de la Banque postale à ce moment fait que la carte ne semble pas avoir été enregistrée mais le compte Nua.ge a été créé quand même.) nuage-boite.jpg

Le site Web de gestion est en nua.ge. Il est curieux qu'une entreprise qui communique beaucoup sur son caractère français ait choisi le TLD de la Géorgie. (La même société détient également nuage.fr mais ne l'utilise pas, ce domaine est vide.) Le domaine a deux serveurs de noms, dont l'un est apparemment dans le réseau de la société :

% check-soa -i nua.ge    
ns1.reagi.com.
	195.60.188.254: OK: 2021111501 (1 ms)
ns2.reagi.com.
	87.98.186.69: OK: 2021111501 (5 ms)
  

On notera qu'aucun des deux n'a IPv6 (on ne trouve d'IPv6 nulle part sur ce réseau).

La création du compte est classique (on laisse plein de données personnelles, on reçoit un courrier avec un cookie, on visite le lien indiqué et on a son compte). Il ne semble pas y avoir d'authentification à deux facteurs disponible dans l'onglet « Sécurité » ce qui, pour une offre IaaS, est vraiment problématique.

J'ai ensuite créé une machine virtuelle, utilisant Debian. (Il ne semble pas y avoir de miroir Debian local à l'hébergeur, la machine est configurée pour aller chercher ses paquets sur le serveur Debian par défaut.) Cela n'a pas marché du premier coup (time out d'abord, puis refus d'authentification SSH avec la clé que j'avais donné). Il a fallu contacter le support (par un service de clavardage sur leur site Web) qui a rapidement réagi, détruit la machine et reconstruit une autre, sur laquelle je pouvais me connecter. (Le problème est admis mais pas encore corrigé.)

Ma machine actuelle a l'adresse 185.189.156.205. Et en IPv6 ? Comme dit plus haut, il n'y a d'IPv6 nulle part. En 2021, c'est incroyable (tous les fournisseurs français d'IaaS ont de l'IPv6 depuis longtemps), et rien que pour cela, je ne prolongerai pas l'essai au-delà de la période de test gratuite.

Autre problème, 185.189.156.205 n'est pas la vraie adresse IP de la machine. Les paquets entrants sont NATés vers une adresse privée (RFC 1918). Non seulement cela fait que la machine ne connait pas sa propre adresse IP, mais cela limite les protocoles utilisables à ceux reconnus par le routeur NAT (TCP, UDP et ICMP). Si vous voulez faire du SCTP ou autre protocole de transport, tant pis pour vous. Autant dire qu'on est très loin d'un vrai service IaaS. Voici la liste des protocoles acceptés :

Ajoutez des instances à ce groupe uniquement si votre application nécessite des ouvertures particulières.
Règles	Protocol	Ports	IP Range
Autorise	UDP	0 - 0	0.0.0.0/0
Autorise	TCP	0 - 0	0.0.0.0/0
Autorise	ICMP	0 - 0	0.0.0.0/0

Question sécurité, tout est bloqué par défaut (ce qui n'est pas logique pour un serveur Internet) et il faut mettre la machine dans le groupe de sécurité « Autoriser tout le trafic entrant (non recommandé) » pour qu'on puisse superviser la machine et utiliser ping. Voici avec les sondes RIPE Atlas :

% blaeu-reach -r 200 185.189.156.205
198 probes reported
Test #33426048 done at 2021-11-16T12:53:50Z
Tests: 593 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 67 ms
  

Cette supervision automatique a été très utile, elle a permis de détecter une bogue dans Nua.ge, qui coupe les instances de temps en temps pour deux à trois minutes. (Problème signalé et admis mais pas encore corrigé.)

Question DNS, on note que les machines reçoivent par défaut comme résolveur… celui du géant étatsunien Cloudflare ce qui, là encore, fait très bizarre pour une offre supposée « souveraine » :

% cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 1.1.1.1
nameserver 1.0.0.1
search int.nua.ge
  

Enfin, au moins, comme ça, on a DNSSEC, ce qui n'est pas le cas de tous les résolveurs français.

Je n'ai pas trouvé de moyen de configurer l'enregistrement DNS de type PTR (dans in-addr.arpa), qui m'aurait permis d'avoir un plus joli nom. Ce manque est ennuyeux si on veut héberger un serveur de messagerie.

Je n'ai pas lu les conditions d'utilisation et de gestion des données personnelles mais Aeris l'a fait, donc je vous renvoie à son récit.

Je n'ai pas trop suivi le mécanisme de facturation. Voici l'interface permettant de suivre sa consommation : nuage-conso.png

Je n'ai pas non plus regardé s'il y avait des API disponibles.

Pour résumer : le service fonctionne, mais ne correspond pas à ce que j'attends d'un service IaaS, surtout que le marché français dans ce domaine est très riche et offre bien d'autres solutions. On ne voit pas ce que Nua.ge apporte de nouveau.

Autres articles sur ce service :


L'article seul

Fiche de lecture : Les Fans

Auteur(s) du livre : Mélanie Bourdaa
Éditeur : C&F Éditions
978-2-37662-029-7
Publié en 2021
Première rédaction de cet article le 15 novembre 2021


Ce livre est consacré à l'étude des fans, notamment de série télé. Souvent présentés comme un peu bizarres, monomaniaques, fanatiques (cf. l'étymologie de « fan »), sans « vraie vie » et vivant dans l'imaginaire, les fans sont au contraire des sujets d'études dignes d'intérêt.

J'ai découvert dans ce livre qu'il existait même une catégorie de SHS sur la question, les fan studies. Les fans ne sont pas une nouveauté de l'Internet, l'auteure cite les regroupements de fans de Sherlock Holmes dès le 19e siècle. La thèse de l'auteure est que les fans ne sont pas des abrutis qui suivent passivement une série mais qu'ils interagissent, qu'ils critiquent, qu'ils utilisent la série dans tel ou tel but, par exemple politique (le sous-titre du livre est « publics actifs et engagés »). Le livre parle du militantisme autour des séries (des féministes utilisant Wonder Woman ou Leia comme référence), de création à partir de séries (fanfiction), etc.

J'ai eu du mal avec les références, toutes étatsuniennes. Par exemple, la dernière étude de cas couvre une série dont j'ignorais même l'existence, Wynonna Earp, qui a apparemment un club de fans particulièrement motivé·es et organisé·es. Il est parfois difficile de suivre le livre si on ne connait pas ces séries.

Les fans sont, par définition, passionnés par leur sujet et cela peut mener à des comportements négatifs, par exemple contre les fans d'autres séries, ou contre les fans de la même série, mais qui préfèrent tel personnage plutôt que tel autre. L'auteur parle assez peu de ces aspects néfastes, qu'on peut facilement observer sur Twitter dans l'univers de la téléréalité, avec les insultes et menaces des fans de tel ou tel personnage.

Les fans peuvent aussi s'estimer en droit d'influencer la série et ses futurs épisodes, menant des campagnes, par exemple pour qu'on donne une place plus importante à tel personnage particulièrement apprécié (parfois pour des raisons politiques). Je trouve personnellement que le livre est un peu court sur l'analyse critique de ce phénomène, par exemple lorsqu'il cite des acteurs et actrices de séries qui tiennent publiquement des discours en accord avec celui de leur personnage dans la série : sincérité ou marketing ? Ce n'est pas étudié.

Les fans, on l'a dit, ne sont pas des spectateurs passifs. Une des parties les plus intéressantes du livre est consacré au travail que font certains fans autour de leur série favorite, par exemple en construisant des formidables encyclopédies en ligne comme le Wiki of Ice and Fire (non cité dans le livre, je crois) ou le Battlestar Galactica Museum. Un tel travail, avec ce qu'il implique, non seulement de temps passé, mais également de coordination dans le groupe, et de mentorat des nouveaux, est bien loin de l'image du fan asocial claquemuré dans sa chambre et s'adonnant au binge-watching. Bref si, comme moi, vous ne connaissez pas tellement ce monde des fans, vous apprendrez plein de choses dans ce livre.

Autre article, plus détaillé, sur ce livre, celui de Christine Hébert.


L'article seul

Combinaison d'analyseurs syntaxiques en Elixir avec NimbleParsec

Première rédaction de cet article le 11 novembre 2021


On a souvent besoin en programmation de faire de l'analyse syntaxique, pour vérifier qu'un texte est correct et pour y trouver les éléments qui nous intéressent. (Je ne considère ici que les textes écrits dans un langage formel, l'analyse de la langue naturelle étant une autre histoire.) Une des techniques que je trouve les plus agréables est celle des combinaisons d'analyseurs. Voici un exemple en Elixir, avec le module NimbleParsec.

L'idée de base est simple : on écrit l'analyseur en combinant des analyseurs simples, puis en combinant les combinaisons. Cela se fait par exemple en Haskell avec le module Parsec dont j'ai déjà parlé ici. En Elixir, cela peut se faire avec l'excellent module NimbleParsec qui est plutôt bien documenté.

Commençons par un exemple trivial, des textes composés d'un seul mot, qui ne doit comporter que des lettres ASCII. L'analyseur consistera en un seul analyseur primitif, ascii_string, fourni par NimbleParsec, et qui prend deux arguments, un pour restreindre la liste des caractères autorisés, et l'autre pour indiquer des options comme, ici, le nombre minimal de caractères :

verb = ascii_string([], min: 1)
defparsec :test, verb
  

(Le code complet est en nimbleparsec-1.exs.) On peut alors analyser des chaînes de caractères et voir le résultat. Si je mets dans le code :

IO.inspect Test1.test("foobar")
IO.inspect Test1.test("")
  

La première chaine sera acceptée (on n'a guère mis de restrictions à ascii_string), la seconde refusée (en raison du min: 1) :

{:ok, ["foobar"], "", %{}, {1, 0}, 6}
{:error, "expected ASCII character", "", %{}, {1, 0}, 0}
  

La valeur retournée par l'analyseur est un tuple commençant par un mot qui indique si tout s'est bien passé (:ok ou :error), une liste donnant les termes acceptés (ici, il n'y en a qu'un) si tout s'est bien passé.

On peut utiliser ces résultats dans du code Elixir classique, avec pattern matching :

def print_result(r) do
    case r do
      {:ok, list, _, _, _, _} -> IO.inspect("Tout va bien et j'ai récupéré #{list}")
      {:error, message, _, _, _, _} -> IO.inspect("C'est raté, à cause de #{message}")
    end
end
  

Ah, si vous ne connaissez pas bien Elixir, la méthode « normale » pour utiliser NimbleParsec dans un projet serait de le déclarer en dépendance et d'utiliser Mix pour gérer ces dépendances mais, ici, on va simplifier, on installe NimbleParsec avec Hex et on lance mix avec les bonnes options pour exécuter le code :

% mix archive.install hex NimbleParsec
% mix run --no-mix-exs nimbleparsec-2.exs
"Tout va bien et j'ai récupéré foobar"
"C'est raté, à cause de expected ASCII character"

Contrairement à ce que son nom pourrait faire croire, ascii_string n'accepte pas que des caractères ASCII, mais tout caractère codé sur huit bits. Dans l'exemple ci-dessus, il accepterait des chaines comme « café au lait » (avec le caractère composé et les espaces). Restreignons un peu :

  verb = ascii_string([?a..?z], min: 1)

Cette fois, seuls les caractères entre le petit a et le petit z seront acceptés. Testons :

% mix run --no-mix-exs nimbleparsec-3.exs
{:ok, ["foobar"], "", %{}, {1, 0}, 6}
{:error, "expected ASCII character in the range 'a' to 'z'", "", %{}, {1, 0}, 0}
{:ok, ["caf"], "é au lait", %{}, {1, 0}, 3}

« café au lait » a quand même été accepté car NimbleParsec s'arrête avec succès dès qu'il est satisfait. Deux solutions : tester le troisième membre du tuple (les caractères restants) pour vérifier qu'il est vide ou bien combiner ascii_string avec l'analyseur eos qui indique la fin de la chaine :

  
verb = ascii_string([?a..?z], min: 1)
defparsec :test, verb |> eos

La combinaison se fait avec l'opérateur classique de séquencement en Elixir, |>. Cette fois, ça marche :

% mix run --no-mix-exs nimbleparsec-3.exs
{:ok, ["foobar"], "", %{}, {1, 0}, 6}
{:error, "expected ASCII character in the range 'a' to 'z'", "", %{}, {1, 0}, 0}
{:error, "expected end of string", "é au lait", %{}, {1, 0}, 3}
  

Maintenant qu'on sait faire des combinaisons, allons plus loin. On voudrait analyser des chaînes du type « foo{bar} » avec un verbe suivi d'une valeur entre accolades :

verb = ascii_string([not: ?\{], min: 1)
value = ascii_string([not: ?\}], min: 1)
body = ignore(string("{")) |> concat(value) |> ignore(string("}"))
defparsec :test, verb |> concat(body) |> eos
  

Décortiquons un peu : verb est défini comme une chaine ne comportant pas l'accolade ouvrante (sinon, l'analyseur, qui est gourmand, ira jusqu'au bout et avalera tout, y compris l'accolade ouvrante). De même, value ne comporte pas l'accolade fermante. body est la composition des deux accolades et de la valeur. Les deux accolades ne servent que de délimiteurs, on ne veut pas récupérer leur valeur, donc on ignore leur résultat (alors que celui de value nous sera retourné, c'est le rôle de concat). Essayons avec ce code :

# Correct
IO.inspect Test4.test("foobar{ga}")
# Tous les autres sont incorrects
IO.inspect Test4.test("foobar")
IO.inspect Test4.test("foobar{ga")
IO.inspect Test4.test("foobar{}")
IO.inspect Test4.test("{ga}")
IO.inspect Test4.test("foobar{ga}extra")
  

Et ça donne :

% mix run --no-mix-exs nimbleparsec-4.exs
{:ok, ["foobar", "ga"], "", %{}, {1, 0}, 10}
{:error, "expected string \"{\"", "", %{}, {1, 0}, 6}
{:error, "expected string \"}\", followed by end of string", "", %{}, {1, 0}, 9}
{:error, "expected ASCII character, and not equal to '}'", "}", %{}, {1, 0}, 7}
{:error, "expected ASCII character, and not equal to '{'", "{ga}", %{}, {1, 0}, 0}
{:error, "expected string \"}\", followed by end of string", "}extra", %{}, {1, 0}, 9}
  

C'est parfait, « foobar{ga} » a été accepté, les autres sont refusés.

Maintenant, il est temps d'introduire un outil très utile de NimbleParsec, la fonction generate. Elle permet de générer des chaines de caractères conformes à la grammaire qu'on a décrite en combinant les analyseurs (lisez quand même la documentation, il y a des pièges). Voici un exemple (en nimbleparsec-5.exs) :


% mix run --no-mix-exs nimbleparsec-5.exs
<<125, 40, 252, 204, 123, 151, 153, 125>>

Que signifie cette réponse incompréhensible ? C'est parce que ascii_string, en dépit de son nom, n'accepte pas que des caractères ASCII mais aussi tous les caractères sur huit bits, qu'Elixir refuse ensuite prudemment d'imprimer. On va donc restreindre les caractères autorisés (avec l'intervalle ?a..?z, déjà vu) et cette fois, ça marche :

% mix run --no-mix-exs nimbleparsec-6.exs
"gavi{xt}"
% mix run --no-mix-exs nimbleparsec-6.exs
"y{ltww}"
% mix run --no-mix-exs nimbleparsec-6.exs
"ha{yxsy}"
% mix run --no-mix-exs nimbleparsec-6.exs
"q{yx}"
  

Nous générons bien désormais des chaines conformes à la grammaire. generate est vraiment un outil très pratique (j'avais travaillé sur un projet ayant des points communs, Eustathius, mais qui n'est plus maintenu).

Voyons maintenant quelques autres combinateurs possibles (je vous rappelle que NimbleParsec a une bonne documentation). repeat permet de répéter un analyseur :

# Permettra "foo{bar}{baz}"
lang = verb |> repeat(body)
  

Tandis qu'optional permettra de rendre un analyseur facultatif :

# Permettra "foo{bar}{baz}" mais aussi "foo"
lang = verb |> optional(repeat(body))

Autres trucs utiles, le premier argument d'ascii_string permet de donner une liste d'intervalles de caractères acceptés. Le programme nimbleparsec-6.exs impose ainsi une lettre majuscule au début, puis permet des tirets :

verb = ascii_char([?A..?Z]) |> concat(ascii_string([?a..?z, ?-], min: 1))
value = ascii_string([?a..?z, ?-], min: 1)
body = ignore(string("{")) |> concat(value) |> ignore(string("}"))
parser = verb |> optional(repeat((body))) |> eos

Voici le résultat :

% mix run --no-mix-exs nimbleparsec-6.exs
"Yga{-c--}{yt}{--}"

% mix run --no-mix-exs nimbleparsec-6.exs
"H--n{-r-v}{-}{j--h}"

% mix run --no-mix-exs nimbleparsec-6.exs
"L-x{-bj}{-}"

% mix run --no-mix-exs nimbleparsec-6.exs
"Upi"

Comme exercice, je vous laisse déterminer comment interdire deux tirets consécutifs.

ascii_string va chercher des caractères ou plus exactement des octets. Si le texte est de l'Unicode, il sera probablement encodé en UTF-8 et on aura peut-être plutôt envie d'utiliser utf8_string :

verb = utf8_string([], min: 1)
...
IO.inspect Test7.test("café-au-lait")
  

Qui donnera :

{:ok, ["café-au-lait"], "", %{}, {1, 0}, 13}

Mais une sérieuse limite apparait : tous les caractères Unicode seront acceptés. On peut en éliminer certains (ici, l'espace - que vous ne voyez pas - et le point) avec not :

verb = utf8_string([not: ? , not: ?.], min: 1)
  

Mais les intervalles (comme ?a..?z que vous avez vu plus haut) n'ont guère d'intérêt en Unicode, où les caractères qui vous intéressent ne sont probablement pas consécutifs. Il faudrait pouvoir utiliser les catégories Unicode, mais je ne trouve pas de moyen de le faire avec NimbleParsec.

Si vous voulez approfondir, je répète une dernière fois que la doc est très complète, mais il y a aussi l'article de Gints Dreimanis et celui de Drew Olson. Et, sur Elixir lui-même, je compte beaucoup sur le livre de Dave Thomas.


L'article seul

Mesurer l'efficacité du pare-feu national chinois

Première rédaction de cet article le 10 novembre 2021


L'Internet en Chine est censuré par un dispositif souvent décrit sous le nom de GFW (Great FireWall). C'est sans doute le dispositif de censure le plus perfectionné au monde. Il a donc été assez étudié mais rarement autant en détail que dans l'excellent article « How Great is the Great Firewall? Measuring China's DNS Censorship », dont les auteurs ont surveillé le GFW sur une longue période.

Le GFW n'a pas une technique unique de censure. Une de ses forces est de combiner plusieurs techniques. L'une d'elles est la génération, par le réseau lui-même (et pas par un résolveur menteur), de fausses réponses DNS. Vous demandez un nom censuré et paf vous recevez une réponse donnant une adresse IP qui n'a rien à voir avec la question posée. Dans la plupart des pays qui censurent avec le DNS, la réponse mensongère est un NXDOMAIN - code indiquant que le nom n'existe pas - ou bien l'adresse d'un site Web qui affichera un message explicatif. Au contraire, les censeurs chinois sont soucieux de brouiller les pistes et renvoient une adresse réelle, ce qui rendra plus difficile de comprendre ce qui se passe.

Voici un exemple. J'interroge l'adresse IP 113.113.113.113, qui est en Chine, sur le réseau de China Telecom. Autant que j'en sache, aucune machine ne répond à cette adresse (testé avec nmap). Si je l'interroge sur un nom de domaine, je n'ai, logiquement, pas de réponse :

% dig @113.113.113.113 A mit.edu
... 
;; connection timed out; no servers could be reached
  

Mais si je l'interroge sur un nom censuré, là, le réseau génère une réponse mensongère :

%  dig @113.113.113.113 A scratch.mit.edu

...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56267
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
scratch.mit.edu.	248 IN A 157.240.6.18

;; Query time: 210 msec
;; SERVER: 113.113.113.113#53(113.113.113.113)
;; WHEN: Tue Nov 09 08:35:29 UTC 2021
;; MSG SIZE  rcvd: 60

  

L'adresse IP 157.240.6.18 appartient à Facebook (normalement, scratch.mit.edu est chez Fastly), exemple typique des mensonges générés par le GFW.

Pour étudier en détail ce mécanisme, les auteurs de l'article « How Great is the Great Firewall? » ont développé le logiciel GFWatch qui permet de faire des études du GFW sur une longue période, entre autres sur les adresses IP renvoyées par le GFWatch.

GFWatch utilise des listes de noms de domaine dans des TLD importants comme .com, augmentées de noms dont on a appris qu'ils étaint censurés (scratch.mit.edu est censuré - cf. exemple plus haut - mais mit.edu ne l'est pas, donc utiliser les listes de noms sous les TLD comme .edu ne suffit pas). Il interroge ensuite des adresses IP en Chine, adresses qui ne répondent pas aux questions DNS (rappelez-vous que les réponses mensongères sont fabriquées par des middleboxes et qu'il n'y a donc même pas besoin que l'adresse IP en question réponde, comme dans le cas de 113.113.113.113). Toute réponse est donc forcément une action de censure. Le logiciel GFWatch stocke alors les réponses. L'article utilise des données de 2020, collectées pendant neuf mois. (On peut voir les domaines censurés.)

Les résultats ? Sur 534 millions de domaines testés, 311 000 ont déclenché une réponse mensongère du GFW. Les censeurs chinois n'ont pas peur des faux positifs et, par exemple, mentorproject.org est censuré, probablement uniquement parce qu'il contient la chaine de caractères torproject.org, censurée parce que les censeurs n'aiment pas Tor.

GFWatch peut ainsi obtenir une longue liste de domaines censurés, et essayer de les classer, ce qui permet d'obtenir une idée de la politique suivie par les censeurs (inutile de dire que les gérants du GFW ne publient pas de rapports d'activité détaillant ce qu'ils font…). On trouve par exemple des domaines liés à la pandémie de Covid-19 (les autorités chinoises ne veulent pas laisser l'information sur la maladie circuler librement).

Une des particularités du GFW est le renvoi d'adresses IP sans lien avec le nom demandé (comme, plus haut, une adresse de Facebook renvoyée à la place de celle du MIT). Quelles sont ces adresses IP ? Combien sont-elles ? Comment sont-elles choisies ? C'est l'un des gros intérêts d'un système comme GFWatch, de pouvoir répondre à ces questions. L'adresse retournée n'est clairement pas prise au hasard dans tout l'espace d'adressage IPv4. Seules 1 781 adresses IPv4 ont été vues par GFWatch, presque la moitié étant des adresses Facebook. Le GFW renvoie aussi des adresses IPv6 :

%  dig @113.113.113.113 AAAA scratch.mit.edu
...
;; ANSWER SECTION:
scratch.mit.edu.	84 IN AAAA 2001::4a75:b6b7
  

Et toutes appartiennent au préfixe réservé pour Teredo (RFC 4380), une technologie désormais abandonnée.

Quant aux adresses IPv4, leur nombre varie dans le temps (de nouvelles adresses apparaissent de temps en temps), et le choix ne semble pas aléatoire, certaines adresses apparaissant davantage que les autres.

Du fait que les réponses mensongères sont générées par le réseau (plus exactement par une middlebox), et pas par un serveur, le GFW brouille parfois les réponses de serveurs légitimes. Plusieurs cas sont cités par l'article, mais je vais plutôt mentionner un cas très récent, le brouillage des réponses du serveur racine k.root-servers.net car le résolveur d'un FAI mexicain a eu le malheur d'interroger l'instance pékinoise de k.root-servers.net et le GFW a donc envoyé ses réponses mensongères. Le point a été discuté sur la liste dns-operations de l'OARC en novembre 2021 et il semble que l'annonce BGP de l'instance pékinoise ait été transmise bien au delà de sa portée voulue (un problème relativement fréquent avec les serveurs anycastés).

L'article montre d'ailleurs que certains résolveurs DNS publics ont reçu des réponses générées par le GFW et les ont mémorisées. Les réponses de cette mémoire ainsi empoisonnée ont ensuite été servies à d'innocents utiisateurs. Bref, on ne répétera jamais assez qu'il faut utiliser DNSSEC (signer les zones, et vérifier les signatures ; les gros résolveurs publics vérifient tous les signatures mais cela ne marche que si la zone est signée).

Comment lutter contre cette censure ? Déjà, l'article note que le GFW est en général « sur le côté » et pas « sur le chemin ». Il injecte un mensonge mais ne bloque pas la vraie réponse. Parfois, celle-ci arrive même avant le mensonge, si le GFW a été lent à réagir. Une solution possible serait donc d'attendre un peu voir si on ne reçoit pas une autre réponse, plus vraie. Certains motifs dans la réponse mensongère (comme l'utilisation du préfixe 2001::/32, normalement inutilisé, pour les requêtes AAAA) pourraient permettre d'ignorer les réponses de la censure. (Vous pouvez voir les adresses retournées par les menteurs sur le site de GFWatch.) Mais, comme dit plus haut, la solution est évidemment DNSSEC, avec un lien sécurisé vers le résolveur validant (par exemple avec DoT ou DoH). Ne vous fiez pas à ce que raconte l'article sur des soi-disant « problèmes de compatibilité », qui ne sont pas détaillés. Mais attention, cela ne résout que la censure du DNS ; le GFW emploie une combinaison de techniques et y échapper n'est pas facile (et peut, si vous êtes en Chine, attirer l'attention de gens assez désagréables et en uniforme).

Vous pouvez aussi regarder la censure chinoise avec un résolveur situé en Chine et accessible via le fédivers, ResolverCN@mastodon.xyz, par exemple voici ce qu'il voyait pour Scratch. Mais ce n'est même pas nécessaire, comme on l'a vu plus haut, donc vous pouvez aussi vous servir du DNS Looking Glass, par exemple en https://dns.bortzmeyer.org/facebook.com?server=113.113.113.113. Dans les réponses ci-dessous, 162.125.32.5 appartient à Dropbox, pas Facebook : dns-lg-gfw.png


L'article seul

RFC 9097: Metrics and Methods for One-Way IP Capacity

Date de publication du RFC : Novembre 2021
Auteur(s) du RFC : A. Morton (AT&T Labs), R. Geib (Deutsche Telekom), L. Ciavattone (AT&T Labs)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 10 novembre 2021


Ce RFC revisite la notion de capacité du RFC 5136 et spécifie une nouvelle métrique, Type-P-One-way-Max-IP-Capacity.

Il y a déjà plusieurs RFC qui spécifient rigoureusement des métriques pour déterminer la capacité réseau. (Attention, les publicités des FAI et les articles dans les médias parlent souvent à tort de débit pour désigner ce qui est en fait la capacité, c'est-à-dire le débit maximum.) Une définition rigoureuse est en effet nécessaire car il peut y avoir, pour une même connexion et un même chemin, des capacités différentes selon ce qu'on mesure. Par exemple, est-ce qu'on compte les bits/s à la couche 3 ou à la couche 7 ? Compte-tenu de l'encapsulation et des retransmissions, la seconde est forcément plus basse. Les définitions actuelles sont surtout dans le RFC 5136 et le RFC 3148 mais le travail n'est jamais terminé et ce nouveau RFC vient donc compléter le RFC 5136. Vu l'importance de cette notion de capacité dans les publicités (« Nouveau : accès Premium Gold Plus à 10 Gb/s ! »), il est crucial que des associations de consommateurs ou des régulateurs puissent mesurer et vérifier les annonces.

Une des raisons pour lesquelles le travail sur la définition des métriques ne cesse jamais est que l'Internet évolue. Ainsi, note le RFC, depuis quelques années :

  • Ce n'est plus forcément le premier kilomètre qui limite la capacité du chemin,
  • le protocole UDP prend plus d'importance, grâce à WebRTC et QUIC,
  • avec les CDN, le contenu se rapproche des utilisateurs (et franchit moins souvent des frontières entre AS).

Première métrique défnie dans notre RFC (section 5), et venant s'ajouter à celles du RFC 5136, Type-P-One-way-IP-Capacity. C'est le nombre de bits par seconde, mesurés en couche 3 et au-dessus (donc incluant l'en-tête IP, par exemple). Le Type-P est là pour rappeler que cette métrique n'a de sens que pour un certain type de trafic, car des équipements réseau « intelligents » peuvent faire que, par exemple, les paquets vers le port 22 passent plus vite que ceux pour un autre port. Type-P est donc la description complète des paquets utilisés. À noter que le RFC recommande d'indiquer la valeur de cette métrique en mégabits par seconde (et pas en mébibits, on utilise plutôt les préfixes des télécoms que ceux de l'informatique).

Deuxième métrique (section 6), Type-P-One-way-Max-IP-Capacity, qui indique la capacité maximum (la différence avec la métrique précédente vient du fait que certains réseaux peuvent avoir une capacité variable, par exemple les réseaux radio, oui, je sais, c'est compliqué).

Troisième métrique (section 7), Type-P-IP-Sender-Bit-Rate. Elle désigne la capacité de l'émetteur à envoyer des bits. En effet, lors d'une mesure, le goulet d'étranglement peut être l'expéditeur et on croit alors que le réseau a une capacité inférieure à ce qu'elle est réellement.

La section 8 se penche sur la mesure effective de ces valeurs. Il faut une mesure active (envoi de bits sur le réseau uniquement pour faire la mesure), et elle possiblement très perturbatrice puisqu'on va chercher à remplir les tuyaux le plus possible. Le RFC inclut un algorithme d'ajustement du trafic mais qui n'est pas un vrai algorithme de contrôle de congestion. Le pseudo-code de cet algorithme est dans l'annexe A.

La mesure est bidirectionnelle (envoyeur et récepteur doivent coopérer) même si la métrique est unidirectionnelle (le One-Way dans le nom). Le RFC recommande de la faire sur UDP (attention au RFC 8085, UDP n'ayant pas de contrôle de congestion propre, c'est à l'application de mesure de faire attention à ne pas écrouler le réseau).

Jouons maintenant un peu avec une mise en œuvre de ce RFC, le programme udpst, sur deux machines Arch Linux (un Raspberry Pi 1, donc avec un réseau très lent) et Debian, sur le même commutateur. On l'installe :

% git clone https://github.com/BroadbandForum/obudpst.git
% cd obudpst
% cmake .
% make

On peut alors lancer le serveur :

% ./udpst
UDP Speed Test
Software Ver: 7.2.1, Protocol Ver: 8, Built: Sep 28 2021 15:46:40
Mode: Server, Jumbo Datagrams: Enabled, Authentication: Available, sendmmsg syscall: Available
  

Et le client, le Raspberry Pi :

    
% ./udpst -u  2001:db8:fafa:35::1
UDP Speed Test
Software Ver: 7.2.1, Protocol Ver: 8, Built: Sep 28 2021 18:25:23
Mode: Client, Jumbo Datagrams: Enabled, Authentication: Available, sendmmsg syscall: Available
Upstream Test Interval(sec): 10, DelayVar Thresholds(ms): 30-90 [RTT], Trial Interval(ms): 50, Ignore OoO/Dup: Disabled,
    SendingRate Index: <Auto>, Congestion Threshold: 3, High-Speed Delta: 10, SeqError Threshold: 10, IPv6 TClass: 0
...
Sub-Interval[10](sec): 10, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 2/8/18, RTTVar(ms): 2-16, Mbps(L3/IP): 65.73
Upstream Summary Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/3/23, RTTVar(ms): 0-16, Mbps(L3/IP): 49.87
Upstream Minimum One-Way Delay(ms): 2 [w/clock difference], Round-Trip Time(ms): 1
Upstream Maximum Mbps(L3/IP): 67.29, Mbps(L2/Eth): 67.45, Mbps(L1/Eth): 67.63, Mbps(L1/Eth+VLAN): 67.67

  

En sens inverse, avec l'option -d, où le Raspberry Pi va envoyer des données :

Downstream Summary Delivered(%):  84.90, Loss/OoO/Dup: 8576/0/0, OWDVar(ms): 0/641/956, RTTVar(ms): 0-39, Mbps(L3/IP): 38.86
Downstream Minimum One-Way Delay(ms): -927 [w/clock difference], Round-Trip Time(ms): 1
Downstream Maximum Mbps(L3/IP): 46.98, Mbps(L2/Eth): 47.68, Mbps(L1/Eth): 48.46, Mbps(L1/Eth+VLAN): 48.62

(Notez le taux de pertes élevé, la pauvre machine n'arrive pas à suivre.)


Téléchargez le RFC 9097


L'article seul

Fiche de lecture : L'École sans école

Auteur(s) du livre : Stéphane Bortzmeyer, Gilles Braun, Éric Bruillard, Goundo Diawara, Olivier Ertzscheid, Camille Fée, Pierre-Yves Gosset, Hélène Mulot, Hélène Paumier, Serge Pouts-Lajus, Delphine Riccio, Élisabeth Schneider, Céline Thiery, Stéphanie de Vanssay, les élèves Lola, Ilyès et Shana
Éditeur : C&F Éditions
978-2-37662-025-9
Publié en 2021
Première rédaction de cet article le 1 novembre 2021


Vous l'avez remarqué, la France a été confinée en mars 2020 et cela a entre autres concerné l'École, qui était fermée ou, plus exactement, sortie de l'école (avec un petit é) pour se faire à distance depuis la maison. D'un tel bouleversement, décidé dans l'urgence, il y a forcément des leçons à tirer. C'est le but de ce petit livre collectif qui réunit un certain nombre d'analyses sur cette « période spéciale ».

À ma connaissance, le ministère n'a pas produit de texte officiel de bilan de cette « expérience ». (Sauf si on considère que le livre du ministre en tient lieu.) Pourtant, il y en a des choses à dire, un grand nombre de gens, des enseignants, élèves, parents, employés non enseignants de l'École ont dû s'adapter dans l'urgence, et ont souvent brillamment innové. Le livre alterne des témoignages du terrain, et des analyses plus générales. Goundo Diawara raconte ce qu'une CPE dans un établissement difficile (REP+) pouvait faire pour maintenir le moral des élèves et de leurs familles (comme pour beaucoup de choses, confinement et travail à la maison sont plus agréables quand on est riche que quand on est pauvre). Stéphanie de Vanssay rappelle que se focaliser sur le numérique, vu parfois comme danger, et parfois comme solution à tout pendant le confinement, est insuffisant. Ainsi, les inégalités ne relèvent pas uniquement de la « fracture numérique ». Serge Pouts-Lajus décrit ce que faisait le personnel non-enseignant, par exemple en préparant des repas et en les apportant aux élèves. Hélène Mulot parle du travail qu'elle a fait avec les élèves autour des masques. Et Pierre-Yves Gosset fait le bilan des relations de l'École avec le numérique, et notamment de sa capitulation, bien antérieure au confinement, devant Microsoft et autres entreprises. (Mais le confinement a aggravé les choses ; « nous avons tous émigré aux États-Unis » en matière d'outils numériques.)

J'espère que ce livre servira à ce que cette « expérience » ne soit pas oubliée et que les leçons du confinement serviront à quelque chose, et permettront de faire évoluer l'École (oui, je suis optimiste). Vous connaissez d'autres livres (à part celui du ministre) qui ont fait le bilan de ce confinement dans le milieu scolaire ?


L'article seul

RFC 9120: Nameservers for the Address and Routing Parameter Area ("arpa") Domain

Date de publication du RFC : Octobre 2021
Auteur(s) du RFC : K. Davies (IANA), J. Arkko (Ericsson)
Pour information
Première rédaction de cet article le 30 octobre 2021


Le TLD .arpa sert pour différentes fonctions techniques et est géré directement par l'IAB. Ce RFC décrit un futur changement dans ses serveurs de noms.

Ce TLD est décrit dans le RFC 3172. Le nom de .arpa fait référence à l'ancien nom de la DARPA, l'agence qui avait financé le développement de l'Internet. Mais, aujourd'hui, il veut dire « Address and Routing Parameter Area » et le TLD sert à diverses fonctions techniques comme la résolution d'adresses IP en noms de domaine via des sous-domaines comme ip6.arpa. Par exemple, l'adresse IP du serveur Web de l'IAB a pour nom correspondant :


% dig -x 2001:1900:3001:11::2c
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53150
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
c.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.0.1.0.0.3.0.0.9.1.1.0.0.2.ip6.arpa. 3600 IN PTR mail.ietf.org.

Comme vous le voyez, dig a inversé l'adresse IP et ajouté ip6.arpa à la fin. .arpa sert également à d'autres fonctions comme le home.arpa du RFC 8375.

Traditionnellement, le domaine .arpa était hébergé sur une partie des serveurs de noms de la racine. Le 22 octobre 2021, voici quels étaient les serveurs faisant autorité pour .arpa :


% dig +nodnssec NS arpa 
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43670
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
arpa.			15910 IN NS b.root-servers.net.
arpa.			15910 IN NS f.root-servers.net.
arpa.			15910 IN NS d.root-servers.net.
arpa.			15910 IN NS l.root-servers.net.
arpa.			15910 IN NS e.root-servers.net.
arpa.			15910 IN NS a.root-servers.net.
arpa.			15910 IN NS c.root-servers.net.
arpa.			15910 IN NS i.root-servers.net.
arpa.			15910 IN NS h.root-servers.net.
arpa.			15910 IN NS g.root-servers.net.
arpa.			15910 IN NS k.root-servers.net.
arpa.			15910 IN NS m.root-servers.net.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Oct 22 20:35:36 CEST 2021
;; MSG SIZE  rcvd: 241

  

Le changement ne concerne que l'hébergement DNS, pas la gestion de .arpa (section 2 de notre RFC), qui reste un TLD critique, et soumis au RFC 3172. Le choix des sous-domaines et de leur administration est inchangé (par exemple, pour ip6.arpa, c'est décrit dans le RFC 5855).

La section 3 du RFC décrit le nouveau système qui, à la date de publication du RFC, n'est pas encore déployé. Le principe est de commencer par utiliser des noms différents pour les serveurs, mais qui pointeront vers les mêmes machines, au moins au début. Les nouveaux noms seront dans le futur sous-domaine ns.arpa, on aura donc a.ns.arpa, b.ns.arpa, etc. Aucune modification dans les serveurs ne sera nécessaire pour cette première étape, qui n'affectera que la zone racine et la zone .arpa. Comme tous les noms seront dans la zone qu'ils servent, il faudra ajouter de la colle aux réponses DNS (ne pas juste dire « le serveur est c.ns.arpa » mais également indiquer son adresse IP). Une fois que tout cela sera réalisé, il n'y aura plus de nom de serveur commun à la racine et à .arpa, et il sera possible dans le futur de migrer vers d'autres serveurs. (Toujours en respectant le RFC 3172.)

Vous pouvez voir l'état actuel de .arpa à l'IANA ou bien dans le DNS.

Notez enfin que certains des serveurs de .arpa autorisent le transfert de zones. Voici une copie faite le 24 octobre 2021.


Téléchargez le RFC 9120


L'article seul

L'informatique doit-elle être rangée dans les sciences humaines et sociales ?

Première rédaction de cet article le 17 octobre 2021


L'informatique est en fait une SHS et devrait être rangée ainsi dans les universités. C'est par cette idée provocante (mais, je vous rassure tout de suite, que l'auteur estime irréaliste) que commence l'article de Randy Connolly « Why computing belongs within the social sciences ». Une thèse intéressante et bien exposée, qui s'appuie sur des éléments sérieux mais qui a aussi d'ennuyeuses faiblesses.

Comme je l'ai dit, l'auteur ne propose pas réellement de réorganiser les universités et le CNRS en déplaçant le département d'informatique au même étage que la sociologie et l'histoire. Son but est plutôt de faire réfléchir au statut de l'informatique : on la place toujours dans les sciences dures (ou sciences exactes), en général à côté de la mathématique mais ne faudrait-il pas reconsidérer cette habitude ? L'idée centrale de l'auteur est que, d'abord, l'informatique a un tel pouvoir aujourd'hui, un tel rôle dans nos sociétés, qu'elle n'appartient plus au monde de la pure science, et ensuite que les sciences humaines et sociales auraient beaucoup à lui apporter.

Un grand nombre des points soulevés par l'auteur sont parfaitement exacts. L'informatique n'est pas seulement une technique à succès, présente partout (comme le sont bien d'autres sciences, par exemple la physique) : elle est au cœur de toutes nos activités à l'heure actuelle. Elle interagit donc fortement avec la société. L'informatique a du pouvoir (c'est bien pour cela que c'est un métier qui paie bien et ne connait pas le chômage) et donc des responsabilités. Affirmer, comme le fait l'auteur, que le code est politique n'est pas nouveau, ni original, mais ce n'est pas forcément encore bien compris, ni même admis par tou·tes les informaticien·nes (« je code juste, je ne fais pas de politique »). Ce n'est donc pas une mauvaise idée de le répéter. Ensuite, il est certain que les autres sciences (pas seulement les SHS) ont des choses à apprendre à l'informatique. C'est encore une banalité (que serait la science qui prétendrait rester isolée et considérerait les autres sciences comme dénuées d'intérêt ?) mais qui n'est pas encore bien intégrée. On trouvera sans peine des informaticien·nes qui renâcleraient à l'idée d'introduire des cours de psychologie ou d'économie dans leur cursus, au nom de « ça ne sert à rien ».

(Au passage, l'auteur a une façon intéressante de décrire la différence entre sciences dures et sciences humaines : les sciences dures se caractérisent par la méthode unique, la bonne, les sciences humaines par le pluralisme des méthodes. En effet, en SHS, il n'y a jamais de consensus entre les chercheurs, même sur des choses de base. Ce critère semble plus utile qu'un critère souvent utilisé, celui de la réfutabilité. Il y a des sciences dures comme la paléontologie ou l'astrophysique où on ne peut pas facilement faire des expériences…)

L'auteur fait trois suggestions concrètes, admettre que les autres sciences ont quelque chose à apporter à l'informatique, des cours de SHS dans les filières informatiques (et pas juste un « cours d'éthique » perdu en fin de semestre et clairement marqué comme secondaire), et l'embauche dans les départements d'informatique de gens qui ne sont pas à proprement parler informaticien·nes. Les trois me semblent de bonnes idées.

J'ai apprécié l'appel à s'ouvrir, à aller voir dans les autres champs disciplinaires ce qu'ils peuvent nous apporter. L'auteur a raison de faire remarquer que certain·es informaticien·nes ont une fâcheuse tendance à croire que tous les problèmes du monde se règlent avec de l'informatique, une vision techno-solutionniste très présente, par exemple, dans le discours macroniste et sa startup nation. Or, si l'arrivée d'informaticien·nes dans un champ nouveau peut rafraichir ce champ, la plupart du temps, quelqu'un qui débarque dans un nouveau domaine sans faire l'effort de la comprendre a plus de chances d'être un arrogant débutant que d'être un génie qui va bouleverser le monde. Mais l'article a aussi des faiblesses importantes.

La première est que la politique est absente. À le lire, on a l'impression que les décisions d'une entreprise comme Facebook sont uniquement dues au fait que les ingénieurs ont une certaine mentalité, et que ce sont eux qui décident. Il montre ainsi une étonnante ignorance du monde de l'entreprise et de ses mécanismes de gouvernance. Zuckerberg ne prend pas ses décisions parce que, il y a longtemps, il était programmeur. Il les prend en fonction des profits pour son entreprise, comme le fait n'importe quel autre patron. Le remplacer par quelqu'un qui a fait des études de science politique ou de communication ne changerait probablement rien. (Pour citer un commentaire de Joseph Bedard, « les patrons des entreprises de la tech ne sont pas des informaticiens et, s'ils l'ont été autrefois, ils ne le sont plus ».) Mais il est vrai qu'aux États-Unis, critiquer le capitalisme est un sujet tabou. Socialement, il est bien plus admis de demander qu'on donne quelques cours d'anthropologie ou de linguistique aux décideurs.

Cette négligence de la politique mène l'auteur à de curieuses affirmations comme de prétendre qu'aujourd'hui, le pouvoir ne s'exercerait rarement que par la violence et plutôt via des algorithmes. S'il est vrai que presque toutes nos activités sont médiées par des logiciels (et que les gens qui développent et déploient ce logiciel ont donc une responsabilité), il n'en est pas moins vrai que l'utilisation de ces logiciels est imposée et n'est pas le résultat d'une diffusion douce. N'importe quel gilet jaune ayant manifesté à Paris pourrait dire au professeur d'université dans sa tour d'ivoire que, si, la violence du pouvoir est encore un moyen utile et utilisé.

Ensuite, si je comprends que l'auteur (qui publie dans une revue de l'ACM) s'adresse surtout à un public d'informaticien·nes, et donc passe l'essentiel de l'article à réhabiliter les SHS dans l'esprit de ses confrères et consœurs, il faut quand même noter que les SHS, comme l'informatique, ne résolvent pas tous les problèmes. L'auteur parle de champs de recherche « établis depuis longtemps » comme si c'était une garantie de sérieux ; le cas de l'astrologie ou bien de la pseudo-médecine qu'on a pratiqué jusqu'au XVIIIe siècle montre que l'ancienneté d'une discipline ne dit rien sur son bon fonctionnement.

L'auteur estime ainsi que la conception de l'Internet, faite sans trop se soucier des problèmes de sécurité (un cliché classique), aurait été différente si on avait impliqué dès le début des gens ayant, entre autres, « une meilleure connaissance de la psychologie humaine ». Cette affirmation est franchement nulle sur plusieurs points. D'abord, l'expérience des réseaux informatiques prouve largement que les systèmes conçus en fonction de la sécurité ne sont tout simplement jamais utilisés et jamais déployés (ce qui, il est vrai, résout pas mal de problèmes de sécurité…). Comme l'analyse très justement le RFC 5218, pour avoir du succès dans le monde réel, il faut être utilisable et agréable, donc ne pas trop embêter les utilisateurs avec la sécurité (même s'il faudra bien s'y atteler un jour). Ensuite, même aujourd'hui, avec l'expérience acquise et la compréhension de l'importance des questions de sécurité, on ne sait pas forcément toujours sécuriser l'Internet sans le stériliser complètement. Enfin, prétendre que les psychologues auraient prévu le problème (alors que les SHS ne sont pas spécialement connues pour leurs succès prédictifs…) car la nature humaine, les gens sont méchants, ça a toujours été comme ça et sera toujours comme ça, c'est du Café du Commerce, pas de la psychologie comme science.

(Les lecteur·trices averti·es noteront en outre que l'article ne différencie pas tout le temps l'informatique en tant que science et celle en tant que technique. Mais c'est un sujet complexe que je ne traite pas moi non plus.)

Ah, et pour finir, une vidéo où une informaticienne parle de sa passion pour la programmation, mais aussi, et à juste titre, du pouvoir qu'apporte cette technique.


L'article seul

Tempête solaire sur l'Internet ?

Première rédaction de cet article le 15 octobre 2021


L'Internet est vulnérable aux attaques, aux pannes du matériel, aux bogues des logiciels. Mais il peut aussi être vulnérable aux actions du Soleil, comme le montre l'étude « Solar superstorm: planning for an Internet apocalypse » qui, en dépit d'un titre putaclic, est une analyse sérieuse et détaillée des risques que courra l'Internet avec l'actuelle croissance de la violence du Soleil.

Le Soleil nous éclaire et nous donne parfois des coups de soleil. Mais il a aussi un autre effet, celui provoqué par les tempêtes solaires, notamment les éjections de masse coronale. Pendant ces tempêtes, le Soleil éjecte une grande quantité de particules dont l'arrivée sur Terre provoque divers phénomènes électromagnétiques, notamment la génération de courants induits dans les conducteurs. Les câbles qui relient les équipements des réseaux informatiques, comme l'Internet, peuvent donc être perturbés, voire endommagés. La plus connue de ces tempêtes est l'événement de Carrington, qui est survenu à une époque où l'électricité était une nouveauté peu employée et où le réseau principal était le télégraphe. Les éjections de masse coronale sont très directionnelles et, si elles ne se produisent pas en direction de la Terre, les conséquences sont minimes (comme par exemple pour l'éruption de juillet 2012).

L'activité solaire, et ces tempêtes, suivent des cycles. Le plus connu est le cycle de 11 ans, et nous en sommes actuellement au cycle n° 25. Mais il y a d'autres cycles, de période plus longue, comme le cycle de Gleissberg. Le hasard a fait que l'expansion de l'Internet a coïncidé avec un minimum de la plupart de ces cycles, donc une activité solaire relativement faible. Mais les choses changent, l'activité solaire augmente, et une tempête de grande intensité, perturbant sérieusement l'Internet (et d'autres constructions techniques) est une possibilité réelle dans les prochaines années. Une tempête de la taille de celle de Carrington aurait des conséquences autrement plus importante aujourd'hui.

(Notez que, si les fibres optiques ne sont pas conductrices, le câble d'alimentation des répéteurs qui les longe l'est, et qu'une fibre optique peut donc être mise hors de service par une tempête solaire.)

L'article « Solar superstorm: planning for an Internet apocalypse » cherche à quantifier le risque et à étudier comment le limiter. Un de ses angles d'attaque est de regarder la distribution géographique des équipements réseau. En effet, les conséquences de la tempête solaire sont plus intenses aux latitudes élevées, donc près des pôles. D'autre part, plus un conducteur est long, plus le courant induit est important. Les câbles sous-marins transocéaniques sont donc les plus vulnérables. L'auteur s'est donc plongé dans les données et a regardé où il y avait le plus de risques. (Il a stocké une copie des données en ligne, sauf celles pour lesquelles il n'avait pas l'autorisation, comme les données de l'UIT.) Par exemple, CAIDA publie des informations très utiles sur les routeurs.

Je vous résume quelques conclusions :

  • Les câbles sous-marins transatlantiques sont très concentrés en un petit nombre de points sur la côte Est des États-Unis (les transpacifiques sont mieux répartis), et trop au Nord, ce qui augmente les risques. En cas de tempête solaire intense, tous ces câbles seraient mis hors d'usage, seuls ceux partant de Floride, à une latitude plus basse, seraient épargnés (et ils ne vont pas en Europe, donc la connectivité entre l'Europe et les États-Unis serait probablement interrompue).
  • Rappelez-vous que la tempête a surtout des effets aux latitudes élevées ; l'auteur calcule que l'Alaska perdait toute sa connectivité sous-marine, mais Hawaï serait relativement épargné.
  • Fait amusant, dans l'hypothèse d'une tempête intense, le Royaume-Uni perdait sa connectivité avec l'Amérique du Nord mais pas avec l'Europe ; un Brexit à l'envers.
  • Les câbles terrestres, plus courts, seront nettement moins touchés.
  • Et les centres de données ? La tendance étant de les mettre de plus en plus au Nord, pour faciliter leur refroidissement, notamment dans le contexte du réchauffement planétaire, ils pourraient également être affectés.
  • Et les serveurs DNS de la racine ? L'auteur y a pensé aussi et considère que, vu leur répartition très variée à la surface du globe, ils ne seront probablement pas tous affectés à la fois.

Dans l'état actuel de la science, on ne sait pas prédire les tempêtes solaires, uniquement déterminer des probabilités. On ne peut donc pas se préparer longtemps à l'avance. Toutefois, en cas de tempête solaire, comme la masse coronale éjectée voyage plus lentement que la lumière, on voit la tempête plusieurs heures, voire plusieurs jours, avant d'en ressentir les effets. Il existe des services d'alarme utilisés, par exemple, par l'aviation. C'est le cas du service Presto du SIDC. Un avertissement typique (daté du 11 octobre 2021) dit « A halo coronal mass ejection has been observed in the available SOHO/LASCO coronagraph imagery at 07:24 on Oct 9. This halo coronal mass ejection is associate with the M1.6-class flare peaking at 06:38 UTC on the same day in the Catania sunspots group 58 (NOAA AR-2882), which was located on the central meridian. The projected speed was measured 692 km/s by the software package CACTus. The true speed has been estimated around 950 km/s. The transit time to Earth is estimated to take about 62 hours, ant the arrival to Earth time would be on Oct 12, around 01:00 UTC. ». Dans ce cas, la masse éjectée (CME = Coronal Mass Ejection) arrivera bien sur Terre mais on a un peu d'avance pour se préparer. Notez que ce service Presto est également accessible via Gemini : presto-gemini.png

Que faire quand on reçoit l'avertissement ? Couper le courant peut aider mais ne suffit pas, le danger venant des courants induits par la réception sur Terre de la masse coronale éjectée. L'auteur recommande de travailler la diversité, avec davantage de câbles, et mieux répartis. La redondance (et l'absence de SPOF) reste la meilleure défense.

L'auteur se penche aussi sur la remise en fonctionnement après la panne et c'est sans doute la plus mauvaise partie de l'article, avec des « solutions » très stratosphériques comme SCION ou Loon.

Ah et, bien sûr, l'article rappelle que le plus gros problème sera peut-être le manque d'électricité, car le réseau électrique va déguster lui aussi (et son bon fonctionnement dépend peut-être en partie de l'Internet).


L'article seul

Panne de routage OVH d'octobre 2021

Première rédaction de cet article le 13 octobre 2021


Aujourd'hui le routage IPv4 chez OVH a été en panne pendant environ une heure. J'indique ici quelques observations effectuées puis j'en profite pour donner un avis sur la fiabilité de l'Internet, sur OVH et sur les yakafokons qui nous expliquent comment il aurait fallu faire. (Si vous n'êtes pas informaticien·ne, allez directement à la fin, la partie qui commence par « Maintenant, les leçons à en tirer. ».)


L'article complet

RFC 9137: Considerations for Cancellation of IETF Meetings

Date de publication du RFC : Octobre 2021
Auteur(s) du RFC : M. Duke (F5 Networks)
Réalisé dans le cadre du groupe de travail IETF shmoo
Première rédaction de cet article le 12 octobre 2021


Pour son travail de normalisation technique, l'IETF tient normalement trois réunions physiques par an. La pandémie de Covid-19 a évidemment changé tout cela. Les premières décisions d'annulation ont été prises selon un procédure ad hoc, mais ce nouveau RFC fournit des critères plus rigoureux pour les prochaines décisions d'annulation.

La dernière réunion physique de l'IETF a eu lieu à Singapour en novembre 2019. Depuis, les conditions sanitaires ont forcé à annuler toutes les réunions. Mais notre nouveau RFC ne se limite pas au cas de la Covid-19. Une réunion, après tout, peut devoir être annulée pour d'autres raisons, un problème de dernière minute dans le bâtiment où elle devait se tenir, une catastrophe naturelle dans le pays d'accueil, un brusque changement dans la politique de visa de ce pays, etc. (Le RFC cite même le cas d'une guerre civile, mais ce n'est encore jamais arrivé à une réunion IETF.) Dans ces cas, l'IETF LLC (la direction administrative de l'IETF) et l'IESG vont devoir décider si on maintient la réunion ou pas.

La section 3 du RFC expose les critères de décision. L'IETF LLC (cf. RFC 8711) détermine si la réunion peut se tenir, l'IESG si cela vaut la peine de la tenir. L'IETF LLC doit évidemment travailler en toute transparence, informant l'IETF de la situation, des décisions possibles et d'un éventuel « plan B ». Il n'est pas toujours possible de procéder proprement et démocratiquement si la situation est urgente (tremblement de terre trois jours avant la réunion…). Dans ce cas, l'IETF LLC doit déterminer seule si la réunion peut se tenir (ce qui implique certaines garanties de sécurité pour les participants, de la restauration mais également un accès Internet qui marche ; les participants à l'IETF n'ont pas juste besoin de dormir et de manger, il leur faut aussi du réseau). L'IETF LLC doit aussi intégrer des paramètres internes comme la disponibilité de ses employés et des bénévoles, et bien sûr les conséquences financières du maintien ou de l'annulation (si le lieu de la réunion considère qu'il n'y avait pas force majeure et ne veut pas rembourser…). La section 3 du RFC 8718 contient des indications utiles à cette évaluation.

L'IESG, lui, doit déterminer s'il y aura suffisamment de monde à la réunion pour que ça vaille la peine. Il ne serait pas malin de maintenir une réunion pour que personne ne vienne.

La section 4 du RFC couvre les alternatives. Si on annule, que peut-on proposer à la place ? Il faut évaluer ces alternatives en tenant compte de leur efficacité (une réunion en ligne est moins efficace) et de leur coût (changer les billets d'avion au dernier moment coûte cher). Ces alternatives peuvent être, dans l'ordre décroissant de préférence :

  • Changer le lieu de la réunion. C'est ce qui dérange le moins le travail, surtout si le nouveau lieu est proche de l'ancien. Naturellement, le nouveau lieu doit correspondre aux critères des RFC 8718 et RFC 8719.
  • Passer en ligne, à une réunion « virtuelle », ce qui a été fait pour toutes les réunions annulées en raison de la Covid-19.
  • Repousser la réunion à plus tard. Ce n'est en général pas facilement faisable, puisque cela perturbe les agendas de tout le monde.
  • Annuler complètement, sans alternative. Le RFC note que cela aura des conséquences, non seulement sur le travail de normalisation, mais également sur des processus politiques comme la détermination de qui peut siéger dans des comités comme le NomCom (comité de nomination, cf. RFC 8788 et RFC 8989).

La section 5 de notre RFC couvre les questions financières. En gros, l'IETF ne remboursera pas les dépenses engagées par les participants (avion, hôtel, etc), seulement les frais d'inscription à la réunion, en totalité s'il y a annulation complète et partiellement dans les autres cas.


Téléchargez le RFC 9137


L'article seul

RFC 9132: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification

Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : M. Boucadair (Orange), J. Shallow, T. Reddy.K (Akamai)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dots
Première rédaction de cet article le 10 octobre 2021


Le protocole DOTS (Distributed Denial-of-Service Open Threat Signaling) vise à permettre au client d'un service anti-dDoS de demander au service de mettre en route des mesures contre une attaque. Ce RFC décrit le canal de signalisation de DOTS, celui par lequel passera la demande d'atténuation de l'attaque. Il remplace le RFC 8782, mais les changements sont mineurs.

Si vous voulez mieux comprendre DOTS, il est recommandé de lire le RFC 8612, qui décrit le cahier des charges de ce protocole, et le RFC 8811, qui décrit l'architecture générale. Ici, je vais résumer à l'extrême : un client DOTS, détectant qu'une attaque par déni de service est en cours contre lui, signale, par le canal normalisé dans ce RFC, à un serveur DOTS qu'il faudrait faire quelque chose. Le serveur DOTS est un service anti-dDoS qui va, par exemple, examiner le trafic, jeter ce qui appartient à l'attaque, et transmettre le reste à son client.

Ces attaques par déni de service sont une des plaies de l'Internet, et sont bien trop fréquentes aujourd'hui (cf. RFC 4987 ou RFC 4732 pour des exemples). Bien des réseaux n'ont pas les moyens de se défendre seuls et font donc appel à un service de protection (payant, en général, mais il existe aussi des services comme Deflect). Ce service fera la guerre à leur place, recevant le trafic (via des manips DNS ou BGP), l'analysant, le filtrant et envoyant ce qui reste au client. Typiquement, le client DOTS sera chez le réseau attaqué, par exemple en tant que composant d'un IDS ou d'un pare-feu, et le serveur DOTS sera chez le service de protection. Notez donc que client et serveur DOTS sont chez deux organisations différentes, communiquant via le canal de signalisation (signal channel), qui fait l'objet de ce RFC.

La section 3 de notre RFC expose les grands principes du protocole utilisé sur ce canal de signalisation. Il repose sur CoAP, un équivalent léger de HTTP, ayant beaucoup de choses communes avec HTTP. Le choix d'un protocole différent de HTTP s'explique par les spécificités de DOTS : on l'utilise quand ça va mal, quand le réseau est attaqué, et il faut donc pouvoir continuer à fonctionner même quand de nombreux paquets sont perdus. CoAP a les caractéristiques utiles pour DOTS, il est conçu pour des réseaux où il y aura des pertes, il tourne sur UDP, il permet des messages avec ou sans accusé de réception, il utilise peu de ressources, il peut être sécurisé par DTLSTCP est également utilisable mais UDP est préféré, pour éviter le head-of-line blocking. CoAP est normalisé dans le RFC 7252. Parmi les choses à retenir, n'oubliez pas que l'encodage du chemin dans l'URI est un peu spécial, avec une option Uri-Path: par segment du chemin (RFC 7252, section 5.10.1). Par abus de langage, j'écrirai « le client CoAP demande /foo/bar/truc.cbor » alors qu'il y aura en fait trois options Uri-Path: :

Uri-Path: "foo"
Uri-Path: "bar"
Uri-Path: "truc.cbor" 
  

Par défaut, DOTS va utiliser le port 4646 (et non pas le port par défaut de CoAP, 5684, pour éviter toute confusion avec d'autres services tournant sur CoAP). Ce port a été choisi pour une bonne raison, je vous laisse la chercher, la solution est à la fin de cet article. Le plan d'URI sera coaps ou coaps+tcp (RFC 7252, section 6, et RFC 8323, section 8.2).

Le fonctionnement de base est simple : le client DOTS se connecte au serveur, divers paramètres sont négociés. Des battements de cœur peuvent être utilisés (par le client ou par le serveur) pour garder la session ouverte et vérifier son bon fonctionnement. En cas d'attaque, le client va demander une action d'atténuation. Pendant que celle-ci est active, le serveur envoie de temps en temps des messages donnant des nouvelles. L'action se terminera, soit à l'expiration d'un délai défini au début, soit sur demande explicite du client. Le serveur est connu du client par configuration manuelle, ou bien par des techniques de découverte comme celles du RFC 8973.

Les messages sont encodés en CBOR (RFC 8949). Rappelez-vous que le modèle de données de CBOR est très proche de celui de JSON, et notre RFC spécifie donc les messages avec une syntaxe JSON, même si ce n'est pas l'encodage utilisé sur le câble. Pour une syntaxe formelle des messages, le RFC utilise YANG (cf. RFC 7951). Le type MIME des messages est application/dots+cbor.

La section 4 du RFC décrit les différents messages possibles plus en détail. Je ne vais pas tout reprendre ici, juste donner quelques exemples. Les URI commencent toujours par /.well-known/dots (.well-known est normalisé dans le RFC 8615, et dots est désormais enregistré à l'IANA). Les différentes actions ajouteront au chemin dans l'URI /mitigate pour les demandes d'actions d'atténuation, visant à protéger de l'attaque, /hb pour les battements de cœur, etc.

Voici par exemple une demande de protection, effectuée avec la méthode CoAP PUT :

Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"

{
       ... Données en CBOR (représentées en JSON dans le RFC et dans
       cet article, pour la lisibilité).
}    
  

L'URI, en notation traditionnelle, sera donc /.well-known/dots/mitigate/cuid=dz6pHjaADkaFTbjr0JGBpw/mid=123. CUID veut dire Client Unique IDentifier et sert à identifier le client DOTS, MID est Mitigation IDentifier et identifie une demande d'atténuation particulière. Si ce client DOTS fait une autre demande de palliation, le MID changera mais le CUID sera le même.

Que met-on dans le corps du message ? On a de nombreux champs définis pour indiquer ce qu'on veut protéger, et pour combien de temps. Par exemple, on pourrait avoir (je rappelle que c'est du CBOR, format binaire, en vrai) :

     {
       "ietf-dots-signal-channel:mitigation-scope": {
         "scope": [
           {
             "target-prefix": [
                "2001:db8:6401::1/128",
                "2001:db8:6401::2/128"
              ],
             "target-port-range": [
               {
                 "lower-port": 80
               },
               {
                 "lower-port": 443
               }
              ],
              "target-protocol": [
                6
              ],
             "lifetime": 3600
           }
         ]
       }
     }
  

Ici, le client demande qu'on protège 2001:db8:6401::1 et 2001:db8:6401::2 (target veut dire qu'ils sont la cible d'une attaque, pas qu'on veut les prendre pour cible), sur les ports 80 et 443, en TCP, pendant une heure. (lower-port seul, sans upper-port indique un port unique, pas un intervalle.)

Le serveur va alors répondre avec le code 2.01 (indiquant que la requête est acceptée et traitée) et des données :

  {
     "ietf-dots-signal-channel:mitigation-scope": {
        "scope": [
           {
             "mid": 123,
             "lifetime": 3600
           }
         ]
      }
   }
  

La durée de l'action peut être plus petite que ce que le client a demandé, par exemple si le serveur n'accepte pas d'actions trop longues. Évidemment, si la requête n'est pas correcte, le serveur répondra 4.00 (format invalide), si le client n'a pas payé, 4.03, s'il y a un conflit avec une autre requête, 4.09, etc. Le serveur peut donner des détails, et la liste des réponses possibles figure dans des registres IANA, comme celui de l'état d'une atténuation, ou celui des conflits entre ce qui est demandé et d'autres actions en cours.

Le client DOTS peut ensuite récupérer des informations sur une action de palliation en cours, avec la méthode CoAP GET :

Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"    
  

Ce GET /.well-known/dots/mitigate/cuid=dz6pHjaADkaFTbjr0JGBpw/mid=123 va renvoyer de l'information sur l'action d'identificateur (MID) 123 :

   {
     "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
         {
           "mid": 123,
           "mitigation-start": "1507818393",
           "target-prefix": [
                "2001:db8:6401::1/128",
                "2001:db8:6401::2/128"
           ],
           "target-protocol": [
             6
           ],
           "lifetime": 1755,
           "status": "attack-stopped",
           "bytes-dropped": "0",
           "bps-dropped": "0",
           "pkts-dropped": "0",
           "pps-dropped": "0"
         }
       ]
     }
   }
  

Les différents champs de la réponse sont assez évidents. Par exemple, pkts-dropped indique le nombre de paquets qui ont été jetés par le protecteur.

Pour mettre fin aux actions du système de protection, le client utilise évidemment la méthode CoAP DELETE :

Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
  

Le client DOTS peut se renseigner sur les capacités du serveur avec un GET de /.well-known/dots/config.

Ce RFC décrit le canal de signalisation de DOTS. Le RFC 8783, lui, décrit le canal de données. Le canal de signalisation est prévu pour faire passer des messages de petite taille, dans un environnement hostile (attaque en cours). Le canal de données est prévu pour des données de plus grande taille, dans un environnement où les mécanismes de transport normaux, comme HTTPS, sont utilisables. Typiquement, le client DOTS utilise le canal de données avant l'attaque, pour tout configurer, et le canal de signalisation pendant l'attaque, pour déclencher et arrêter l'atténuation.

Les messages possibles sont modélisés en YANG. YANG est normalisé dans le RFC 7950. Notez que YANG avait été initialement créé pour décrire les commandes envoyées par NETCONF (RFC 6241) ou RESTCONF (RFC 8040) mais ce n'est pas le cas ici : DOTS n'utilise ni NETCONF, ni RESTCONF mais son propre protocole basé sur CoAP. La section 5 du RFC contient tous les modules YANG utilisés.

La mise en correspondance des modules YANG avec l'encodage CBOR figure dans la section 6. (YANG permet une description abstraite d'un message mais ne dit pas, à lui tout seul, comment le représenter en bits sur le réseau.) Les clés CBOR sont toutes des entiers ; CBOR permet d'utiliser des chaînes de caractères comme clés mais DOTS cherche à gagner de la place. Ainsi, les tables de la section 6 nous apprennent que le champ cuid (Client Unique IDentifier) a la clé 4, suivie d'une chaîne de caractères en CBOR. (Cette correspondance est désormais un registre IANA.) D'autre part, DOTS introduit une étiquette CBOR, 271 (enregistrée à l'IANA, cf. RFC 8949, section 3.4) pour marquer un document CBOR comme lié au protocole DOTS.

Évidemment, DOTS est critique en matière de sécurité. S'il ne fonctionne pas, on ne pourra pas réclamer une action de la part du service de protection. Et s'il est mal authentifié, on risque de voir le méchant envoyer de faux messages DOTS, par exemple en demandant l'arrêt de l'atténuation. La section 8 du RFC rappelle donc l'importance de sécuriser DOTS par TLS ou plutôt, la plupart du temps, par son équivalent pour UDP, DTLS (RFC 6347). Le RFC insiste sur l'authentification mutuelle du serveur et du client, chacun doit s'assurer de l'identité de l'autre, par les méthodes TLS habituelles (typiquement via un certificat). Le profil de DTLS recommandé (TLS est riche en options et il faut spécifier lesquelles sont nécessaires et lesquelles sont déconseillées) est en section 7. Par exemple, le chiffrement intègre est nécessaire.

La section 11 revient sur les questions de sécurité en ajoutant d'autres avertissements. Par exemple, TLS ne protège pas contre certaines attaques par déni de service, comme un paquet TCP RST (ReSeT). On peut sécuriser la communication avec TCP-AO (RFC 5925) mais c'est un vœu pieux, il est très peu déployé à l'heure actuelle. Ah, et puis si les ressources à protéger sont identifiées par un nom de domaine, et pas une adresse ou un préfixe IP (target-fqdn au lieu de target-prefix), le RFC dit qu'évidemment la résolution doit être faite avec DNSSEC.

Question mises en œuvre, DOTS dispose d'au moins quatre implémentations, dont l'interopérabilité a été testée plusieurs fois lors de hackathons IETF (la première fois ayant été à Singapour, lors de l'IETF 100) :

Notez qu'il existe des serveurs de test DOTS publics comme coaps://dotsserver.ddos-secure.net:4646.

Ah, et la raison du choix du port 4646 ? C'est parce que 46 est le code ASCII pour le point (dot en anglais) donc deux 46 font deux points donc dots.

L'annexe A de notre RFC résume les principaux changements depuis le RFC 8782. Le principal changement touche les modules YANG, mis à jour pour réparer une erreur et pour tenir compte du RFC 8791. Il y a aussi une nouvelle section (la 9), qui détaille les codes d'erreur à renvoyer, et l'espace des valeurs des attributs a été réorganisé… Rien de bien crucial, donc.


Téléchargez le RFC 9132


L'article seul

Indiquer la consommation énergétique par requête a-t-il un sens ?

Première rédaction de cet article le 9 octobre 2021


Dans les débats sur l'empreinte environnementale du numérique, on voit souvent citer des coûts énergétiques par opération élémentaire, du genre « un message consomme X joules » ou bien « une recherche Google brûle autant de charbon que faire chauffer N tasses de café ». Ces chiffres sont trompeurs, et voici pourquoi.

Lorsqu'ils sont cités, ces chiffres sont souvent accompagnés d'injonctions à la sobriété. « N'envoyez pas ce courrier que vous étiez en train d'écrire et vous sauverez un arbre. » En effet, annoncer des coûts environnementaux par requête donne à penser que, si on s'abstient d'une action, le coût diminuera d'autant. Mais ce n'est pas ainsi que les choses se passent. Ces chiffres « par opération » sont obtenus (normalement…) en divisant la consommation énergétique totale par le nombre d'opérations. C'est classique, c'est le calcul de la moyenne. Si on connait la consommation d'essence de toutes les voitures en France, et le nombre de voitures, calculer la consommation moyenne de chaque voiture est simple. Certes, il faudrait tenir compte du fait qu'une petite voiture consomme moins qu'un SUV mais, en première approximation, cela a du sens de dire « chaque voiture dévore N litres d'essence par an ». Et il est raisonnable d'en déduire que de mettre des voitures supplémentaires sur la route augmentera cette consommation, de façon proportionnelle à l'augmentation du nombre de véhicules. La proportionnalité s'applique également à la consommation d'essence rapportée au nombre de kilomètres : la quantité de carburant brûlé est à peu près proportionnelle à ce nombre de kilomètres. Si je roule deux fois moins, je consomme deux fois moins d'essence, et ça diminuera le relâchement de gaz à effet de serre. Dans tous ces cas, la moyenne est un concept mathématique parfaitement valable.

Mais tout ne fonctionne pas ainsi : la consommation électrique des équipements réseau, par exemple, n'est pas linéaire, elle est même souvent constante (cela dépend des équipements ; il y un coût constant et un variable, ce dernier étant en général plus faible que le coût constant). Que le routeur passe des paquets ou pas, il consommera la même quantité d'énergie. Envoyer deux fois moins de courriers ne diminuera donc pas la consommation énergétique de votre box, ou du reste de l'Internet. Ainsi, le tweet de France Culture « Savez-vous que chaque mail envoyé, chaque vidéo regardée, émet des gaz à effet de serre ? » est faux et trompeur. Si vous renoncez à votre soirée devant Netflix, la consommation électrique des routeurs, serveurs et autres équipements ne changera pas forcément, et calculer une moyenne par film ou série visionné n'a donc pas beaucoup de sens. La moyenne n'est légitime que si la dépendance est à peu près linéaire.

Bon, OK mais, même si la moyenne n'a pas de sens et que les déclarations sensationnalistes « envoyer un courrier, c'est relâcher X grammes de dioxyde de carbone dans l'atmosphère » sont à côté de la plaque, il n'en reste pas moins que le numérique a une empreinte environnementale, non ? Oui, la construction et l'exploitation des réseaux informatiques a un coût (y compris environnemental). Ce n'est pas un coût à l'utilisation, d'accord. Mais si les gens augmentent leur activité en ligne, par exemple si ce blog double son nombre de visiteurs, il faudra déployer davantage de matériels (dont la construction est le principal facteur d'empreinte environnementale du numérique) et il y aura donc bien un résultat (néfaste…) sur l'environnement. (Le matériel nouveau sera plus efficace : un routeur capable de 100 Gb/s ne consommera pas dix fois qu'un routeur capable de 10 Gb/s. Mais sa fabrication, on l'a vu, a un fort coût environnemental.) Bref, chaque requête individuelle ne pèse rien, mais leur augmentation va mener à une empreinte accrue sur l'environnement. (En sens inverse, on pourrait se dire que, si les gens arrêtent de regarder Netflix, cette société va éteindre certains équipements et que cela diminuera la consommation d'électricité. Mais c'est moins certain et, rappelez-vous, c'est surtout la fabrication qui coûte. Une fois le serveur installé dans l'armoire, il a déjà imprimé l'essentiel de sa marque sur l'environnement.)

Ce raisonnement (comme quoi l'effet attendu de la sobriété n'est pas de diminuer la consommation énérgétique aujourd'hui, mais de limiter les dépenses de matériel demain) est correct et justifie donc qu'on porte attention aux conséquences écologiques du numérique. La frugalité est donc une bonne chose mais attention à ne pas la justifier par des arguments faux, comme ces coûts par requête.

Est-ce qu'à défaut d'être scientifiquement pertinent, les arguments fondés sur une moyenne sont au moins efficaces pour la communication, sensibilisant les utilisatrices et utilisateurs à l'importance de l'empreinte environnementale du numérique ? Même si c'était le cas, ce ne serait pas à mon avis (mon avis de rationaliste convaincu) une raison suffisante pour l'utiliser. Tromper les gens n'est pas une bonne idée. Mais, en plus, je ne suis même pas sûr que l'argument soit efficace : la plupart des gens le comprendront de travers, croyant que tel ou tel geste d'extinction va vraiment diminuer tout de suite l'empreinte environnementale.

Le point essentiel de cet article était que la moyenne n'est pas forcément pertinente. Mais, sinon, que peut-on faire pour que l'empreinte environnementale cesse d'augmenter ou en tout cas que cette augmentation ralentisse ? Le discours médiatique dominant est plein de conseils absurdes et évite soigneusement de s'attaquer à des usages sacrés. On a vu ainsi un politicien qui dénonçait l'utilisation de l'Internet pour regarder du « porno dans l'ascenseur » mais qui se prenait en photo regardant un match de foot depuis sa voiture. (Le sport-spectacle est intouchable, quand on est un politicien ambitieux, pas question de le critiquer.)

Donc, voici ma liste de quelques « gisements d'économie énergétique » importants qui ne sont pas toujours mentionnés :

  • La publicité est une source importante de dégâts environnementaux, par l'encouragement à la consommation mais aussi par un effet plus direct, l'importance des infrastructures qui sont dédiées à son fonctionnement en ligne. Il est grinçant de voir sur le Web des articles critiquant vertueusement l'« enfer numérique » mais qui contiennent des publicités. Pour l'utilisateur·rice final·e, installer un bloqueur de publicité est une bien meilleure action écologique que renoncer à envoyer un message. Mais les médias n'en parleront pas (la publicité est également sacrée).
  • La surveillance de masse est également très coûteuse du point de vue environnemental, car elle aussi dépend d'infrastructures complexes et consommatrices (par exemple pour la vidéo-surveillance, et c'est encore pire avec la reconnaissance faciale). De même qu'on voit des articles anti-Internet (lui reprochant sa consommation électrique) qui sont hébergés sur des sites Web avec des publicités, il est fréquent de trouver des traqueurs comme ceux de Google Analytics sur ces sites. Lutter contre le capitalisme de surveillance est plus écologique que de ne pas envoyer le courrier que vous venez d'écrire.
  • La fabrication du matériel est très coûteuse du point de vue environnemental. Changer moins souvent de matériel est donc également une action utile.
  • Question frugalité, il est important de promouvoir les techniques qui imposent le moins de contraintes sur le réseau et sur les machines : LEDBAT (RFC 6297) comme algorithme de transport ou Gemini côté application.
  • En moins disruptif, on peut noter que les applications et sites Web d'aujourd'hui sont loin d'être des modèles de frugalité. Leur consommation importante de ressources (notamment de temps de processeur) pousse rapidement les machines les plus anciennes dans la catégorie « vieux trucs à jeter ». Si vous êtes développeur ou développeuse, une des choses les plus importantes que vous pouvez faire pour le climat est de développer des applications et sites plus frugaux. (Et d'envoyer promener le marketeux qui dira « c'est moche, c'est trop austère, le client ne va pas aimer ».) C'est ce que prône par exemple le courant small Web ou slow Web. (On peut aussi citer l'intéressant Low-tech magazine, pour les bricoleur·ses.)

On trouve en ligne (ou sur papier…) plein de ressources sur l'empreinte environnementale du numérique. Toutes ne sont pas sérieuses, loin de là. En voici quelques-unes qui sont utiles (ce qui ne veut pas dire que je suis 100 % d'accord avec leurs auteurs) :


L'article seul

Plusieurs domaines de premier niveau en panne

Première rédaction de cet article le 7 octobre 2021


Le monde des noms de domaine a vu aujourd'hui un incident rare : la panne complète d'un TLD, .club, et même de plusieurs autres.

Commençons par les faits : ce jeudi 7 octobre, vers 1035 UTC, plus moyen de résoudre aucun nom de domaine en .club. Tous les résolveurs renvoyaient le code de retour SERVFAIL (SERver FAILure). Une telle panne complète d'un TLD est rare (la dernière de .com a eu lieu en 1997).

Pour le déboguage, on peut regarder les jolies images de DNSviz, ou bien utiliser dig :


%  dig NS club

; <<>> DiG 9.16.21 <<>> NS club
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30784
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;club.			IN NS

;; Query time: 2606 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 07 13:55:28 CEST 2021
;; MSG SIZE  rcvd: 33

  

Un test avec les sondes RIPE Atlas montrait que le problème n'était pas juste avec mon résolveur :

% blaeu-resolve --type SOA -r 100 club
[ERROR: SERVFAIL] : 81 occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633603168 1800 300 604800 1800] : 1 occurrences 
Test #32444898 done at 2021-10-07T11:55:21Z
  

La raison ? Les serveurs faisant autorité pour .club répondaient tous SERVFAIL :

    
 dig @2610:a1:1076::d7 SOA club

; <<>> DiG 9.16.21 <<>> @2610:a1:1076::d7 SOA club
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58363
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;club.			IN SOA

;; Query time: 66 msec
;; SERVER: 2610:a1:1076::d7#53(2610:a1:1076::d7)
;; WHEN: Thu Oct 07 13:57:39 CEST 2021
;; MSG SIZE  rcvd: 33

  

Contrairement à la récente panne de Facebook, il ne s'agissait donc pas d'un problème de routage ; les serveurs répondaient bien, mais mal. (Typiquement, quand un serveur faisant autorité répond SERVFAIL, c'est qu'il n'a pas pu charger les données de la zone, par exemple suite à une erreur de syntaxe dans le fichier de zone.)

Le TLD .hsbc (même opérateur technique de registre et même hébergeur DNS) a été frappé de la même façon :

% blaeu-resolve --type SOA -r 100 hsbc
[ERROR: SERVFAIL] : 90 occurrences 
[ns1.dns.nic.hsbc. admin.tldns.godaddy. 1633405738 1800 300 604800 1800] : 1 occurrences 
Test #32445325 done at 2021-10-07T12:23:28Z
  

La panne semble avoir été complètement résolue vers 1410 UTC :

% blaeu-resolve --type SOA -r 100 club
[ns1.dns.nic.club. admin.tldns.godaddy. 1633615537 1800 300 604800 1800] : 90 occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633613754 1800 300 604800 1800] : 1 occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633615179 1800 300 604800 1800] : 4 occurrences 
Test #32446901 done at 2021-10-07T14:14:47Z
  

Quelques informations publiques :


L'article seul

La panne Facebook du 4 octobre 2021

Première rédaction de cet article le 4 octobre 2021
Dernière mise à jour le 5 octobre 2021


Aujourd'hui, Facebook a connu une panne importante. Que s'est-il passé ? On sait désormais que la cause racine était un problème de configuration des routeurs BGP. A-t-on des détails ?

Le message d'erreur de beaucoup d'utilisateurs : facebook-octobre-2021.jpg

Je vous le dis tout de suite, je n'ai pas d'informations internes à Facebook, et je n'ai pas fait une longue enquête. N'attendez donc pas de révélations extraordinaires. Commençons par les faits. Aujourd'hui, lundi 4 octobre vers 1550 UTC, les services de Facebook, y compris WhatsApp et Instagram étaient en panne. (La panne a duré environ 6 heures.) Les utilisateurs avaient typiquement un message faisant allusion au nom de domaine, qui ne marchait pas.

Arrivé là, il faut se rappeler que les noms de domaine et le protocole DNS sont critiques pour le fonctionnement de l'Internet. Quasiment toute activité sur l'Internet commence par une requête DNS. Si elle ne fonctionne pas, presque rien n'est possible. Mais il faut aussi se rappeler que ce DNS ne fonctionne pas sur un réseau parallèle : il utilise l'Internet lui aussi, les paquets DNS circulent dans des paquets IP et que donc un problème affectant IP va souvent se manifester comme un problème DNS (puisque c'est par le DNS qu'on commence une session).

Demandons aux sondes RIPE Atlas de trouver les serveurs de noms de facebook.com :

% blaeu-resolve -r 200 --type NS facebook.com
[a.ns.facebook.com. b.ns.facebook.com. c.ns.facebook.com. d.ns.facebook.com.] : 97 occurrences 
[ERROR: SERVFAIL] : 48 occurrences 
[] : 3 occurrences 
Test #32421708 done at 2021-10-04T16:16:14Z

Une partie y arrive, probablement parce que l'information était encore dans la mémoire de leur résolveur. Mais ce n'est pas le cas de toutes. En effet, pendant la panne, les serveurs DNS faisant autorité pour facebook.com ne répondaient pas. Voici la liste de ces serveurs, obtenue avec dig en demandant à un serveur de la zone parente, .com (on ne pouvait pas faire un dig « normal » puisque le résolveur qu'il utilise aurait essayé de joindre les serveurs en panne) :


% dig @a.gtld-servers.net. A a.ns.facebook.com. 

; <<>> DiG 9.16.15-Debian <<>> @a.gtld-servers.net. A a.ns.facebook.com.
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4686
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
...
;; AUTHORITY SECTION:
facebook.com.		172800 IN NS a.ns.facebook.com.
facebook.com.		172800 IN NS b.ns.facebook.com.
facebook.com.		172800 IN NS c.ns.facebook.com.
facebook.com.		172800 IN NS d.ns.facebook.com.
...
;; ADDITIONAL SECTION:
a.ns.facebook.com.	172800 IN A 129.134.30.12
a.ns.facebook.com.	172800 IN AAAA 2a03:2880:f0fc:c:face:b00c:0:35
...
;; Query time: 16 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Mon Oct 04 18:24:55 CEST 2021
;; MSG SIZE  rcvd: 833

Maintenant, demandons aux sondes RIPE Atlas d'interroger un de ces serveurs, a.ns.facebook.com :

%  blaeu-resolve -r 200 --type NS --nameserver 129.134.30.12 --nsid facebook.com 
Nameserver 129.134.30.12
[] : 3 occurrences 
[TIMEOUT] : 189 occurrences 
Test #32421749 done at 2021-10-04T16:25:09Z

On le voit, l'échec est total. Un peu plus tard, ça marche un peu mieux :

%  blaeu-resolve -r 200 --type NS --nameserver 129.134.30.12 --nsid facebook.com 
Nameserver 129.134.30.12
[TIMEOUT] : 192 occurrences 
[ERROR: SERVFAIL] : 3 occurrences 
[a.ns.facebook.com. b.ns.facebook.com. c.ns.facebook.com. d.ns.facebook.com.] : 1 occurrences 
Test #32421800 done at 2021-10-04T16:35:54Z
  

Donc, les choses sont claires : les serveurs DNS faisant autorité ne marchaient pas. Cela explique la panne vue par les utilisateurs. Maintenant, pourquoi ces quatre serveurs (et davantage de machines physiques, en raison de l'anycast) seraient-ils tous tombés en même temps ? Il y a plusieurs hypothèses, comme une erreur de configuration propagée automatiquement à toutes les machines (automatiser les configurations simplifie la vie mais les erreurs ont des conséquences plus graves). Mais on peut noter autre chose : tous ces serveurs sont dans le même AS, le 32934, l'AS de Facebook. Un problème de routage dans l'AS, empêchant les paquets d'arriver, peut également empêcher les serveurs DNS de répondre. Mettre tous ses œufs dans le même panier est décidément une mauvaise pratique. (Notez que ZoneMaster teste cette mauvaise pratique et vous alerte.) C'est un problème connu, déjà signalé par le RFC 2182, en 1997…

Creusons cette idée. Plusieurs observateurs ont noté que les préfixes IP de Facebook ont subitement disparu de la DFZ. Cela explique que les serveurs DNS soient devenus injoignables. Les sondes RIPE Atlas montrent que les traceroute ne vont pas très loin, les préfixes n'étant plus annoncés :

% blaeu-traceroute -r 10 --format 129.134.30.12
Measurement #32421753 Traceroute 129.134.30.12 uses 10 probes
9 probes reported
Test #32421753 done at 2021-10-04T16:26:49Z
From:  89.152.207.6    2860    NOS_COMUNICACOES, PT
Source address:  89.152.207.6
Probe ID:  1001047
1    ['!', '!', '!']
2    10.137.196.193    NA    NA    [10.743, 10.446, 6.726]
3    10.255.48.82    NA    NA    [12.727, 15.974, 14.397]
4    ['*', '*', '*']
5    ['*', '*', '*']
6    ['*', '*', '*']
7    ['*', '*', '*']
8    ['*', '*', '*']
255    ['*', '*', '*']

From:  188.254.182.226    43205    BULSATCOM-BG-AS Sofia, BG
Source address:  192.168.88.13
Probe ID:  15646
1    192.168.88.1    NA    NA    [0.66, 0.415, 0.4]
2    188.254.180.1    43205    BULSATCOM-BG-AS Sofia, BG    [1.552, 1.614, 1.231]
3    46.40.64.1    43205    BULSATCOM-BG-AS Sofia, BG    [2.223, '*', '*']
4    ['*', '*', '*']
5    ['*', '*', '*']
6    ['*', '*', '*']
7    ['*', '*', '*']
8    ['*', '!', '!', '!', '!', '!', '!', '*', '*']
255    ['*', '*', '*']

Des préfixes IP plus généraux sont parfois restés. Ainsi, le 129.134.30.0/24 d'un des serveurs a disparu mais un /17 plus générique est resté. On voit ici (source: RIPEstat, le retrait du /24 puis son rétablissement (129.134.30.0/23, 129.134.31.0/24 et bien d'autres avaient subi le même sort) : facebook-octobre-2021-ripestat.jpg

La panne DNS semble donc avoir été une conséquence d'une fausse manœuvre BGP. Cela explique, par exemple, que le service Tor de Facebook, facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion, ne marche pas non plus (il ne dépend pas du DNS, .onion est spécial).

Le réseau social Instagram pendant la panne. Bien que ses serveurs DNS répondaient parfaitement, le serveur Web dépend de Facebook : facebook-octobre-2021-instagram.png

Plusieurs personnes sur les réseaux sociaux ont également noté que tous les serveurs faisant autorité pour facebook.com étaient sous le même domaine (ns.facebook.com). Ce n'est pas forcément une mauvaise idée. Certes, cela oblige à publier des colles (les adresses IP des serveurs), ce qui complique l'administration. Et, si le domaine en question a un problème, par exemple administratif, cela frappe tous les serveurs. D'un autre côté, cela évite de dépendre de tiers, ce qui est pourquoi cette pratique est parfois recommandée (par exemple par l'ANSSI).

En revanche, il était tout à fait justifié de noter que les TTL de Facebook sont anormalement bas : 300 secondes. Cela veut dire que si la panne dure plus de 5 minutes, ce qui a été le cas, les mémoires des résolveurs ne servent plus à rien. La robustesse du DNS nécessite des TTL bien plus longs (supérieurs à la durée d'une panne typique).

Ah, et puis rappelez-vous que Facebook n'est pas tout l'Internet : tous les autres services fonctionnaient parfaitement (sauf ceux qui avaient choisi de dépendre de Facebook).

Articles dans les médias :

La panne vue par l'excellent service de vérification DNSviz (le même résultat, en ligne) : facebook-octobre-2021-dnsviz.jpg


L'article seul

RFC 9117: Revised Validation Procedure for BGP Flow Specifications

Date de publication du RFC : Août 2021
Auteur(s) du RFC : J. Uttaro (AT&T), J. Alcaide, C. Filsfils, D. Smith (Cisco), P. Mohapatra (Sproute Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 28 septembre 2021


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.


Téléchargez le RFC 9117


L'article seul

Fiche de lecture : L'enfer numérique

Auteur(s) du livre : Guillaume Pitron
Éditeur : Les Liens qui Libèrent
979-10-209-0996-1
Publié en 2021
Première rédaction de cet article le 28 septembre 2021


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

Je ne vais pas citer les articles publiés dans les médias sur ce livre, tous unanimement élogieux et sans jamais une seule critique. La corporation médiatique se serre les coudes, face à un Internet qui a écorné leur monopole de la parole. Mais, sinon, une autre critique de ce livre, sous un angle assez différent, celle de laem.


L'article seul

RFC 9115: An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates

Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : Y. Sheffer (Intuit), D. López, A. Pastor Perales (Telefonica I+D), T. Fossati (ARM)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF acme
Première rédaction de cet article le 21 septembre 2021


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.


Téléchargez le RFC 9115


L'article seul

Articles des différentes années : 2021  2020  2019  2018  2017  2016  2015  Précédentes années

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

Un article de ce blog au hasard.