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.
Date de publication du RFC : Décembre 2021
Auteur(s) du RFC : J. Gould, R. Wilhelm (VeriSign)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 31 décembre 2021
Le protocole EPP d'avitaillement des noms de domaine permet, entre autres opérations, de transférer un domaine d'un client (typiquement un BE) à un autre. Cette opération ouvre de sérieux problèmes de sécurité, le transfert pouvant être utilisé pour détourner un nom de domaine. En général, la sécurisation de ce transfert est faite par un mot de passe stocké en clair. Notre RFC décrit une méthode pour gérer ces mots de passe qui évite ce stockage, et qui gêne sérieusement les transferts malveillants.
EPP est normalisé dans le RFC 5730 et c'est ce document qui décrit le cadre général
d'autorisation d'un transfert de domaines. La forme exacte que prend
l'autorisation dépend du type d'objets qu'on gère avec EPP. Pour les
domaines (RFC 5731), c'est un élément
<authInfo>
, qui peut contenir divers
types de sous-élements mais le plus fréquent est un simple
mot de passe (parfois appelé « code de
transfert » ou « code d'autorisation », ou simplement « authinfo »),
comme dans cet exemple, une réponse à une commande EPP
<info>
, où le mot de passe est
« 2fooBAR » :
<domain:infData> <domain:name>example.com</domain:name> ... <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> ... <domain:authInfo> <domain:pw>2fooBAR</domain:pw> </domain:authInfo> </domain:infData>
L'utilisation typique de ce mot de passe est que le client (en
général un BE)
le crée, le stocke en clair, l'envoie au serveur, qui le
stocke. Lors d'un transfert légitime, le BE gagnant recevra ce mot
de passe (typiquement via le titulaire de l'objet, ici un nom de
domaine) et le transmettra au registre (RFC 5731, section 3.2.4). Ici, le BE gagnant demande à son
client le code d'autorisation qu'il a normalement obtenu via le BE
perdant (si le client est vraiment le titulaire légitime) : Et ici le BE perdant indique à
son client le code d'autorisation :
(registar = BE)
Notez que la façon d'autoriser les transferts, et d'accéder aux informations d'autorisation, dépend de la politique du registre. Les RFC sur EPP normalisent la technique mais pas la politique. Par exemple, lorsqu'un BE demande un transfert sans fournir d'information d'autorisation, certains registres refusent immédiatement le transfert, tandis que d'autres le mettent en attente d'une acceptation ou d'un refus explicite. De même, certains registres permettent de récupérer l'information d'autorisation, comme dans l'exemple ci-dessus, alors que d'autres (comme CentralNic) refusent.
Même chose pour d'autres types d'objets comme les contacts (RFC 5733) même si en pratique la pratique du transfert est plus rare pour ces types. Le mot de passe étant typiquement stocké en clair chez le client, pour pouvoir être donné en cas de transfert, on voit les risques que cela pose en cas d'accès à la base du BE. Aujourd'hui, stocker un mot de passe en clair est nettement considéré comme une mauvaise pratique de sécurité.
À la place, notre RFC décrit, non pas une modification du protocole EPP, mais une nouvelle procédure, une façon créative de se servir du protocole existant pour gérer ces informations d'autorisation de manière plus sérieuse : l'objet (par exemple le nom de domaine) est créé sans information d'autorisation, le serveur EPP (par exemple le registre de noms de domaine) doit refuser le transfert si cette information est manquante. Lors d'un transfert légitime, le client (par exemple un BE) perdant va générer un mot de passe, le transmettre au registre et à son client (typiquement le titulaire du nom de domaine) et ne pas le stocker. Le registre stockera le mot de passe uniquement sous forme condensée et, lorsqu'il recevra la demande de transfert accompagnée d'un mot de passe, il pourra condenser ce mot et vérifier qu'il correspond bien à celui stocké. Le mot ne servira qu'une fois et l'information d'autorisation est détruite après le succès du transfert. Tout ceci ne nécessite pas de modification du protocole, mais, dans certains cas, une modification des pratiques des différents acteurs (par exemple, le serveur EPP doit accepter qu'un objet soit créé sans information d'autorisation, et doit considérer que cela vaut refus de tout transfert).
Le RFC note que la norme EPP ne décrit, logiquement, que le protocole, c'est-à-dire l'interaction entre les deux machines, mais pas ce que fait chaque machine de son côté. Ainsi, la nécessité de stocker les mots de passe de manière sécurisée n'est pas imposée par EPP (mais est néanmoins une bonne pratique).
D'autre part, EPP ne prévoit pas explicitement de durée de vie pour les mots de passe (mais n'interdit pas non plus de les supprimer au bout d'un temps donné, ce qui va être justement la technique de notre RFC).
Petite révision sur les acteurs de l'avitaillement de noms de domaine en section 2 du RFC. La norme EPP parle de client et de serveur, notions techniques, mais du point de vue business, il y a trois acteurs (cf. la terminologie dans le RFC 8499), le registre (qui gère le serveur EPP), le bureau d'enregistrement (BE, qui gère le client EPP) et le titulaire (qui se connecte à son BE via une interface Web ou une API). Dans beaucoup de domaines d'enregistrement, il n'y a aucun lien direct entre le titulaire et le registre, tout devant passer par le BE.
Maintenant, place à la description de la nouvelle manière de faire
des transferts. Bien qu'elle ne change pas le protocole, qu'elle ne
soit qu'une nouvelle façon d'utiliser ce qui existe déjà dans EPP,
elle doit se signaler lors de la connexion EPP, avec
l'espace de noms
urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
(enregistré
à l'IANA). En effet, la nouvelle manière a besoin que le
serveur accepte des choses qui sont autorisées par EPP mais pas
obligatoires, notamment :
NULL
dans une base SQL),<update>
,<info>
,
Le serveur, lui, en recevant
urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
,
peut compter que le client EPP saura :
L'autorisation d'information dans l'élement XML
<domain:pw>
(RFC 5731, section 3.2.4) est un mot de passe qui doit être
difficile à deviner par un attaquant. Idéalement, il doit être
aléatoire ou équivalent (RFC 4086). Le RFC
calcule que pour avoir 128 bits d'entropie, avec uniquement les
caractères ASCII imprimables, il faut environ 20
caractères.
Pour compenser l'absence de la notion de durée de vie de l'information d'autorisation dans EPP, le client ne doit définir une information d'autorisation que lorsqu'un transfert est demandé, et supprimer cette information ensuite. La plupart du temps, le domaine n'aura pas d'information d'autorisation, et les transferts seront donc refusés.
L'information d'autorisation, comme tout mot de passe, ne doit plus être stockée en clair, mais sous forme d'un condensat. Le BE perdant ne doit pas la stocker (il la génère, la passe au titulaire et l'oublie ensuite). Le BE gagnant ne doit la stocker que le temps de finaliser le transfert. Évidemment, toute la communication EPP doit être chiffrée (RFC 5734). Lors d'une demande de transfert, le registre va vérifier qu'un condensat de l'information d'autorisation transmise par le BE gagnant correspond à ce que le BE perdant avait envoyé. L'information vide est un cas particulier, le registre ne doit pas tester l'égalité mais rejeter le transfert.
La section 4 explique en détail le processus de transfert avec cette nouvelle méthode :
Voici en EPP quelques messages pour réaliser ces différentes opérations. D'abord, la création d'un nom (notez le mot de passe vide) :
<create> <domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> <domain:name>example.test</domain:name> <domain:authInfo> <domain:pw/> </domain:authInfo> </domain:create> </create>
Ici, la mise à jour de l'information d'autorisation par le BE
perdant, lorsque le titulaire lui a annoncé le départ du domaine ;
le mot de passe est
LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
(le RFC
rappelle fortement l'importance de générer un mot de passe fort, par
exemple en utilisant des sources bien aléatoires, comme documenté
dans le RFC 4086) :
<update> <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> <domain:name>example.test</domain:name> <domain:chg> <domain:authInfo> <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP</domain:pw> </domain:authInfo> </domain:chg> </domain:update> </update>
Le BE perdant devra peut-être également supprimer l'état
clientTransferProhibited
, si le domaine était
protégé contre les transferts.
Le BE gagnant peut également vérifier l'information
d'autorisation sans déclencher un transfert, avec une requête
<info>
, qui lui renverra l'information
d'autorisation. Pour plusieurs exemples par la suite, j'ai utilisé le
logiciel Cocca. Cocca,
par défaut, ne stocke pas l'autorisation d'information en clair et
ne peut donc pas la renvoyer.
Ou bien le client EPP peut envoyer une commande
<info>
en indiquant l'information
d'autorisation. S'il obtient une erreur EPP 2202 (RFC 5730, section 3), c'est que cette
information n'était pas correcte. Ici, la
réponse EPP de Cocca lorsqu'on lui envoie un
<info>
avec information d'autorisation correcte :
Client : <info xmlns="urn:ietf:params:xml:ns:epp-1.0"><info xmlns="urn:ietf:params:xml:ns:domain-1.0"><name>foobar.test</name><authInfo xmlns="urn:ietf:params:xml:ns:domain-1.0"><pw xmlns="urn:ietf:params:xml:ns:domain-1.0">tropfort1298</pw></authInfo></info></info> Serveur : ... <ns1:authInfo><ns1:pw>Authinfo Correct</ns1:pw></ns1:authInfo> ...
Et si cette information est incorrecte :
Serveur : ... <ns1:authInfo><ns1:pw>Authinfo Incorrect</ns1:pw></ns1:authInfo>
(Mais Cocca répond quand même avec un code EPP 1000, ce qui n'est pas correct.)
Et enfin, bien sûr, voici la demande de transfert elle-même :
<transfer op="request"> <domain:transfer xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> <domain:name>example1.com</domain:name> <domain:authInfo> <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP</domain:pw> </domain:authInfo> </domain:transfer> </transfer>
Et si c'est bon :
<ns0:response xmlns:ns0="urn:ietf:params:xml:ns:epp-1.0" xmlns:ns1="urn:ietf:params:xml:ns:domain-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ns0:result code="1000"><ns0:msg>Command completed successfully</ns0:msg></ns0:result><ns0:msgQ count="2" id="3" /> <ns1:trStatus>serverApproved</ns1:trStatus> ...
Et avec une mauvaise information d'autorisation :
<ns0:response xmlns:ns0="urn:ietf:params:xml:ns:epp-1.0"><ns0:result code="2202"><ns0:msg>Invalid authorization information; (T07) Auth Info Password incorrect</ns0:msg></ns0:result>...
La section 6 du RFC décrit le problème de la transition depuis
l'ancien modèle d'autorisation vers le nouveau. Notez que certains
registres peuvent avoir une partie du nouveau système déjà en
place. Le registre qui désire transitionner doit d'abord s'assurer
que l'information d'autorisation absente ou vide équivaut à un
rejet. Il doit ensuite permettre aux BE de mettre une information
d'autorisation vide, permettre que la commande
<info>
puisse tester une information
d'autorisation, s'assurer que l'acceptation d'un transfert supprime
l'information d'autorisation, etc.
L'extension à EPP décrite dans ce RFC a été enregistrée dans le registre des extensions EPP. Quelles sont les mises en œuvre de ce RFC ? Cocca, déjà cité, le fait partiellement (par exemple en ne stockant pas les mots de passe en clair). Je n'ai pas testé avec ce logiciel ce qui se passait avec une information d'autorisation vide. Sinon, CentralNic a déjà ce mécanisme en production. Et Verisign l'a mis dans son SDK.
Date de publication du RFC : Décembre 2021
Auteur(s) du RFC : T. Sattler, R. Carney, J. Kolker (GoDaddy)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 26 décembre 2021
Un registre, par exemple un registre de noms de domaine, utilise parfois le protocole EPP pour la communication avec ses clients. Ce RFC décrit comment utiliser ce protocole pour informer les clients des périodes d'indisponibilité du registre, par exemple lors d'une opération de maintenance.
Aujourd'hui, un registre prévient de ses periodes
d'indisponibilité prévues par divers moyens : courriers aux BE, messages sur des
réseaux sociaux, page Web dédiée comme :
Chaque registre le fait de façon différente, il n'existe pas de règles communes, et le côté non-structuré de ces annonces fait qu'il faut une interventon humaine pour les analyser et les mettre dans un agenda. Et un BE peut devoir interagir avec de nombreux registres ! Notre RFC propose d'utiliser EPP (RFC 5730) pour ces annonces.
Donc, premier principe, puisqu'on va souvent manipuler des dates,
les dates et heures seront toutes représentées en UTC et dans le format
du RFC 3339. Ensuite, les annonces seront dans
un élément XML <item>
, de
l'espace de noms
urn:ietf:params:xml:ns:epp:maintenance-1.0
(enregistré
à l'IANA). Parmi les sous-éléments de cet élément :
id
, un identificateur de
l'évènement,systems
, qui permettra de désigner les
systèmes affectés,environment
, pour dire si l'évènement
concerne la production ou bien un banc de test,start
et end
, qui
indiquent le début et la fin (prévue…) de l'évènement,
Un exemple d'évènement, une intervention sur le serveur EPP
epp.registry.example
de production, peut être :
<maint:item> <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id> <maint:systems> <maint:system> <maint:name>EPP</maint:name> <maint:host>epp.registry.example</maint:host> <maint:impact>full</maint:impact> </maint:system> </maint:systems> <maint:environment type="production"/> <maint:start>2021-12-30T06:00:00Z</maint:start> <maint:end>2021-12-30T07:00:00Z</maint:end> <maint:reason>planned</maint:reason> <maint:detail> https://www.registry.example/notice?123 </maint:detail> <maint:tlds> <maint:tld>example</maint:tld> <maint:tld>test</maint:tld> </maint:tlds> </maint:item>
On voit que le serveur EPP sera arrêté pendant une heure
(<impact>full</impact>
indiquant
une indisponibilité totale) et que cela affectera les TLD
.example
et .test
. Une
telle information, étant sous une forme structurée, peut être
analysée par un programme et automatiquement insérée dans un agenda,
ou un système de supervision.
Les commandes EPP exactes, maintenant (section 4 du RFC). La
commande <info>
peut renvoyer maintenant
un élément <maint:info>
qui contient
l'information de maintenance. Voici l'exemple du RFC. D'abord, la
question du client, qui veut de l'information sur l'évènement
2e6df9b0-4092-4491-bcc8-9fb2166dcee6
:
<info> <maint:info xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"> <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id> </maint:info> </info>
Puis la réponse du serveur :
<response> <result code="1000"> <msg>Command completed successfully</msg> </result> <resData> <maint:infData xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"> <maint:item> <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6 </maint:id> <maint:type lang="en">Routine Maintenance</maint:type> <maint:systems> <maint:system> <maint:name>EPP</maint:name> <maint:host>epp.registry.example </maint:host> <maint:impact>full</maint:impact> </maint:system> </maint:systems> <maint:environment type="production"/> <maint:start>2021-12-30T06:00:00Z</maint:start> <maint:end>2021-12-30T07:00:00Z</maint:end> <maint:reason>planned</maint:reason> <maint:detail> https://www.registry.example/notice?123 </maint:detail> <maint:description lang="en">free-text </maint:description> <maint:description lang="de">Freitext </maint:description> <maint:tlds> <maint:tld>example</maint:tld> <maint:tld>test</maint:tld> </maint:tlds> <maint:intervention> <maint:connection>false</maint:connection> <maint:implementation>false</maint:implementation> </maint:intervention> <maint:crDate>2021-11-08T22:10:00Z</maint:crDate> </maint:item> </maint:infData> </resData> ...
Ici, le client connaissait l'identificateur d'une opération de maintenance particulière. S'il ne le connait pas et veut récupérer une liste d'événements :
<info> <maint:info xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"> <maint:list/> </maint:info> </info>
Il récupérera alors une <maint:list>
, une
liste d'opérations de maintenance.
Le client EPP peut
également être prévenu des maintenances par la commande
<poll>
, qui dote EPP d'un système de
messagerie (RFC 5730, section 2.9.2.3). Ainsi,
un message dans la boite aux lettres du client pourra être :
<response> <result code="1301"> <msg>Command completed successfully; ack to dequeue</msg> </result> <msgQ count="1" id="12345"> <qDate>2021-11-08T22:10:00Z</qDate> <msg lang="en">Registry Maintenance Notification</msg> </msgQ> <resData> <maint:infData xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"> <maint:item> <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id> <maint:pollType>create</maint:pollType> <maint:systems> <maint:system> <maint:name>EPP</maint:name> <maint:host>epp.registry.example </maint:host> <maint:impact>full</maint:impact> ...
La section 5 du RFC décrit la syntaxe formelle de cette extension (en XML Schema). Elle est dans le registre IANA des extensions à EPP.
Et question mises en œuvre ? Apparemment, les registres gérés par GoDaddy et Tango envoient déjà ces informations de maintenance.
Première rédaction de cet article le 25 décembre 2021
Décembre 2021, des correspondants m'informent que ma clé PGP n'est plus utilisable pour m'envoyer des messages chiffrés. Unusable public key ou autres messages peu parlants. Alors que ça marchait avant.
% gpg --encrypt --recipient CCC66677 toto.txt gpg: CCC66677: skipped: Unusable public key gpg: toto.txt: encryption failed: Unusable public key
C'était un simple oubli idiot de ma part : la clé a plusieurs sous-clés, ayant des rôles différents (chiffrement, signature…). Lors de la précédente expiration de la clé, j'avais bien re-signé mais en oubliant une des sous-clés, celle de chiffrement (une grosse bêtise). Au lieu d'un message clair du genre « cette clé a expiré » (ce qui se produit quand toutes les clés sont expirées), le logiciel, ne voyant que la clé de signature, n'arrivait pas à produire un message d'erreur intelligent. (Au passage, le format de clés PGP ou, plus exactement, OpenPGP, est normalisé dans le RFC 4880).
La clé et ses sous-clés, dont une (tout à la fin) était expirée :
sec rsa4096/555F5B15CCC66677 created: 2014-02-08 expires: 2023-12-21 usage: SC trust: unknown validity: undefined ssb rsa4096/3FA836C996A4A254 created: 2014-02-09 expires: 2023-12-21 usage: S ssb* rsa4096/9045E02757F02AA1 created: 2014-02-09 expired: 2021-12-19 usage: E
(Usage: E = encryption - chiffrement, alors que Usage: S désigne la possibilité de signer.)
Une fois tout re-signé proprement :
sec rsa4096/555F5B15CCC66677 created: 2014-02-08 expires: 2023-12-25 usage: SC trust: unknown validity: undefined ssb* rsa4096/3FA836C996A4A254 created: 2014-02-09 expires: 2023-12-25 usage: S ssb* rsa4096/9045E02757F02AA1 created: 2014-02-09 expires: 2023-12-25 usage: E
Vous pouvez récupérer ma clé publique sur les serveurs de clés PGP habituels, ou bien directement sur ce site Web. Les raisons pour lesquelles j'ai mis une date d'expiration à ma clé (ce n'est pas obligatoire et, vous avez vu, ça peut entrainer des problèmes), sont détaillées dans un autre article.
Merci à André Sintzoff pour le signalement et à Kim Minh Kaplan pour la solution.
Date de publication du RFC : Décembre 2021
Auteur(s) du RFC : C. Bormann (Universität Bremen TZI)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF cbor
Première rédaction de cet article le 25 décembre 2021
Le langage CDDL (Concise Data Definition Language) est un langage de description de schémas de données, notamment pour le format CBOR. Ce nouveau RFC étend CDDL avec de nouveaux opérateurs, permettant entre autres l'addition d'entiers et la concaténation de chaines de caractères.
CDDL est normalisé dans le RFC 8610 (et le format CBOR dans le RFC 8949). Il permet l'ajout de nouveaux opérateurs pour étendre le langage, possibilité utilisée par notre nouveau RFC. Notez que, comme les modèles de données de JSON et CBOR sont très proches, les schémas CDDL peuvent également être utilisés pour JSON, ce que je fais ici pour les exemples car le JSON est plus facile à lire et à écrire.
D'abord, l'opérateur .plus
. Il permet par
exemple, dans la spécification d'un schéma, de faire dépendre
certains nombres d'autres nombres. L'exemple ci-dessous
définit un type « intervalle » où la borne supérieure doit être
supérieure de 5 à la borne inférieure :
top = interval<3> interval<BASE> = BASE .. (BASE .plus 5)
Avec un tel schéma, la valeur 4 sera acceptée mais 9 sera refusée :
% cddl tmp.cddl validate tmp.json CDDL validation failure (nil for 9): [9, [:range, 3..8, Integer], ""]
Deuxième opérateur, la
concaténation, avec le nouvel opérateur
.cat
:
s = "foo" .cat "bar"
Dans cet exemple, évidemment, .cat
n'est pas
très utile, on aurait pu écrire la chaine complète directement. Mais
.cat
est plus pertinent quand on veut manipuler
des chaines contenants des sauts de ligne :
s = "foo" .cat ' bar baz '
Ce schéma acceptera la chaine de caractère "foo\n bar\n
baz\n"
.
Dans l'exemple ci-dessus, bar
et
baz
seront précédés des espaces qui
apparaissaient dans le code source. Souvent, on souhaite mettre ces
espaces en début de ligne dans le code source, pour
l'indenter joliment, mais les supprimer dans
le résultat final. Cela peut se faire avec l'opérateur pour lequel
notre RFC invente le joli mot de détentation
(dedending), .det
, qui
fonctionne comme .cat
mais « dédente » les
lignes :
s = "foo" .det ' bar baz '
Cette fois, le schéma n'acceptera que la chaine
"foo\nbar\nbaz\n"
.
Le RFC note que, comme .det
est l'abréviation
de dedending cat, on aurait pu l'appeler
.dedcat
mais cela aurait chagriné les amis des
chats.
CDDL est souvent utilisé dans les normes techniques de l'Internet
et celles-ci contiennent souvent des
grammaires en ABNF (RFC 5234). Pour permettre de réutiliser les règles ABNF dans
CDDL, et donc se dispenser d'une ennuyeuse traduction, un nouvel
opérateur fait son apparition, .abnf
. Le RFC
donne l'exemple de la grammaire du RFC 3339,
qui normalise les formats de date : abnf-rfc3339.cddl
. Avec ce fichier, on peut accepter des
chaines comme "2021-12-15"
ou
"2021-12-15T15:52:00Z"
. Notons qu'il reste
quelques difficultés car les règles d'ABNF ne sont pas parfaitement
compatibles avec celles de CDDL. Si .abnf
va
traiter l'ABNF comme de l'Unicode encodé en
UTF-8, un autre opérateur,
.abnfb
, va le traiter comme une bête suite
d'octets. D'autre part, comme ABNF exige souvent des sauts de ligne,
les opérateurs .cat
et
.det
vont être très utiles.
Quatrième et dernier opérateur introduit par ce RFC,
.feature
. À quoi sert-il ? Comme le langage
CDDL peut ếtre étendu au-delà de ce qui existait dans le RFC 8610, on court toujours le risque de traiter
un schéma CDDL avec une mise en œuvre de CDDL qui ne connait pas
toutes les fonctions utilisées dans le schéma. Cela produit en
général un message d'erreur peu clair et, surtout, cela mènerait à
considérer des données comme invalides alors qu'elles sont
parfaitement acceptables pour le reste du
schéma. .feature
sert donc à marquer les
extensions qu'on utilise. Le programme qui met en œuvre CDDL pourra
ainsi afficher de l'information claire. Par exemple, si on définit
une personne :
person = { ? name: text ? organization: text }
puis qu'on veut rajouter son groupe sanguin :
{"name": "Jean", "bloodgroup": "O+"}
Cet objet sera rejeté, en raison du champ
bloodgroup
. On va faire un schéma plus ouvert, avec
.feature
:
person = { ? name: text ? organization: text * (text .feature "further-person-extension") => any }
Et, cette fois, l'objet est accepté avec un message d'avertissement clair :
% cddl person-new-feature.cddl validate tmp.json ** Features potentially used (tmp.json): further-person-extension: ["bloodgroup"]
Comme le schéma est assez ouvert, la fonction de génération de fichiers d'exemple de l'outil donne des résultats amusants :
% cddl person-new-feature.cddl generate {"name": "plain", "dependency's": "Kathryn's", "marvelous": "cleavers"}
Les nouveaux opérateurs ont été placés dans le registre
IANA. Ils sont mis en œuvre dans l'outil de référence de CDDL
(le cddl
utilisé ici). Écrit en
Ruby, on peut l'installer avec la méthode Ruby
classique :
% gem install cddl
Il existe une autre mise en œuvre de CDDL (qui porte malheureusement le même nom). Elle est en Rust et peut donc s'installer avec :
% cargo install cddl
Elle n'inclut pas encore les opérateurs de ce RFC :
% /home/stephane/.cargo/bin/cddl validate --cddl plus.cddl plus.json Validation of "plus.json" failed error parsing CDDL: error: lexer error ┌─ input:8:12 │ 8 │ (BASE .plus 1) => int ; upper bound │ ^^^^^ invalid control operator
Date de publication du RFC : Mars 1982
Auteur(s) du RFC : Elizabeth Feinler, Ken Harrenstien, Zaw-Sing Su, Vic White (SRI International, Network Information Center)
Statut inconnu, probablement trop ancien
Première rédaction de cet article le 22 décembre 2021
Un peu d'histoire, avec ce RFC 810, qui mettait à jour le format du fichier géant qui, à l'époque, contenait la liste de toutes les machines de l'Internet. Il remplaçait le RFC 608.
Par rapport à son prédécesseur, ce RFC marquait le début de la fin de ce fichier
géant : ses limites étaient désormais bien comprises, et le
DNS était en cours
d'élaboration, quoique encore dans le futur. En attendant ce système
décentralisé et réparti, notre RFC mettait à jour la syntaxe du
fichier HOSTS.TXT
, aussi appelé
« hosts » ou « host
table ». Il s'appliquait à
l'Internet mais aussi à son prédécesseur
Arpanet qui, à l'époque, vivait encore, une
vie séparée. Le fichier était ensuite distribué par un serveur
centralisé, décrit dans le RFC 811. Si vous
vouliez le fichier entier, notre RFC rappelait les instructions, à
l'époque où les URL n'existaient pas encore : « Connectez-vous
à 10.0.0.73
en FTP, en utilisant le compte
ANONYMOUS
et le mot de passe
GUEST
, puis utilisez la commande
get
pour le fichier
<NETFINFO>HOSTS.TXT
». (On notera qu'à
l'époque, le FTP anonyme était réellement
anonyme, la convention d'utiliser son adresse comme mot de passe n'existait pas
encore.)
Bon, quelle était la syntaxe de ce fichier ? Les noms étaient
composés de lettres ASCII, de chiffres, de
traits d'union et de
points, en 24 caractères maximum. Ils étaient
insensibles à la casse. Il existait des
conventions de nommage : un routeur devait
avoir un nom se terminant en -GATEWAY
ou
-GW
. Un TAC devait se nommer
quelquechose-TAC
. (Le RFC ne prend pas la peine
d'expliquer ce qu'est un TAC. Un TAC,
Terminal Access Controller était un ordinateur
spécialisé dans le service de terminaux, qui n'avait pas de compte
local et ne servait qu'à se connecter à des ordinateurs
distants.)
Le RFC décrit ensuite le format des adresses. Loin des débuts de l'Arpanet, elles étaient déjà sur 32 bits à l'époque (cela avait été normalisé par le RFC 796 en 1981). La longueur du préfixe dépendait de la valeur des premiers bits de l'adresse (le système des classes, qui a été abandonné en 1993).
Le fichier contenait aussi les noms des réseaux. Pour les machines, le fichier ne contenait pas que noms et adresses. À cette époque sans Web et sans moteur de recherche, il servait aussi à publier les services disponibles sur chaque machine. Et il indiquait aussi le système d'exploitation des machines, information utile quand on voulait se connecter avec telnet. (D'autres protocoles nécessitaient de connaitre ce système d'exploitation. L'utilisation de FTP en dépendait, sans compter les problèmes d'encodage des caractères, dans un monde sans Unicode.) Voici quelques exemples de machines, datant de 1983 :
HOST : 10.0.0.4, 192.5.12.21 : UTAH-CS : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP : HOST : 10.0.0.6 : MIT-MULTICS,MULTICS : HONEYWELL-DPS-8/70M : MULTICS : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,TCP/ECHO,TCP/DISCARD,ICMP : HOST : 10.0.0.9 : HARV-10,ACL : DEC-10 : TOPS10 :: HOST : 32.2.0.42 : UCL-TAC,LONDON-TAC : H-316 : TAC : TCP : HOST : 26.4.0.73 : SRI-F4 : FOONLY-F4 : TENEX :: HOST : 10.0.0.51, 26.0.0.73 : SRI-NIC,NIC : DEC-2060 : TOPS20 : TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
Vous noterez que l'université d'Utah
utilise toujours, en 2021, le même préfixe
192.5.12.0/24
… Par contre, le
MIT n'a plus de service ECHO… (Ce service
était normalisé dans le RFC 862.) La machine de
l'UCL était une des rares étrangères aux
USA. Le Foonly qu'on voit au
SRI était une machine connue pour avoir fait
les CGI des films Tron
et, come le note John Shaft, Looker :
« première fois qu'il était possible de voir de la
3D avec ombrage dans un film, de mémoire. Un
corps humain de surcroît. ». Quant à la machine
SRI-NIC
, c'est elle qui distribuait ce fichier
(son adresse avait changé depuis la publication du RFC).
L'internet était encore assez centralisé à l'époque, et il était possible de décider d'un « jour J », où on fait changer tout le monde en même temps : ce RFC fixait la date au 1er mai 1982, où tout le monde devait utiliser le nouveau format, l'ancien, celui du RFC 608, étant abandonné.
Une copie du fichier de 1983 est en ligne (merci à Patrick Mevzek pour l'avoir trouvée) et j'en ai fait une copie locale.
Date de publication du RFC : Décembre 2021
Auteur(s) du RFC : L.V. Velvindron (cyberstorm.mu), K.M. Moriarty (CIS), A.G. Ghedini (Cloudflare)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 20 décembre 2021
Vous le savez certainement déjà, car toutes les lectrices et tous les lecteurs de ce blog sont très attentif·ves et informé·es, mais les algorithmes de condensation MD5 et SHA-1 ont des failles connues et ne doivent pas être utilisés dans le cadre de signatures. Vous le savez, mais tout le monde ne le sait pas, ou bien certain·es ont besoin d'un document « officiel » pour agir donc, le voici : notre RFC dit qu'on ne doit plus utiliser MD5 et SHA-1 dans TLS.
Si vous voulez savoir pourquoi ces algorithmes sont mauvais, le RFC 6151 vous renseignera (et la section 1 de notre RFC 9155 vous donnera une bibliographie récente).
La section 2 à 5 sont le cœur du RFC et elle est sont très simples : pas de MD5, ni de SHA-1 pour les signatures. Dans le registre IANA, ces algorithmes sont désormais marqués comme déconseillés.
Les fanas de cryptographie noteront qu'on peut toujours utiliser SHA-1 pour HMAC (où ses faiblesses connues n'ont pas de conséquences).
Première rédaction de cet article le 14 décembre 2021
Vous avez sans doute suivi l'affaire de la faille de sécurité Log4Shell. Elle a souvent été utilisée comme point de départ pour des discussions à propos du financement du logiciel libre, en mode « de nombreuses grosses entreprises utilisent tel logiciel libre et en dépendent mais ne contribuent pas à son financement ». Ce point de vue mérite d'être nuancé.
La faille concerne le logiciel Log4j, très utilisé (ce qui explique en partie l'intérêt porté à la faille Log4Shell). Comme beaucoup de logiciels libres très utilisés, il ne bénéficie pas d'une équipe de développeurs payés à temps plein pour le maintenir. Je cite tout de suite le dessin de XKCD que tout le monde mentionne tout le temps. Face à cela, on lit souvent des affirmations comme quoi les grosses entreprises (par exemple les GAFA) devraient financer ces logiciels cruciaux. Je pense que c'est plus compliqué que cela, et je voudrais présenter ici deux faits et une opinion.
Premier fait, un ou une développeureuse de logiciel libre n'est pas forcément bénévole. Le logiciel libre n'est pas synonyme de gratuité et, de toute façon, la gratuité du logiciel ne veut pas dire que les développeureuses n'ont pas été payé·es. Il y a beaucoup de logiciels libres cruciaux qui sont maintenus par des salarié·es. (Dans le domaine du DNS, c'est le cas de tous les serveurs libres, comme BIND ou NSD, maintenus par les employé·es de l'ISC, de NLnet Labs, de PowerDNS, etc.) D'affirmer comme je l'ai lu souvent qu'il faut s'inquiéter des logiciels libres car leurs développereuses sont bénévoles est donc absurde. La question du financement du logiciel libre est une question très intéressante (il est parfaitement normal que les programmeureuses soient payé·es pour leur travail) mais elle a de nombreuses réponses.
Deuxième fait, si le logiciel est libre, par définition, personne n'est obligé de payer pour l'utiliser. Du point de vue moral, on peut trouver que ce n'est pas beau qu'Amazon ou Google ne dépensent pas un centime pour des logiciels qu'ils utilisent mais c'est le principe du logiciel libre. Un·e auteur·e de logiciel peut toujours mettre son logiciel sous une licence non-libre, imposant par exemple un paiement pour un usage commercial (ce qui est en général une mauvaise idée) mais ce n'est plus du logiciel libre.
Enfin, mon opinion. À défaut d'imposer un paiement, ce qui n'est pas possible pour un logiciel libre, ne faudrait-il pas au moins exercer une pression morale pour que les entreprises qui gagnent de l'argent avec une infrastructure composée en (bonne) partie de logiciel libre mettent la main sur l'interface Web de leur banque et envoient de l'argent ?
Ce point soulève de nombreuses questions. D'abord, si la programmeuse ou le programmeur a choisi le logiciel libre (et donc de ne pas forcément toucher de l'argent des utilisateurs), c'est qu'il y a une raison. Souvent, c'était pour être elle-même ou lui-même plus libre, pour ne pas dépendre de product owners, de commerciaux ou de décideurs qui lui diraient qu'ils veulent telle ou telle jolie fonction dans l'interface. Si le financement des logiciels libres est assuré par des grosses entreprises, elles exigeront sans doute du reporting, des process formalisés, elles demanderont un pouvoir de décision, et tou·tes les auteur·es de logiciel libre n'ont pas envie de travailler dans un tel cadre. Même si Amazon voulait payer, tout le monde ne le voudrait pas. (En outre, se faire payer pour développer du logiciel libre est parfois compliqué, du point de vue administratif, même si quelqu'un veut le faire.)
C'est d'autant plus vrai que ces grosses entreprises ont souvent un rôle très néfaste dans l'Internet. Je me souviens d'une discussion il y a quelques années avec la responsable d'un gros projet libre, financé en grande partie par des contrats avec des entreprises de l'Internet qui payaient pour que telle ou telle fonction soit développée. Je lui suggérai des améliorations pour préserver la vie privée des utilisateurices. Elle m'avait répondu « Stéphane, tu nous demandes toujours des trucs pour mieux protéger la vie privée, mais les clients qui paient nous paient pour, au contraire, trouver des moyens de récolter davantage de données. »
Bien sûr, une solution possible serait d'isoler les programmeuses ou programmeurs des financeurs via, par exemple, une fondation qui recevrait l'argent et le distribuerait (un certain nombre de gros logiciels libres fonctionnent ainsi, et c'est d'ailleurs le cas de Log4j). Mais cela ne convient pas non plus à tout le monde. (Ces fondations ne sont pas forcément innocentes.)
Et la sécurité n'y gagnerait pas forcément. Dans le cas de Log4Shell, les auteurs ont commis une bogue, c'est sûr. Mais tous les logiciels peuvent avoir des bogues, que leurs auteurs soient payés ou pas. Et, une fois la bogue signalée, tout semble indiquer que les auteurs de Log4j ont réagi vite et bien. Tout n'est pas une question de financement, et, en matière de sécurité, la conscience professionnelle et la réactivité comptent davantage. Rajouter des règles, des procédures et de la bureaucratie, sous couvert d'avoir des dévelopements logiciels « plus sérieux » ne serait pas un progrès en sécurité, probablement plutôt le contraire. (Sans compter que les grosses entreprises sont les premières à réclamer davantage de fonctions, donc davantage de failles de sécurité, et à prioriser l'apparence sur la qualité.)
[Ne me faites pas dire ce que je n'ai pas dit ; je n'ai pas proposé que les développeur·ses de logiciels soient forcément pauvres et grelottant de froid dans une mansarde non chauffée. Qu'ielles soient payé·es est normal. Mais, vu l'actuel marché de l'emploi dans la programmation, celles et ceux qui ne s'intéressent qu'à l'argent n'ont en général pas de problème. La question du financement et de la maintenance des logiciels essentiels est importante, mais elle ne se résoudra pas en demandant simplement aux GAFA de mettre la main à la poche.]
Quelques lectures sur ce sujet délicat :
Date de publication du RFC : Décembre 2021
Auteur(s) du RFC : M. Richardson (Sandelman Software Works), C. Bormann (Universität Bremen TZI)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF cbor
Première rédaction de cet article le 14 décembre 2021
Ce nouveau RFC normalise deux étiquettes CBOR pour représenter des adresses IP et des préfixes d'adresses.
Le format de données CBOR, normalisé dans le RFC 8949, a une liste de types prédéfinis mais on peut en créer d'autres, en étiquetant la donnée avec un entier qui permettre de savoir comment interpréter la donnée en question. Notre RFC introduit les étiquettes 52 (pour les adresses IPv4) et 54 (pour les adresses IPv6). Ah, pourquoi 52 et 54 ? Je vous laisse chercher, la solution est à la fin de l'article
La section 3 de notre RFC décrit le format. Pour chaque famille (IPv4 ou IPv6), il y a trois formats (tous avec la même étiquette) :
eth0
sur Linux,
voir la section 6 du RFC 4007 pour IPv6, et
les RFC 4001 et RFC 6991 pour IPv4, mais cela
peut aussi être un entier), identificateur qui est local à la
machine.La section 5 du RFC contient une description en CDDL (RFC 8610) de ces données.
J'ai écrit une mise en œuvre en Python de ce RFC, qui renvoie à un client
HTTP son
adresse IP, et le préfixe annoncé dans la DFZ en BGP (en utilisant pour cela les
données du RIS,
via le programme WhichASN). Le
service est accessible à l'adresse
https://www.bortzmeyer.org/apps/addresses-in-cbor
,
par exemple :
% curl -s https://www.bortzmeyer.org/apps/addresses-in-cbor > tmp.cbor
Le CBOR est du binaire, on peut regarde avec le programme read-cbor :
% read-cbor tmp.cbor Array of 3 items String of length 165: Your IP address in CBOR [...] Tag 54 Byte string of length 16 Tag 54 Array of 2 items Unsigned integer 32 Byte string of length 4
On voit que le service renvoie un tableau CBOR de trois entrées :
Vu avec le programme cbor2diag, le même fichier :
% cbor2diag.rb tmp.cbor ["Your IP address in CBOR, done with Python 3.9.2 [...]", 54(h'200141D0030222000000000000000180'), 54([32, h'200141D0'])]
(Le préfixe du client HTTP était en effet bien
2001:41d0::/32
.) Le code source de service est
dans les sources du moteur de ce
blog, plus précisement en
wsgis/dispatcher.py
.
Sinon, la raison du choix des étiquettes est que, en ASCII, 52 est le chiffre 4 et 54 est 6. Les deux étiquettes sont désormais dans le registre IANA. À noter que la représentation des adresses IP en CBOR avait été faite initialement avec les étiquettes 260 et 261, en utilisant un encodage complètement différent. 260 désignait les adresses (v4 et v6), 261, les préfixes. (Ces deux étiquettes sont marquées comme abandonnées, dans le registre IANA.) Au contraire, dans notre nouveau RFC, l'étiquette identifie la version d'IP, la distinction entre adresse et préfixe se faisant par un éventuel entier initial pour indiquer la longueur.
Date de publication du RFC : Décembre 2021
Auteur(s) du RFC : B. Laurie, A. Langley, E. Kasper, E. Messeri (Google), R. Stradling (Sectigo)
Expérimental
Réalisé dans le cadre du groupe de travail IETF trans
Première rédaction de cet article le 10 décembre 2021
Le système de gestion de certificats PKIX (dérivé des certificats X.509) a une énorme faiblesse. N'importe quelle AC peut émettre un certificat pour n'importe quel nom de domaine. Il ne suffit donc pas de bien choisir son AC, votre sécurité dépend de toutes les AC. Ce RFC propose une approche pour combler cette faille de sécurité : encourager/obliger les AC à publier « au grand jour » les certificats qu'elles émettent. Un titulaire d'un certificat qui craint qu'une AC n'émette un certificat à son nom sans son autorisation n'a alors qu'à surveiller ces publications. (Il peut aussi découvrir à cette occasion que sa propre AC s'est fait pirater ou bien est devenue méchante et émet des certificats qu'on ne lui a pas demandés. L'idée est aussi d'empêcher l'émission « discrète » de vrais/faux certificats qui seraient ensuite utilisés uniquement à certains endroits.) Ce système, dit « Certificate Transparency » (CT) avait initialement été normalisé dans le RFC 6962, que notre RFC remplace, le protocole passant à une nouvelle version, la v2 (toujours considérée comme expérimentale).
Le principe est donc de créer des journaux des certificats émis. Le journal doit être public, pour que n'importe qui puisse l'auditer (section 4 du RFC). Il doit être en mode « ajout seulement » pour éviter qu'on puisse réécrire l'histoire. Les certificats sont déjà signés mais le journal a ses propres signatures, pour prouver son intégrité. Conceptuellement, ce journal est une liste de certificats dans l'ordre de leur création. Toute AC peut y ajouter des certificats (la liste ne peut pas être ouverte en écriture à tous, de crainte qu'elle ne soit remplie rapidement de certificats bidons). En pratique, le RFC estime que la liste des AC autorisées à écrire dans le journal sera l'union des listes des AC acceptées dans les principaux navigateurs Web (voir aussi les sections 4.2 et 5.7, chaque journal est responsable de ce qu'il accepte ou pas comme soumissions).
À chaque insertion, le journal renvoie à l'AC une estampille
temporelle signéee (SCT, pour Signed Certificate
Timestamp), permettant à l'AC de prouver qu'elle a bien
enregistré le certificat. Si on a cette signature mais que le
certificat est absent du journal, l'observateur aura la preuve que
le journal ne marche pas correctement. Le format exact de cette
estampille temporelle est décrit en section 4.8. Idéalement, elle
devra être envoyée au client par les serveurs TLS, dans l'extension
TLS transparency_info
(désormais enregistrée
à l'IANA), comme preuve de la bonne foi de l'AC (cf. section
6 et notamment 6.5, car c'est plus compliqué que cela). Bien sûr,
cette validation de l'insertion dans un journal ne dispense pas de
la validation normale du certificat (un certificat peut être
journalisé et mensonger à la fois). Notez aussi que, si le serveur
TLS n'envoie pas toutes les données au client, celui-ci peut les
demander au journal (opérations /get-proof-by-hash
et
get-all-by-hash
) mais, ce faisant, il informe
le journal des certificats qui l'intéressent et donc, par exemple,
des sites Web qu'il visite.
De même, une extension à OCSP (RFC 6960) peut être utilisée pour appuyer les réponses OCSP. On peut même inclure les preuves d'inclusion dans le journal dans le certificat lui-même, ce qui permet d'utiliser des serveurs TLS non modifiés.
Les titulaires de certificats importants, comme Google, mais aussi des chercheurs, des agences de sécurité, etc, pourront alors suivre l'activité de ces journaux publics (section 8.2 du RFC). Ce qu'ils feront en cas de détection d'un certificat anormal (portant sur leur nom de domaine, mais qu'ils n'ont pas demandé) n'est pas spécifié dans le RFC : cela dépend de la politique de l'organisation concernée. Ce RFC fournit un mécanisme, son usage n'est pas de son ressort. Ce journal n'empêchera donc pas l'émission de vrais/faux certificats, ni leur usage, mais il les rendra visibles plus facilement et sans doute plus vite.
Notons que les certificats client, eux, ne sont typiquement pas journalisés (rappelez-vous que les journaux sont publics et que les certificats client peuvent contenir des données personnelles). Le serveur TLS ne peut donc pas utiliser Certificate Transparency pour vérifier le certificat du client. (Le RFC estime que le principal risque, de toute façon, est celui d'usurpation du serveur, pas du client.)
Pour que cela fonctionne, il faudra que les clients TLS vérifient que le certificat présenté est bien dans le journal (autrement, le méchant n'aurait qu'à ne pas enregistrer son vrai/faux certificat, cf. section 8.3 du RFC).
En pratique, la réalisation de ce journal utilise un arbre de Merkle, une structure de données qui permet de mettre en œuvre un système où l'ajout de certificats est possible, mais pas leur retrait, puisque chaque nœud est un condensat de ses enfants (voir aussi le RFC 8391). La section 2 du RFC détaille l'utilisation de ces arbres et la cryptographie utilisée. (Et les exemples en section 2.1.5 aident bien à comprendre comment ces arbres de Merkle sont utilisés.)
Le protocole utilisé entre les AC et le journal, comme celui
utilisé entre les clients TLS et le journal, est HTTP et le format des
données du JSON (section 5, qui décrit l'API). Ainsi, pour
ajouter un certificat nouvellement émis au journal géré sur
sunlight-log.example.net
, l'AC fera :
POST https://sunlight-log.example.net/ct/v2/submit-entry
et le corps de la requête HTTP sera un tableau JSON de certificats encodés en Base64. La réponse contiendra notamment l'estampille temporelle (SCT pour Signed Certificate Timestamp). S'il y a un problème, le client recevra une des erreurs enregistrées. Pour récupérer des certificats, le programme de surveillance fera par exemple :
GET https://sunlight-log.example.net/ct/v2/get-entries
D'autres URL permettront de récupérer les condensats cryptographiques contenus dans l'arbre de Merkle, pour s'assurer qu'il est cohérent.
Comme il n'existe (en octobre 2021) aucune mise en œuvre de la
version 2 du protocole, voici quelques exemples, utilisant des
journaux réels, et la version 1 du protocole (notez le
v1
dans l'URL). Pour trouver les coordonnées
des journaux, j'ai utilisé la liste
« officielle » du projet. Notez que tous les journaux qui y figurent ne fonctionnent pas
correctement. Notez aussi que, comme pour les AC ou les serveurs de clés PGP, il n'y a
pas de « journal de référence », c'est à chacun de choisir les
journaux où il va écrire, et qu'il va lire. Le script test-ct-logs-v1.py
teste la liste, et trouve :
50 logs are OK, 54 are currently broken
Si vous vous demandez pourquoi un même opérateur a plusieurs
journaux, c'est en partie parce qu'il n'est pas possible de faire
évoluer les algorithmes cryptographiques au sein d'un même journal
(cf. section 9 du RFC) et qu'il faut donc de temps en temps créer un
nouveau journal. Un journal est identifié par son URL, sa clé publique et
(en v2) par son OID. Par exemple, le journal
« Nimbus 2021 » de Cloudflare est en
https://ct.cloudflare.com/logs/nimbus2021/
et a
la clé
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAExpon7ipsqehIeU1bmpog9TFo4Pk8+9oN8OYHl1Q2JGVXnkVFnuuvPgSo2Ep+6vLffNLcmEbxOucz03sFiematg==
(je ne donne pas l'OID, il n'existe pas encore de journaux qui
utilisent la version 2 du protocole). Voici un exemple d'utilisation
(le STH est le Signed Tree Head, la valeur de la
racine de l'arbre de Merkle, cf. section 4.2.10) :
% curl -s https://ct.cloudflare.com/logs/nimbus2021/ct/v1/get-sth | jq . { "tree_size": 408013312, "timestamp": 1634739692384, "sha256_root_hash": "7GnGjI7L6O5fn8kQKTdJG2riShNTTbcjRP2WbLoZrvQ=", "tree_head_signature": "BAMARjBEAiAQ0gb6udc9e28ykUGUzl0HV8U5NlJhPVSTUF4JtXGSeQIgcSbZ9kRgttGzpFETFem4eCv7GgUYPUUnl7lTGGFZSHM=" }
Plus de quatre cents millions de certificats, fichtre. Si on veut récupérer les deux premiers certificats journalisés :
% curl -s https://ct.cloudflare.com/logs/nimbus2021/ct/v1/get-entries\?start=0\&end=1 | jq . { "entries": [ { "leaf_input": [L'exemple est fait avec un journal v1, l'objet JSON renvoyé est différent en v2.]
Mais vous pouvez aussi utiliser Certificate
Transparency (CT) sans aller regarder du JSON. Un service en
ligne comme
vous permet de
scruter un journal. Voici par exemple l'actuel certificat de ce
blog, ou bien tous les certificats au
nom de la Banque Postale (CT est
utile pour le renseignement).
https://crt.sh
On a vu que plusieurs acteurs intervenaient, le gérant du
journal, les AC, les gens qui regardent le journal, par exemple pour
l'auditer, etc. Une utilisation courante de CT est pour surveiller
l'émission de certificats au nom de son entreprise ou de son
organisation, pour repérer les AC qui créent des certificats
incorrects. Pour éviter de programmer tout cela de zéro en partant
du RFC, on peut utiliser le service Certstream, qui sert
d'intermédiaire avec plusieurs journaux, et sa bibliothèque
Python. Ainsi, le petit script test-certstream.py
permet de détecter tous les certificats
émis pour les noms de domaine en
.fr
:
% pip3 install certstream % ./test-certstream.py ... [2021-10-23T13:21:46] pimpmydrone.fr (SAN: www.pimpmydrone.fr) [2021-10-23T13:21:51] pascal-goldbach.fr (SAN: www.pascal-goldbach.fr) [2021-10-23T13:21:52] leginkobiloba.fr (SAN: www.leginkobiloba.fr) [2021-10-23T13:21:52] promabat-distribution.fr (SAN: www.promabat-distribution.fr) [2021-10-23T13:21:53] maevakaliciak.fr (SAN: mail.maevakaliciak.fr, www.maevakaliciak.fr) [2021-10-23T13:21:55] pascal-goldbach.fr (SAN: www.pascal-goldbach.fr) [2021-10-23T13:21:56] maevakaliciak.fr (SAN: mail.maevakaliciak.fr, www.maevakaliciak.fr) [2021-10-23T13:21:57] blog.nicolas-buffart.itval.fr (SAN: euromillions-generator.itval.fr, itval.fr, loto-generator.itval.fr, password-generator.itval.fr, www.blog.nicolas-buffart.itval.fr, www.euromillions-generator.itval.fr, www.itval.fr, www.loto-generator.itval.fr, www.password-generator.itval.fr) ...
Bien sûr, cela fait beaucoup (regardez les intervalles entre deux messages). En pratique, on modifierait sans doute ce script pour ne regarder que les noms de son organisation. Ainsi, vous pouvez détecter les certificats et chercher ensuite s'ils sont légitimes (ce qui, dans certaines organisations très cloisonnées n'ira pas de soi…).
À part Certstream, Samuel Bizien Filippi me suggère CertSpotter mais qui me semble uniquement payant. Il a une API. Elle peut être utilisée par le programme check_ct_logs, qui peut être utilisé comme script de test pour les programmes de supervision comme Icinga.
Le projet « Certificate Transparency » (largement impulsé par Google) a un site officiel (lecture recommandée) et, une liste de diffusion (sans compter le groupe de travail IETF TRANS, mais qui se limitait à la normalisation, il ne parle pas des aspects opérationnels, et il a de toute façon été clos en août 2021). Questions logiciels, si vous voulez créer votre propre journal, il y a le programme de Google.
Aujourd'hui, on peut dire que « Certificate Transparency » est un grand succès. La plupart (voire toutes ?) des AC y participent, il existe de nombreux journaux publics, et ils sont fréquemment utilisés pour l'investigation numérique (voire pour le renseignement, puisqu'on peut savoir, via les journaux, les noms de domaine pas encore annoncés, ce qui a parfois été cité comme une objection contre CT). Un bon exemple est celui de l'attaque « moyen-orientale » de 2018 (mais il y a aussi l'affaire du certificat révoqué de la Poste). Par contre, un client TLS ne peut pas encore être certain que tous les certificats seront dans ces journaux, et ne peut donc pas encore refuser les serveurs qui ne signalent pas la journalisation du certificat. Et le navigateur Firefox ne teste pas encore la présence des certificats dans le sjournaux.
Un point amusant : le concept de « Certificate Transparency » montre qu'il est parfaitement possible d'avoir un livre des opérations publiquement vérifiable sans chaine de blocs. La chaine de blocs reste nécessaire quand on veut autoriser l'écriture (et pas juste la lecture) au public.
La section 1.3 du RFC résume les principaux changements entre les versions 1 (RFC 6962) et 2 du protocole :
get-all-by-hash
dans
l'API,signed_certificate_timestamp
(valeur 18) par
transparency_info
(valeur 52, et voir aussi le nouvel
en-tête HTTP
Expect-CT:
du RFC 9163,CT ne change pas de statut avec la version 2 : il est toujours classé par l'IETF comme « Expérimental » (bien que largement déployé). La sortie de cette v2 n'est pas allée sans mal (le premier document étant sorti en février 2014), avec par exemple aucune activité du groupe pendant la deuxième moitié de 2020.
Une des plus chaudes discussions pour cette v2 avait été la
proposition de changer l'API pour que les requêtes, au lieu d'aller
à <BASE-URL>/ct/v2/
partent du chemin
/.well-known/
du RFC 8615. Cette idée a finalement été rejetée, malgré le RFC 8820, qui s'oppose à cette idée de chemins
d'URL en dur.
Première rédaction de cet article le 9 décembre 2021
Il y a quelques jours, la justice étatsunienne a saisi, sur demande de Microsoft, un certain nombre de domaines, et les a transférés à cette société. Quelques informations techniques concrètes suivent pour celles et ceux qui seraient intéressé·es.
D'abord, le jugement du 2 décembre (trouvé par Rayna
Stamboliyska, merci beaucoup) : une
copie en ligne. En gros, Microsoft a
identifié des noms de
domaine utilisés par un groupe de délinquants nommé
Nickel (apparemment entre autres pour contrôler des botnets composés de machines
Microsoft Windows). La société a donc demandé à la justice de saisir ces
noms. Cela marche car ces domaines étaient dans les TLD
.com
et
.org
, TLD gérés par des
registres étatsuniens (alors que beaucoup de
gens croient qu'ils ont un statut « international »). La justice a
donné raison à Microsoft et ordonné le transfert des
noms. Techniquement, c'est l'équivalent d'un détournement de nom de
domaine ; Microsoft, ayant désormais le contrôle du nom, peut
changer les informations associées et, par exemple, envoyer le
trafic vers un serveur qu'ils contrôlent. La liste de ces noms
figure dans l'annexe A du jugement.
Prenons un de ces noms au hasard,
optonlinepress.com
. Une requête
whois nous montre le nouveau titulaire (on
admire la célérité de l'opération, effectuée le lendemain du
jugement) :
% whois optonlinepress.com ... Updated Date: 2021-12-03T21:42:26Z ... Registrant Name: Digital Crimes Unit Digital Crimes Unit Registrant Organization: Microsoft Corporation Registrant Street: One Microsoft Way, Registrant City: Redmond Registrant State/Province: WA Registrant Postal Code: 98052 Registrant Country: US ...
(Attention, .com
est un registre mince, et les
informations au registre peuvent être
différentes de celles au BE, notamment si l'injonction
judiciaire a visé le registre sans prévenir le BE. Mais, ici, tout
est cohérent.)
Le domaine est désormais délégué aux serveurs DNS faisant autorité de Microsoft (ici, avec l'outil check-soa) :
% check-soa optonlinepress.com NS104A.microsoftinternetsafety.net. 13.107.222.41: OK: 1 NS104B.microsoftinternetsafety.net. 13.107.206.41: OK: 1 ns001.microsoftinternetsafety.net. 13.107.222.41: OK: 1 ns002.microsoftinternetsafety.net. 13.107.206.41: OK: 1
(On notera que la liste des serveurs n'est pas la même dans la zone
parente, .com
et dans la zone
optonlinepress.com
. C'est une erreur de
configuration fréquente et Zonemaster proteste à juste
titre. Ici, encore plus rigolo, les serveurs supplémentaires
ont la même adresse
IP.)
DNSDB nous montre l'ancienne configuration :
;; bailiwick: com. ;; count: 136 ;; first seen: 2020-06-17 19:04:12 -0000 ;; last seen: 2021-12-01 16:37:44 -0000 optonlinepress.com. IN NS ns67.domaincontrol.com. optonlinepress.com. IN NS ns68.domaincontrol.com.
La nouvelle étant :
;; bailiwick: com. ;; count: 4 ;; first seen in zone file: 2021-12-04 22:50:22 -0000 ;; last seen in zone file: 2021-12-07 22:50:26 -0000 optonlinepress.com. IN NS ns104a.microsoftinternetsafety.net. optonlinepress.com. IN NS ns104b.microsoftinternetsafety.net.
L'adresse IP pour le nom optonlinepress.com
est
désormais 40.83.198.93
(chez Microsoft) alors
qu'elle était auparavant 172.105.98.76
(chez le
gros hébergeur Linode), qui ne répond plus
aujourd'hui. D'ailleurs, les anciens serveurs faisant autorité répondent
toujours pour ce nom (ce qui est courant en cas de saisie
judiciaire, l'ancien hébergeur n'ayant pas été prévenu) :
% dig +norecurse @ns67.domaincontrol.com. ANY optonlinepress.com ; <<>> DiG 9.16.22-Debian <<>> +norecurse @ns67.domaincontrol.com. ANY optonlinepress.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1600 ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1472 ;; QUESTION SECTION: ;optonlinepress.com. IN ANY ;; ANSWER SECTION: optonlinepress.com. 600 IN A 172.105.98.76 optonlinepress.com. 3600 IN NS ns67.domaincontrol.com. optonlinepress.com. 3600 IN NS ns68.domaincontrol.com. optonlinepress.com. 3600 IN SOA ns67.domaincontrol.com. dns.jomax.net. ( 2020111802 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 600 ; minimum (10 minutes) ) ;; Query time: 12 msec ;; SERVER: 2603:5:2174::2c#53(2603:5:2174::2c) ;; WHEN: Thu Dec 09 10:53:43 CET 2021 ;; MSG SIZE rcvd: 164
L'affaire a fait l'objet d'un article sur ArsTechnica qui semble essentiellement reprendre l'article officiel de Microsoft, qui est très médiocre (utilisant au hasard des termes comme server et website, et mélangeant tout).
Date de publication du RFC : Novembre 2021
Auteur(s) du RFC : J. Hong, T. You (ETRI, L. Dong, C. Westphal (Futurewei Technologies), B. Ohlman (Ericsson)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF icnrg
Première rédaction de cet article le 1 décembre 2021
L'ICN est l'idée (très contestable) qu'un réseau informatique sert à accéder à du « contenu » et que le réseau doit donc être architecturé autour de cette idée de contenu. Les noms identifient ainsi un contenu donné. Mais il faut bien ensuite trouver le contenu donc résoudre ces noms en quelque chose de plus concret. Ce RFC est le cahier des charges d'un tel système de résolution de noms pour les projets ICN. Comme beaucoup de cahier des charges, il est très « liste au Père Noël », accumulant des desiderata sans se demander s'ils sont réalistes (et compatibles entre eux !).
Comme avec beaucoup de documents qui promeuvent l'ICN, ce RFC donne une description erronée du nommage et de l'adressage dans l'Internet d'aujourd'hui. Passons, et voyons ce que l'ICN propose. L'idée est que le contenu est stocké dans des NDO (Named Data Objects) et que toute activité dans le réseau coniste à récupérer des NDO. Les NDO sont identifiés par un nom. Il ne s'agit pas seulement d'un identificateur mis au-dessus d'un réseau architecturé sur d'autres concepts (comme le sont les URI) mais du concept de base du réseau ; les routeurs ne routent plus selon des adresses mais selon les noms des NDO. Le problème est évidemment qu'il faudra bien, à la fin, trouver l'objet désiré. Cela nécessite (cf. RFC 7927) :
Ce RFC se focalise sur le premier point, le NRS (Name Resolution Service), et en est le cahier des charges. Le RFC 9236 a depuis décrit l'architecture envisagée. Si vous voulez apprendre des choses sur les ICN en général et la résolution de noms en particulier, voir par exemple « A Survey of Information-Centric Networking » ou « A Survey of Information-Centric Networking Research ».
Si on compare avec l'Internet actuel, le NRS aura un rôle analogue à celui de BGP (plutôt que du DNS, car le NRS sera au cœur du réseau, et complètement inséparable). Bon, ceci dit, c'est plus compliqué que cela car, derrière l'étiquette « ICN », il y a des tas de propositions différentes. Par exemple, certaines ressemblent plutôt à l'Internet actuel, avec une résolution de noms en localisateurs qui servent ensuite pour le routage (comme dans IDnet, cf. « IDNet: Beyond All-IP Network), alors que d'autres versions du concept d'ICN utilisent les noms pour le routage (comme le NDN ou le CCNx du RFC 8569). La section 2.4 du RFC compare ces approches.
La section 3 du RFC est ensuite le cahier des charges proprement dit. Malheureusement, elle plane au-dessus des réalités quand elle affirme par exemple qu'il faut un NRS qui fonctionnera de la même façon que l'espace de nommage soit plat ou hiérarchique. C'est très irréaliste, il n'y a pas de nette séparation entre la structure de l'espace de nommage et le mécanisme de résolution. Ainsi, ce mécanisme, dans le cas du DNS, est très lié à la structure des noms. Si on la change, tout le DNS serait à refaire (et sans doute en moins efficace). Parmi les systèmes d'ICN qui utilisent un nommage hiérarchique (et réintroduisent donc une forme de « localisation » dans les noms), on trouve NDN et CCNx.
Certains des mécanismes de résolution discutés ont déjà un RFC, par exemple le NI du RFC 6920, utilisé dans NetInf (cf. « Network of Information (NetInf) - An information-centric networking architecture »).
Bref, les principes du NRS :
Et le cahier des charges à proprement parler est en section 4. Je ne cite pas tout mais la liste au Père Noël comprend :
Une conclusion ? Les projets regroupés sous le nom d'ICN sont assez anciens, n'ont rien fait de vraiment nouveau récemment, et il y a peu de chances que ce RFC soit suivi de réalisations concrètes.
Date de publication du RFC : Novembre 2021
Auteur(s) du RFC : 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 1 décembre 2021
Rien de très grave dans ce nouveau RFC, qui règle un problème surtout bureaucratique, le fait que les politiques d'inclusion dans les registres IANA pour certains algorithmes utilisés par DNSSEC n'étaient pas parfaitement alignées.
En effet, le RFC 6014 avait modifié la politique d'enregistrement des algorithmes cryptographiques de « Action de normalisation » à la plus laxiste « RFC nécessaire » (rappelez-vous que tous les RFC ne sont pas des normes, voir le RFC 8126 qui décrit ces politiques possibles). Mais cette « libéralisation » laissait de côté certains algorithmes, ceux utilisés pour les enregistrements DS (RFC 4034), et ceux utilisés pour NSEC3 (RFC 5155), qui restaient en « Action de normalisation ». Notre nouveau RFC aligne les politiques d'enregistrement des algorithmes utilisés pour les DS et pour NSEC3 pour qu'ils soient eux aussi « RFC nécessaire ».
Il modifie également le RFC 8624 pour préciser que les algorithmes normalisés dans des RFC qui ne sont pas sur le chemin des normes sont également couverts par les règles du RFC 8624 ; en gros, ils sont facultatifs (MAY dans le langage du RFC 2119).
Les registres concernés sur celui sur NSEC3 et celui sur DS. Ils portent désormais la mention RFC Required.
Comme l'enregistrement d'algorithmes va, du fait de ce RFC, être plus léger, cela facilitera l'enregistrement de bons algorithmes, mais aussi de mauvais. Le programmeur qui met en œuvre DNSSEC, ou l'administratrice système qui le déploie, ne doit donc pas considérer que la présence dans un registre IANA vaut forcément approbation de la solidité cryptographique de l'algorithme. Il faut consulter la littérature technique avant d'utiliser ces algorithmes.
Auteur(s) du livre : Gabriele Balbi, Nelson
Ribeiro, Valérie Schafer, Christian
Schwarzenegger
Éditeur : De Gruyter Oldenbourg
978-3-11-073988-6
Publié en 2021
Première rédaction de cet article le 29 novembre 2021
Dans le débat public au sujet de l'Internet et du Web, il y a beaucoup de concepts qui sont discutés comme s'ils étaient nouveaux alors qu'ils ont en fait des racines anciennes (gouvernance, bulle de filtre, authenticité, participation d'amateurs…). Cet ouvrage collectif (en anglais) réunit plusieurs contributions qui analysent l'histoire d'un concept et ses origines, souvent bien antérieures au monde numérique.
Le livre a impliqué de nombreuses contributrices et de nombreux contributeurs (celles et ceux cité·es au début de cet article sont « juste » les coordinateurices). Chacun·e s'est attaqué à un concept particulier, montrant son historicité. Mon exemple favori a toujours été les soi-disant fake news, présentées comme une nouveauté du Web alors que le mensonge est aussi ancien que la communication. (Mais, en mettant le terme en anglais, on peut faire croire que c'est quelque chose de nouveau.) La version papier du livre est coûteuse mais il est sous une licence Creative Commons et peut être téléchargé.
Bien sûr, en insistant sur l'ancienneté d'un concept, et des débats qui l'ont toujours accompagné, il ne s'agit pas de dire que rien n'est nouveau, que tout existait déjà dans l'Antiquité. Mais juste de rappeler que la pression médiatico-commerciale a tendance à gommer le passé et à mettre en avant tous les mois un truc présenté comme nouveau.
Le livre commence logiquement par le concept de réseau, qui existait avant les réseaux informatiques, comme le réseau routier de l'empire romain (en étoile, « tous les chemins mènent à Rome », ce qui matérialisait la position dominante de la capitale), ou, plus récemment, le réseau télégraphique. Ces anciens réseaux ont déjà fait l'objet d'innombrables études et réflexions, rappelées par Massimo Rospocher et Gabriele Balbi. Certaines de ces études et réflexions s'appliquent toujours à l'ère de l'Internet. Le concept de multimédia fait l'objet d'un passionnant article de Katie Day Good, qui évoque les espoirs qu'avaient fait naitre les nouveaux médias, par exemple dans le domaine de l'éducation. Les commerciaux des entreprises liées à la radio annonçaient sans rire que radio et autres médias nouveaux à l'époque allaient révolutionner l'enseignement. On retrouve dans les textes de la première moitié du XXe siècle bien des illusions technosolutionnistes d'aujourd'hui. Toujours dans la technique, l'intelligence artificielle est bien sûr à l'honneur, tant le concept est ancien mais ressort régulièrement comme solution miracle à tous les problèmes (article de Paolo Bory, Simone Natale et Dominique Trudel).
Après la technique, la politique. « Gouvernance » est également un concept présenté comme nouveau alors que la politique (arriver à prendre des décisions quand tout le monde n'a pas les mêmes intérêts et les mêmes opinions) est étudiée depuis pas mal de siècles. Comme le rappellent Francesca Musiani et Valérie Schafer, la politique sur l'Internet a des particularités nouvelles, mais les questions politiques liées à l'émergence d'un nouveau réseau ne sont pas, elles, une nouveauté. On se posait des questions de gouvernance bien avant l'Internet, par exemple avec le télégraphe. De même, l'usage de données pour gouverner (la « dataification »), analysée par Eric Koenen, Christian Schwarzenegger et Juraj Kittler, remonte à longtemps, par exemple aux efforts de Jean-Baptiste Colbert en France pour que tout ce qui se passe en France lui soit transmis. On fichait déjà tout, avant que l'arrivée des ordinateurs n'accélère considérablement la quantité de données récoltées, et on en espérait déjà, avant qu'on parle de big data un gouvernement plus efficace. Évidemment, le concept de fake news a droit à son article, et Monika Hanley et Allen Munoriyarwa font un intéressant historique de l'histoire de la tromperie et de la propagande mensongère, remontant au second triumvirat de Rome, en 43 avant l'ère commune, et passant par le XIXe siècle, où l'extension de la littératie et la diffusion massive des journaux allait pouvoir faire décoller cette activité (un fait que les médias d'aujourd'hui oublient quand ils critiquent les fake news diffusées sur le Web). Même regard critique de Maria Löblich et Niklas Venema sur les « bulles de filtre », qui ne sont pas apparues avec les « algorithmes » des réseaux sociaux.
Une autre section traite des utilisateurs et de leurs pratiques. Jérôme Bourdon traite le cas de la présence et de la distance. Quand on communique « en présentiel » et pas par courrier électronique, est-ce qu'on communique « en vrai » ? Des gens avec qui on n'interagit qu'en ligne sont-ils de « vrais » ami·es ? Et, pour prendre un exemple récent, une réunion en ligne est-elle une vraie réunion ? Cicéron et Madame de Sévigné sont cités pour leurs réflexions à ce sujet, montrant qu'à chaque époque, des gens s'inquiétaient de savoir ce qu'était la présence. Dans son article sur la solitude, Edward Brennan poursuit le même genre de réflexions, ce qui permet de relativiser certaines inquiétudes sur « l'adolescent dans sa chambre qui n'interagit qu'en ligne ». Autre phénomène social étudié, les fans et leurs pratiques (j'en profite pour vous recommander le livre de Mélanie Bourdaa sur ce sujet des fans). Eleonora Benecchi et Erika Ningxin Wang décrivent le phénomène du fandom. Par contre, il est curieux qu'elles commencent par brandir des étiquettes raciales et prétendent avoir une approche « décoloniale » quand les seuls exemples non-« occidentaux » cités sont ceux de pays qui n'ont pas été colonisés (Chine et Japon). Et puis commencer par dire que la Chine est différente de l'Occident pour donner ensuite comme exemple que les fans, en Chine, ont une relation affective avec le personnage de fiction qu'ils aiment… Comme si ce n'était pas le cas de tous les fans… C'est l'avantage et l'inconvénient des ouvrages collectifs, il n'y a pas d'unité. Mais la quasi-totalité des articles sont excellents (je ne les ai pas tous cités ici).
Ce livre est écrit par des universitaires pour un public déterminé à s'accrocher un peu. Mais cela vaut la peine, j'y ai appris beaucoup de choses et j'ai bien perçu la profondeur de ces questions, qui agitent l'humanité depuis longtemps.
Première rédaction de cet article le 28 novembre 2021
Une statistique tout à fait inutile mais, bon, on est dimanche soir. Quels sont les RFC les plus cités sur ce blog ?
Je mentionne en effet très souvent des RFC et je pointe vers l'article de résumé que j'ai écrit. La façon dont ce blog est écrit permet facilement d'écrire un petit programme pour voir quels RFC sont les plus fréquemment utilisés ici, un critère de tri qui en vaut bien d'autres :
% ./most-cited-rfcs.py RFC 1918: 66 times RFC 5246: 66 times RFC 1035: 63 times ...
On trouve donc dans l'ordre décroissant des citations sur ce blog :
From:
, Date:
,
Subject:
…). L'importance du courrier
électronique explique sa bonne position dans cette liste. À noter
que beaucoup de gens citent encore le RFC 822, qui n'est plus la norme de l'IMF depuis bien
longtemps.Évidemment, cette liste reflète surtout les choix éditoriaux de l'auteur et n'indique donc pas une quelconque « importance » de tel ou tel RFC.
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 :
Vous voyez ici le schéma de la résolution DNS sans la
QNAME minimisation puis avec :
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
Il existe aussi une étude récente sur la QNAME minimization en République Tchèque.
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.
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 ...
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.)
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é.)
Pour voir, j'ai mis sur cette machine
perruche.bortzmeyer.org
un très simple serveur
HTTP qui ne répond qu'à /hello
et
/date
:
% curl http://perruche.bortzmeyer.org/date The time is 20:43:09.579900
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 :
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 :
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ée 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. Et un intéressant interview vidéo de l'auteure.
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.
Des limites ou des défauts de cette solution ? Les deux principaux me semblent :
Bref, cette solution a l'avantage d'être très simple à mettre en œuvre pour un besoin ponctuel ou personnel, mais n'est pas forcément bien adaptée pour un analyseur « de production ».
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.
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
. Dans
les réponses ci-dessous, https://dns.bortzmeyer.org/facebook.com?server=113.113.113.113
162.125.32.5
appartient à Dropbox, pas Facebook :
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 :
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.)
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 ?
Sur ce livre, il y a aussi une présentation d'une heure en vidéo et un article de Bruno Devauchelle dans le Café Pédagogique.
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
Dernière mise à jour le 4 mai 2022
Le TLD
.arpa
sert pour
différentes fonctions techniques et est géré directement par
l'IAB. Ce
RFC décrit un
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
Comme vous pouvez le voir, c'était presque tous les serveurs de la
racine (si vous aimez les jeux : quel serveur de la racine n'hébergeait
pas .arpa
?). La raison pour cela est que
.arpa
est critique et doit donc bénéficier d'un
hébergement solide. Profiter des serveurs de la racine était donc
intéressant. Mais le problème est que ça lie
.arpa
à la racine. On pourrait avoir envie de
faire des changements dans les serveurs faisant autorité pour
.arpa
sans toucher aux serveurs de la racine,
celle-ci étant encore plus critique (cf. RFC 7720). Le principe de base de notre nouveau RFC est donc : découpler les
serveurs DNS de .arpa
de ceux de la racine (ce
qui avait été fait pour ip6.arpa
il y a dix ans,
voir le RFC 5855).
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. 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 sont dans le
sous-domaine ns.arpa
, on a 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). Il n'y a désormais
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.) Voici l'état actuel :
% dig +nodnssec NS arpa ; <<>> DiG 9.16.1-Ubuntu <<>> +nodnssec NS arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15962 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;arpa. IN NS ;; ANSWER SECTION: arpa. 517877 IN NS h.ns.arpa. arpa. 517877 IN NS i.ns.arpa. arpa. 517877 IN NS k.ns.arpa. arpa. 517877 IN NS l.ns.arpa. arpa. 517877 IN NS m.ns.arpa. arpa. 517877 IN NS a.ns.arpa. arpa. 517877 IN NS b.ns.arpa. arpa. 517877 IN NS c.ns.arpa. arpa. 517877 IN NS d.ns.arpa. arpa. 517877 IN NS e.ns.arpa. arpa. 517877 IN NS f.ns.arpa. arpa. 517877 IN NS g.ns.arpa. ;; Query time: 3 msec ;; SERVER: 192.168.2.254#53(192.168.2.254) ;; WHEN: Wed May 04 08:57:47 CEST 2022 ;; MSG SIZE rcvd: 228
Vous pouvez également voir cet é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.
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.
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 :
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 de
SpaceWeatherLive, ou du 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 :
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).
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. ».)
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 :
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.
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 DTLS… TCP 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 9147). 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.
Première rédaction de cet article le 9 octobre 2021
Dernière mise à jour le 4 octobre 2022
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 plus 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.
J'emprunte à Pierre Beyssac une terminologie intéressante (cf. son fil Twitter originel) : il y a le modèle « conséquentiel » qui se focalise sur les conséquences d'un acte individuel. Je fais dix kilomètres en voiture, cela aura des conséquences environnementales, je renonce à prendre la voiture, il n'y aura pas de conséquences environnementales. Et le modèle « attributif » qui consiste à diviser une empreinte environnementale globale par le nombre d'utilisations, même s'il n'y a pas linéarité des causes et des effets. Le modèle conséquentiel est plus frappant (« si vous prenez votre voiture au lieu du vélo, vous relâcherez X grammes de gaz à effet de serre ») mais plus difficile (voire impossible) à calculer sérieusement dans le monde du numérique. On se sert donc plutôt en général de modèles attributifs, mais en les faisant passer pour des modèles conséquentiels, et en utilisant la « force de frappe » rhétorique de ces derniers, ce qui est intellectuellement malhonnête.
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 :
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) :
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ébogage, 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 :
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 :
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) :
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 :
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 :
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.
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.
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.
Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : F. Gont (SI6 Networks), N. Hilliard (INEX), G. Doering (SpaceNet AG), W. Kumari (Google), G. Huston (APNIC), W. Liu (Huawei Technologies)
Pour information
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 20 septembre 2021
IPv6 souffre de réseaux mal gérés qui se permettent de jeter les paquets ayant des caractéristiques normales, mais qui déplaisent à certains équipements réseau. C'est par exemple le cas des paquets utilisant les en-têtes d'extension. Pourquoi les paquets utilisant ces en-têtes sont-ils souvent jetés ?
Ces en-têtes d'extension (qui n'ont pas d'équivalent en IPv4) sont normalisés dans le RFC 8200, section 4. Ils servent à la fois à des fonctions de base d'IPv6 (comme la fragmentation) et à étendre le protocole si nécessaire. Mais, en pratique, on observe trop souvent que les paquets IPv6 utilisant ces en-têtes d'extension ne passent pas sur certains réseaux. Ce RFC vise à étudier pourquoi, et à expliquer les conséquences. Comme toujours quand on explique un phénomène (la délinquance, par exemple), des gens vont comprendre de travers et croire qu'on justifie le phénomène en question (« expliquer, c’est déjà vouloir un peu excuser », avait stupidement dit un ancien premier ministre français, à propos du terrorisme djihadiste). Le cas est d'autant plus fréquent qu'en français, « comprendre » est ambigu, car il peut désigner l'explication (qui est utile aussi bien aux partisans qu'aux adversaires d'un phénomène) que la justification. Bref, ce RFC explique pourquoi des paquets innocents sont détruits, il ne dit pas qu'il faut continuer à le faire !
La section 4 du RFC explique la différence entre l'en-tête d'un paquet IPv6 et celui d'un paquet de l'ancienne version. Dans les deux versions, le problème est de placer des options dans les en-têtes. Le gros changement est l'utilisation par IPv6 d'un en-tête de taille fixe (40 octets), suivi d'une liste chainée d'en-têtes d'extension permettant d'encoder ces options. Au contraire, IPv4 avait un en-tête de taille variable (entre 20 et 60 octets), avec un champ indiquant sa longueur, champ qu'il fallait lire avant d'accéder à l'en-tête. Le mécanisme d'IPv4 n'était ni pratique, ni rapide, mais celui d'IPv6 n'est pas plus satisfaisant : il faut lire toute la liste chainée (dont la longueur est quelconque et non limitée) si on veut accéder aux informations au-dessus de la couche 3. Ce n'est pas un problème pour les routeurs, à qui la couche 3 suffit (à part le cas de l'en-tête Hop-by-hop options), mais c'est ennuyeux pour les autres boitiers situés sur le chemin, comme les pare-feux. Les évolutions récentes d'IPv6 ont aidé, comme l'obligation que tous les en-têtes d'extension soient dans le premier fragment, si le datagramme est fragmenté (RFC 7112), ou comme l'imposition d'un format commun aux futurs en-têtes d'extension (dans le RFC 6564), mais l'analyse de la liste des en-têtes d'extension reste un travail pénible pour les machines.
Le problème est identifié depuis longtemps. Il est analysé dans
l'Internet-Draft
draft-taylor-v6ops-fragdrop
,
dans draft-wkumari-long-headers
,
dans draft-kampanakis-6man-ipv6-eh-parsing
mais aussi dans des RFC, le RFC 7113, le
RFC 8900 et le RFC 9288. Cela a mené à plusieurs changements
dans la norme, je vous renvoie aux RFC 5722,
RFC 7045, RFC 8021,
etc. Plusieurs changements ont été intégrés dans la dernière
révision du RFC principal de la norme, le RFC 8200. Ainsi, celui-ci dispense désormais les routeurs de
chercher un éventuel en-tête d'extension Hop-by-hop
options.
Parallèlement à ces analyses du protocole, diverses études ont porté sur le phénomène des paquets jetés s'ils contenaient des en-têtes d'extension. Cela a été documenté dans « Discovering Path MTU black holes on the Internet using RIPE Atlas », dans « IPv6 Extension Headers in the Real World v2.0 », également dans « Dealing with IPv6 fragmentation in the DNS » et « Measurement of IPv6 Extension Header Support » ainsi que dans le RFC 7872.
Comment est-ce que les équipements intermédiaires du réseau fonctionnent, et pourquoi est-ce que les en-têtes d'extension IPv6 peuvent parfois les défriser ? La section 6 du RFC rappelle l'architecture de ces machines. Un routeur de cœur de réseau est très différent de l'ordinateur de base, avec son processeur généraliste et sa mémoire de grande taille, ce qui le rend lent, mais souple. Au contraire, la transmission des paquets par le routeur est en général faite par du matériel spécialisé, ASIC ou NPU. (Vous pouvez consulter des explications dans l'exposé fait à l'IETF « Modern Router Architecture for Protocol Designers » et dans l'article « Modern router architecture and IPv6 ».) Avant de transmettre un paquet reçu sur l'interface de sortie, le routeur doit trouver quelle interface utiliser. Une méthode courante est de prendre les N premiers octets du paquet et de les traiter dans une TCAM ou une RLDRAM, où se fera la détermination du saut suivant (et donc de l'interface de sortie). Le choix du nombre N est crucial : plus il est petit, plus le routeur pourra traiter de paquets, mais moins il aura d'information sur le paquet. (En pratique, on observe des N allant de 192 à 384 octets.) Du fait qu'un routeur se limite normalement à la couche Réseau, et que l'en-tête IPv6 a une taille fixe, envoyer simplement les 40 octets de cet en-tête devrait suffire. Mais lisez plus loin : certains routeurs ou autres équipements intermédiaires sont configurés pour regarder au-delà, et voudraient des informations de la couche Transport, plus dure à atteindre.
Une solution, pour les routeurs qui ne lisent qu'un nombre limité d'octets avant de prendre une décision, est de lire les en-têtes d'extension un par un, et de réinjecter le reste du paquet dans le dispositif de traitement. Ça se nomme la recirculation, c'est plus lent, mais ça marche quelle que soit la longueur de la chaîne des en-têtes d'extension.
Comme le routeur comprend toujours un processeur généraliste (ne serait-ce que pour faire tourner les fonctions de contrôle comme SSH et les protocoles de routage), une autre solution serait d'envoyer à ce processeur les paquets « compliqués » (mais lire le RFC 6192 d'abord). L'énorme différence de performance entre le processeur généraliste et les circuits spécialisés fait que ce ne serait pas une solution réaliste sauf pour un trafic très modéré. (Le RFC note que certains routeurs ont trois dispositifs de traitement des paquets, et pas seulement deux comme présenté plus haut : outre le processeur généraliste, qui ne leur sert qu'aux fonctions de contrôle, et des circuits matériels spécialisés, ils ont un dispositif logiciel de transmission des paquets. Plus souple que les circuits spécialisés, il n'est pas forcément plus rapide que le processeur généraliste mais, au moins, il n'interfère pas avec les fonctions de contrôle.)
Bon, on l'a déjà dit, mais cela vaut la peine de le répéter : à part le cas (agaçant) de l'en-tête Hop-by-hop options, un routeur, équipement de couche 3 n'a normalement aucun besoin d'aller regarder tous les en-têtes d'extension (qui sont presque tous pour la machine terminale de destination uniquement). Encore moins de faire du DPI et d'aller chercher des informations dans les couches 4 à 7. Mais la section 7 du RFC explique pourquoi certains routeurs le font quand même (il s'agit d'une description de leurs pratiques, pas une approbation ; beaucoup des raisons données sont mauvaises).
D'abord, la répartition de charge et l'ECMP. Si un routeur peut faire passer un paquet via deux interfaces différentes, laquelle choisir ? Alterner (un coup à gauche, un coup à droite) augmenterait la probabilité d'une arrivée des paquets dans le désordre. On préfère la prédictabilité : tous les paquets d'un même flot doivent suivre le même chemin. Comment déterminer le « flot », notion parfois un peu floue ? En restant dans les couches basses, on peut utiliser uniquement les adresses IP de source et de destination mais elles ne sont pas assez discriminantes. En IPv6, on peut en théorie utiliser l'étiquette de flot (normalisé dans le RFC 6437, ainsi que les RFC 6438 et RFC 7098 pour son utilisation) mais elle n'est pas toujours présente, en partie (encore !) par la faute de middleboxes qui, ignorant ce concept d'étiquette de flot, jetaient les paquets qui en avaient une. (Voir les articles de I. Cunha, « IPv4 vs IPv6 load balancing in Internet routes » et J. Jaeggli, « IPv6 flow label: misuse in hashing ».) En pratique, les systèmes qui ont besoin d'identifier les flots utilisent plutôt une heuristique : le tuple à cinq élements {protocole de transport, adresse IP source, adresse IP destination, port source, port destination}. Ce n'est pas parfait mais, en pratique, cela marche à peu près. On voit que cela nécessite d'accéder à de l'information de la couche Transport, les ports. (Cette heuristique a d'autres limites : par exemple elle ne marche pas si une partie de la couche Transport est chiffrée, comme c'est le cas avec QUIC.)
Autre cas où un boitier intermédiaire ressent le besoin d'accéder aux informations des couches supérieures, les ACL. La plupart des pare-feux permettent d'utiliser comme critère de filtrage les numéros de ports, ce qui va nécessiter d'analyser la chaine des en-têtes d'extension IPv6 pour parvenir à la couche Transport. Entre les pare-feux mal faits qui cherchent les informations de la couche Transport immédiatement après l'en-tête fixe (car le programmeur a tout simplement sauté la partie du RFC qui parlait des en-têtes d'extension) et les difficultés posées par le fait, qu'avant le RFC 6564, les en-têtes d'extension inconnus étaient impossibles à analyser, on voit qu'arriver à la couche Transport n'est pas si facile que ça (le RFC dit qu'il est plus compliqué d'analyser IPv6 qu'IPv4, ce qui est très contestable ; mais ce n'est en effet pas plus facile). Cela peut avoir des conséquences en terme de sécurité, par exemple si un méchant ajoute des en-têtes d'extension dans l'espoir que ses paquets ne soient pas correctement identifiés (cf. RFC 7113).
Autre exemple, le réassemblage des paquets fragmentés nécessite un état (mémoriser les fragments en cours de réassemblage), ce qui peut être fatal à la mémoire du pare-feu, notamment en cas d'attaque. Pour les coûts de ce filtrage, voir l'article d'E. Zack « Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests ». Cette difficulté peut encourager les pare-feux à jeter les paquets ayant des en-têtes d'extension, surtout si un administrateur réseaux ignorant dit bien fort « ces en-têtes d'extension ne servent à rien de toute façon » (RFC 7872).
Un problème proche est celui de la protection contre les attaques par déni de service. Filtrer avec les adresses IP peut être fait rès efficacement (cf. RFC 5635) mais ne marche pas, par exemple si l'adresse IP source est usurpée. Une des méthodes utilisées alors est de repérer un motif récurrent dans les paquets envoyés par l'attaquant, et de filtrer sur ce motif (vous pouvez lire ici un exemple avec le DNS). Là encore, des informations au-delà de la couche Réseau sont nécessaires. Toujours en sécurité, les NIDS ont aussi besoin de plus d'informations que ce que fournit la couche Réseau.
Et, bien sûr, comme toute complexité, les en-têtes d'extension augmentent les risques de sécurité, d'autant plus qu'il y a un cercle vicieux : comme ils sont peu utilisés, le code qui les traite est peu testé, donc il y a des bogues, donc ils sont peu utilisés, etc.
Donc, un certain nombre de machines intermédiaires, qui assurent des fonctions allant au-delà de ce que fait un « simple » routeur, ont des problèmes avec les en-têtes d'extension IPv6 et choisissent souvent la solution de facilité, qui est de les jeter systématiquement.
Première rédaction de cet article le 17 septembre 2021
Une méthode courante pour réaliser une attaque par déni de service sur l'Internet est de trouver un réflecteur, une machine qui, sollicitée par l'attaquant, va envoyer des paquets vers la victime. Les bons (du point de vue de l'attaquant…) réflecteurs font en outre de l'amplification, émettant davantage de paquets et/ou d'octets qu'envoyés par l'attaquant. Un article à la conférence Usenix d'août 2021 expose un nouveau type de réflecteurs : les innombrables middleboxes placées pour censurer des communications sont tellement mal conçues qu'elles font d'excellents (du point de vue de l'attaquant…) réflecteurs.
Détaillons cet article, « Weaponizing Middleboxes for TCP Reflected Amplification ». Le but d'un attaquant est de trouver de nombreux réflecteurs (plus ils sont nombreux, plus l'attaque sera efficace) mais aussi de maximiser l'amplification (on parle de BAF - Bandwidth Amplification Factor - pour le gain en octets et de PAF - Packet Amplification Factor - pour le gain en paquets). On a ainsi vu des attaques exploitant l'amplification de protocoles utilisant UDP, comme par exemple le DNS ou bien NTP. Une des bases de l'attaque par réflexion étant de mentir sur son adresse IP, a priori, ces attaques ne sont pas possibles avec TCP, qui protège contre cette usurpation (RFC 5961). Mais, en fait, on sait déjà que des attaques par réflexion avec TCP sont possibles, et qu'elles ont parfois un bon BAF. C'est ce que développent les auteurs de l'article.
Comme réflecteurs, ils utilisent des
middleboxes, ces engins
installés en intermédiaires sur un grand nombre de chemins sur
l'Internet, qui examinent le trafic et agissent, souvent n'importe
comment. Une utilisation courante des middleboxes
est la censure, soit étatique (au niveau d'un
pays), soit au niveau
d'un réseau local. Par exemple, la middlebox va
examiner le trafic HTTP et, si l'adresse IP de destination est sur sa
liste de blocage, empêcher la communication. Une des façons de le
faire est de prétendre être le vrai serveur et de renvoyer une page
indiquant que la connexion est bloquée :
Arrivé là, vous commencez à voir comment cela peut être exploité pour une attaque : l'attaquant envoie un paquet TCP d'ouverture de connexion (paquet SYN) vers une adresse IP censurée, en usurpant l'adresse IP de la victime, et le message de censure, avec l'image, sera envoyée à la victime, fournissant un BAF sérieux.
Mais, là, vous allez me dire que ça ne marchera pas, TCP ne fonctionne pas comme cela : la middlebox n'arrivera pas à établir une session TCP complète puisque la victime ne répondra pas aux accusés de réception, ou bien enverra un paquet de fin de session (paquet RST). Mais c'est là que l'article devient intéresssant : les auteurs ont découvert que de nombreuses middleboxes ne font pas du TCP correct : elles envoient le message de censure (une page Web complète, avec images), sans attendre qu'une session TCP soit établie.
Ce n'est pas uniquement de l'incompétence de la part des auteurs des logiciels qui tournent dans la middlebox. C'est aussi parce que, notamment dans le cas de la censure étatique, la middlebox ne voit pas forcément passer tous les paquets, le trafic Internet étant souvent asymétrique (si on a plusieurs liaisons avec l'extérieur). Et puis il faut aller vite et avoir le moins possible d'état à mémoriser. La middlebox ne se donne donc pas la peine de vérifier que la session TCP a été établie, elle crache ses données tout de suite, assomant la victime pour le compte de l'attaquant. L'amplification maximale observée (en octets, le BAF) a été de plus de 7 000… Et certains cas pathologiques permettaient de faire encore mieux.
Comment ont été trouvées les middleboxes
utilisables ? Comme l'attaque ne marche que si la
middlebox ne fait pas du TCP
correct, les conditions exactes du déclenchement de la réflexion ne
sont pas faciles à déterminer. Les auteurs ont donc envoyé une
variété de paquets TCP (avec ou sans PSH, ACK, etc) et utilisé le
système d'apprentissage Geneva pour
découvrir la solution la plus efficace. (Au passage, le meilleur
déclencheur de la censure semble être
www.youporn.com
, largement bloqué un peu
partout.) En balayant tout l'Internet avec
ZMap, ils ont pu identifier un grand nombre
de réflecteurs. Ils ne les ont évidemment pas utilisé pour une vraie
attaque, mais des méchants auraient pu le faire, montrant ainsi le
danger que présente ces boitiers bogués et largement répandus (ils
sont très populaires auprès des décideurs), alors
qu'ils fournissent une armée de réflecteurs prêts à l'emploi.
Certains réflecteurs arrivent même à des facteurs d'amplification incroyables, voire infinis (une fois un paquet envoyé par l'attaquant, le tir de barrage du réflecteur ne cesse jamais). Les auteurs expliquent cela par des boucles de routage, faisant passer le paquet déclencheur plusieurs fois par la middlebox (et parfois sans diminuer le TTL), ainsi que par des réactions aux réactions de la victime (qui envoie des paquets RST).
Des bons réflecteurs d'attaque ont été identifiés à des nombreux endroits, comme l'université Brigham Young ou la municipalité de Jacksonville. Identifier les produits utilisés a été plus difficile mais on pu repérer le Dell SonicWALL NSA 220 ou un équipement Fortinet. D'un point de vue géopolitique, on notera que les réflecteurs sont situés un peu partout, avec évidemment davantage de présence dans les dictatures. Par contre, la Chine est assez peu représentée, leur système de censure étant (hélas) plus intelligement bâti.
Première rédaction de cet article le 16 septembre 2021
Le mardi 14 septembre est sortie la version 14 d'Unicode (retardée pour cause de Covid-19). Une description officielle des principaux changements est disponible mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)
Pour explorer plus facilement la grande base Unicode, j'utilise un programme qui la convertit en SQL et permet ensuite de faire des analyses variées. Faisons quelques requêtes SQL :
ucd=> SELECT count(*) AS Total FROM Characters; total -------- 144762
Combien de caractères sont arrivés avec la version 14 ?
ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version::float; ... 11.0 | 684 12.0 | 554 12.1 | 1 13.0 | 5930 14.0 | 838
838 nouveaux caractères, c'est une version calme (la version 13 apportait bien davantage de caractères). Quels sont ces nouveaux caractères ?
ucd=> SELECT To_U(codepoint) AS Code_point, name FROM Characters WHERE version='14.0' ORDER BY Codepoint; code_point | name -----------+---------------------------------------------------------------------------- ... U+870 | ARABIC LETTER ALEF WITH ATTACHED FATHA U+871 | ARABIC LETTER ALEF WITH ATTACHED TOP RIGHT FATHA U+872 | ARABIC LETTER ALEF WITH RIGHT MIDDLE STROKE U+873 | ARABIC LETTER ALEF WITH LEFT MIDDLE STROKE U+874 | ARABIC LETTER ALEF WITH ATTACHED KASRA ... U+12F90 | CYPRO-MINOAN SIGN CM001 U+12F91 | CYPRO-MINOAN SIGN CM002 U+12F92 | CYPRO-MINOAN SIGN CM004 U+12F93 | CYPRO-MINOAN SIGN CM005 ... U+1CF00 | ZNAMENNY COMBINING MARK GORAZDO NIZKO S KRYZHEM ON LEFT U+1CF01 | ZNAMENNY COMBINING MARK NIZKO S KRYZHEM ON LEFT U+1CF02 | ZNAMENNY COMBINING MARK TSATA ON LEFT ... U+1E290 | TOTO LETTER PA U+1E291 | TOTO LETTER BA U+1E292 | TOTO LETTER TA U+1E293 | TOTO LETTER DA ... U+1FAAC | HAMSA U+1FAB7 | LOTUS U+1FAB8 | CORAL U+1FAB9 | EMPTY NEST U+1FABA | NEST WITH EGGS ...
Cette version amène en effet plusieurs écritures nouvelles comme le toto, le chypro-minoen (toujours pas déchiffré, ce qui explique que ses caractères aient un numéro et pas un nom), le vieil ouïghour (écriture pour laquelle ont été fabriquées les plus anciens caractères mobiles connus), le vithkuqi, ou le tangsa. On trouve également beaucoup de nouveaux caractères de l'alphabet arabe pour écrire des langues non-arabes.
Plus anecdotique, on trouve également la notation musicale Znamenny.
Si vous avez les bonnes polices de caractères, vous allez pouvoir voir quelques exemples (sinon, le lien mène vers Uniview). Un nouveau symbole apparait, le Som (⃀), pour la monnaie officielle du Kirghizistan. Et on a l'habituelle succession de nouveaux émojis, plus ou moins utiles. Les recruteurs aimeront l'index pointé 🫵, les royalistes seront contents de la tête couronnée 🫅, les nostalgiques d'Usenet auront le troll 🧌, les fanas de Dune frémiront en voyant l'eau qu'on verse 🫗, les geeks s'angoisseront de la batterie vide 🪫 et les partisans de la surveillance de la population noteront qu'on a un émoji « carte d'identité » 🪪. Les personnes transgenres remarqueront l'homme enceint (🫃, ainsi que la personne enceinte 🫄, la femme enceinte 🤰 était arrivée en Unicode version 9).
Tiens, d'ailleurs, combien de caractères Unicode sont des symboles (il n'y a pas que les emojis parmi eux, mais Unicode n'a pas de catégorie « emoji ») :
ucd=> SELECT count(*) FROM Characters WHERE category IN ('Sm', 'Sc', 'Sk', 'So'); count ------- 7741
Ou, en plus détaillé, et avec les noms longs des catégories :
ucd=> SELECT description,count(category) FROM Characters,Categories WHERE Categories.name = Characters.category AND category IN ('Sm', 'Sc', 'Sk', 'So') GROUP BY category, description; description | count -----------------+------- Modifier_Symbol | 125 Other_Symbol | 6605 Math_Symbol | 948 Currency_Symbol | 63
Date de publication du RFC : Août 2021
Auteur(s) du RFC : R. Raszuk (NTT Network Innovations), B. Decraene (Orange), C. Cassar, E. Aman, K. Wang (Juniper Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 13 septembre 2021
Les grands AS ont tellement de routeurs BGP qu'ils ne peuvent pas connecter chaque routeur à tous les autres. On utilise alors souvent des réflecteurs de route, un petit nombre de machines parlant BGP auxquelles tout le monde se connecte, et qui redistribuent les routes externes apprises. Mais une machine BGP ne redistribue que les routes qu'elle utiliserait elle-même. Or, le réflecteur risque de faire un choix en fonction de sa position dans le réseau, qui n'est pas la même que celle du routeur « client ». Les routeurs risquent donc d'apprendre du réflecteur des routes sous-optimales (la route optimale étant typiquement celle qui amène à la sortie le plus vite possible, en application de la méthode de la patate chaude). Ce RFC définit une extension de BGP qui va permettre de sélectionner des routes spécifiques à un client, ou à un groupe de clients.
Un petit rappel : un réflecteur de routes (route reflector) fonctionne sur iBGP (Internal BGP), à l'intérieur d'un AS, alors que les serveurs de routes (route server) font de l'eBGP (External BGP), par exemple sur un point d'échange. Ces réflecteurs sont décrits dans le RFC 4456. Ils ne sont pas la seule méthode pour distribuer l'information sur les routes externes à l'intérieur d'un grand AS, mais c'est quand même la solution la plus fréquente.
Le RFC 4456 notait déjà que, vu les coûts attribués aux liens internes à l'AS, le réflecteur ne choisirait pas forcément les mêmes routes que si on avait utilisé un maillage complet. Le routage « de la patate chaude » (qui consiste à essayer de faire sortir le paquet de son réseau le plus vite possible, pour que ce soit un autre qui l'achemine) risque donc de ne pas aussi bien marcher : le point de sortie lorsqu'on utilise le réflecteur sera peut-être plus éloigné que si on avait le maillage complet, surtout si le réflecteur est situé en dehors du chemin habituel des paquets et n'a donc pas la même vision que les routeurs « normaux ». Or, c'est un cas fréquent. Le réflecteur choisira alors des routes qui sont optimales pour lui, mais qui ne le sont pas pour ces routeurs « normaux ».
La solution ? Permettre à l'administrateur réseaux de définir une localisation virtuelle pour le réflecteur, à partir de laquelle il fera ses calculs et choisira ses routes, au lieu d'utiliser sa localisation physique. Cette localisation virtuelle sera une adresse IP. Le réflecteur peut avoir plusieurs de ces localisations virtuelles, adaptées à des publics différents. Bref, le texte du RFC 4271 qui concerne la sélection de la meilleure route (section 9.1.2.2 du RFC 4271) est modifié pour remplacer « en fonction du saut suivant » par « en fonction de l'adresse IP configurée dans le réflecteur ».
Pour que cela marche, il faut que le réflecteur ait une vue complète du réseau, pour pouvoir calculer des coûts à partir de n'importe quel point du réseau. C'est possible avec les IGP à état des liens comme OSPF, ou bien avec BGP-LS (RFC 7752).
Et si le réflecteur a plusieurs clients ayant des desiderata différents, par exemple parce qu'ils sont situés à des endroits différents ? Dans ce cas, il doit faire tourner plusieurs processus de décision, chacun configuré avec une localisation vituelle différente.
Les principales marques de routeurs mettent déjà en œuvre ce RFC, comme on peut le voir sur la liste des implémentations. Du côté des logiciels qui ne sont pas forcément installés sur des routeurs, il semble que BIRD ne sache pas encore faire comme décrit dans ce RFC.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : F. Gont, G. Gont (SI6 Networks), M. Lichvar (Red Hat)
Chemin des normes
Première rédaction de cet article le 13 septembre 2021
Le protocole NTP utilisait traditionnellement un port bien connu, 123, comme source et comme destination. Cela facilite certaines attaques en aveugle, lorsque l'attaquant ne peut pas regarder le trafic, mais sait au moins quels ports seront utilisés. Pour compliquer ces attaques, ce RFC demande que NTP utilise des numéros de ports aléatoires autant que possible.
NTP est un très vieux protocole (sa norme actuelle est le RFC 5905 mais sa première version date de 1985, dans le RFC 958). Dans son histoire, il a eu sa dose des failles de sécurité. Certaines des attaques ne nécessitaient pas d'être sur le chemin entre deux machines qui communiquent car elles pouvaient se faire en aveugle. Pour une telle attaque, il faut deviner un certain nombre de choses sur la communication, afin que les paquets de l'attaquant soient acceptés. Typiquement, il faut connaitre les adresses IP source et destination, ainsi que les ports source et destination et le key ID de NTP (RFC 5905, section 9.1). NTP a plusieurs modes de fonctionnement (RFC 5905, sections 2 et 3). Certains nécessitent d'accepter des paquets non sollicités et, dans ce cas, il faut bien écouter sur un port bien connu, en l'occurrence 123. Mais ce n'est pas nécessaire dans tous les cas et notre RFC demande donc qu'on n'utilise le port bien connu que si c'est nécessaire, au lieu de le faire systématiquement comme c'était le cas au début de NTP et comme cela se fait encore trop souvent (« Usage Analysis of the NIST Internet Time Service »). C'est une application à NTP d'un principe général sur l'Internet, documenté dans le RFC 6056 : n'utilisez pas de numéros de port statiques ou prévisibles. Si on suit ce conseil, un attaquant en aveugle aura une information de plus à deviner, ce qui gênera sa tâche. Le fait d'utiliser un port source fixe a valu à NTP un CVE, CVE-2019-11331.
La section 3 du RFC résume les considérations à prendre en compte. L'idée de choisir aléatoirement le port source pour faire face aux attaques en aveugle est présente dans bien d'autres RFC comme le RFC 5927 ou le RFC 4953. Elle est recommandée par le RFC 6056. Un inconvénient possible (mais mineur) est que la sélection du chemin en cas d'ECMP peut dépendre du port source (calcul d'un condensat sur le tuple à cinq éléments {protocole, adresse IP source, adresse IP destination, port source, port destination}, avant d'utiliser ce condensat pour choisir le chemin) et donc cela peut affecter les temps de réponse, troublant ainsi NTP, qui compte sur une certaine stabilité du RTT. D'autre part, le port source aléatoire peut gêner certaines stratégies de filtrage par les pare-feux : on ne peut plus reconnaitre un client NTP à son port source. Par contre, un avantage du port source aléatoire est que certains routeurs NAT sont suffisamment bogués pour ne pas traduire le port source s'il fait partie des ports « système » (inférieurs à 1 024), empêchant ainsi les clients NTP situés derrière ces routeurs de fonctionner. Le port source aléatoire résout le problème.
Assez de considérations, passons à la norme. Le RFC 5905, section 9.1, est modifié pour remplacer la supposition qui était faite d'un port source fixe par la recommandation d'un port source aléatoire.
Cela ne pose pas de problème particulier de mise en œuvre. Par
exemple, sur un système POSIX, ne
pas faire de bind()
sur la
prise suffira à ce que les paquets associés
soient émis avec un port source aléatoirement sélectionné par le
système d'exploitation.
À propos de mise en œuvre, où en sont les logiciels actuels ? OpenNTPD n'a jamais utilisé le port source 123 et est donc déjà compatible avec la nouvelle règle. Même chose pour Chrony. Par contre, à ma connaissance, ntpd ne suit pas encore la nouvelle règle.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : W. Toorop (NLnet Labs), S. Dickinson (Sinodun IT), S. Sahib (Brave Software), P. Aras, A. Mankin (Salesforce)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dprive
Première rédaction de cet article le 12 septembre 2021
Traditionnellement, le transfert d'une zone DNS depuis le serveur maitre vers ses esclaves se fait en clair. Si l'authentification et l'intégrité sont protégées, par exemple par TSIG, le transfert en clair ne fournit pas de confidentialité. Or on n'a pas forcément envie qu'un tiers puisse lire l'entièreté de la zone. Ce RFC normalise un transfert de zones sur TLS, XoT (zone transfer over TLS). Il en profite pour faire quelques ajustement dans l'utilisation de TCP pour les transferts de zone.
Le RFC fait quarante-deux pages mais le principe est très simple. Au lieu de faire le transfert de zones (aussi nommé AXFR, RFC 5936) directement sur TCP, on le fait sur du TLS, comme le fait DoT (RFC 7858). Le reste du RFC est consacré à des détails pratiques, mais le concept tient en une seule phrase.
Le DNS sur TLS est normalisé depuis cinq
ans, mais il ne couvre officiellement que la communication entre la
machine terminale et le résolveur. Bien que des essais aient
été faits pour communiquer en TLS avec des serveurs faisant
autorité, rien n'est encore normalisé. Mais, au fait, est-ce
que les transferts de zone ont vraiment besoin de confidentialité ?
Le RFC 9076 ne traite pas le problème, le
renvoyant aux RFC 5936 (la norme du transfert
de zones, qui parle de la possibilité de restreindre ce transfert à
des machines autorisées) et au RFC 5155 (qui
parle des risques d'énumération de tous les noms d'une
zone). Certes, le DNS étant public, tout le monde peut interroger
les serveurs faisant autorité, et connaitre ainsi les données
associées à un nom de
domaine, mais il faut pour cela connaitre les noms. Si
les petites zones n'ont rien de secret (elles ne contiennent que
l'apex et www
), si certaines zones sont
publiques (la racine, par exemple), pour les autres zones, leur
responsable ne souhaite pas forcément qu'on ait accès à tous les
noms. Certains peuvent être le nom d'une personne
(le-pc-de-henri.zone.example
), et donc être des
données personnelles, à protéger (le RFC note bien sûr que c'est une
mauvaise pratique, mais elle existe), certains noms peuvent
renseigner sur les activités et les projets d'une entreprise. Bref,
il peut être tout à fait raisonnable de ne pas vouloir transmettre
la zone en clair.
À noter qu'une surveillance du réseau pendant un transfert de zones fait en clair n'est pas la seule façon de trouver tous les noms. Une autre technique est l'énumération, utilisant par exemple les enregistrement NSEC de DNSSEC. Les enregistrement NSEC3 du RFC 5155 ont été conçus pour limiter ce risque (mais pas le supprimer ; le projet NSEC5 va essayer de résoudre le problème mais c'est loin d'être garanti).
Comment sécurise-t-on les transferts de zone aujourd'hui ? Les TSIG du RFC 8945 protègent l'intégrité mais pas la confidentialité. Vous pouvez trouver des détails pratiques sur la sécurisation des transferts de zone, combinant TSIG et ACL, dans un document du NIST en anglais et un document de l'ANSSI en français. On peut aussi en théorie utiliser IPsec entre maitre et esclaves mais cela semble irréaliste. D'où l'idée de base de ce nouveau RFC : mettre le transfert de zones sur TLS. Après tout, on utilise déjà TLS pour sécuriser la communication entre le client final et le résolveur : le protocole DoT, normalisé dans le RFC 7858.
Notre RFC introduit quelques nouveaux acronymes rigolos :
Pour la terminologie liée à la vie privée, voir le RFC 6973.
La section 3 du RFC spécifie le modèle de menace : on veut protéger le transfert de zones contre l'espionnage par un tiers, mais on n'essaie pas de cacher l'existence de la zone, ou le fait que telle machine soit serveur faisant autorité pour la zone. En effet, ces informations peuvent être obtenues facilement en interrogeant le DNS ou, dans le cas d'un maitre caché, en regardant le trafic réseau, sans même en décrypter le contenu.
Les principes de conception de XoT ? Fournir de la confidentialité et de l'authentification grâce à TLS, mais aussi en profiter pour améliorer les performances. Un certain nombre de programmes DNS ne peuvent pas, par exemple, utiliser la même connexion TCP pour plusieurs transferts de zone (même si le RFC 5936 le recommande). Il est difficile de résoudre ce problème sans casser les programmes existants et pas encore mis à jour. Par contre, XoT étant nouveau, il peut spécifier dès le début certains comportements qui améliorent les performances, comme l'utilisation d'une seule connexion pour plusieurs transferts.
Petit rappel de comment fonctionne le transfert de zones (RFC 5936, si vous voulez tous les détails). D'abord, le fonctionnement le plus courant : le serveur maitre (ou primaire) envoie un NOTIFY (RFC 1996) à ses esclaves (ou secondaires). Ceux-ci envoient une requête de type SOA au maitre puis, si le numéro de série récupéré est supérieur au leur, ils lancent l'AXFR sur TCP. Il y a des variations possibles : si le maitre n'envoie pas de NOTIFY ou bien s'ils sont perdus, les esclaves testent quand même de temps en temps le SOA (paramètre Refresh du SOA). Autre variante possible : les esclaves peuvent utiliser IXFR (RFC 1995) au lieu de AXFR pour ne transférer que la partie de la zone qui a changé. Et ils peuvent avoir à se rabattre en AXFR si le maitre ne gérait pas IXFR. Et les messages IXFR peuvent être sur UDP ou sur TCP (en pratique, BIND, NSD et bien d'autres font toujours l'IXFR sur TCP). Bref, il y a plusieurs cas. Les messages NOTIFY et SOA ne sont pas considérés comme sensibles du point de vue de la confidentialité et XoT ne les protège pas.
Maintenant, avec XoT, comment ça se passera (section 6 du RFC) ?
Une fois le transfert de zones décidé (via SOA, souvent précédé du
NOTIFY), le client (qui est donc le serveur secondaire) doit établir
une connexion TLS (1.3 minimum), en utilisant ALPN, avec
le nom dot
(on notera que c'est donc le même
ALPN pour XoT et pour DoT, l'annexe A du RFC explique ce choix). Le
port est par défaut le classique 853 de
DoT. Le client authentifie le serveur via les techniques du RFC 8310. Le serveur vérifie le client, soit avec
des mécanismes TLS (plus sûrs mais plus compliqués à mettre en
œuvre), soit avec les classiques ACL. Le client TLS (le serveur DNS esclave) fait
ensuite de l'IXFR ou du AXFR classique sur ce canal TLS. Le serveur
doit être capable d'utiliser les codes d'erreur étendus du RFC 8914.
Voilà, c'est tout. Maintenant, quelques détails
pratiques. D'abord, rappelez-vous qu'il n'existe pas à l'heure
actuelle de norme pour du DoT entre résolveur et serveur faisant
autorité. Mais il y a des expériences en cours. Ici, par exemple, je
fais du DoT avec un serveur faisant autorité pour facebook.com
:
% kdig +tls @a.ns.facebook.com. SOA facebook.com ;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) ... ;; ANSWER SECTION: facebook.com. 3600 IN SOA a.ns.facebook.com. dns.facebook.com. 1631273358 14400 1800 604800 300 ;; Received 86 B ;; Time 2021-09-10 13:35:44 CEST ;; From 2a03:2880:f0fc:c:face:b00c:0:35@853(TCP) in 199.0 ms
Mais on pourrait imaginer des serveurs faisant autorité qui ne fournissent pas ce service, pas encore normalisé, mais qui veulent faire du XoT. Est-ce possible de réserver TLS aux transferts de zone, mais sans l'utiliser pour les requêtes « normales » ? Oui, et dans ce cas le serveur doit répondre REFUSED à ces requêtes normales, avec le code d'erreur étendu 21 (Not supported). Ceci dit, il est difficile de dire comment réagiront les clients ; ils risquent d'ignorer le code d'erreur étendu et de recommencer bêtement (ou au contraire d'arrêter complètement d'utiliser le serveur).
Le but de XoT est de protéger le contenu de la zone contre les regards indiscrets. Mais comme vous le savez, TLS ne dissimule pas la taille des données qui passent entre ses mains et l'observation de cette taille peut donner des informations à un observateur, par exemple la taille des mises à jour en IXFR indique l'activité d'une zone. Le RFC suggère donc de remplir les données. Cela peut nécessiter d'envoyer des réponses vides, ce qui était interdit par les précédents RFC mais est maintenant autorisé.
Et les différentes formes de parallélisme des requêtes que permet le DNS sur TCP (et donc DoT) ? Elles sont décrites dans le RFC 7766. Si elles sont nécessaires pour exploiter le DNS de manière satisfaisante, elles ne sont pas forcément utiles pour XoT et notre RFC explique qu'on n'est pas forcé, par exemple, de permettre le pipelining (envoi d'une nouvelle requête quand la réponse à la précédente n'est pas encore arrivée) quand on fait du XoT. Par contre, comme avec tous les cas où on utilise du DNS sur TCP, il est recommandé de garder les connexions ouvertes un certain temps, par exemple en suivant le RFC 7828.
J'ai parlé plus haut de l'authentification dans une session XoT. La section 9 du RFC revient en détail sur cette question. Quels sont les mécanismes existants pour authentifier un transfert de zones ? Ils diffèrent par les services qu'ils rendent :
Les mécanismes possibles sont :
Quelles sont les mises en œuvres actuelles de XoT ? Une liste existe. Actuellement, il n'y a guère que NSD qui permet le XoT mais le travail est en cours pour d'autres. Voyons comment faire du XoT avec NSD. On télécharge la dernière version (XoT est apparu en 4.3.7), on la compile (pas besoin d'options particulières) et on la configure, par exemple ainsi :
server: port: 7053 ... tls-service-key: "server.key" tls-service-pem: "server.pem" # No TLS service if the port is not explicit in an interface definition ip-address: 127.0.0.1@7153 tls-port: 7153 zone: name: "fx" zonefile: "fx" # NSD 4.3.7 (september 2021) : not yet a way to restrict XoT provide-xfr: 127.0.0.1 NOKEY
Ainsi configuré, NSD va écouter sur le port 7153 en TLS. Notons qu'il n'y a pas de moyen de configurer finement : il accepte forcément XoT et les requêtes « normales ». De même, on ne peut pas obliger un client DNS à n'utiliser que XoT. Testons avec kdig, un client DNS qui accepte TLS, d'abord une requête normale :
% kdig +tls @localhost -p 7153 SOA fx ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 11413 ... ;; ANSWER SECTION: fx. 600 IN SOA ns1.fx. root.fx. 2021091201 604800 86400 2419200 86400 ... ;; Time 2021-09-12 11:06:39 CEST ;; From 127.0.0.1@7153(TCP) in 0.2 ms
Parfait, tout marche. Et le transfert de zones ?
% kdig +tls @localhost -p 7153 AXFR fx ;; AXFR for fx. fx. 600 IN SOA ns1.fx. root.fx. 2021091201 604800 86400 2419200 86400 ... ;; Received 262 B (1 messages, 9 records) ;; Time 2021-09-12 11:07:25 CEST ;; From 127.0.0.1@7153(TCP) in 2.3 ms
Excellent, nous faisons du XoT. Wireshark nous le confirme :
% tshark -d tcp.port==7153,tls -i lo port 7153 ... 4 0.001200185 127.0.0.1 → 127.0.0.1 TLSv1 439 Client Hello ... 6 0.006305031 127.0.0.1 → 127.0.0.1 TLSv1.3 1372 Server Hello, Change Cipher Spec, Application Data, Application Data, Application Data, Application Data ... 10 0.007385823 127.0.0.1 → 127.0.0.1 TLSv1.3 140 Application Data
Dans ce cas, on utilisait NSD comme serveur primaire, recevant les clients XoT. Il peut aussi fonctionner comme serveur secondaire et il est alors client XoT. Je n'ai pas testé mais John Shaft l'a fait et en gros la configuration ressemble à :
tls-auth: name: un-nom-pour-identifier-ce-bloc auth-domain-name: nom-du-serveur-principal zone: ... request-xfr: AXFR 2001:db8::1 NOKEY un-nom-pour-identifier-ce-bloc
Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : L. Lhotka (CZ.NIC), P. Spacek (ISC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 9 septembre 2021
YANG est le langage standard à
l'IETF
pour décrire des modèles de données, afin de, par exemple, gérer
automatiquement des ressources. Ce RFC décrit le module YANG
iana-dns-class-rr-type
, qui rassemble les
définitions des types d'enregistrements DNS.
YANG est normalisé dans le RFC 7950, et d'innombrables RFC décrivent des modules YANG pour de nombreux protocoles. YANG est utilisé par des protocoles de gestion à distance de ressources, comme RESTCONF (RFC 8040) ou NETCONF (RFC 6241). Mais ce RFC est le premier qui va utiliser YANG pour le DNS. L'un des objectifs (à long terme pour l'instant) est d'utiliser RESTCONF ou un équivalent pour gérer des serveurs DNS, résolveurs ou serveurs faisant autorité. (C'est un très vieux projet que cette gestion automatisée et normalisée des serveurs DNS.) Un mécanisme standard de gestion des serveurs nécessite un modèle de données commun, et c'est là que YANG est utile. Notre RFC est encore loin d'un modèle complet, il ne définit que le socle, le type des données que le DNS manipule. C'est la version YANG de deux registres IANA, celui des types d'enregistrements DNS et celui des classes (même si ce dernier concept est bien abandonné aujourd'hui).
Le registre IANA pour le DNS contient treize sous-registres. Le RFC n'en passe que deux en YANG, les classes et les types d'enregistrement. Les autres devront attendre un autre RFC. Les types d'enregistrement sont modélisés ainsi :
typedef rr-type-name { type enumeration { enum A { value 1; description "a host address"; reference "RFC 1035"; } enum NS { value 2; description "an authoritative name server"; ...
Et les classes (mais, rappelez-vous, seule la classe
IN
compte aujourd'hui) :
typedef dns-class-name { type enumeration { enum IN { value 1; description "Internet (IN)"; reference "RFC 1035"; } enum CH { value 3; description "Chaos (CH)"; reference "D. Moon, 'Chaosnet', A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981."; } ...
Le module YANG complet se retrouve dans le registre IANA (créé par le RFC 6020).
Le module YANG devra suivre l'actuel registre IANA, qui utilise un autre format. Pour faciliter la synchronisation, le RFC contient une feuille de style XSLT pour convertir l'actuel format, qui est la référence, vers le format YANG. La feuille de style est dans l'annexe A du RFC mais vous avez une copie ici. Voici comment produire et vérifier le module YANG :
% wget https://www.iana.org/assignments/dns-parameters/dns-parameters.xml % xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml > iana-dns-class-rr-type.yang % pyang iana-dns-class-rr-type.yang
Le moteur XSLT xsltproc fait partie de la
libxslt. Le vérificateur YANG Pyang
est distribué via
GitHub mais on peut aussi l'installer avec pip (pip
install pyang
).
Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : A. Biryukov, D. Dinu (University of Luxembourg), D. Khovratovich (ABDK Consulting), S. Josefsson (SJD AB)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF cfrg
Première rédaction de cet article le 8 septembre 2021
En général, en informatique, on essaie de diminuer la consommation de mémoire et de processeur des programmes, afin de les rendre plus efficaces. Mais il y a aussi des cas où on va tenter de réduire délibérement l'efficacité d'un programme. C'est le cas des fonctions de condensation qui sont utilisées en sécurité : on ne veut pas faciliter la tâche de l'attaquant. Ainsi, Argon2, spécifié dans ce RFC est volontairement très consommatrice de mémoire et d'accès à cette mémoire. Elle peut être utilisée pour condenser des mots de passe, ou pour des sytèmes à preuve de travail.
L'article original décrivant Argon2 est « Argon2: the memory-hard function for password hashing and other applications » et vous pouvez également lire « Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications ». Notre RFC reprend la description officielle, mais en s'orientant davantage vers les programmeurs et programmeuses qui devront mettre en œuvre cette fonction. Argon2 est conçu pour être memory-hard, c'est-à-dire faire souvent appel à la mémoire de la machine. Cela permet notamment aux ordinateurs classiques de tenir tête aux systèmes à base d'ASIC. (Par exemple, nombreuses sont les chaînes de blocs utilisant des preuves de travail. La fonction utilisée par Bitcoin, SHA-256, conçue pour être simple et rapide, n'est pas memory-hard et le résultat est qu'il y a belle lurette qu'un ordinateur, même rapide, n'a plus aucune chance dans le minage de Bitcoin. Seules les machines spécialisées peuvent rester en course, ce qui contribue à centraliser le minage dans peu de fermes de minage.) Argon2 est donc dur pour la mémoire, comme décrit dans l'article « High Parallel Complexity Graphs and Memory-Hard Functions ». À noter qu'Argon2 est très spécifique à l'architecture x86.
Argon2 se décline en trois variantes, Argon2id (celle qui est recommandée par le RFC), Argon2d et Argon2i. Argon2d a des accès mémoire qui dépendent des données, ce qui fait qu'il ne doit pas être employé si un attaquant peut examiner ces accès mémoire (attaque par canal auxiliaire). Il convient donc pour du minage de cryptomonnaie mais pas pour une carte à puce, que l'attaquant potentiel peut observer en fonctionnement. Argon2i n'a pas ce défaut mais est plus lent, ce qui ne gêne pas pour la condensation de mots de passe mais serait un problème pour le minage. Argon2id, la variante recommandée, combine les deux et est donc à la fois rapide et résistante aux attaques par canal auxiliaire. (Cf. « Tradeoff Cryptanalysis of Memory-Hard Functions », pour les compromis à faire en concevant ces fonctions dures pour la mémoire.) Si vous hésitez, prenez donc Argon2id. La section 4 du RFC décrit plus en détail les paramètres des variantes, et les choix recommandés.
Argon repose sur une fonction de condensation existante (qui n'est pas forcément dure pour la mémoire) et le RFC suggère Blake (RFC 7693).
La section 3 du RFC décrit l'algorithme mais je n'essaierai pas de vous le résumer, voyez le RFC.
La section 5 contient des vecteurs de test si vous voulez programmer Argon2 et vérifier les résultats de votre programme.
La section 7 du RFC revient en détail sur certaines questions de sécurité, notamment l'analyse de la résistance d'Argon2, par exemple aux attaques par force brute.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : F. Gont (SI6 Networks), J. Zorz (6connect), R. Patterson (Sky UK), B. Volz (Cisco)
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 7 septembre 2021
Quand un FAI modifie la configuration de son réseau IPv6, les routeurs chez les clients finaux, les CPE, ne retransmettent pas toujours rapidement ce changement, ce qui mène parfois à des problèmes de connectivité. Ce RFC décrit ce que doivent faire ces CPE pour minimiser les conséquence négatives d'une rénumérotation d'un réseau.
Le problème est documenté dans le RFC 8978 : par exemple, lorsqu'un routeur chez M. Toutlemonde (une « box ») redémarre et « oublie » sa configuration réseau précédente, si elle a changé chez le FAI entretemps, les machines du réseau local de M. Toutlemonde risquent de continuer à utiliser pendant un certain une ancienne configuration, désormais invalide. Comment éviter cela ?
Notre RFC se penche surtout sur le cas où le routeur de M. Toutlemonde a appris son préfixe IPv6 depuis le FAI via la délégation de préfixe DHCP du RFC 8415, et qu'il retransmet l'information sur ce préfixe dans le réseau local avec le SLAAC du RFC 4862 (via les RA, Router Advertisements, RFC 4861) ou bien DHCP. Les machines terminales sur le réseau local peuvent aussi agir (ce sera dans un futur RFC) mais l'actuel RFC ne concerne que les routeurs. Il consiste en une série d'exigences auxquelles doivent se prêter les routeurs, exigences qui s'ajoutent à celles déjà présentes dans le RFC 7084 ou bien qui modifient des exigences de ce RFC 7084.
Beaucoup de ces exigences nécessitent un mécanisme de stockage d'informations sur le routeur, stockage qui doit survivre aux redémarrages, ce qui ne sera pas évident pour tous les routeurs. Ainsi, le RFC demande que, du côté WAN, le routeur utilise toujours le même identificateur (IAID, Identity Association IDentifier, RFC 8415, section 4.2) en DHCP (pour essayer de garder le même préfixe). Certains routeurs choisissent apparemment l'IAID au hasard à chaque démarrage, ce qui leur obtient un nouveau préfixe. Il vaut mieux le garder, mais cela nécessite qu'il puisse être stocké et mémorisé même en cas de redémarrage. Comme tous les routeurs n'ont pas de mécanisme de stockage stable, les exigences du RFC sont exprimées (dans le langage du RFC 2119) par un SHOULD et pas un MUST.
Autre exigence, qui relève du bon sens, le routeur ne doit pas, lorsqu'il utilise un préfixe du côté LAN (le réseau local), utiliser une durée de vie plus longue (options Preferred Lifetime et Valid Lifetime du message d'information sur le préfixe envoyé par le routeur, RFC 4861, section 4.6.2) que celle qu'il a lui-même appris en DHCP côté WAN. On ne doit pas promettre ce qu'on ne peut pas tenir, la durée du bail DHCP s'impose au routeur et aux annonces qu'il fait sur le réseau local.
Enfin, le routeur ne doit pas, au redémarrage, envoyer
systématiquement un abandon du préfixe appris en DHCP (message DHCP
RELEASE
). Certains routeurs font apparemment
cela, ce qui risque de déclencher une renumérotation brutale (RFC 8978).
Lorsque le préfixe change, le routeur devrait aussi signaler cela sur le réseau local. Là encore, cela impose une mémoire, un stockage stable. Il doit se souvenir de ce qu'il a reçu, et annoncé, précédemment, pour pouvoir annoncer sur le réseau local que ces anciens préfixes ne doivent plus être utilisés (cela se fait en annonçant ces préfixes, mais avec une durée de vie nulle). Dans un monde idéal, le routeur sera prévenu des changements de préfixe parce que le FAI réduira la durée de vie de ses baux DHCP, permettant un remplacement ordonné d'un préfixe par un autre. Dans la réalité, on a parfois des renumérotations brutales, sans préavis (RFC 8978). Le routeur doit donc également gérer ces cas.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : E. Vyncke (Cisco), K. Chittimaneni (Square), M. Kaeo (Double Shot Security), E. Rey (ERNW)
Pour information
Réalisé dans le cadre du groupe de travail IETF opsec
Première rédaction de cet article le 7 septembre 2021
Tous les gens qui gèrent des réseaux IPv4 savent comment les sécuriser (normalement…). Et pour IPv6 ? Si ce n'est pas un protocole radicalement différent, il a quand même quelques particularités de sécurité. Ce RFC donne des conseils pratiques et concrets sur la sécurisation de réseaux IPv6. (Je le répète, mais c'est juste une nouvelle version d'IP : l'essentiel du travail de sécurisation est le même en v4 et en v6.)
Les différences entre IPv4 et IPv6 sont subtiles (mais, en sécurité, la subtilité compte, des petits détails peuvent avoir de grandes conséquences). Ceci dit, le RFC a tendance à les exagérer. Par exemple, il explique que la résolution d'adresses de couche 3 en adresses de couche 2 ne se fait plus avec ARP (RFC 826) mais avec NDP (RFC 4861). C'est vrai, mais les deux protocoles fonctionnent de manière très proche et ont à peu près les mêmes propriétés de sécurité (en l'occurrence, aucune sécurité). Plus sérieusement, le remplacement d'un champ d'options de taille variable dans IPv4 par les en-têtes d'extension d'IPv6 a certainement des conséquences pour la sécurité. Le RFC cite aussi le cas du NAPT (Network Address and Port Translation, RFC 2663). Souvent appelée à tort NAT (car elle ne traduit pas que l'adresse mais également le port), cette technique est très utilisée en IPv4. En IPv6, on ne fait pas de traduction ou bien on fait du vrai NAT, plus précisement du NPT (Network Prefix Translation, RFC 6296) puisqu'on change le préfixe de l'adresse. La phrase souvent entendue « en IPv6, il n'y a pas de NAT » est doublement fausse : c'est en IPv4 qu'on n'utilise pas le NAT, mais le NAPT, et on peut faire de la traduction d'adresses en IPv6 si on veut. NAT, NAPT ou NPT ne sont évidemment pas des techniques de sécurité mais elles peuvent avoir des conséquences pour la sécurité. Par exemple, toute traduction d'adresse va complexifier le réseau, ce qui introduit des risques. Autre facteur nouveau lié à IPv6 : la plupart des réseaux vont devoir faire de l'IPv4 et de l'IPv6 et les différentes techniques de coexistence de ces deux versions peuvent avoir leur propre impact sur la sécurité (RFC 4942).
La section 2 du RFC est le gros morceau du RFC ; c'est une longue liste de points à garder en tête quand on s'occupe de la sécurité d'un réseau IPv6. Je ne vais pas tous les citer, mais en mentionner quelques-uns qui donnent une bonne idée du travail du ou de la responsable de la sécurité.
D'abord, l'adressage. Aux débuts d'IPv6, l'idée était que les spécificités d'IPv6 comme le SLAAC allaient rendre la renumérotation des réseaux tellement triviale qu'on pourrait changer les adresses souvent. En pratique, ce n'est pas tellement le cas (RFC 7010) et il faut donc prêter attention à la conception de son adressage : on aura du mal à en changer. Heureusement, c'est beaucoup plus facile qu'en IPv4 : l'abondance d'adresses dispense des astuces utilisées en IPv4 pour essayer d'économiser chaque adresse. Par exemple, on peut donner à tous ses sous-réseaux la même longueur de préfixe, quelle que soit leur taille, ce qui simplifie bien les choses (le RFC 6177 est une lecture instructive). Comme en IPv4, les adresses peuvent être liées au fournisseur d'accès (PA, Provider Allocated) ou bien obtenues indépendamment de ce fournisseur (PI, Provider Independent). Le RFC 7381 discute ce cas. Cela peut avoir des conséquences de sécurité. Par exemple, les adresses PA sont en dernier ressort gérées par l'opérateur à qui il faudra peut-être demander certaines actions. Et ces adresses PA peuvent pousser à utiliser la traduction d'adresses, qui augmente la complexité. (D'un autre côté, les adresses PI sont plus difficiles à obtenir, surtout pour une petite organisation.) Ah, et puis, pour les machines terminales, le RFC 7934 rappelle à juste titre qu'il faut autoriser ces machines à avoir plusieurs adresses (il n'y a pas de pénurie en IPv6). Une des raisons pour lesquelles une machine peut avoir besoin de plusieurs adresses est la protection de la vie privée (RFC 8981).
Les gens habitués à IPv4 demandent souvent quel est l'équivalent du RFC 1918 en IPv6. D'abord, de telles adresses privées ne sont pas nécessaires en IPv6, où on ne manque pas d'adresses. Mais si on veut, on peut utiliser les ULA (Unique Local Addresses) du RFC 4193. Par rapport aux adresses privées du RFC 1918, elles ont le gros avantage d'être uniques, et donc d'éviter toute collision, par exemple quand deux organisations fusionnent leurs réseaux locaux. Le RFC 4864 décrit comment ces ULA peuvent être utilisés pour la sécurité.
Au moment de concevoir l'adressage, un choix important est celui de donner ou non des adresses IP stables aux machines. (Ces adresses stables peuvent leur être transmises par une configuration statique, ou bien en DHCP.) Les adresses stables facilitent la gestion du réseau mais peuvent faciliter le balayage effectué par un attaquant pendant une reconnaissance préalable. Contrairement à ce qu'on lit parfois encore, ce balayage est tout à fait possible en IPv6, malgré la taille de l'espace d'adressage, même s'il est plus difficile qu'en IPv4. Le RFC 7707 explique les techniques de balayage IPv6 possibles. Même chose dans l'article « Mapping the Great Void ». Bref, on ne peut pas compter sur la STO et donc, adresses stables ou pas, les machines connectées à l'Internet peuvent être détectées, et doivent donc être défendues.
Cela n'empêche pas de protéger la vie privée des utilisateurs en utilisant des adresses temporaires pour contacter l'extérieur. L'ancien système de configuration des adresses par SLAAC était mauvais pour la vie privée puisqu'il utilisait comme partie locale de l'adresse (l'IID, Interface IDentifier) l'adresse MAC, ce qui permettait d'identifier une machine même après qu'elle ait changé de réseau. Ce système est abandonné depuis longtemps (RFC 8064) au profit d'adresses aléatoires (RFC 8981). Ceci dit, ces adresses aléatoires posent un autre problème : comme elles changent fréquemment, elles ne permettent pas à l'administrateur réseau de suivre les activités d'une machine (c'est bien leur but), et on ne peut plus utiliser de mécanismes comme les ACL. Une solution possible est d'utiliser des adresses qui sont stables pour un réseau donné mais qui ne permettent pas de suivre une machine quand elle change de réseau, les adresses du RFC 7217. C'est dans beaucoup de cas le meilleur compromis. (Le RFC 7721 contient des détails sur les questions de sécurité liées aux adresses IP.)
On peut aussi couper SLAAC (cela peut se faire à distance avec des annonces RA portant le bit M) et n'utiliser que DHCP mais toutes les machines terminales n'ont pas un client DHCP.
En parlant de DHCP, lui aussi pose des problèmes de vie privée (décrits dans le RFC 7824) et si on veut être discret, il est recommandé d'utiliser le profil restreint défini dans le RFC 7844.
Après les adresses, la question des en-têtes d'extension, un concept nouveau d'IPv6. En IPv4, les options sont placées dans l'en-tête, qui a une longueur variable, ce qui complique et ralentit son analyse. En IPv6, l'en-tête a une longueur fixe (40 octets) mais il peut être suivi d'un nombre quelconque d'en-têtes d'extension (RFC 8200, section 4). Si on veut accéder à l'information de couche 4, par exemple pour trouver le port TCP, il faut suivre toute la chaîne d'en-têtes. Ce système était conçu pour être plus facile et plus rapide à analyser que celui d'IPv4, mais à l'usage, ce n'est pas le cas (le RFC estime même que le système d'IPv6 est pire). En partie pour cette raison, certains nœuds intermédiaires jettent tous les paquets IPv6 contenant des en-têtes d'extension (RFC 7872, RFC 9288). D'autres croient que la couche Transport suit immédiatement l'en-tête, sans tenir compte de la possibilité qu'il y ait un en-tête d'extension, ce qui fausse leur analyse. L'en-tête d'extension Hop-by-hop options était particulièrement problématique, car devant être traité par tous les routeurs (le RFC 8200 a adouci cette règle).
Pour faciliter la tâche des pare-feux, plusieurs règles ont été ajoutées aux en-têtes d'extension depuis les débuts d'IPv6 : par exemple le premier fragment d'un datagramme doit contenir la totalité des en-têtes d'extension.
À l'interface
d'IPv6 et de la couche 2, on
trouve quelques problèmes supplémentaires. D'abord, concernant la
résolution d'adresses IP en adresses
MAC, pour laquelle IPv6 utilise le protocole NDP
(Neighbor Discovery Protocol, RFC 4861). NDP partage avec ARP un problème fondamental :
n'importe quelle machine du réseau local peut répondre ce qu'elle
veut. Par exemple, si une machine demande « qui est
2001:db8:1::23:42:61
? », toutes les machines
locales peuvent techniquement répondre « c'est moi » et donner leur
adresse MAC. Ce problème et quelques autres analogues sont
documentés dans les RFC 3756 et RFC 6583. DHCP pose le même genre de problèmes,
toute machine peut se prétendre serveur DHCP et répondre aux
requêtes DHCP à la place du serveur légitime. Pour se prémunir
contre les attaques faites par des machines envoyant de faux
RA, on peut aussi isoler les machines, par
exemple en donnant un /64 à chacune, ou bien en configurant
commutateurs ou points d'accès Wifi pour bloquer les communications
de machine terminale à machine terminale (celles qui qui ne sont pas
destinées au routeur). Le RFC recommande le RA
guard du RFC 6105.
Et sur les mobiles ? Un lien 3GPP est un lien point-à-point, l'ordiphone qui est à un bout ne peut donc pas parler aux autres ordiphones, même utilisant la même base. On ne peut parler qu'au routeur (GGSN - GPRS Gateway Support Node, ou bien PGW - Packet GateWay). Pour la même raison, il n'y a pas de résolution des adresses IP et donc pas de risque liés à cette résolution. Ce mécanisme empêche un grand nombre des attaques liées à NDP. Si vous voulez en apprendre plus à ce sujet, il faut lire le RFC 6459.
Le
multicast peut être
dangereux sur un réseau local, puisqu'il permet d'écrire à des
machines qui n'ont rien demandé. Certains réseaux WiFi bloquent le
multicast. En IPv6, cela empêche des actions
néfastes comme de pinguer
ff01::1
(l'adresse multicast
qui désigne toutes les machines du réseau local), mais cela bloque
aussi des protocoles légitimes comme mDNS
(RFC 6762).
Compte-tenu de la vulnérabilité du réseau local, et des risques associés, il a souvent été proposé de sécuriser l'accès à celui-ci et IPv6 dispose d'un protocole pour cela, SEND, normalisé dans le RFC 3971, combiné avec les CGA du RFC 3972. Très difficile à configurer, SEND n'a connu aucun succès, à part dans quelques environnements ultra-sécurisés. On ne peut clairement pas compter dessus.
Voyons maintenant la sécurité du plan de contrôle : les routeurs et le routage (RFC 6192). Les problèmes de sécurité sont quasiment les mêmes en IPv4 et en IPv6, la principale différence étant le mécanisme d'authentification pour OSPF. Un routeur moderne typique sépare nettement le plan de contrôle (là où on fait tourner les protocoles comme OSPF, mais aussi les protocoles de gestion comme SSH qui sert à configurer le routeur) et le plan de transmission, là où se fait la transmission effective des paquets. Le second doit être très rapide, car il fonctionne en temps réel. Il utilise en général du matériel spécialisé, alors que le plan de contrôle est la plupart du temps mis en œuvre avec un processeur généraliste, et un système d'exploitation plus classique. Pas toujours très rapide, il peut être submergé par un envoi massif de paquets. Le plan de contrôle ne gère que les paquets, relativement peu nombreux, qui viennent du routeur ou bien qui y arrivent, le plan de transmission gérant les innombrables paquets que le routeur transmet, sans les garder pour lui. Chaque paquet entrant est reçu sur l'interface d'entrée, le routeur consulte une table qui lui dit quel est le routeur suivant pour ce préfixe IP, puis il envoie ce paquet sur l'interface de sortie. Et le tout très vite.
Notre RFC conseille donc de protéger le plan de contrôle en bloquant le plus tôt possible les paquets anormaux, comme des paquets OSPF qui ne viendraient pas d'une adresse locale au lien, ou les paquets BGP qui ne viennent pas d'un voisin connu. (Mais, bien sûr, il faut laisser passer l'ICMP, essentiel au débogage et à bien d'autres fonctions.) Pour les protocoles de gestion, il est prudent de jeter les paquets qui ne viennent pas du réseau d'administration. (Tout ceci est commun à IPv4 et IPv6.)
Protéger le plan de contrôle, c'est bien, mais il faut aussi protéger le protocole de routage. Pour BGP, c'est pareil qu'en IPv4 (lisez le RFC 7454). Mais OSPF est une autre histoire. La norme OSPFv3 (RFC 4552) comptait à l'origine exclusivement sur IPsec, dont on espérait qu'il serait largement mis en œuvre et déployé. Cela n'a pas été le cas (le RFC 8504 a d'ailleurs supprimé cette obligation d'IPsec dans IPv6, obligation qui était purement théorique). Le RFC 7166 a pris acte de l'échec d'IPsec en créant un mécanisme d'authentification pour OSPFv3. Notre RFC recommande évidemment de l'utiliser.
Sinon, les pratiques classiques de sécurité du routage tiennent toujours. Ne pas accepter les routes « bogons » (conseil qui n'est plus valable en IPv4, où tout l'espace d'adressage a été alloué), celles pour des adresses réservées (RFC 8190), etc.
Pas de sécurité sans surveillance (c'est beau comme du Ciotti, ça) et journalisation. En IPv6 comme en IPv4, des techniques comme IPFIX (RFC 7011), SNMP (RFC 4293), etc sont indispensables. Comme en IPv4, on demande à son pare-feu, son serveur RADIUS (RFC 2866) et à d'autres équipements de journaliser les évènements intéressants. À juste titre, et même si ça va chagriner les partisans de la surveillance massive, le RFC rappelle que, bien que tout cela soit très utile pour la sécurité, c'est dangereux pour la vie privée, et que c'est souvent, et heureusement, encadré par des lois comme le RGPD. Administrateur réseaux, ne journalise pas tout, pense à tes responsabilités morales et légales !
Bon, mais cela, c'est commun à IPv4 et IPv6. Qu'est-ce qui est spécifique à IPv6 ? Il y a le format textuel canonique des adresses, normalisé dans le RFC 5952, qui permet de chercher une adresse sans ambiguité. Et la mémoire des correspondances adresses IP adresses MAC dans les routeurs ? Elle est très utile à enregistrer, elle existe aussi en IPv4, mais en IPv6 elle est plus dynamique, surtout si on utilise les adresses favorables à la vie privée du RFC 8981. Le RFC recommande de la récupérer sur le routeur au moins une fois toutes les 30 secondes. Et le journal du serveur DHCP ? Attention, en IPv6, du fait de l'existence de trois mécanismes d'allocation d'adresses (DHCP, SLAAC et statique) au lieu de deux en IPv4, le journal du serveur DHCP ne suffit pas. Et puis il ne contiendra pas l'adresse MAC mais un identificateur choisi par le client, qui peut ne rien vous dire. (Ceci dit, avec les machines qui changent leur adresse MAC, DHCPv4 a un problème du même genre.) En résumé, associer une adresse IP à une machine risque d'être plus difficile qu'en IPv4.
Une autre spécificité d'IPv6 est l'existence de nombreuses technologies de transition entre les deux protocoles, technologies qui apportent leurs propres problèmes de sécurité (RFC 4942). Normalement, elles n'auraient dû être que temporaires, le temps que tout le monde soit passé à IPv6 mais, comme vous le savez, la lenteur du déploiement fait qu'on va devoir les supporter longtemps, les réseaux purement IPv6 et qui ne communiquent qu'avec d'autres réseaux IPv6 étant une petite minorité. La technique de coexistence la plus fréquente est la double pile, où chaque machine a à la fois IPv4 et IPv6. C'est la plus simple et la plus propre, le trafic de chaque version du protocole IP étant natif (pas de tunnel). Avec la double pile, l'arrivée d'IPv6 n'affecte pas du tout IPv4. D'un autre côté, il faut donc gérer deux versions du protocole. (Anecdote personnelle : quand j'ai commencé dans le métier, IP était très loin de la domination mondiale, et il était normal, sur un réseau local, de devoir gérer cinq ou six protocoles très différents. Prétendre que ce serait une tâche insurmontable de gérer deux versions du même protocole, c'est considérer les administrateurs réseaux comme très paresseux ou très incompétents.) L'important est que les politiques soient cohérentes, afin d'éviter, par exemple, que le port 443 soit autorisé en IPv4 mais bloqué en IPv6, ou le contraire. (C'est parfois assez difficile à réaliser sans une stricte discipline : beaucoup de pare-feux n'ont pas de mécanisme simple pour indiquer une politique indépendante de la version du protocole IP.)
Notez que certains réseaux peuvent être « double-pile » sans que l'administrateur réseaux l'ait choisi, ou en soit conscient, si certaines machines ont IPv6 activé par défaut (ce qui est fréquent et justifié). Des attaques peuvent donc être menées via l'adresse locale au lien même si aucun routeur du réseau ne route IPv6.
Mais les plus gros problèmes de sécurité liés aux techniques de coexistence/transition viennent des tunnels. Le RFC 6169 détaille les conséquences des tunnels pour la sécurité. Sauf s'ils sont protégés par IPsec ou une technique équivalente, les tunnels permettent bien des choses qui facilitent le contournement des mesures de sécurité. Pendant longtemps, l'interconnexion entre réseaux IPv6 isolés se faisait via des tunnels, et cela a contribué aux légendes comme quoi IPv6 posait des problèmes de sécurité. Aujourd'hui, ces tunnels sont moins nécessaires (sauf si un réseau IPv6 n'est connecté que par des opérateurs archaïques qui n'ont qu'IPv4).
Les tunnels les plus dangereux (mais aussi les plus pratiques) sont les tunnels automatiques, montés sans configuration explicite. Le RFC suggère donc de les filtrer sur le pare-feu du réseau, en bloquant le protocole IP 41 (ISATAP - RFC 5214, 6to4 - RFC 3056, mais aussi 6rd - RFC 5969 - qui, lui, ne rentre pas vraiment dans la catégorie « automatique »), le protocole IP 47 (ce qui bloque GRE, qui n'est pas non plus un protocole « automatique ») et le port UDP 3544, pour neutraliser Teredo - RFC 4380. D'ailleurs, le RFC rappelle plus loin que les tunnels statiques (RFC 2529), utilisant par exemple GRE (RFC 2784), sont plus sûrs (mais IPsec ou équivalent reste recommandé). 6to4 et Teredo sont de toute façon très déconseillés aujourd'hui (RFC 7526 et RFC 3964).
Et les mécanismes de traduction d'adresses ? On peut en effet traduire des adresses IPv4 en IPv4 (le traditionnel NAT, qui est plutôt du NAPT en pratique, puisqu'il traduit aussi le port), ce qui est parfois présenté à tort comme une fonction de sécurité, mais on peut aussi traduire de l'IPv4 en IPv6 ou bien de l'IPv6 en IPv6. Le partage d'adresses que permettent certains usages de la traduction (par exemple le CGNAT) ouvre des problèmes de sécurité bien connus. Les techniques de traduction d'IPv4 en IPv6 comme NAT64 - RFC 6146 ou 464XLAT - RFC 6877 apportent également quelques problèmes, décrits dans leurs RFC.
J'ai parlé plus haut du fait que les systèmes d'exploitation modernes ont IPv6 et l'activent par défaut. Cela implique de sécuriser les machines contre les accès non voulus faits avec IPv6. Du classique, rien de spécifique à IPv6 à part le fait que certains administrateurs système risqueraient de sécuriser les accès via IPv4 (avec un pare-feu intégré au système d'exploitation, par exemple) en oubliant de le faire également en IPv6.
Tous les conseils donnés jusqu'à présent dans cette section 2 du RFC étaient communs à tous les réseaux IPv6. Les sections suivantes s'attaquent à des types de réseau spécifiques à certaines catégories d'utilisateurs. D'abord (section 3), les « entreprises » (en fait, toutes les organisations - RFC 7381, pas uniquement les entreprises capitalistes privées, comme le terme étatsunien enterprise pourrait le faire penser). Le RFC contient quelques conseils de sécurité, proches de ce qui se fait en IPv4, du genre « bloquer les services qu'on n'utilise pas ». (Et il y a aussi le conseil plus évident : bloquer les paquets entrants qui ont une adresses IP source interne et les paquets sortants qui ont une adresse IP source externe.)
Et pour les divers opérateurs (section 4 du RFC) ? C'est plus délicat car ils ne peuvent pas, contrairement aux organisations, bloquer ce qu'ils ne veulent pas (sauf à violer la neutralité, ce qui est mal). Le RFC donne des conseils de sécurisation BGP (identiques à ceux d'IPv4) et RTBH (RFC 5635). Il contient également une section sur l'« interception légale » (le terme politiquement correct pour les écoutes et la surveillance). Légalement, les exigences (et les problèmes qu'elles posent) sont les mêmes en IPv4 et en IPv6. En IPv4, le partage d'adresses, pratique très répandue, complique sérieusement la tâche des opérateurs quand ils reçoivent un ordre d'identifier le titulaire de telle ou telle adresse IP (RFC 6269). En IPv6, en théorie, la situation est meilleure pour la surveillance, une adresse IP n'étant pas partagée. Par contre, l'utilisateur peut souvent faire varier son adresse au sein d'un préfixe /64.
Quand au réseau de l'utilisateur final, il fait l'objet de la section 5. Il n'y a pas actuellement de RFC définitif sur la délicate question de la sécurité de la maison de M. Michu. Notamment, les RFC 6092 et RFC 7084 ne prennent pas position sur la question très sensible de savoir si les routeurs/pare-feux d'entrée de ce réseau devraient bloquer par défaut les connexions entrantes. La sécurité plaiderait en ce sens mais ça casserait le principe de bout en bout.
Voilà, nous avons terminé cette revue du long RFC. Je résumerai mon opinion personnelle en disant : pour la plupart des questions de sécurité, les ressemblances entre IPv4 et IPv6 l'emportent sur les différences. La sécurité n'est donc pas une bonne raison de retarder la migration si nécessaire vers IPv6. J'ai développé cette idée dans divers exposés et articles.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : A. Melnikov (Isode), B. Leiba (Futurewei Technologies)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF extra
Première rédaction de cet article le 3 septembre 2021
IMAP, protocole d'accès distant à des boites aux lettres n'est pas juste un protocole, c'est tout un écosystème, décrit dans de nombreux RFC. Celui-ci est le socle de la version actuelle d'IMAP, la « 4rev2 ». Elle remplace la précédente version, « 4rev1 » (normalisée dans le RFC 3501). Le principal changement est sans doute une internationalisation plus poussée pour les noms de boites aux lettres et les en-têtes des messages.
Les protocoles traditionnels du courrier électronique, notamment SMTP ne permettaient que d'acheminer le courrier jusqu'à destination. Pour le lire, la solution la plus courante aujourd'hui est en mode client/serveur, avec IMAP, qui fait l'objet de notre RFC. IMAP ne permet pas d'envoyer du courrier, pour cela, il faut utiliser le RFC 6409. IMAP fonctionne sur un modèle où les messages ont plutôt vocation à rester sur le serveur, et où les clients peuvent, non seulement les récupérer mais aussi les classer, les détruire, les marquer comme lus, etc. IMAP permet de tout faire à distance.
Pour apprendre IMAP, il vaut mieux ne pas commencer par le RFC,
qui est très riche. (La lecture du RFC 2683 est recommandée
aux implémenteurs.) Pourtant, le principe de base est simple. IMAP
est client/serveur. Le
client se connecte en TCP au serveur, sur le
port 143, et envoie des commandes sous forme
de texte, comme avec SMTP. Il s'authentifie avec la commande
LOGIN
, choisit une boite aux lettres avec la
commande SELECT
, récupère un message avec la
commande FETCH
. IMAP peut aussi utiliser du
TLS
implicite, sur le port 993. Voici un exemple de session. Notons tout
de suite, c'est un point très important du protocole IMAP, que
chaque commande est précédée d'une étiquette
(tag, voir les sections 2.2.1 et 5.5 du RFC)
arbitraire qui change à chaque commande et qui permet d'associer une
réponse à une commande, IMAP permettant d'envoyer plusieurs
commandes sans attendre de réponse. Les réponses portent
l'étiquette correspondante, ou bien un
astérisque s'il s'agit d'un message du
serveur non sollicité. Ici, le serveur utilise le logiciel Archiveopteryx :
% telnet imap.example.org imap Trying 192.0.2.23... Connected to imap.example.org. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN COMPRESS=DEFLATE ID LITERAL+ STARTTLS] imap.example.org Archiveopteryx IMAP Server com1 LOGIN stephane vraimentsecret com1 OK [CAPABILITY IMAP4rev1 ACL ANNOTATE BINARY CATENATE CHILDREN COMPRESS=DEFLATE CONDSTORE ESEARCH ID IDLE LITERAL+ NAMESPACE RIGHTS=ekntx STARTTLS UIDPLUS UNSELECT URLAUTH] done com2 SELECT INBOX * 189 EXISTS * 12 RECENT * OK [UIDNEXT 1594] next uid * OK [UIDVALIDITY 1] uid validity * FLAGS (\Deleted \Answered \Flagged \Draft \Seen) * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft \Seen \*)] permanent flags com2 OK [READ-WRITE] done
Le serveur préfixe ses réponses par OK si tout va bien, NO s'il ne pas réussi à faire ce qu'on lui demande et BAD si la demande était erronnée (commande inconnue, par exemple). Ici, avec l'étiquette A2 et un Dovecot :
A2 CAVAPAS A2 BAD Error in IMAP command CAVAPAS: Unknown command (0.001 + 0.000 secs).
Si le serveur n'est accessible qu'en TLS implicite (TLS démarrant
automatiquement au début, sans STARTTLS
), on
peut utiliser un client TLS en ligne de commande, comme celui de
GnuTLS :
% gnutls-cli -p 993 imap.maison.example - Certificate[0] info: - subject `CN=imap.maison.example', issuer `CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc.', serial 0x02e9bf, RSA key 2048 bits, signed using RSA-SHA512, activated `2020-12-14 14:47:42 UTC', expires `2022-12-14 14:47:42 UTC', pin-sha256="X21ApSVQ/Qcb5Q8kgL/YqlH2XuEco/Rs2X2EgkvDEdI=" ... - Status: The certificate is trusted. - Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) [À partir d'ici, on fait de l'IMAP] * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready. A1 LOGIN stephane vraimenttropsecret A1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY STATUS=SIZE SAVEDATE LITERAL+ NOTIFY SPECIAL-USE] Logged in A2 SELECT INBOX ... * 0 EXISTS * 0 RECENT A2 OK [READ-WRITE] Select completed (0.002 + 0.000 + 0.001 secs). ... A14 FETCH 1 (BODY.PEEK[HEADER.FIELDS (SUBJECT)]) * 1 FETCH (BODY[HEADER.FIELDS (SUBJECT)] {17} Subject: Test ) A14 OK Fetch completed (0.007 + 0.000 + 0.006 secs).
Les commandes IMAP, comme FETCH
dans l'exemple
ci-dessus, sont décrites dans la section 6 du RFC.
Pour tester son serveur IMAP, on peut aussi utiliser fetchmail et
lui demander d'afficher toute la session avec -v
-v
:
% fetchmail -v -v -u MYLOGIN imap.1and1.fr Enter password for MYLOGIN@imap.1and1.fr: fetchmail: 6.3.6 querying imap.1and1.fr (protocol auto) at Tue Apr 15 12:00:27 2008: poll started fetchmail: 6.3.6 querying imap.1and1.fr (protocol IMAP) at Tue Apr 15 12:00:27 2008: poll started Trying to connect to 212.227.15.141/143...connected. fetchmail: IMAP< * OK IMAP server ready H mimap3 65564 fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ ID STARTTLS CHILDREN QUOTA IDLE NAMESPACE UIDPLUS UNSELECT SORT AUTH=LOGIN AUTH=PLAIN fetchmail: IMAP< A0001 OK CAPABILITY finished. fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: IMAP> A0002 STARTTLS fetchmail: IMAP< A0002 OK Begin TLS negotiation. fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Server CommonName: imap.1and1.fr fetchmail: imap.1and1.fr key fingerprint: 93:13:99:6A:3F:23:73:C3:00:37:4A:39:EE:22:93:AB fetchmail: IMAP> A0003 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ ID CHILDREN QUOTA IDLE NAMESPACE UIDPLUS UNSELECT SORT AUTH=LOGIN AUTH=PLAIN fetchmail: IMAP< A0003 OK CAPABILITY finished. fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: imap.1and1.fr: upgrade to TLS succeeded. fetchmail: IMAP> A0004 LOGIN "m39041005-1" * fetchmail: IMAP< A0004 OK LOGIN finished. fetchmail: selecting or re-polling default folder fetchmail: IMAP> A0005 SELECT "INBOX"
En IMAP, un message peut être identifié par un UID
(Unique Identifier) ou par un numéro. Le numéro
n'est pas global, il n'a de sens que pour une boite donnée, et il
peut changer, par exemple si on détruit des messages. L'UID, lui,
est stable, au moins pour une session (et de préférence pour
toutes). Les messages ont également des attributs
(flags). Ceux qui commencent par une
barre oblique inverse comme
\Seen
(indique que le message a été lu),
\Answered
(on y a répondu), etc, sont
obligatoires, et il existe également des attributs optionnels
commençant par un dollar comme
$Junk
(spam). Les
fonctions de recherche d'IMAP pourront utiliser ces attributs comme
critères de recherche. Les attributs optionnels
(keywords) sont listés dans un
registre IANA, et on peut en ajouter (le RFC 5788
explique comment).
IMAP a des fonctions plus riches, notamment la possibilité de chercher dans les messages (section 6.4.4 du RFC), ici, on extrait les messages de mai 2007, puis on récupère le sujet du premier message, par son numéro :
com10 SEARCH since 1-May-2007 before 31-May-2007 * SEARCH 12 com10 OK done com11 FETCH 1 (BODY.PEEK[HEADER.FIELDS (SUBJECT)]) * 1 FETCH (BODY[HEADER.FIELDS (Subject)] {17} Subject: Rapport sur les fonctions de vue dans Archiveopteryx ) com11 OK done
IMAP 4rev2 est complètement internationalisé et, par exemple, peut gérer des en-têtes en UTF-8, comme décrits dans le RFC 6532, ce qui est une des améliorations par rapport à 4rev1.
Vous noterez dans les réponses CAPABILITY
montrées plus haut, que le serveur indique la ou les versions d'IMAP
qu'il sait gérer. Il peut donc annoncer 4rev1 et 4rev2, s'il est
prêt à gérer les deux. Le client devra utiliser la commande
ENABLE
pour choisir. S'il choisit 4rev2, le
serveur pourra utiliser les nouveautés de 4rev2, notamment dans le
domaine de l'internationalisation (noms de boites en UTF-8, alors
que 4rev1 savait tout juste utiliser un bricolage basé sur
UTF-7).
IMAP 4rev2 est compatible avec 4rev1 (un logiciel de la précédente norme peut interagir avec un logiciel de la nouvelle). Il peut même interagir avec l'IMAP 2 du RFC 1776 (IMAP 3 n'a jamais été publié), cf. RFC 2061.
L'annexe E résume les principaux changements depuis le RFC 3501, qui normalisait IMAP 4rev1 :
BINARY
du RFC 3516 ou le LIST-EXTENDED
du RFC 5258.UNSEEN
de la commande
SELECT
.La réalisation d'un client ou d'un serveur IMAP soulève plein de problèmes pratiques, que la section 5 de notre RFC traite. Par exemple, les noms des boites aux lettres peuvent être en Unicode, plus précisément le sous-ensemble d'Unicode du RFC 5198 (cela n'était pas possible en 4rev1). Un logiciel doit donc s'attendre à rencontrer de tels noms.
IMAP est mis en œuvre dans de nombreux serveurs comme Dovecot, Courier, ou Archiveopteryx, déjà cité (mais qui semble abandonné). Mais, comme vous l'avez vu dans les exemples de session IMAP cités plus haut, la version de notre RFC, « 4rev2 » n'a pas encore forcément atteint tous les logiciels.
Côté client, on trouve du IMAP dans beaucoup de logiciels, des webmails, des MUA classiques comme mutt, des MUA en ligne de commande comme fetchmail, très pratique pour récupérer son courrier. (Si vous écrivez un logiciel IMAP à partir de zéro, ce RFC recommande la lecture préalable du RFC 2683.)
Il existe également des bibliothèques toutes faites pour programmer son client IMAP à son goût comme imaplib pour Python. Voici un exemple d'un court programme Python qui se connecte à un serveur IMAP, sélectionne tous les messages et les récupère. On note que la bibliothèque a choisi de rester très proche du vocabulaire du RFC :
import imaplib # Unlike what the documentation says, "host" has no proper default. connection = imaplib.IMAP4_SSL(host='localhost') connection.login("stephane", "thisissecret") connection.select() # Select the default mailbox typee, data = connection.search(None, "ALL") for num in data[0].split(): # Fetches the whole message # "RFC822" est le terme traditionnel mais le format des messages # est désormais dans le RFC 5322. typ, data = connection.fetch(num, '(RFC822)') print('Message %s\n%s\n' % (num, data[0][1])) connection.close() connection.logout()
Première rédaction de cet article le 31 août 2021
Le registre d'adresses IP Afrinic est actuellement l'objet d'une attaque juridique dans un conflit qui l'oppose à un revendeur d'adresses IP. L'affaire est complexe et vous ne trouverez pas ici d'opinions fermes sur « qui a raison » mais je voudrais expliquer de quoi il retourne et surtout signaler un problème grave : la justice a gelé les comptes bancaires d'Afrinic, menaçant à terme l'Internet africain. Il ne s'agit donc pas d'une affaire purement privée entre deux organisations en conflit.
D'abord, qu'est-ce qu'un RIR, un registre
d'adresses IP ? C'est l'organisme qui attribue les adresses IP, afin d'en garantir
l'unicité. Les informations sur ces allocations sont ensuite
publiquement accessibles via whois ou
RDAP. Il y a cinq RIR dans le monde,
Afrinic couvrant le continent
africain. Contrairement aux noms de domaine,
dont la gestion suscite toujours passions et controverses (l'une des
facettes de la « gouvernance de
l'Internet »), celle des adresses IP soulève nettement
moins d'intérêt. C'est en partie dû au fait qu'on se moque d'avoir
telle ou telle adresse IP (à quelques exceptions près comme certains résolveurs DNS publics avec leurs adresses
facilement mémorisables comme 1.1.1.1
). Et puis les adresses IP,
c'est purement virtuel, le registre peut en « fabriquer » autant
qu'il veut, non ? Il ne devrait pas y avoir de problème de pénurie,
n'est-ce pas ?
Mais cela n'est vrai que pour l'actuelle version du protocole IP, la version 6. Avec l'ancienne version, IPv4, toujours utilisée à certains endroits, les adresses ne sont codées que sur 32 bits, ce qui ne permet qu'environ quatre milliards d'adresses (un peu moins en pratique, certaines adresses étant réservées pour des usages spécifiques). Si ce chiffre semble important, il est très insuffisant par rapport aux besoins de l'Internet mondial. Il y a donc bel et bien pénurie d'adresses IPv4 et, comme le disait ma grand-mère, « quand le foin manque dans l'écurie, les chevaux se battent ». Les tensions sur le stock d'adresses IPv4 imposent donc que les RIR aient une politique d'allocation de ces adresses, les réservant à ceux qui en ont besoin. On se doute bien que l'élaboration de telles politiques ne se fasse pas sans douleur, et les cinq RIR ont d'ailleurs des politiques différentes. En outre, et pour son malheur, Afrinic a eu pendant longtemps un stock d'adresses IPv4 important, ce qui a aggravé les tentations. (Le pillage des ressources de l'Afrique n'est pas une invention nouvelle.)
Et c'est la source du conflit actuel entre Afrinic et la société Cloud Innovation (chinoise, mais enregistrée dans un paradis fiscal africain). Cette société obtient des adresses IPv4 par différents moyens, et les loue ensuite à ses clients, notamment en Chine. Ce n'est pas forcément illégal, l'achat, la vente et la location d'adresses IP peuvent être acceptées par le système légal, et par les politiques des RIR (les détails sont complexes, je vous les épargne). On peut trouver ce business répugnant mais il existe et n'est pas interdit. Ceci dit, les organisations qui obtiennent des adresses IP sont censées respecter les règles d'allocation du RIR auquel elles se sont adressées. Ici, Afrinic reproche à Cloud Innovation d'avoir obtenu de nombreuses adresses IP en violation des règles, et menace cette société de reprendre les adresses, argumentant notamment sur le fait qu'elles ne sont pas utilisées en Afrique. Comme la question est complexe (j'ai déjà du mal à retenir les règles du RIR de ma région), je ne vais pas trancher en désignant un bon et un méchant.
Le vrai problème se situe ensuite : Cloud Innovation a obtenu de la justice qu'elle interdise à Afrinic de reprendre les adresses en question mais surtout à obtenu le gel des comptes bancaires d'Afrinic, ce qui menace le fonctionnement même du registre et, à terme, de l'Internet en Afrique.
Mais quelle justice au fait ? Afrinic est enregistré à Maurice et c'est donc la justice de ce pays qui est compétente. Je ne formulerai pas d'opinion sur la qualité de la justice mauricienne, je ne la connais pas, mais je trouve quand même que le blocage des comptes, empêchant l'une des parties au procès de fonctionner et même de payer ses juristes, est anormale, notamment compte-tenu de ses conséquences pour l'Internet. D'ailleurs, pourquoi Maurice ? C'est parce que, bien que chaque RIR serve un continent entier, l'organisation doit bien être enregistrée quelque part. Elle ne peut pas planer au-dessus des lois nationales. Pour avoir un statut international, il faudrait un traité intergouvernemental (comme pour l'Union africaine) et, outre la difficulté à négocier un tel traité, cela aurait d'autres conséquences de gouvernance, notamment sur le rôle des gouvernements. Il fallait donc un pays particulier et Maurice semblait un choix raisonnable. (Les Européens noteront que c'est pour la même raison que leur RIR est à Amsterdam et que l'Internet européen dépend donc de la justice néerlandaise.)
À court terme, l'Internet continue à fonctionner en Afrique : les RIR ne sont pas impliqués dans l'activité quotidienne, les paquets ne passent pas par eux, les opérateurs Internet font fonctionner les réseaux que le RIR fonctionne ou pas. Mais à moyen terme, le « gel » d'Afrinic pourrait paralyser beaucoup d'activités indispensables, notamment la tenue du registre des adresses IP. D'où l'urgence d'une solution.
Des personnes plus pressées ont suggéré d'attaquer l'attaquant et, par exemple, de ne plus router les préfixes IP de Cloud Innovation. La question est évidemment très délicate, car si je comprends l'exaspération de certains, des actions unilatérales de ce genre ne sont pas non plus un procédé satisfaisant pour résoudre les conflits. Il vaudrait mieux que la justice mauricienne débloque les comptes d'Afrinic, en attendant un jugement au fond.
(Un autre point dont j'aurais préféré ne pas parler ; le problème expliqué dans cet article a une origine extérieure à Afrinic. Il n'est pas lié à un autre problème, qui avait été abondemment discuté en 2019-2020, d'un employé d'Afrinic vendant discrètement des adresses IP, problème qui fait également l'objet d'actions en justice. Voir entre autres ma conférence à Coriin 2020.)
Et revenons à IPv6. Son déploiement est actuellement insuffisant, en raison de la lenteur anormale mise par beaucoup d'acteurs à effectuer la migration. Il y a des raisons à cela mais il faut noter que ces décisions de trainer la patte, en fonction des intérêts de ces acteurs, ont des conséquences globales, celles d'accentuer la pression sur les rares adresses IPv4, menant à ce genre de crises.
Quelles lectures pour finir :
Date de publication du RFC : Août 2021
Auteur(s) du RFC : M. Boutier, J. Chroboczek (IRIF, University of Paris)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF babel
Première rédaction de cet article le 29 août 2021
Traditionnellement, le routage dans l'Internet se fait sur la base de l'adresse IP de destination. Mais on peut aussi envisager un routage où l'adresse IP source est prise en compte. Ce nouveau RFC étend le protocole de routage Babel en lui ajoutant cette possibilité.
Babel, normalisé dans le RFC 8966 est un protocole de routage à vecteur de
distance. Il est prévu par défaut pour du routage
IP traditionnel, où
le protocole de routage construit une table de transmission qui
associe aux préfixes IP de destination le routeur suivant
(next hop). Un paquet
arrive dans un routeur ? Le routeur regarde
dans sa table le préfixe le plus spécifique qui correspond à
l'adresse IP de destination (utilisant pour cela une structure de
données comme, par exemple, le Patricia trie)
et, lorsqu'il le trouve, la table contient les coordonnées du
routeur suivant. Par exemple, si une entrée de la table dit que
2001:db8:1:fada::/64
a pour routeur suivant
fe80::f816:3eff:fef2:47db%eth0
, un paquet
destiné à 2001:db8:1:fada::bad:1234
sera
transmis à ce fe80::f816:3eff:fef2:47db
, sur
l'interface réseau eth0
. Cette transmission
classique a de nombreux avantages : elle est simple et rapide, et
marche dans la plupart des cas.
Mais ce mécanisme a des limites. On peut vouloir prendre en compte d'autres critères que l'adresse de destination pour la transmission d'un paquet. Un exemple où un tel critère serait utile est le multihoming. Soit un réseau IP qui est connecté à plusieurs opérateurs, afin d'assurer son indépendance et pour faire face à un éventuel problème (technique ou commercial) chez l'un des opérateurs. La méthode officielle pour cela est d'acquérir des adresses indépendantes du fournisseur et de faire router ces adresses par les opérateurs auxquels on est connectés (par exemple en leur parlant en BGP). Mais avoir de ces adresses PI (Provider-Independent) est souvent difficile. Quand on est passionnée, on y arrive mais ce n'est pas vraiment accessible à tout le monde. On se retrouve donc en général avec des adresses dépendant du fournisseur. C'est par exemple le cas de loin le plus courant pour le particulier, la petite association ou la PME. Dans ce cas, le multihoming est compliqué. Mettons que les deux fournisseurs d'accès se nomment A et B et que chacun nous fournisse un préfixe d'adresses IP. Si une machine interne a deux adresses IP, chacune tirée d'un des préfixes, et qu'elle envoie vers l'extérieur un paquet ayant comme adresse source une adresse de B, que se passe-t-il ? Si le paquet est envoyé via le fournisseur B, tout va bien. Mais s'il est envoyé via le fournisseur A, il sera probablement jeté par le premier routeur de A, puisque son adresse IP source ne sera pas une adresse du fournisseur (RFC 3704 et RFC 8704). Pour éviter cela, il faudrait pouvoir router selon l'adresse IP source, envoyant les paquets d'adresse source A vers le fournisseur A et ceux ayant une adresse source B vers B. En gros, soit l'information de routage influe sur le choix de l'adresse source, soit c'est le choix de l'adresse source qui influe sur le routage. On ne peut pas faire les deux, ou alors on risque une boucle de rétroaction. Ce RFC choisit la deuxième solution.
La première solution serait que la machine émettrice choisisse l'adresse IP source selon que les adresses de destination soient routées vers A ou vers B. Le RFC 3484 explique comment le faire en séquentiel et le RFC 8305 le fait en parallèle (algorithme dit des « globes oculaires heureux »). Mais les systèmes actuels ne savent typiquement pas le faire et, de toute façon, cela ne réglerait pas le cas où le routage change pendant la vie d'une connexion TCP. TCP, contrairement à QUIC ou SCTP, ne supporte pas qu'une adresse IP change en cours de route, sauf à utiliser les extensions du RFC 8684. Une dernière solution serait de laisser les applications gérer cela (cf. RFC 8445) mais on ne peut pas compter que toutes les applications le fassent. Bref, le routage tenant compte de la source reste souvent la meilleure solution.
À part le cas du multihoming, d'autres usages peuvent tirer profit d'un routage selon la source. Ce routage peut simplifier la configuration des tunnels. Il peut aussi être utile dans le cas de l'anycast. Lorsqu'on utilise du routage classique, fondé uniquement sur la destination, il est difficile de prédire quels clients du groupe anycast seront servis par quelle instance du groupe. Cela rend la répartition de charge compliquée (il faut jouer avec les paramètres des annonces BGP, par exemple) et cela pose des problèmes aux protocoles avec état, comme TCP, où un même client doit rester sur la même instance du groupe anycast. (Des utilisations de l'anycast pour des services sans état, comme le DNS sur UDP, n'ont pas ce problème.) Au contraire, avec du routage fait selon la source, chaque instance anycast peut annoncer sa route avec le ou les préfixes IP qu'on veut que cette instance serve.
D'ailleurs, si vous voulez en savoir plus sur le routage selon la source (ou SADR Source-Address Dependent Routing, également appelé SSR pour Source-Specific Routing), vous pouvez lire l'article détaillé des auteurs du RFC, « Source-Specific Routing ». On peut aussi noter que ce routage dépendant de la source n'est pas la même chose qu'un routage décidé par la source (source routing), qui indiquerait une liste de routeurs par où passer. Ici, chaque routeur reste maitre du saut suivant (sur le routage décidé par la source, voir RFC 8354, et un exemple dans le RFC 6554).
Bon, le routage tenant compte de la source est intéressant,
OK. Mais, avant de s'y lancer, il faut faire attention à un petit
problème, la spécificité des routes. Lorsqu'on route uniquement
selon la destination, et que plusieurs routes sont possibles, la
règle classique d'IP est celle de la spécificité. La route avec le
préfixe le plus spécifique (le plus long) gagne. Mais que se passe
t-il si on ajoute l'adresse source comme critère ? Imaginons qu'on
ait deux routes, une pour la destination
2001:db8:0:1::/64
et s'appliquant à toutes les
sources et une autre route pour toutes les destinations (route par
défaut), ne s'appliquant qu'à la source
2001:db8:0:2::/64
. On va noter ces deux routes
sous forme d'un tuple (destination, source) donc, ici,
(2001:db8:0:1::/64
, ::/0
)
et (::/0
,
2001:db8:0:2::/64
). Pour un paquet venant de
2001:db8:0:2::1
et allant en
2001:db8:0:1::1
, quelle est la route la plus
spécifique ? Si on considère la spécificité de la destination
d'abord, la route choisie sera la
(2001:db8:0:1::/64
,
::/0
). Mais si on regarde la spécificité de la
source en premier, ce sera l'autre route, la (::/0
,
2001:db8:0:2::/64
) qui sera adoptée. Doit-on
laisser chaque machine libre de faire du destination d'abord ou du
source d'abord ? Non, car tous les routeurs du domaine doivent
suivre la même règle, autrement des boucles pourraient se former, un
paquet faisant du ping-pong éternel entre un routeur « destination
d'abord » et un routeur « source d'abord ». Babel impose donc une
règle : pour déterminer la spécificité d'une route, on regarde la
destination d'abord. Le choix n'est pas arbitraire, il correspond à
des topologies réseau typique, avec des réseaux locaux pour
lesquelles on a une route spécifique, et une route par défaut pour
tout le reste.
Un autre point important est celui du système de transmission des paquets. Il faut en effet rappeler que le terme « routage » est souvent utilisé pour désigner deux choses très différentes. La première est le routage à proprement parler (routing en anglais), c'est-à-dire la construction des tables de transmission, soit statiquement, soit avec des protocoles de routage comme Babel. La seconde est la transmission effective des paquets qui passent par le routeur (forwarding en anglais). Si on prend un routeur qui tourne sur Unix avec le logiciel babeld, ce dernier assure bien le routage au sens strict (construire les tables de routage grâce aux messages échangés avec les autres routeurs) mais c'est le noyau Unix qui s'occupe de la transmission. Donc, si on veut ajouter des fonctions de routage tenant compte de la source, il ne suffit pas de le faire dans le programme qui fait du Babel, il faut aussi s'assurer que le système de transmission en est capable, et avec la bonne sémantique (notamment l'utilisation de la destination d'abord pour trouver la route la plus spécifique). Si Babel, avec les extensions de ce RFC, tourne sur un système qui ne permet pas cela, il faut se résigner à ignorer les annonces spécifiques à une source. (Pour des systèmes comme Linux, qui permet le routage selon la source mais avec une mauvaise sémantique, puisqu'il utilise la source d'abord pour trouver la route la plus spécifique, la section V-B de l'article des auteurs cité plus haut fournit un algorithme permettant de créer des tables de transmission correctes.)
Le passage du routage classique au routage tenant compte de la
source nécessite de modifier les structures de données du protocole
de routage, ici Babel (section 3 du RFC). Les différentes structures
de données utilisées par une mise en œuvre de Babel doivent être
modifiées pour ajouter le préfixe de la source, et plusieurs des
TLV dans les messages que s'échangent les
routeurs Babel doivent être étendus avec un sous-TLV (RFC 8966, section 4.4) qui contient un préfixe
source. La section 5 du RFC détaille les modifications nécessaires
du protocole Babel. Les trois types de TLV
qui indiquent un préfixe de destination, Updates,
Route Requests et Seqno,
doivent désormais transporter en plus un sous-TLV indiquant le
préfixe source, marqué comme obligatoire (RFC 8966, section 4.4), de façon à ce qu'une version de Babel
ne connaissant pas le routage selon la source n'accepte pas des
annonces incomplètes. Si une annonce ne dépend pas de l'adresse IP
source, il ne faut pas envoyer un sous-TLV avec le préfixe
::/0
mais au contraire ne pas mettre de
sous-TLV (les autres versions de Babel accepteront alors
l'annonce).
Ainsi, des versions de Babel gérant les extensions de notre RFC 9079 et d'autres qui ne les gèrent pas (fidèles au RFC 8966) pourront coexister sur le même réseau, sans que des boucles de routage ne se forment. En revanche, comme la notion de sous-TLV obligatoire n'est apparue qu'avec le RFC 8966, les vieilles versions de Babel, qui suivent l'ancien RFC 6126, ne doivent pas être sur le même réseau que les routeurs à routage dépendant de la source.
Le nouveau sous-TLV Source Prefix a le type 128 et sa valeur comporte un préfixe d'adresses IP, encodé en {longueur, préfixe}.
Notez que si les routeurs qui font du routage selon la source n'annoncent que des routes ayant le sous-TLV indiquant un préfixe source, les routeurs qui ne gèrent pas ce routage selon la source, et qui ignorent donc cette annonce, souffriront de famine : il n'y aura pas de routes vers certaines destinations, conduisant le routeur à jeter les paquets. Il peut donc être prudent, par exemple, d'avoir une route par défaut sans condition liée à la source, pour ces routeurs qui ignorent cette extension.
Question sécurité, il faut signaler (section 9 du RFC), que cette extension au routage apporte davantage de souplesse, et que cela peut nécessiter une révision des règles de sécurité, si celles-ci supposaient que tous les paquets vers une destination donnée suivaient le même chemin. Ainsi, le filtrage des routes (RFC 8966, annexe C) pourra être inutile si des routes spécifiques à une source sont présentes. Autre supposition qui peut être désormais fausse : une route spécifique à une machine de destination (host route, c'est-à-dire un préfixe /128) n'est plus forcément obligatoire, une autre route pour certaines sources peut prendre le dessus.
Au moins deux mises en œuvre de cette extension existent, dans babeld depuis la version 1.6 (en IPv6 seulement), et dans BIRD depuis la 2.0.2.
Merci à Juliusz Chroboczek pour sa relecture, et pour ses bonnes remarques sur le choix entre le routage selon la source et les autres solutions.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : M. Niedermayer, D. Rice, J. Martinez
Pour information
Réalisé dans le cadre du groupe de travail IETF cellar
Première rédaction de cet article le 24 août 2021
Ce RFC décrit FFV1, un encodage de flux vidéo sans pertes, et sans piège connu, par exemple de brevet.
Certains encodages vidéo font perdre de l'information, c'est-à-dire que, après décompression, on ne retrouve pas tout le flux original. Ces encodages avec pertes tirent profit des limites de l'œil humain (on n'encode pas ce qui ne se voit pas) mais peut poser des problèmes dans certains cas. Par exemple, si on veut stocker une vidéo sur le long terme, il est certainement préférable qu'elle soit aussi « authentique » que possible, et donc encodée sans pertes. Les organisations qui font de l'archivage sur le long terme (comme l'INA) ont tout intérêt à privilégier un format sans pertes et libre, qui sera encore utilisable dans 50 ans, plutôt que de choisir les derniers gadgets à la mode. Si on souhaite faire analyser cette vidéo par autre chose qu'un œil humain, par exemple un programme qui souhaite avoir la totalité des informations, là encore, le « sans perte » est nécessaire. FFV1 est sans perte, pour le plus grand bénéfice de l'archivage et de la science. C'est le premier codec sans perte documenté par l'IETF.
FFV1 ne date pas d'aujourd'hui, et le RFC traite d'un coup trois versions de FFV1 (section 4.2.1) :
Le nom FFV1 veut dire « FF Video 1 » et FF est une référence à FFmpeg, le programme de référence (qui a largement précédé la spécification officielle) dont le nom venait de Fast Forward (avance rapide).
Je ne vais pas vous décrire les algorithmes de FFV1, ça dépasse largement mes compétences. Comme le note le RFC, il faut d'abord connaitre le codage par intervalle, et le modèle YCbCr. Je vous renvoie donc à l'article en français d'un des auteurs et bien sûr au RFC lui-même. FFV1 utilise souvent des techniques un peu anciennes, pour éviter les problèmes de brevet.
Le RFC utilise du pseudo-code pour décrire l'encodage FFV1. Ce pseudo-code particulier est assez proche de C. Vous verrez donc du pseudo-code du genre :
for (i = 0; i < quant_table_set_count; i++) { states_coded if (states_coded) { for (j = 0; j < context_count[ i ]; j++) { for (k = 0; k < CONTEXT_SIZE; k++) { initial_state_delta[ i ][ j ][ k ] } } } }
Le type de média video/FFV1
a été enregistré
à l'IANA pour les flux encodés en FFV1.
FFV1 décrit un encodage d'un flux vidéo, pas un format de conteneur. Le flux en question doit donc être inclus dans un conteneur, par exemple aux formats AVI, NUT ou Matroska (section 4.3.3 pour les détails de l'inclusion dans chaque format).
Comme pour tout codec utilisé sur le grand méchant Internet, un programme qui lit du FFV1 doit être paranoïaque et ne doit pas supposer que le flux vidéo est forcément correct. Même si le contenu du fichier est délibérement malveillant, le décodeur ne doit pas allouer de la mémoire à l'infini ou boucler sans fin (ou, pire encore, exécuter du code arbitraire par exemple parce qu'il y aura eu un débordement de pile ; FFV1 lui-même ne contient pas de code exécutable). Le RFC (section 6) donne l'exemple d'un calcul de taille d'une image où on multiplie la largeur par la hauteur, sans plus de précautions. Si cela provoque un dépassement d'entier, des tas de choses vilaines peuvent arriver. Un exemple de précaution : FFmpeg a été soumis à des flux FFV1 corrects et à des données aléatoires, tout en étant examiné par Valgrind et le vérificateur de Clang et aucun accès mémoire anormal n'a été détecté.
Question mises en œuvre, FFV1 est suffisamment ancien pour que de nombreux programmes sachent le décoder. L'implémentation de référence est FFmpeg (qui sait aussi encoder en FFV1). Il y a également un décodeur en Go, développé en même temps que la spécification et il y a aussi MediaConch dont le développement a permis de détecter des incohérences entre le projet de spécification et certains programmes. La spécification elle-même a été développée sur GitHub si vous voulez suivre son histoire, et son futur (une version 4 est prévue).
Comme exemple d'une vidéo encodée en FFV1, j'ai pris les 20
premières secondes de mon
exposé au FOSDEM 2021. Le fichier (pour 20 secondes de
vidéo !) fait 60 mégaoctets : la
compression sans perte est évidemment moins efficace que si on
accepte les pertes. Le fichier a été produit par FFmpeg
(ffmpeg -i retro_gemini.webm -vcodec ffv1 -level 3 -to
00:00:20 retro_gemini.mkv
, notez que, si FFV1 lui-même
est sans perte, si vous encodez en FFV1 à partir d'un fichier déjà
comprimé avec perte, vous ne recupérez évidemment pas ce qui a été
perdu). mediainfo vous montre son contenu :
% mediainfo retro_gemini.mkv General ... Format : Matroska Movie name : Gemini, a modern protocol that looks retro ... DATE : 2021-02-07 EVENT : FOSDEM 2021 SPEAKERS : Stéphane Bortzmeyer Video ID : 1 Format : FFV1 Format version : Version 3.4 Codec ID : V_MS/VFW/FOURCC / FFV1 Duration : 20 s 0 ms Bit rate mode : Variable Bit rate : 25.7 Mb/s Width : 1 280 pixels Height : 720 pixels Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Compression mode : Lossless ...
Ou bien avec ffprobe :
% fprobe -show_format -show_streams retro_gemini.mkv ... Input #0, matroska,webm, from 'retro_gemini.mkv': Metadata: title : Gemini, a modern protocol that looks retro DATE : 2021-02-07 ... [STREAM] index=0 codec_name=ffv1 codec_long_name=FFmpeg video codec #1 codec_type=video codec_time_base=1/25 codec_tag_string=FFV1 width=1280 height=720 ...
Merci à Jérôme Martinez pour sa relecture attentive.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : V. Dukhovni (Two Sigma), S. Huque (Salesforce), W. Toorop (NLnet Labs), P. Wouters (Aiven), M. Shore (Fastly)
Expérimental
Première rédaction de cet article le 12 août 2021
Lorsqu'on authentifie un serveur TLS (par exemple un serveur
DoT) avec DANE, le client TLS
doit utiliser un résolveur DNS
validant et tenir compte de son résultat
(données validées ou pas), ce qui n'est pas toujours facile, ni même
possible dans certains environnements. Ce RFC propose une solution pour cela : une
extension à TLS, dnssec_chain
, qui permet au
serveur TLS d'envoyer l'ensemble des enregistrements DNS pertinents
au client, le dispensant ainsi de solliciter un résolveur
validant. Toute la cuisine de vérification peut ainsi se faire sans
autre canal que TLS.
TLS
(normalisé dans les RFC 5246 et RFC 8446) fournit un canal de communication
sécurisé, si on a authentifié le serveur situé en face. La plupart
du temps, on authentifie via un certificat
PKIX (RFC 5280). Dans certains
cas, ce n'est pas facile d'utiliser PKIX. Par exemple, pour
DoT (RFC 7858), le
résolveur DoT n'est typiquement connu que par une adresse IP, alors que le
certificat ne contient en général qu'un nom
(oui, le RFC 8738 existe, mais n'est pas
toujours activé par les autorités de
certification). Les serveurs DoT sont souvent
authentifiables par DANE (RFC 6698 et
RFC 7671). Par exemple, mon résolveur DoT
public, dot.bortzmeyer.fr
, est authentifiable
avec DANE (regardez les données TLSA de
_853._tcp.dot.bortzmeyer.fr
). Mais DANE dépend
de la disponibilité d'un résolveur DNS
validant. Diverses raisons font que le
client TLS peut avoir du mal à utiliser un résolveur validant, et à
récupérer l'état de la validation (toutes les API de résolution de
noms ne donnent pas accès à cet état). L'article « Discovery
method for a DNSSEC validating stub resolver »
donne des informations sur ces difficultés. Bref, devoir récupérer
ces enregistrements DANE de manière sécurisée peut être un
problème. Et puis utiliser le DNS pour récupérer des données
permettant d'authentifier un résolveur DNS pose un
problème d'œuf et de poule.
D'où l'idée centrale de ce RFC : le client TLS demande au serveur de lui envoyer ces enregistrements. Le client n'a plus « que » à les valider à partir d'une clé de confiance DNSSEC (typiquement celle de la racine, commune à tout le monde). Le serveur peut aussi, s'il n'utilise pas DANE, renvoyer la preuve de non-existence de ces enregistrements, le client saura alors, de manière certaine, qu'il peut se rabattre sur un autre mécanisme d'authentification. L'extension TLS de notre RFC peut servir à authentifier un certificat complet, ou bien une clé brute (RFC 7250). Dans ce dernier cas, cette extension protège en outre contre les attaques dites « Unknown Key-Share ».
Notez le statut de ce RFC : cette spécification est pour l'instant expérimentale, elle n'a pas vraiment réuni de consensus à l'IETF, mais elle fait partie des solutions proposées pour sécuriser DoT, dans le RFC 8310 (section 8.2.2).
Bon, maintenant, l'extension elle-même (section 2). C'est une
extension TLS (ces extensions sont spécifiées dans la section 4.2 du
RFC 8446), elle est nommée
dnssec_chain
et enregistrée
dans le registre IANA, avec le code 59. Son champ de données
(extension_data
) vaut, dans le
ClientHello
, le port de
connexion et, dans le ServerHello
, un ensemble
d'enregistrements DNS au format binaire du DNS (pour TLS 1.2 ; en
1.3, cet ensemble est attaché au certificat du serveur). Dans le
langage de description des données TLS, cela donne, du client vers
le serveur :
struct { uint16 PortNumber; } DnssecChainExtension;
Et du serveur vers le client :
struct { uint16 ExtSupportLifetime; opaque AuthenticationChain<1..2^16-1> } DnssecChainExtension;
(Le ExtSupportLifetime
indique que le serveur
s'engage à continuer à gérer cette extension pendant au moins ce
temps - en heures. Si ce n'est plus le cas avant l'expiration du
délai, cela peut indiquer une usurpation par un faux serveur.)
Cette extension est donc une forme, assez spéciale, de « DNS sur
TLS ». Le client ne doit pas oublier d'envoyer un SNI (RFC 6066), pour que le serveur sache quel nom va
être authentifié et donc quels enregistrements DNS renvoyer. Quant
au serveur, s'il ne gère pas cette extension, il répond au client
avec un ServerHello
n'ayant pas l'extension
dnssec_chain
. Même chose si le serveur accepte
l'extension mais, pour une raison ou pour une autre, n'a pas pu
rassembler tous les enregistrements DNS.
Et pourquoi le client doit-il indiquer le port auquel il voulait se connecter ? Le serveur le connait, non ? Mais ce n'est pas forcément le cas, soit parce qu'il y a eu traduction de port quelque part sur le chemin, soit parce que le client a été redirigé, par exemple via le type d'enregistrement SVCB (RFC 9460). Le port indiqué par le client doit être le port original, avant toute traduction ou redirection.
Revenons à la « chaine », l'ensemble d'enregistrements DNS qui va
permettre la validation DANE. Le format est le format binaire
habituel du DNS, décrit dans le RFC 1035,
section 3.2.1. L'utilisation de ce format, quoiqu'il soit inhabituel
dans le monde TLS, permet, entre autres avantages, l'utilisation des
bibliothèques logicielles DNS existantes. Le RFC recommande
d'inclure dans l'ensemble d'enregistrements une chaine complète, y
compris la racine et incluant donc les clés DNSSEC de celle-ci
(enregistrements DNSKEY), même si le client les connait probablement
déjà. Cela donne par exemple la chaine suivante, pour le serveur
www.example.com
écoutant sur le port 443. Notez
qu'on inclut les signatures (RRSIG) :
_443._tcp.www.example.com
TLSA_443._tcp.www.example.com
TLSA)example.com
. DNSKEYexample.com
DNSKEY)example.com
DSexample.com
DS)com
DNSKEYcom
DNSKEY)com
DScom
DS).
DNSKEY.
DNSKEY)
(L'exemple suppose que
_443._tcp.www.example.com
et
example.com
sont dans la même zone.) Voilà,
avec tous ces enregistrements, le client peut, sans faire appel à un
résolveur DNS validant, vérifier (s'il a confiance dans la clé de la
racine) l'authenticité de l'enregistrement DANE (type TLSA) et donc
le certificat du serveur. De la même façon, si on n'a pas
d'enregistrement TLSA, le serveur peut envoyer les preuves de
non-existence (enregistrements NSEC ou NSEC3). Bon, évidemment, dans
ce cas, c'est moins utile, autant ne pas gérer l'extension
dnssec_chain
… Face à ce déni, le client TLS
n'aurait plus qu'à se rabattre sur une autre méthode
d'authentification.
Le serveur TLS construit la chaine des enregistrements comme il veut, mais pour l'aider, la section 3 du RFC fournit une procédure possible, à partir d'interrogations du résolveur de ce serveur. Une autre possibilité, plus simple pour le serveur, serait d'utiliser les requêtes chainées du RFC 7901 (mais qui n'ont pas l'air très souvent déployées aujourd'hui).
Comme tous les enregistrements DNS, ceux inclus dans l'extension
TLS dnssec_chain
ont une durée de vie. Et les signatures DNSSEC ont
une période de validité (en général plus longue que la durée de
vie). Le serveur TLS qui construit l'ensemble d'enregistrements qu'il
va renvoyer peut donc mémoriser cet ensemble, dans la limite du
TTL et de l'expiration
des signatures DNSSEC. Le client TLS peut lui aussi mémoriser ces
informations, dans les mêmes conditions.
On a vu plus haut que les données de l'extension TLS incluaient
un ExtSupportLifetime
qui indiquait combien de
temps le client pouvait s'attendre à ce que le serveur TLS continue
à gérer cette extension. Car le client peut épingler
(pinning) cette information. Cela permet de
détecter certaines attaques (« ce serveur gérait l'extension
dnssec_chain
et ce n'est maintenant plus le
cas ; je soupçonne un détournement vers un serveur pirate »). Cet
engagement du serveur est analogue au HSTS de HTTPS (RFC 6797) ; dans les deux cas, le serveur s'engage à rester
« sécurisé » pendant un temps minimum (mais pas infini, car on doit
toujours pouvoir changer de politique). À noter que « gérer
l'extension dnssec_chain
» n'est pas la même
chose que « avoir un enregistrement TLSA », on peut accepter
l'extension mais ne pas avoir de données à envoyer (il faudra alors
envoyer la preuve de non-existence mentionnée plus haut). Bien sûr,
le client TLS est libre de sa politique. Il peut aussi décider
d'exiger systématiquement l'acceptation de l'extension TLS
dnssec_chain
(ce qui, aujourd'hui, n'est
réaliste que si on ne parle qu'à un petit nombre de serveurs).
Si un serveur gérait l'extension
dnssec_chain
mais souhaite arrêter, il doit
bien calculer son coup : d'abord réduire
ExtSupportLifetime
à zéro puis attendre que
la durée annoncée dans le précédent
ExtSupportLifetime
soit écoulée, afin que tous
les clients aient arrêté de l'épingler comme serveur à
dnssec_chain
. Il peut alors proprement stopper
l'extension (cf. section 10 du RFC).
Un petit problème se pose si on fait héberger le serveur TLS chez
un tiers. Par exemple, imaginons que le titulaire du domaine
boulanger.example
ait un serveur chez la
société JVL (Je Vous Loge) et que
server.boulanger.example
soit un alias
(enregistrement de type CNAME) vers
clients.jvl.example
. Le client TLS va envoyer
server.boulanger.example
comme SNI. Il ne sera
pas pratique du tout pour JVL de coordonner la chaine
d'enregistrements DNS et le certificat. Il est donc conseillé que
l'enregistrement TLSA du client soit lui aussi un alias vers un
enregistrement TLSA de l'hébergeur. Cela pourrait donner (sans les
signatures, pour simplifier la liste) :
server.boulanger.example
CNAME (vers
clients.jvl.example
)_443._tcp.server.boulanger.example
CNAME
(vers _dane443.node1.jvl.example
)clients.jvl.example
AAAA_dane443.node1.jvl.example
TLSA
Les deux premiers enregistrements sont gérés par l'hébergé, les deux
derniers par l'hébergeur. (La section 9 du RFC explique pourquoi
l'enregistrement TLSA de l'hébergeur n'est pas en
_443._tcp
…)
Comme dit plus haut, le client TLS est maitre de sa politique : il peut exiger l'extension TLS, il peut l'accepter si elle existe, il peut l'ignorer. Si l'authentification par DANE échoue mais que celle par PKIX réussit, ou le contraire, c'est au client TLS de décider, en fonction de sa politique, ce qu'il fait.
Est-ce que le serveur TLS qui gère cette extension doit envoyer la chaine complète de certificats ? S'il veut pouvoir également être identifié avec PKIX, oui. Si non, s'il se contente de DANE et plus précisément de DANE-EE ou DANE-TA (ces deux termes sont définis dans le RFC 7218), il peut envoyer uniquement le certificat du serveur (pour DANE-EE).
Question mise en œuvre, l'excellente bibliothèque ldns a (je n'ai pas testé…) tout ce qu'il faut pour générer et tester ces chaines d'enregistrements DNS. Si vous voulez développer du code pour gérer cette extension, l'annexe A du RFC contient des vecteurs de test qui vous seront probablement bien utiles.
Date de publication du RFC : Août 2021
Auteur(s) du RFC : D. Crocker (Brandenburg InternetWorking), R. Signes (Fastmail), N. Freed (Oracle)
Expérimental
Première rédaction de cet article le 5 août 2021
Vous trouvez que le courrier électronique, c'est vieux et ringard, et que les réseaux sociaux avec leurs possibilités de réaction (« J'aime ! », « Je partage ! », « Je rigole ! »), c'est mieux ? Et bien, vous n'êtes pas le seul ou la seule. Ce nouveau RFC normalise un mécanisme pour mettre des réactions courtes et impulsives dans le courrier électronique.
L'idée de base est que, si ce RFC plait et est mis en œuvre par les auteurs de MUA, on verra près du message qu'on lit un menu avec des émojis, et on cliquera dessus, et l'émetteur du message verra sur son propre MUA le message qu'il a envoyé accompagné de ces réactions. (Le RFC ne normalise pas une apparence particulière à ces réactions, cf. section 5.2 pour des idées qui ne sont que des suggestions.)
Bien sûr, on peut déjà répondre à un message avec des émojis dans le corps de la réponse. Mais l'idée est de structurer cette réaction pour permettre une utilisation plus proche de celle des réseaux sociaux, au lieu que la réaction soit affichée comme un message comme les autres. Liée au message originel, cette structuration permettra, par exemple, au MUA de l'émetteur originel de voir le nombre de Likes de son message… (Quant à savoir si c'est utile, c'est une autre histoire…)
Techniquement, cela fonctionnera avec la combinaison des en-têtes
Content-Disposition:
et
In-Reply-To:
. Voici un exemple montrant le
format d'une réaction (négative…) à un message (le
12345@example.com
) :
To: author@example.com From: recipient@example.org Date: Today, 29 February 2021 00:00:10 -800 Message-id: 56789@example.org In-Reply-To: 12345@example.com Subject: Re: Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: Reaction 👎
(Si vous n'avez pas les bons émojis sur votre système, le caractère
en question était le pouce vers le
bas.) Recevant cette réponse, le MUA de l'auteur
(author@example.com
) peut rechercher le message
12345@example.com
et afficher que
recipient@example.org
n'est pas enthousiaste.
Le paramètre Reaction
pour l'en-tête
Content-Disposition:
(RFC 2183) a été ajouté
au registre IANA.
Le texte dans la partie MIME qui a l'en-tête
Content-Disposition: Reaction
est une ligne
d'émojis. On
peut utiliser les séquences
d'émojis. Tous les émojis sont utilisables mais le RFC en
liste cinq qui sont particulièrement importants car considérés comme
la base, le minimum que devrait reconnaitre tout MUA :
Notez que le concept de séquence d'émojis n'est pas simple. Ce concept permet d'éviter de normaliser des quantités astronomiques d'émojis, en autorisation la combinaison d'émojis. Il est utilisé entre autres pour les drapeaux nationaux, ainsi le drapeau libanais sera 🇱🇧 (U+1F1F1 qui indique le L du code pays ISO 3166 et U+1F1E7 qui indique le B). Le RFC rappelle qu'écrire du code dans son application pour gérer ces séquences n'est pas raisonnable et qu'il vaut mieux utiliser une bibliothèque Unicode existante.
Les sections 4 et 5 du RFC donnent quelques idées aux auteurs de MUA sur la gestion de ces réactions. Normalement, l'IETF normalise des protocoles, pas des interfaces utilisateur. Mais cela n'interdit pas de parler un peu d'UX dans le RFC, comme indiqué plus haut. En outre, l'interface utilisateur vers le courrier est typiquement assez différente de celle des réseaux sociaux où ce concept de réaction existe. Ainsi, le RFC ne tranche pas sur la question de savoir s'il faut envoyer la réaction uniquement à l'auteur original du message, ou bien à tous les destinataires. Ou bien s'il faut envoyer un message contenant juste la partie Réaction ou si on peut la combiner avec un autre contenu. Et que faire si, depuis la même adresse, on reçoit plusieurs réactions, éventuellement contradictoires ? Ne garder que la dernière (attention, le courrier électronique ne conserve pas l'ordre d'envoi) ? Les additionner ?
Toujours en UX, le RFC note que la réception d'une image dépend beaucoup du récepteur. (Et, contrairement à ce que laisse entendre le RFC, ce n'est pas juste une question de « culture », des personnes de la même « culture » peuvent comprendre différemment la même image.) Il faut donc faire attention aux réactions, qui peuvent être mal comprises. (Ceci dit, c'est exactement pareil avec le texte seul.) Et, comme toujours sur l'Internet, cette possibilité pourra ouvrir de nouveaux problèmes de sécurité (utilisation pour l'hameçonnage ?).
Date de publication du RFC : Juillet 2021
Auteur(s) du RFC : J. Yao, L. Zhou, H. Li (CNNIC), N. Kong (Consultant), W. Tan (Cloud Registry), J. Xie
Pour information
Première rédaction de cet article le 30 juillet 2021
Le bundling est le rassemblement de plusieurs noms de domaine dans un seul lot (bundle) qui va être traité comme un nom unique pour des opérations comme l'enregistrement du nom ou son transfert à un autre titulaire. Il est surtout pratiqué par les registres qui ont beaucoup de noms en écriture chinoise. Ce RFC décrit une extension au protocole d'avitaillement EPP pour pouvoir traiter ces lots.
Le problème n'existe pas qu'en chinois mais ce sont surtout les
sinophones qui se sont manifestés à ce sujet, en raison de la
possibilité d'écrire le même mot en écriture
traditionnelle ou en écriture
simplifiée (on parle de variantes :
l'ensemble des variantes forme le lot). Pour prendre un exemple
non-chinois, PIR avait décidé qu'un nom dans
.ngo
et dans .ong
devaient
être dans le même lot. Un registre qui décide que ces deux termes
sont équivalents et doivent être gérés ensemble (par exemple,
appartenir au même titulaire) les regroupent dans un lot
(bundle, ou parfois
package). C'est la politique suggérée dans les
RFC 3743 et RFC 4290, et
le RFC 6927 décrit les pratiques
existantes. Par exemple, certains registres peuvent n'autoriser
qu'une variante par lot, et bloquer les autres (empêcher leur
enregistrement), tandis que d'autres enregistreront tous les noms
ensemble. Sans compter bien sûr les registres qui n'ont pas de
système de lot du tout. Notre nouveau RFC 9095 ne prend pas
position sur ce sujet délicat, il décrit juste un moyen technique de
manipuler ces lots avec EPP (RFC 5731).
Les variantes dans un même lot n'ont pas forcément tout en commun. Un registre peut par exemple décider que l'enregistrement des variantes doit être fait par le même titulaire mais qu'un nom du lot peut ensuite être transféré à un autre titulaire. Notre RFC se limite au cas strict où les membres du lot ont presque tous leurs attributs (titulaires, contacts, date d'expiration, peut-être serveurs de noms et, pourquoi pas, clés DNSSEC) en commun.
La
lecture du RFC nécessite un peu de terminologie spécifique, décrite
dans sa section 2. Par exemple, le RDN (Registered Domain
Name) est celui qui a été demandé par le titulaire lors de
l'enregistrement, et le BDN (Bundled Domain Name)
est un nom qui a été inclus dans le lot, en fonction des règles du
registre. Par exemple, si un registre décidait que tout nom avec des
traits d'union était équivalent au même nom
sans traits d'union, et qu'un titulaire enregistre
tarte-poireaux.example
(le RDN), alors
tartepoireaux.example
et
tarte-poi-reaux.example
seraient des BDN,
membres du même lot que le RDN. Dans le modèle de notre RFC, les
métadonnées comme la date d'expiration ou comme l'état du domaine
sont attachées au RDN, les BDN du lot partageant ces
métadonnées.
Notons aussi que le RFC n'envisage que le cas de lots assez
petits (par exemple le nom en écriture chinoise traditionnelle et
celui en écriture chinoise simplifiée). L'exemple que je donnais
avec le trait d'union ne rentre pas tellement dans le cadre de ce
RFC car le nombre de BDN est alors beaucoup plus élevé et serait
difficile à gérer. (Amusez-vous à calculer combien de variantes de
tartepoireaux.example
existeraient si un
décidait que le trait d'union n'est pas significatif.)
Dans l'extension EPP décrite dans ce RFC, le RDN
est représenté (section 5 du RFC) en Unicode
(le « U-label ») ou bien en ASCII (le « A-label »,
la forme « punycodée »). L'élement XML est
<b-dn:rdn>
(où b-dn
est un préfixe possible pour l'espace de noms
XML de notre RFC, urn:ietf:params:xml:ns:epp:b-dn
). Si le RDN est représenté en ASCII, un attribut XML
uLabel
permet d'indiquer la version Unicode du
nom. Cela donnerait, par exemple, <b-dn:rdn
uLabel="实例.example">xn--fsq270a.example</b-dn:rdn>
.
Enfin, la section 6 décrit les commandes et réponses EPP pour
notre extension. La commande <check>
n'est pas modifiée dans sa syntaxe mais le RFC impose que, si un nom
qui fait partie d'un lot est envoyé dans la question, la réponse
doit contenir le RDN et le BDN. Pour un RDN en
sinogrammes, on aurait ainsi la version en
écriture traditionnelle et en écriture simplifiée (ici, le nom est
disponible à l'enregistrement) :
<response> <result code="1000"> <msg>Command completed successfully</msg> </result> <resData> <domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> <domain:cd> <domain:name avail="1"> xn--fsq270a.example</domain:name> </domain:cd> <domain:cd> <domain:name avail="1"> xn--fsqz41a.example </domain:name> <domain:reason>This associated domain name is a produced name based on bundle name policy. </domain:reason> </domain:cd> </domain:chkData> ...
La commande <info>
n'est pas non plus
modifiée mais sa réponse l'est, par l'ajout d'un élément
<bundle>
qui décrit le lot :
<response> <result code="1000"> <msg>Command completed successfully</msg> </result> <resData> <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> <domain:name>xn--fsq270a.example</domain:name> <domain:roid>58812678-domain</domain:roid> <domain:status s="ok"/> ... </domain:infData> </resData> <extension> <b-dn:infData xmlns:b-dn="urn:ietf:params:xml:ns:epp:b-dn"> <b-dn:bundle> <b-dn:rdn uLabel="实例.example"> xn--fsq270a.example </b-dn:rdn> <b-dn:bdn uLabel="實例.example"> xn--fsqz41a.example </b-dn:bdn> </b-dn:bundle> </b-dn:infData> </extension>
Quand on crée un domaine qui fait partie d'un lot, la commande
<create>
doit inclure une extension
indiquant que le client EPP connait la gestion de lots, et la
réponse à <create>
lui donnera le
BDN. D'une manière analogue, la commande
<delete>
détruira tout le lot et
l'indiquera dans la réponse. La commande
<update>
fonctionne sur le même
principe : elle modifie le RDN et indique dans sa réponse le BDN
affecté. La syntaxe complète de cette extension EPP figure dans la
section 7 du RFC, sous forme d'un schéma
W3C. Par ailleurs, cette extension est enregistrée dans
le
registre des extensions EPP (celui créé par le RFC 7451).
Un petit mot sur la sécurité, car de nombreux adversaires de l'internationalisation, notamment anglophones, ont critiqué les noms de domaine en Unicode, les accusant de tous les maux : les auteurs du RFC notent que des noms en chinois sont enregistrés depuis plus de quinze ans, et qu'aucun problème particulier n'a été signalé.
Questions mises en œuvre de ce RFC, les registres chinois (comme
.cn
ou
.tw
) suivent les
principes de ce RFC (l'enregistrement d'un lot) depuis
longtemps. CNNIC déploie cette extension
EPP. En dehors de la sinophonie, PIR utilise
les lots pour .ngo
et
.ong
. Et cette extension EPP est mise en œuvre
dans Net::DRI.
Et, comme souvent, il y a un brevet de Verisign sur la technique décrite dans ce RFC. Je ne l'ai pas lu mais il y a des chances qu'il soit sans mérite, comme beaucoup de brevets logiciels.
Date de publication du RFC : Juillet 2021
Auteur(s) du RFC : P. van Dijk (PowerDNS)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 25 juillet 2021
Ce nouveau RFC corrige une légère bavure. Lorsqu'on utilise la mémorisation énergique du RFC 8198 pour synthétiser des réponses DNS en utilisant les informations DNSSEC, les normes existantes permettaient une mémorisation pendant une durée bien trop longue. Cette erreur (peu grave en pratique) est désormais corrigée.
Rappelons que le principe du RFC 8198 est
d'autoriser un résolveur DNS à synthétiser
des informations qu'il n'a normalement pas dans sa mémoire,
notamment à partir des enregistrements NSEC
de
DNSSEC (RFC 4034,
section 4). Si un résolveur interroge la racine du DNS :
% dig @a.root-servers.net A foobar ... ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37332 ... foo. 86400 IN NSEC food. NS DS RRSIG NSEC
La réponse est négative (NXDOMAIN
)
et un enregistrement NSEC annonce au client DNS
qu'il n'y a pas de nom dans la racine entre
.foo
et .food
. Si le
résolveur mémorise cette information et qu'on lui demande par la
suite un nom en .foocat
, il n'aura pas besoin
de contacter la racine, il sait, en raison de l'enregistrement NSEC
que ce nom ne peut pas exister.
Bon, mais combien de temps le résolveur peut-il mémoriser cette
non-existence ? Le RFC 2308 disait qu'une
réponse négative (NXDOMAIN
) pouvait être
mémorisée pendant une durée indiquée par le
minimum du champ Minimum
de l'enregistrement SOA et du TTL de ce même enregistrement
SOA. Mais le RFC 4034, normalisant DNSSEC,
disait que l'enregistrement NSEC devait avoir un TTL égal au champ
Minimum
du SOA. Dans l'exemple de la racine du
DNS, à l'heure actuelle, cela ne change rien, ces durées sont toutes
égales. Mais elles pourraient être différentes. Si un enregistrement
SOA a un Minimum
à une journée mais un TTL
d'une heure, le RFC 2308 impose une heure de
mémorisation au maximum, le RFC 4034
permettait une journée… Ça pourrait même être exploité pour une
attaque en faisant des requêtes qui retournent des enregistrements
NSEC, afin de nier l'existence d'un nom pendant plus longtemps que
prévu. [Bon, dans le monde réel, je trouve que
c'est un problème assez marginal mais ce n'est pas une raison pour ne
pas le corriger.]
Le RFC 8198 avait déjà tenté de corriger le
problème mais sans y réussir. Notre nouveau RFC impose désormais
clairement que, contrairement à ce que dit le RFC 4034 (et deux ou trois autres RFC sur DNSSEC), la durée
maximale de mémorisation est bien le minimum du
champ Minimum
de l'enregistrement
SOA et du TTL
de ce même enregistrement SOA.
Si les logiciels que vous utilisez pour signer les zones ne
peuvent pas être corrigées immédiatement, le RFC demande que vous
changiez le contenu de la zone pour mettre la même valeur au champ
Minimum
de l'enregistrement
SOA et au TTL
de ce même enregistrement SOA.
En pratique, les signeurs suivants ont déjà été corrigés :
Date de publication du RFC : Juillet 2021
Auteur(s) du RFC : T. Wicinski
Pour information
Réalisé dans le cadre du groupe de travail IETF dprive
Première rédaction de cet article le 24 juillet 2021
La surveillance généralisée sur l'Internet est un gros problème pour la vie privée. L'IETF s'active donc à améliorer la protection de la vie privée contre cette surveillance (RFC 7258). Un protocole qui avait souvent été négligé dans ce travail est le DNS. Ce RFC décrit les problèmes de vie privée liés au DNS. Il remplace le RFC 7626, avec deux changements important, l'intégration des techniques de protection développées et déployées depuis l'ancien RFC et, malheureusement, beaucoup de propagande anti-chiffrement imposée par les acteurs traditionnels des résolveurs DNS qui ne veulent pas se priver de leurs possibilités de contrôle et de surveillance.
Ce RFC est en fait à la croisée de deux activités. L'une d'elles consiste à documenter les problèmes de vie privée, souvent ignorés jusqu'à présent dans les RFC. Cette activité est symbolisée par le RFC 6973, dont la section 8 contient une excellente analyse de ces problèmes, pour un service particulier (la présence en ligne). L'idée est que, même si on ne peut pas résoudre complètement le problème, on peut au moins le documenter, pour que les utilisateurs soient conscients des risques. Et la seconde activité qui a donné naissance à ce RFC est le projet d'améliorer effectivement la protection de la vie privée des utilisateurs du DNS, en marchant sur deux jambes : minimiser les données envoyées et les rendre plus résistantes à l'écoute, via le chiffrement. L'objectif de diminution des données a débouché sur la QNAME minimization spécifiée dans le RFC 9156 et le chiffrement a donné DoT (RFC 7858) et DoH (RFC 8484).
Donc, pourquoi un RFC sur les questions de vie privée dans le
DNS ? Ce dernier est un très ancien protocole, dont l'une des
particularités est d'être mal spécifié : aux deux RFC originaux, les
RFC 1034 et RFC 1035, il
faut ajouter dix ou vingt autres RFC dont la lecture est nécessaire
pour tout comprendre du DNS. Et aucun travail de consolidation n'a
jamais été fait, contrairement à ce qui a eu lieu pour XMPP,
HTTP ou
SMTP. Or, le DNS est crucial, car quasiment
toutes les transactions Internet mettent en jeu au moins une requête
DNS (ne me dites pas des bêtises du genre « moi, je télécharge avec
BitTorrent, je
n'utilise pas le DNS » : comment allez-vous sur
thepiratebay.am
?) Mais, alors que les
questions de vie privée liées à HTTP ont fait l'objet d'innombrables articles
et études, celles liées au DNS ont été largement ignorées pendant
longtemps (voir la bibliographie du RFC pour un état de
l'art). Pourtant, on peut découvrir bien des choses sur votre
activité Internet uniquement en regardant le trafic DNS.
Une des raisons du manque d'intérêt pour le thème « DNS et vie privée » est le peu de compétences concernant le DNS : le protocole est souvent ignoré ou mal compris. C'est pourquoi le RFC doit commencer par un rappel (section 1) du fonctionnement du DNS.
Je ne vais pas reprendre tout le RFC ici. Juste quelques rappels
des points essentiels du DNS : il existe deux sortes de serveurs
DNS, qui n'ont pratiquement aucun rapport. Il y a les
serveurs
faisant autorité et les résolveurs. Les premiers
sont ceux qui connaissent de première main l'information pour une
zone DNS donnée (comme fr
ou
wikipedia.org
). Ils sont gérés par le titulaire
de la zone ou bien sous-traités à un hébergeur DNS. Les seconds, les
résolveurs, ne connaissent rien (à part l'adresse IP des serveurs de la racine). Ils
interrogent donc les serveurs faisant autorité, en partant de la
racine. Les résolveurs sont gérés par le FAI ou le service
informatique qui s'occupe du réseau local de l'organisation. Ils
peuvent aussi être individuels, ou bien au
contraire être de gros serveurs publics comme Google Public DNS, gros fournisseur de la
NSA. Pour
prendre un exemple concret (et en simplifiant un peu), si M. Michu
veut visiter le site Web
http://thepiratebay.am/
, son navigateur va
utiliser les services du système d'exploitation sous-jacent pour
demander l'adresse IP de
thepiratebay.am
. Le système d'exploitation va
envoyer une requête DNS au résolveur (sur
Unix, les adresses IP des résolveurs sont
dans /etc/resolv.conf
). Celui-ci va demander
aux serveurs de la racine s'ils connaissent
thepiratebay.am
, il se fera rediriger vers les
serveurs faisant autorité pour am
, puis vers ceux faisant
autorité pour thepiratebay.am
. Le résolveur
aura alors une réponse qu'il pourra transmettre au navigateur de
M. Michu.
Principal point où j'ai simplifié : le DNS s'appuie beaucoup sur
la mise en cache des données, c'est-à-dire sur
leur mémorisation pour gagner du temps la fois suivante. Ainsi, si
le même M. Michu, cinq minutes après, veut aller en
http://armenpress.am/
, son résolveur ne
demandera rien aux serveurs de la racine : il sait déjà quels sont
les serveurs faisant autorité pour am
.
Le trafic DNS est un trafic IP ordinaire, typiquement porté par UDP. Mais il peut aussi fonctionner sur TCP et bientôt sur QUIC. Il peut être écouté, et comme il n'est pas toujours chiffré, un indiscret peut tout suivre. Voici un exemple pris avec tcpdump sur un serveur racine (pas la racine officielle, mais, techniquement, cela ne change rien) :
15:29:24.409283 IP6 2001:67c:1348:8002::7:107.10127 > \ 2001:4b98:dc2:45:216:3eff:fe4b:8c5b.53: 32715+ [1au] \ AAAA? www.armenpress.am. (46)
On y voit que le client
2001:67c:1348:8002::7:107
a demandé l'adresse
IPv6 de
www.armenpress.am
.
Pour compléter le tableau, on peut aussi noter que les logiciels
génèrent un grand nombre de requêtes DNS, bien supérieur à ce que
voit l'utilisateur. Ainsi, lors de la visite d'une page Web, le
résolveur va envoyer la requête primaire (le
nom du site visité, comme thepiratebay.am
), des
requêtes secondaires dues aux objets contenus
dans la page Web (JavaScript, CSS, divers
traqueurs et autres outils de cyberflicage ou de cyberpub) et même
des requêtes tertiaires, lorsque le
fonctionnement du DNS lui-même nécessitera des requêtes. Par
exemple, si abc.xyz
est hébergé sur des
serveurs dans google.com
, une visite de
http://abc.xyz/
nécessitera de résoudre les
noms comme ns1.google.com
, donc de faire des
requêtes DNS vers les serveurs de
google.com
.
Bien sûr, pour un espion qui veut analyser tout cela, le trafic DNS représente beaucoup de données, souvent incomplètes en raison de la mise en cache, et dont l'interprétation peut être difficile (comme dans l'exemple ci-dessus). Mais les organisations qui pratiquent l'espionnage massif, comme la NSA, s'y connaissent en matière de big data et savent trouver les aiguilles dans les bottes de foin.
Les sections 3 à 7 du RFC détaille les risques pour la vie privée
dans les différents composants du DNS. Notez que la confidentialité
du contenu du DNS n'est pas prise en compte (elle l'est dans les
RFC 5936 et RFC 5155). Il est important de noter qu'il y a une énorme
différence entre la confidentialité du contenu
et la confidentialité des requêtes. L'adresse
IP de www.charliehebdo.fr
n'est pas un secret : les données DNS sont publiques, dès qu'on
connait le nom de domaine, et tout le monde peut faire une requête
DNS pour la connaitre. Mais le fait que vous fassiez une requête
pour ce nom ne devrait pas être public. Vous n'avez pas forcément
envie que tout le monde le sache. (On peut quand même nuancer un peu
le côté « public » des données DNS : on peut avoir des noms de
domaine purement internes à une organisation. Mais ces noms
« fuitent » souvent, par la marche sur la zone décrite dans le RFC 4470, ou via des systèmes de « passive DNS).
Pour comprendre les risques, il faut aussi revenir un peu au protocole DNS. Les deux informations les plus sensibles dans une requête DNS sont l'adresse IP source et le nom de domaine demandé (qname, pour Query Name, cf. RFC 1034, section 3.7.1). L'adresse IP source est celle de votre machine, lorsque vous parlez au résolveur, et celle du résolveur lorsqu'il parle aux serveurs faisant autorité. Elle peut indiquer d'où vient la demande. Lorsque on utilise un gros résolveur, celui-ci vous masque vis-à-vis des serveurs faisant autorité (par contre, ce gros résolveur va avoir davantage d'informations). Ceci dit, l'utilisation d'ECS (RFC 7871) peut trahir votre adresse IP, ou au moins votre préfixe. (Cf. cette analyse d'ECS. D'autre part, certains opérateurs se permettent d'insérer des informations comme l'adresse MAC dans des options EDNS de la requête.)
Quant au qname, il peut être très révélateur :
il indique les sites Web que vous visitez, voire, dans certains cas,
les logiciels utilisés. Au moins un client
BitTorrent fait des requêtes DNS pour
_bittorrent-tracker._tcp.domain.example
,
indiquant ainsi à beaucoup de monde que vous utilisez un protocole
qui ne plait pas aux ayant-droits. Et si vous utilisez le RFC 4255, pas mal de serveurs verront à quelles
machines vous vous connectez en SSH...
Donc où un méchant qui veut écouter votre trafic DNS peut-il se placer ? D'abord, évidemment, il suffit qu'il écoute le trafic réseau. On l'a dit, le trafic DNS aujourd'hui est souvent en clair donc tout sniffer peut le décoder. Même si vous utilisez HTTPS pour vous connecter à un site Web, le trafic DNS, lui, ne sera pas chiffré. (Les experts pointus de TLS noteront qu'il existe d'autres faiblesses de confidentialité, comme le SNI du RFC 6066, qui n'est pas encore protégé, cf. RFC 8744.) À noter une particularité du DNS : le trafic DNS peut passer par un autre endroit que le trafic applicatif. Alice peut naïvement croire que, lorsqu'elle se connecte au serveur de Bob, seul un attaquant situé physiquement entre sa machine et celle de Bob représente une menace. Alors que son trafic DNS peut être propagé très loin, et accessible à d'autres acteurs. Si vous utilisez, par exemple, le résolveur DNS public de FDN, toute la portion de l'Internet entre vous et FDN peut facilement lire votre trafic DNS.
Donc, l'éventuel espion peut être près du câble, à écouter. Mais il peut être aussi dans les serveurs. Bercé par la musique du cloud, on oublie souvent cet aspect de la sécurité : les serveurs DNS voient passer le trafic et peuvent le copier. Pour reprendre les termes du RFC 6973, ces serveurs sont des assistants : ils ne sont pas directement entre Alice et Bob mais ils peuvent néanmoins apprendre des choses à propos de leur conversation. Et l'observation est très instructive. Elle est utilisée à de justes fins dans des systèmes comme DNSDB (section 6 du RFC) mais il n'est pas difficile d'imaginer des usages moins sympathiques comme dans le cas du programme NSA MORECOWBELL.
Les résolveurs voient tout le trafic puisqu'il y a peu de mise en cache en amont de ces serveurs. Il faut donc réfléchir à deux fois avant de choisir d'utiliser tel ou tel résolveur ! Il est déplorable qu'à chaque problème DNS (ou supposé tel), des ignorants bondissent sur les réseaux sociaux pour dire « zyva, mets 8.8.8.8 [Google Public DNS] comme serveur DNS et ça ira plus vite » sans penser à toutes les données qu'ils envoient à la NSA ainsi.
Les serveurs faisant autorité voient passer moins de trafic (à cause des caches des résolveurs) mais, contrairement aux résolveurs, ils n'ont pas été choisis délibérement par l'utilisateur. Celui-ci peut ne pas être conscient que ses requêtes DNS seront envoyées à plusieurs acteurs du monde du DNS, à commencer par la racine. Le problème est d'autant plus sérieux que, comme le montre une étude, la concentration dans l'hébergement DNS est élevée : dix gros hébergeurs hébergent le tiers des domaines des 100 000 sites Web les plus fréquentés (listés par Alexa).
Au passage, le lecteur attentif aura noté qu'un résolveur personnel (sur sa machine ou dans son réseau local) a l'avantage de ne pas envoyer vos requêtes à un résolveur peut-être indiscret mais l'inconvénient de vous démasquer vis-à-vis des serveurs faisant autorité, puisque ceux-ci voient alors votre adresse IP. Une bonne solution (qui serait également la plus économe des ressources de l'Internet) serait d'avoir son résolveur local et de faire suivre les requêtes non résolues au résolveur du FAI. Du point de vue de la vie privée, ce serait sans doute la meilleure solution mais cela ne résout hélas pas un autre problème, celui des DNS menteurs, contre lesquels la seule protection est d'utiliser uniquement un résolveur de confiance. On peut résoudre ce problème en ayant son propre résolveur mais qui fait suivre à un résolveur public de confiance. Notez que la taille compte : plus un résolveur est petit, moins il protège puisque ses requêtes sortantes ne seront dues qu'à un petit nombre d'utilisateurs.
Enfin, il y a aussi les serveurs DNS « pirates » (installés, par
exemple, via un serveur DHCP lui-même pirate) qui détournent le trafic
DNS, par exemple à des fins de surveillance. Voir par exemple
l'exposé de Karrenberg à JCSA
2012 disponible
en ligne (transparents 27 et 28, Unknown
et Other qui montrent l'existence de clones
pirates du serveur racine
K.root-servers.net
).
Pour mes lecteurs en France férus de droit, une question intéressante : le trafic DNS est-il une « donnée personnelle » au sens de la loi Informatique & Libertés ? Je vous laisse plancher sur la question, qui a été peu étudiée.
Les changements depuis le RFC 7626 sont résumés dans l'annexe A. Outre des retours d'expérience basés sur le déploiement de solutions minimisant et/ou chiffrant les données, ils consistent essentiellement en remarques négatives sur le chiffrement, défendant le mécanisme traditionnel de résolution DNS. Il n'y avait d'ailleurs pas forcément d'urgence à sortir un nouveau RFC. Comme le demandait Alissa Cooper, l'auteure du RFC 6973, « Why not wait to see how QUIC, DOH, ADD, ODNS, etc. shake out in the next few years and take this up then? ». C'est en raison de ces changements négatifs que je ne suis pas cité comme auteur du RFC (contraitement à son prédécesseur). Sara Dickinson, qui avait géré l'essentiel du travail pour les débuts de ce nouveau RFC, s'est également retirée, en raison de la dureté des polémiques qui ont déchiré l'IETF sur ce document.
Depuis la sortie du RFC 7626, il y a eu un certain nombre de déploiement de techniques améliorant la protection de la vie privée dans le cas du DNS, notamment la minimisation des données (RFC 9156) et le chiffrement (DoT, RFC 7858, DoH, RFC 8484, et le futur DoQ). Cela permet des retours d'expérience. Par exemple, sur l'ampleur du déploiement de la minimisation, ou sur les performances du chiffrement (voir « An End-to-End, Large-Scale Measurement of DNS-over-Encryption »). Il y a eu également des discussions politiques à propos de ces techniques et de leur déploiement, souvent malhonnêtes ou confuses (et ce RFC en contient plusieurs) comme l'accusation de « centralisation », qui sert surtout à protéger l'état actuel, où l'opérateur de votre réseau d'accès à l'Internet peut à la fois vous surveiller et contrôler ce que vous voyez, via sa gestion de la résolution DNS. Mais il est vrai que rien n'est simple en matière de sécurité et que DoH (mais pas DoT) est trop bavard, puisqu'il hérite des défauts de HTTP, en envoyant trop d'informations au serveur.
Le RFC essaie de décourager les utilisateurs d'utiliser le chiffrement (dans l'esprit du RFC 8404) en notant que ce n'est pas une technologie parfaite (par exemple, l'observation des métadonnées peut donner des indications ou, autre exemple, une mauvaise authentification du résolveur peut vous faire envoyer vos requêtes à un méchant). C'est vrai mais c'est le cas de toutes les solutions de sécurité et on ne trouve pas de tels avertissements dans d'autres RFC qui parlent de chiffrement. L'insistance des opérateurs pour placer ces messages anti-chiffrement dans ce RFC montre bien, justement, l'importance de se protéger contre la curiosité des opérateurs.
Le RFC remarque également qu'il n'existe pas actuellement de moyen de découvrir automatiquement le résolveur DoT ou DoH. Mais c'est normal : un résolveur DoT ou DoH annoncé par le réseau d'accès, par exemple via DHCP, n'aurait guère d'intérêt, il aurait les mêmes défauts (et les mêmes qualités) que le résolveur traditionnel. DoT et DoH n'ont de sens qu'avec un résolveur configuré statiquement. Le RFC cite des déploiements de résolveurs DNS avec chiffrement faits par plusieurs FAI (aucun en France, notons-le). Cela montre une grosse incompréhension du problème : on ne chiffre pas pour le plaisir de chiffrer, mais parce que cela permet d'aller de manière sécurisée vers un autre résolveur. Chiffrer la communication avec le résolveur habituel ne fait pas de mal mais on ne gagne pas grand'chose puisque ce résolveur a les mêmes capacités de surveillance et de modification des réponses qu'avant. Notons que le RFC, inspiré par la propagande des telcos, raconte que le risque de surveillance est minimisé par le chiffrement du lien radio dans les réseaux 4G et après. Cela oublie le fait que la surveillance peut justement venir de l'opérateur.
Plus compliqué est le problème de l'endroit où se fait cette configuration. Traditionnellement, la configuration du résolveur à utiliser était faite globalement par le système d'exploitation. Ce n'est pas du tout une règle du protocole DNS (les RFC normalisant le DNS ne contrôlent que ce qui circule sur le câble, pas les choix locaux de chaque machine) et il serait donc absurde d'invoquer un soi-disant principe comme quoi le DNS serait forcément géré au niveau du système. Certains déploiements de DoH (celui de Firefox, par exemple), mettent le réglage dans l'application (en l'occurrence le navigateur Web). La question est discutable et discutée mais, de toute façon, elle ne relève pas de l'IETF (qui normalise ce qui passe sur le réseau) et il est anormal que le RFC en parle.
Le temps passé depuis le RFC 7626 a également permis la mise en service d'un plus grand nombre de résolveurs publics, comme Quad9 ou comme celui de Cloudflare. Mais il n'y a pas que les grosses boîtes états-uniennes qui gèrent des résolveurs DNS publics. Ainsi, je gère moi-même un modeste résolveur public. Le très intéressant RFC 8932 explique le rôle des politiques de vie privée dans ces résolveurs publics et comment en écrire une bonne. Bien sûr, comme toujours en sécurité, la lutte de l'épée contre la cuirasse est éternelle et des nouvelles actions contre la vie privée et la liberté de choix apparaissent, par exemple des réseaux qui bloquent l'accès à DoT (en bloquant son port 853) ou aux résolveurs DoH connus (DoH a été développé en partie pour être justement plus difficile à bloquer).
Date de publication du RFC : Juillet 2021
Auteur(s) du RFC : J. Arkko (Ericsson), S. Farrell (Trinity College Dublin), M. Kühlewind (Ericsson), C. Perkins (University of Glasgow)
Pour information
Première rédaction de cet article le 23 juillet 2021
La pandémie de Covid-19 en 2020 a affecté de nombreux aspects de notre vie. Concernant plus spécifiquement l'Internet, elle a accru l'utilisation d'outils de communication informatiques. Quels ont été les effets de ces changements sur l'Internet ? Un atelier de l'IAB fait le point sur ces effets et en tire des leçons. Je vous le dis tout de suite : contrairement à certains discours sensationnalistes, l'Internet n'a pas subi de conséquences sérieuses.
De janvier à mars 2020, de nombreux pays ont imposé un confinement plus ou moins strict. Des activités comme le travail ou l'éducation devaient se faire à distance, en utilisant les outils numériques. Certains politiciens ont tenu des discours dramatisants, prétendant que, si on ne renonçait pas à regarder ses vidéos favorites, l'Internet allait s'écrouler. Même si aucun professionnel des réseaux n'a repris ce discours, cela ne veut pas dire qu'il ne s'est rien passé. L'IAB a donc organisé en novembre 2020 un atelier (évidemment tenu en ligne car il n'y avait pas le choix) pour étudier les effets de ces confinements sur l'Internet, comprendre ce qui est arrivé et peut-être formuler des recommandations.
Donc, pendant le confinement et l'augmentation du télétravail qui en a résulté, le trafic Internet a changé. Il n'a pas toujours augmenté (les travailleurs utilisaient également Internet quand ils étaient au bureau, et les gens regardaient déjà Netflix avant la pandémie) mais il s'est déplacé : trafic de type différent, à des heures différentes, etc. Et, dans la plupart des pays, c'est arrivé assez soudainement, laissant peu de temps pour l'adaptation. La sécurité a été également très affectée, les mesures de sécurité conçues sur la base d'un lieu physique n'ayant plus de sens. Tout à coup, il a fallu autoriser beaucoup d'accès distants, avec tous les risques que cela impliquait. L'atelier lui-même a été différent des précédents ateliers de l'IAB, qui étaient fondés sur une participation physique pendant deux jours continus. Cette fois, l'atelier s'est fait en trois sessions à distance, avec respiration et réflexion entre les sessions.
Qu'ont observé les acteurs de l'Internet ? À l'atelier, certains
FAI ou
gérants de points d'échange Internet ont
signalé des accroissements de 20 % du trafic. C'est à la fois
beaucoup et peu. C'est beaucoup car c'est survenu soudainement, sans
être étalé sur une période permettant le déploiement de nouvelles
ressources, et c'est peu, car la croissance de l'utilisation des
réseaux est un phénomène permanent : il faut toujours augmenter la
capacité (20 % représente une
augmentation annuelle typique, mais qui fut concentrée en quelques
semaines). On voit ici le trafic sur le point d'échange
Internet de Francfort (la source
est ici). S'il y a bien une brusque montée début 2020 avec le
démarrage du confinement, il faut noter qu'elle s'inscrit dans une
augmentation du trafic Internet sur le long terme :
Cette montée du trafic lors du confinement est également
relativisée sur les statistiques de trafic au point
d'échange parisien (la source est ici) :
De même, l'article « Measurement of congestion on ISP interconnection links » mesure des moments de congestion limités aux États-Unis en mars. Cette croissance était très inégalement répartie selon les services. Vous ne serez pas surpris d'apprendre que certains opérateurs de services de vidéo-conférence ont vu leur activité tripler, voire décupler. Une intéressante conclusion est que, contrairement à ce que certains discours sensationnalistes comme ceux de Thierry Breton prétendaient, l'Internet n'a pas connu de problème généralisé. Comme toujours dans ce réseau mondial, les problèmes sont restés localisés, ralentissements à certains endroits, baisse automatique de la qualité des vidéos à d'autres, mais pas de problème systémique. Ce bon résultat n'a pas été obtenu uniquement par la capacité du réseau existant à encaisser la montée en charge. Il y a eu également de nombreuses actions prises par les différents acteurs du réseau, qui ne sont pas restés les bras croisés face au risque. Bref, vu du point de vue scientifique, c'était une expérience intéressante, qui montre que l'Internet peut résister à des crises, ce qui permet de penser que les problèmes futurs ne seront pas forcément fatals.
[L'atelier portait bien sur l'Internet, sur l'infrastructure, pas sur les services hébergés. Il est important de faire la distinction car certains services (comme ceux de l'Éducation Nationale en France) ont été incapables de résister à la charge et se sont vite écroulés. Mais ce n'était pas une défaillance de l'Internet, et renoncer à regarder des vidéos n'aurait pas protégé le CNED contre ces problèmes. Notons qu'il n'y avait pas de fatalité à ces problèmes des services : Wikipédia et Pornhub, deux services très différents dans leur utilisation et leur gestion, ont continué à fonctionner correctement.]
Voyons maintenant les détails, dans la section 3 du RFC. On commence avec la sous-section 3.1, les mesures. Que s'est-il passé ? Comme on pouvait s'y attendre, le trafic résidentiel a augmenté (en raison du travail à la maison), tandis que celui des réseaux mobiles chutait (on se déplaçait moins). Le trafic vers les opérateurs de services de vidéo-conférence (comme Zoom) a augmenté, ainsi que celui des services de distraction (VoD) pendant la journée. Mais il y a eu surtout un gros déplacement des pics d'activité. En semaine, l'activité Internet était très liée au rythme de la journée, avec des trafics très différents dans la journée et le soir. Pendant les confinements, on a vu au contraire une activité plus étalée dans le temps chez les FAI résidentiels, et une activité de la semaine qui ressemble à celle des week-ends. Là encore, pas de conséquences graves, bien que certains FAI aient signalé des ralentissements notamment en mars 2020. Bref, l'Internet sait bien résister aux sautes de trafic qui, il est vrai, font partie de son quotidien depuis sa création.
Parmi les articles soumis pour l'atelier, je vous recommande, sur
la question des mesures, le très détaillé « A
view of Internet Traffic Shifts at ISP and IXPs during the COVID-19
Pandemic ». Les auteurs ont observé le trafic chez
plusieurs opérateurs et points d'échange (le
seul nommé est le réseau académique de
Madrid). Par exemple, en utilisant diverses
heuristiques (le port seul ne suffit plus,
tout le monde étant sur 443),
les auteurs ont des chiffres concernant diverses applications
(vidéo-conférence, vidéo à la demande, jeux en ligne, etc). Moins
détaillé, il y a le « IAB
COVID-19 Workshop: Interconnection Changes in the United
States » (à l'origine publié dans un
Internet-Draft,
draft-feamster-livingood-iab-covid19-workshop
).
Un exemple de changement du trafic est donné par le Politecnico de Turin qui a vu son trafic sortant multiplié par 2,5, en raison de la diffusion de ses 600 cours en ligne par jour, alors que le trafic entrant était divisé par 10. Dans les universités, le trafic entrant est typiquement bien plus gros que le sortant (les étudiants et enseignants sont sur le campus et accèdent à des ressources distantes) mais cela a changé pendant le confinement, les ressources externes étant accédées depuis la maison. (Une entreprise aurait pu voir des effets différents, si les employés accèdent à ces ressources externes via le VPN de l'entreprise.) Le REN REDIMadrid a vu également de gros changements dans son trafic. Effet imprévu, les communications avec les AS d'Amérique latine a augmenté, probablement parce que les étudiants hispanophones américains profitaient des possibilités de cours à distance pour suivre les activités des universités de l'ex-métropole.
Comme dit plus haut, les réseaux mobiles, 4G et autres, ont vu leur activité baisser. L'article « A Characterization of the COVID-19 Pandemic Impact on a Mobile Network Operator Traffic » note une mobilité divisée par deux en Grande-Bretagne et un trafic diminué d'un quart. (Certaines personnes ne sont plus mobiles mais utilisent la 4G à la maison, et il y a bien d'autres phénomènes qui rendent compliquée l'analyse.) L'observation des signaux envoyés par les téléphones (le réseau mobile sait où vous êtes…) a également permis de mesurer l'ampleur de la fuite hors des grandes villes (10 % des Londoniens).
Et dans la connexion des FAI avec les services sur le cloud ? Les liens d'interconnexion entre FAI et fournisseurs de services ont-ils tenu ? Pas de congestion persistante mais des moments de tension, par exemple aux États-Unis vers les petits FAI, qui n'avaient pas toujours une interconnexion suffisante pour encaisser tout le trafic accru. Comme toujours sur l'Internet, malgré le caractère mondial de la pandémie, il y a peu d'observations valables partout et tout le temps, vu la variété des capacités des liaisons. Malgré l'observation générale « globalement, ça a tenu », il y a toujours des endroits où ça rame à certains moments.
En effet, le bon fonctionnement de l'Internet mondial ne signifiait pas que tous les MM. Toutlemonde de la Terre avaient une bonne qualité de connexion. L'article « The Impact of COVID-19 on Last-mile Latency » (plus de détails sur le blog de l'auteur) rend compte de mesures faites avec les sondes RIPE Atlas, qui trouvent une congestion plus fréquente sur le « premier kilomètre » (le lien entre la maison de M. Toutlemonde et le premier POP de son FAI) pendant le confinement. Cela dépend évidemment beaucoup du FAI et du pays, le Japon ayant été particulièrement touché. La situation s'est toutefois améliorée au fur et à mesure, notamment en raison des déploiements de capacité supplémentaire par les opérateurs (et, au Japon, des investissements qui étaient prévus pour les Jeux Olympiques). L'Internet se retrouve donc plus robuste qu'avant. Le RFC cite même Nietzsche « Ce qui ne me tue pas me rend plus fort ».
On l'a dit, le trafic n'a pas seulement changé quantitativement mais aussi qualitativement. La vidéo-conférence a, fort logiquement, crû. Le trafic très asymétrique de certains FAI grand public (beaucoup plus de trafic entrant vers les consommateurs que de trafic sortant) s'est un peu égalisé, en raison des flux vidéos sortants. NCTA et Comcast signalent plus de 30 % de hausse de ce trafic sortant, Vodafone 100 %. Un rapport d'Ericsson sur les utilisateurs signale :
Ces changements sont-ils permanents ? Resteront-ils dans le « monde d'après » ? Le RFC estime que le télétravail s'est désormais installé et restera ; on peut donc prévoir que l'utilisation intensive d'outils de réunion à distance persistera (cf. le rapport « Work-At-Home After Covid-19—Our Forecast »).
Après ces observations, la section 3 du RFC continue avec des considérations sur les problèmes opérationnels constatés. D'abord, un point de fracture numérique. Aux États-Unis, et probablement dans bien d'autres pays, le débit entrant chez les utilisateurs est corrélé au niveau de vie. Mais on a constaté pendant la pandémie une réduction de l'écart entre riches et pauvres (l'étude ne portait pas sur des foyers individuels mais sur des zones géographiques identifiées par leur code postal, un bon indicateur de niveau de vie, au moins aux USA). Cette réduction de l'écart n'était pas forcément liée à un changement de comportement des utilisateurs mais l'était peut-être au fait que certains FAI comme Comcast ont étendu la capacité liée à des abonnements bon marché, par souci de RSE pendant la crise. L'écart entre riches et pauvres était donc peut-être dû à une différence dans les abonnements souscrits, pas à une différence d'utilisation de l'Internet.
Les applications vedettes des confinements ont évidemment été les outils de réunion en ligne, gros services privateurs et capteurs de données personnelles comme Microsoft Teams ou Zoom, ou bien services reposant sur des logiciels libres comme BigBlueButton (dont le RFC, qui reflète un point de vue surtout étatsunien, ne parle pas). D'autres outils de distribution de vidéo, comme YouTube ont vu également leur trafic augmenter soudainement. Certains acteurs, comme justement YouTube, ont délibérement réduit la qualité des vidéos pour diminuer la charge sur le réseau, mais il n'est pas évident que cela ait eu un effet majeur. Autre catégorie d'applications qui a vu son utilisation augmenter, les jeux en ligne. Souvent très consommateurs de ressources, ils ont la particularité de demander à la fois une forte capacité (en raisons des contenus multimédias riches à télécharger) et une faible latence (quand on tire sur le zombie, il doit tomber tout de suite). La mise à jour d'un jeu très populaire a un effet très net sur le réseau des FAI ! Mais il faut noter que ce n'est pas un phénomène spécifique au confinement. Les opérateurs ont déjà dû faire face à des évènements soudains, comme une nouvelle version d'un logiciel très utilisé ou comme une nouvelle mode, par exemple une application qui connait un succès rapide, ce qui est assez fréquent sur l'Internet. Outre ces « effets Slashdot », il y a aussi les attaques par déni de service, qui nécessitent de suravitailler (mettre davantage de capacité que strictement nécessaire). Les opérateurs ont donc déjà de l'expérience dans ce domaine mais, note le RFC, cette expérience n'est pas toujours partagée.
Une discussion lors de l'atelier a porté sur la possibilité de gérer ce genre de problèmes par des mesures discriminatoires, de type qualité de service (un terme propagandiste, il faut le noter : si on discrimine, certains auront une meilleure qualité et d'autres une moins bonne). Marquer le trafic « pas essentiel » (qui décidera de ce qui n'est pas essentiel ?) avec DSCP pour le faire passer par les chemins les plus lents aurait-il aidé ? Compte-tenu du caractère très brûlant de ce débat, il n'est pas étonnant qu'aucun consensus n'est émergé de l'atelier. Le RFC se réjouit qu'au moins les engueulades ont été moins graves que d'habitude.
Une bonne partie de cet atelier était consacré à l'étude de faits : qu'ont vu les opérateurs ? Or, ils n'ont pas vu la même chose. Cela reflète les différences de situation mais aussi les différences dans les outils d'observation. La métrologie n'est pas une chose facile ! Par exemple, les applications de vidéo-conférence ou de distribution de vidéo à la demande ont des mécanismes de correction d'erreur et de gestion de la pénurie très élaborés. L'application s'adapte en permanence aux caractéristiques du réseau, par exemple en ajustant son taux de compression. C'est très bien pour l'utilisateur, cela permet de lui dissimuler une grande partie des problèmes, mais cela complique l'observation. Et quand il y a un problème, il est difficile à analyser. L'autre jour, sans que cela ait de rapport avec un confinement, je regardais une vidéo sur Netflix et la qualité de l'image était vraiment médiocre, gâchant le plaisir. Mais où était le problème ? Mon PC était trop lent ? Le Wifi était pourri ? Le réseau de Free surchargé ? L'interconnexion entre Free et Netflix était-elle encombrée ? Les serveurs de Netflix ramaient-ils ? C'est très difficile à dire, et cela dépend de beaucoup de choses (par exemple, deux utilisateurs de Netflix ne tombent pas forcément sur le même serveur chez Netflix et peuvent donc avoir des vécus différents). Et puis, globalement, on manque de capacités d'observation sur l'Internet. Le client ne voit pas ce qui se passe sur le serveur, le serveur ne sait pas grand'chose sur le client, et peut-être qu'aucun des deux n'a pas visibilité sur l'interconnexion. Chacun connait bien son réseau, mais personne ne connait l'Internet dans son ensemble. Le RFC note que, paradoxalement, la Covid-19 a amélioré les choses, en augmentant le niveau de coopération entre les acteurs de l'Internet.
Et la sécurité ? Elle a aussi été discutée à l'atelier car le passage brusque de tant de gens au télétravail a changé le paysage de la sécurité. On ne pouvait plus compter sur le pare-feu corporate et sur les machines du bureau soigneusement verrouillées par la DSI. Au lieu de cela, tout le monde utilisait des VPN pas toujours bien maitrisés (cf. l'article « IAB COVID-19 Network Impacts »). Et la pandémie a été l'occasion de nombreuses escroqueries (décrites dans le même article). À propos de sécurité, le RFC en profite pour vanter les résolveurs DNS menteurs et critiquer DoH (qui n'est pour rien dans ces escroqueries).
En conclusion, le RFC note que le bon fonctionnement de l'Internet pendant la pandémie n'était pas dû uniquement à ses qualités intrinsèques, mais aussi à l'action de nombreux acteurs. Comme d'autres professions, les techniciens et techniciennes de l'Internet étaient une des lignes de défense face à l'épidémie et cette ligne était très motivée, et a tenu. Ces techniciennes et techniciens méritent donc de chaudes félicitations. Mais on peut quand même améliorer les choses :
Et le RFC se conclut par un bilan de cet atelier qui, contrairement aux ateliers précédents de l'IAB, a été fait entièrement en ligne. Les participants ont été plutôt contents, notamment du fait que le travail à distance a permis de changer le format : au lieu de deux jours complets de discussions, l'atelier a pu se tenir en alternant des moments de discussion et du travail chez soi, pour approfondir et critiquer les discussions. Toutefois, le RFC note que cela a bien marché car la quasi-totalité des présents se connaissaient bien, étant des participants de longue date à l'IETF. Il n'est pas du tout évident que cela aurait aussi bien marché avec des gens nouveaux, le présentiel étant crucial pour créer des liens informels.
L'ensemble des articles écrits par les participants à l'atelier (pour participer, il fallait avoir écrit un texte) est disponible en ligne (en bas de la page).
Première rédaction de cet article le 21 juillet 2021
Une passionnante discussion sur la liste NANOG vient de porter sur les « problèmes gris ». Qu'est-ce qu'un problème gris en matière de réseaux informatiques ?
Les réseaux ne sont pas fiables, toute personne qui a déjà vu un message « Connection time out » peut en témoigner. De l'erreur de configuration chez un opérateur à l'attaque d'une pelleteuse sur une fibre, en passant par une bogue dans les routeurs, les causes de panne ne manquent pas. Ces pannes sont typiquement binaires : soit toutes les communications passent, soit aucune ne passe. À défaut d'être faciles à prévenir, ou même à réparer, ces pannes sont triviales à détecter : la supervision couine et les utilisateurs râlent. Mais il y a aussi des pannes « grises ». C'est quand ça déconne mais pas de manière binaire : la grande majorité du trafic passe (et on peut donc ne s'apercevoir de rien) mais le problème gris frappe une petite minorité des paquets, selon des critères qui ne sont pas évidents à première vue. Par exemple, le réseau laisse passer tous les paquets, sauf ceux qui ont telle combinaison d'options. Ou bien il laisse passer 99,99 % des paquets mais jette les autres (en dehors du cas de congestion, où il est normal de jeter les paquets). Dans la discussion sur NANOG, un ingénieur citait un cas qu'il avait rencontré où une line card défaillante jetait tous les paquets IPv6 où le 65e bit de l'adresse de destination était à 1 (ce qui est apparemment assez rare). Le terme a été utilisé dans d'autres contextes que le réseau (par exemple cette étude de Microsoft).
La discussion sur la liste NANOG avait été lancée dans le contexte d'une étude de l'École polytechnique de Zurich, étude qui commençait par un sondage auprès des opérateurs pour leur demander s'ils géraient les problèmes gris et comment.
D'abord, une constatation peu originale mais qu'il est important de rappeler. Même en dehors de la congestion, aucun réseau ne transporte 100 % des paquets. Il y a toujours des problèmes, les réseaux étant des objets physiques, soumis aux lois de la physique et aux perturbations diverses (comme les rayons cosmiques). Aucune machine n'est idéale, l'électronique n'est pas virtuelle et est donc imparfaite, la mémoire d'un routeur ne garde pas forcément intact ce qu'on lui a confié. Et, non, FCS et ECC ne détectent pas tous les problèmes. Comme le notait un observateur : « De ma longue expérience, j'en ai tiré une analyse (très pertinente) : en informatique il y a entre 1 % et 2 % de magie. C'est faux, mais ça soulage parfois de se dire qu'on est peut être la cible d'un sortilège vaudou ou sous la coupe d'une bonne fée. » Si un opérateur prétendait sincèrement ne pas avoir de problèmes gris, cela indiquerait une absence de recherche plutôt qu'une absence de problème. Fermer les yeux permet de dormir mieux :-)
Les problèmes gris sont très difficiles à détecter. Supposons que, comme tout bon ingénieur, vous avez un système de supervision automatique qui fonctionne, mettons, en envoyant des messages ICMP de type Echo et en attendant une réponse. Si vous envoyez trois paquets par test, et que le réseau jette 1 % des paquets (un chiffre très élevé) au hasard, vous n'avez qu'une chance sur un demi-million de détecter le problème. Bien sûr, on ne se contente pas de ce genre de tests. On regarde par exemple les compteurs attachés aux interfaces des routeurs et on regarde si les compteurs d'erreur grimpent. Mais si c'est l'électronique des routeurs qui est défaillante, les compteurs ne seront pas fiables.
Les problèmes gris sont parfois déterministes (comme dans l'exemple du bit 65 plus haut) mais pas toujours et, s'ils ne sont pas reproductibles, le problème est encore pire. Même s'ils sont déterministes, l'algorithme n'est pas forcément évident. Si les paquets sont aiguillés à l'intérieur d'un équipement selon des critères complexes, et qu'un seul des circuits est défaillant, vous ne trouverez pas forcément tout de suite pourquoi, des fois, ça passe et, des fois, ça ne passe pas.
Est-ce grave pour l'opérateur ? Dans la discussion sur NANOG, un participant a dit franchement que les problèmes gris étaient fréquents mais tellement difficiles à traiter (par exemple parce qu'ils impliquent souvent de longues et difficiles négociations avec les vendeurs de matériel) qu'il valait mieux les ignorer, sauf si un client râlait. Mais, justement, le client ne râle pas toujours si le problème est rare, et difficile à pointer du doigt avec précision. Et puis les systèmes modernes comportent tellement de couches superposées que le client a le plus grand mal à trouver l'origine d'un problème. Ainsi, dans le cas d'un problème spécifique à IPv6, comme celui cité plus haut, le fait que le navigateur Web typique se rabatte automatiquement et rapidement en IPv4 n'aide pas au diagnostic (même si c'est certainement mieux pour le bonheur de l'utilisateur).
Pour donner une idée de la subtilité des problèmes gris, un participant à NANOG citait un cas d'un commutateur qui perdait 0,00012 % des paquets, un nombre difficile à repérer au milieu des erreurs de mesure. Le problème avait été détecté lors du remplacement des anciens tests (genre les trois messages ICMP cités plus haut) par des tests plus violents.
Bref, quand vous (enfin, votre navigateur Web) avez récupéré cet article, peut-être un problème gris a-t-il perturbé cette récupération. Peut-être n'a-t-il même pas été détecté et le texte que vous lisez n'est pas le bon…
Date de publication du RFC : Juillet 2021
Auteur(s) du RFC : N. Jenkins, R. Stepanek (Fastmail)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF calext
Première rédaction de cet article le 20 juillet 2021
Beaucoup d'applications gèrent des agendas, avec des réunions à ne pas oublier, des évènements récurrents, des rendez-vous précis. Le format traditionnel d'échange de ces applications est iCalendar, normalisé dans le RFC 5545 (ou, dans sa déclinaison en JSON, jCal, dans le RFC 7265). Ce RFC propose une syntaxe JSON mais, surtout, un modèle de données très différent, JSCalendar. Le but est de remplacer iCalendar.
Les principes de base ? Simplicité (au moins dans les cas simples, car les calendriers sont des bêtes compliquées…), uniformité (autant que possible, une seule façon de représenter un évènement), tout en essayant de permettre des conversions depuis iCalendar (RFC 5545 et RFC 7986), donc en ayant un modèle de données compatible. JSCalendar, comme son nom l'indique, utilise JSON, plus exactement le sous-ensemble i-JSON, normalisé dans le RFC 7493.
Bon, mais pourquoi ne pas avoir gardé iCalendar ? Parce qu'il est trop complexe avec plusieurs formats de date, parce que ses règles de récurrence sont ambigües et difficiles à comprendre, parce que sa syntaxe est mal définie. jCal n'a pas ce dernier problème mais il garde tous les autres. On voit même des logiciels utiliser leur propre représentation en JSON des données iCalendar au lieu d'utiliser jCal. Bref, JSCalendar préfère repartir, sinon de zéro, du moins d'assez loin.
Voici un exemple très simple et très minimal de représentation d'un évènement en JSCalendar :
{ "@type": "Event", "uid": "a8df6573-0474-496d-8496-033ad45d7fea", "updated": "2020-01-02T18:23:04Z", "title": "Some event", "start": "2020-01-15T13:00:00", "timeZone": "America/New_York", "duration": "PT1H" }
Comme avec iCalendar, les données JSCalendar peuvent être échangées par courrier ou avec n'importe quel autre protocole de son choix comme JMAP ou WebDAV.
Avant d'attaquer ce format JSCalendar, rappelez-vous qu'il utilise JSON et que la terminologie est celle de JSON. Ainsi, on nomme « objet » ce qui, selon le langage utilisé, serait un dictionnaire ou un tableau associatif. Ensuite, outre les types de base de JSON, JSCalendar a des types supplémentaires (section 1), notamment :
Id
, un identificateur, pour que les
objets aient un nom simple et unique (c'est une chaîne de
caractères JSON). On peut par exemple utiliser un UUID (RFC 9562). Dans l'exemple ci-dessus, le membre
uid
de l'objet est un
Id
.UTCDateTime
, une date-et-heure (un
instant dans le temps) au format du RFC 3339
dans une chaîne de caractères JSON, est obligatoirement en
UTC. Un
tel type est intéressant pour les évènements internationaux comme
une vidéoconférence. Dans l'exemple
ci-dessus, le membre updated
est de ce
type.LocalDateTime
, une date-et-heure selon
le fuseau horaire local. Un tel type est utile pour les évènements
locaux, comme un pique-nique. Dans
l'exemple ci-dessus, qui concerne une réunion en présentiel,
start
est de ce type. On a besoin des deux
types, à la fois parce que les évènements en distanciel et en
présentiel n'ont pas les mêmes besoins, et aussi parce que le
décalage entre les deux peut varier. Les calendriers, c'est
compliqué et le RFC cite l'exemple de la
LocalDateTime
2020-10-04T02:30:00
qui n'existe pas à
Melbourne car le passage à
l'heure d'été fait qu'on saute de 2h à 3h,
mais qui peut apparaitre dans les calculs
(start
+ une durée) ou bien si les règles de
l'heure d'été changent.Duration
est une durée, exprimée comme
en iCalendar (PT1H
pour « une heure » dans
l'exemple ci-dessus, ce serait P1Y
pour une
année). Gag : une journée (P1D
) ne fait pas
forcément 24 heures, par exemple si on passe à l'heure d'été
pendant cette journée.SignedDuration
, une durée qui peut être
négative.TimeZoneId
, un identifiant pour un
fuseau horaire, pris dans la base de l'IANA, par
exemple Europe/Paris
.PatchObject
est un pointeur JSON (ces
pointeurs sont normalisés dans le RFC 6901)
qui permet de désigner un objet à modifier.Relation
est un objet, et plus un
simple type scalaire comme les précédents. Il permet d'indiquer
une relation entre deux objets, notamment vers un objet parent ou
enfant..Link
est également une relation et donc
un objet, mais vers le monde extérieur. Il a des propriétés comme
href
(dont la valeur est, comme vous vous en
doutez, un URI) ou cid
qui
identifie le contenu vers lequel on pointe, dans la syntaxe du
RFC 2392.Les types de JSCalendar figurent dans un registre IANA, qu'on peut remplir avec la procédure « Examen par un expert » du RFC 8126.
Bien, maintenant que nous avons tous nos types, construisons des objets. Il y en a de trois types (section 2) :
Event
(l'exemple ci-dessus, regardez
sa propriété @type
) est un évènement
ponctuel, par exemple une réunion professionnelle ou une
manifestation de rue. Il a une date-et-heure de départ, et une
durée.Task
est une tâche à accomplir, elle
peut avoir une date-et-heure limite et peut avoir une durée
estimée.Group
est un groupe d'évènements JSCalendar.JSCalendar n'a pas de règles de canonicalisation (normalisation)
générales, car cela dépend trop de considérations sémantiques que le
format ne peut pas connaitre. Par exemple, JSON permet des
tableaux, et JSCalendar utilise cette
possibilité mais, quand on veut décider si deux tableaux sont
équivalents, doit-on tenir compte de l'ordre des éléments
([1, 2] == [2, 1]
) ? Cela dépend de
l'application et JSCalendar ne fixe donc pas de règles pour ce
cas. (Un cas rigolo et encore pire est celui des valeurs qui sont
des URI
puisque la canonicalisation des URI dépend du plan -
scheme.)
Quelles sont les propriétés typiques des objets JSCalendar (section 4) ? On trouve notamment, communs aux trois types d'objets (évènement, tâche et groupe) :
@type
, le type d'objet (Event
dans l'exemple ci-dessus, un des trois types possibles).uid
(a8df6573-0474-496d-8496-033ad45d7fea
dans
l'exemple), l'identificateur de l'objet (il est recommandé que ce
soit un des UUID du RFC 9562).prodID
, un identificateur du logiciel
utilisé, un peu comme le User-Agent:
de
HTTP. Le
RFC suggère d'utiliser un FPI.updated
, une date-et-heure de type
UTCDateTime
.title
et
description
, des chaînes de caractères
utiles.locations
(notez le S) qui désigne les
lieux physiques de l'évènement. C'est compliqué. Chaque lieu est
un objet de type Location
qui a comme
propriétés possibles un type (tiré du registre
des types de lieux créé par le RFC 4589), et une localisation sous forme de
latitude et
longitude (RFC 5870).virtualLocations
, qui indique des
informations comme l'URI (via la propriété du même nom). Ainsi,
une conférence en ligne organisée par l'assocation Parinux via
BigBlueButton aura comme
virtualLocations
{"@type":
"VirtualLocation", "uri":
"https://bbb.parinux.org/b/ca--xgc-4r3-n8z", …}
.color
permet de suggérer au logiciel
une couleur à utiliser pour l'affichage, qui est une valeur
RGB en hexadécimal ou bien un nom de couleur
CSS.Et je suis loin d'avoir cité toutes les propriétés possibles, sans compter celles spécifiques à un type d'objet.
Pour le cas de locations
, le RFC fournit un
exemple de vol international (quand il était encore possible de prendre
l'avion) :
{ "...": "", "title": "Flight XY51 to Tokyo", "start": "2020-04-01T09:00:00", "timeZone": "Europe/Berlin", "duration": "PT10H30M", "locations": { "418d0b9b-b656-4b3c-909f-5b149ca779c9": { "@type": "Location", "rel": "start", "name": "Frankfurt Airport (FRA)" }, "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { "@type": "Location", "rel": "end", "name": "Narita International Airport (NRT)", "timeZone": "Asia/Tokyo" } } }
Notez les UUID pour identifier les lieux, et le changement de fuseau horaire entre le départ et l'arrivée. Si l'évènement a lieu à la fois en présentiel et en distanciel (ici, le concert est dans un lieu physique identifié par ses coordonnées géographiques, mais aussi diffusé en ligne), cela peut donner :
{ "...": "", "title": "Live from Music Bowl: The Band", "description": "Go see the biggest music event ever!", "locale": "en", "start": "2020-07-04T17:00:00", "timeZone": "America/New_York", "duration": "PT3H", "locations": { "c0503d30-8c50-4372-87b5-7657e8e0fedd": { "@type": "Location", "name": "The Music Bowl", "description": "Music Bowl, Central Park, New York", "coordinates": "geo:40.7829,-73.9654" } }, "virtualLocations": { "1": { "@type": "VirtualLocation", "name": "Free live Stream from Music Bowl", "uri": "https://stream.example.com/the_band_2020" } }, ...
Les fournisseurs de logiciel peuvent ajouter des propriétés
définies par eux. Dans ce cas, le RFC recommande fortement qu'ils
les nomment en les faisant précéder d'un nom de domaine identifiant le fournisseur. Si
celui-ci a example.com
et veut une propriété
toto
, il la nommera
example.com:toto
. C'est évidemment une solution
temporaire, les fournisseurs ont tout intérêt à enregistrer ces
propriétés pour qu'elles puissent servir à tout le monde. Le
mécanisme d'enregistrement de nouvelles propriétés est « Examen par
un expert » (RFC 8126) et les propriétés sont
dans un
registre IANA.
Passons maintenant à un aspect compliqué mais indispensable des
calendriers : les règles de récurrence, comme « Réunion de service
tous les premiers lundis du mois à 10 h, sauf jour férié ». Il est
important de maintenir ces évènements récurrents sous forme de
règles, et de ne pas de les instancier immédiatement, car
l'application des règles peut donner des résultats différents dans
le futur. JSCalendar permet une propriété
recurrenceRules
qui décrit ces règles de
récurrence et évidemment une
excludedRecurrenceRules
car s'il n'y a pas
d'exceptions, ce n'est pas drôle. Exprimer les règles n'est pas
facile. L'idée est de spécifier la récurrence sous forme d'une série
de règles, chacune indiquant une fréquence (annuelle, mensuelle, etc), à
chaque fois à partir de la propriété start
, le
calendrier utilisé (qui doit être un des calendriers disponibles
dans CLDR), la marche à suivre quand une règle
produit une date invalide dans ce calendrier (annuler l'évènement,
le mettre avant, le mettre après), et plein d'autres propriétés
optionnelles comme le jour du mois (« réunion tous les 6 du mois »),
de la semaine (« tous les mercredis »), etc. Il faut ensuite
plusieurs pages au RFC pour expliquer la façon subtile dont les
règles sont appliquées, et se combinent. Les exceptions de la
excludedRecurrenceRules
fonctionnent de la même
façon, et sont ensuite soustraites des dates-et-heures sélectionnées
par les règles.
Le RFC fournit cet exemple de récurrence : le premier
avril arrive tous les ans (et dure une journée, notez le
duration
) :
{ "...": "", "title": "April Fool's Day", "showWithoutTime": true, "start": "1900-04-01T00:00:00", "duration": "P1D", "recurrenceRules": [{ "@type": "RecurrenceRule", "frequency": "yearly" }] }
Alors qu'ici, on fait du yoga une demi-heure chaque jour à 7 h du matin :
{ "...": "", "title": "Yoga", "start": "2020-01-01T07:00:00", "duration": "PT30M", "recurrenceRules": [{ "@type": "RecurrenceRule", "frequency": "daily" }] }
Bon, ensuite, quelques détails pour aider le logiciel à classer
et présenter les évènements. Un évènement peut avoir des propriétés
comme priority
(s'il y a deux réunions en même
temps, laquelle choisir ?), freeBusyStatus
(est-ce que cet évènement fait que je doive être considéré comme
occupé ou est-il compatible avec autre chose ?),
privacy
(cet évènement peut-il être affiché
publiquement ?), participationStatus
(je
viendrai, je ne viendrai pas, je ne sais pas encore…), et plein
d'autres encore.
Il y a aussi des propriétés concernant d'autres sujets, par
exemple l'adaptation locale. Ainsi, la propriété
localizations
indique la ou les langues à utiliser (leur valeur est une
étiquette de langue du RFC 5646).
Toutes les propriétés vues jusqu'à présent étaient possibles pour tous les types d'objets JSCalendar (évènement, tâche et groupe). D'autres propriétés sont spécifiques à un ou deux types :
Event
) peuvent avoir
entre autres
un start
(un
LocalDateTime
qui indique le début de
l'évènement) et un duration
(la durée de
l'évènement).Task
) peuvent avoir un
start
mais aussi un due
qui indique la date où elles doivent être terminées, et un
percentComplete
(pour les chefs de
projet…).Group
) ont, par exemple,
entries
, qui indique les objets qui sont
membres du groupe.Les fichiers à ce format JSCalendar sont servis sur l'Internet
avec le type
application/jscalendar+json
.
Pour terminer, voyons un peu la sécurité de JSCalendar (section 7). Évidemment, toutes les informations stockées dans un calendrier sont sensibles : rares sont les personnes qui accepteraient de voir la totalité de leur agenda être publiée ! Celui-ci permet en effet de connaitre le graphe social (les gens qu'on connait), les lieux où passe la personne, ses habitudes et horaires, bref, que des choses personnelles. Toute application qui manipule des données JSCalendar doit donc soigneusement veiller à la confidentialité de ces données, et doit les protéger.
Le risque d'accès en lecture n'est pas le seul, la modification non autorisée de l'agenda serait également un problème, elle pourrait permettre, par exemple, de faire déplacer une personne en un lieu donné. D'autres conséquences d'une modification pourraient toucher la facturation (location d'une salle pendant une certaine durée) ou d'autres questions de sécurité (activer ou désactiver une alarme à certains moments). L'application qui manie du JSCalendar doit donc également empêcher ces changements non autorisés.
Notez que ces problèmes de sécurité ne concernent pas le format à proprement parler, mais les applications qui utilisent ce format. Rien dans JSCalendar, dans ce RFC, ne le rend particulièrement vulnérable ou au contraire protégé, tout est dans l'application.
Les règles de récurrence sont complexes et, comme tout programme, elles peuvent entrainer des conséquences imprévues, avec consommation de ressources informatiques associées. Un exemple aussi simple que la session de yoga quotidienne citée plus haut pourrait générer une infinité d'évènements, si elle était mise en œuvre par une répétition systématique, jusqu'à la fin des temps. Les programmes doivent donc faire attention lorsqu'ils évaluent les règles de récurrence.
L'un des buts d'un format standard d'évènements est évidemment l'échange de données. Il est donc normal et attendu qu'une application de gestion d'agenda reçoive des objets JSCalendar de l'extérieur, notamment via l'Internet. On voit souvent du iCalendar en pièce jointe d'un courrier, par exemple. Il ne faut pas faire une confiance aveugle à ces données venues d'on ne sait où, et ne pas tout intégrer dans le calendrier du propriétaire. L'authentification du courrier (par exemple avec DKIM, RFC 6376) aide un peu, mais n'est pas suffisante.
Les fuseaux horaires sont une source de confusion sans fin. Un utilisateur qui n'est pas attentif, lorsqu'on lui dit qu'un évènement a lieu à 10h30 (UTC-5) peut croire que c'est 10h30 de son fuseau horaire à lui. (Et encore, ici, j'ai indiqué le fuseau horaire de manière lisible, contrairement à ce que font la plupart des Étatsuniens, qui utilisent leurs sigles à eux comme PST, ou ce que font les Français qui n'indiquent pas le fuseau horaire, persuadés qu'ils sont que le monde entier est à l'heure de Paris.) Cette confusion peut être exploitée par des méchants qui utiliseraient les fuseaux horaires de manière délibérement peu claire pour tromper quelqu'un sur l'heure d'un évènement. (Dans la série Mad Men, les hommes qui ne supportent pas l'arrivée d'une femme dans le groupe lui donnent des informations trompeuses sur les heures de réunion, pour qu'elle manque ces évènements.)
Où trouve-t-on du JSCalendar à l'heure actuelle ? Mobilizon ne l'a pas encore (l'action « Ajouter à mon agenda » exporte du iCalendar). Fastmail annonce qu'ils gèrent JSCalendar (mais apparemment seulement dans les échanges JMAP, pas avec l'import/export normal). Cyrus l'a aussi (si vous avez des détails, ça m'intéresse). Pour le cas des récurrences, vous avez une intéressante mise en œuvre en Python. Attention, il y a aussi plein de logiciels qui s'appellent « jscalendar » (notamment des widgets JavaScript pour afficher un calendrier dans un formulaire Web) mais qui n'ont aucun rapport avec ce RFC.
Date de publication du RFC : Juillet 2021
Auteur(s) du RFC : G. Fairhurst (University of Aberdeen), C. Perkins (University of Glasgow)
Pour information
Réalisé dans le cadre du groupe de travail IETF tsvwg
Première rédaction de cet article le 20 juillet 2021
La couche Transport n'est pas celle qui suscite le plus de passions dans l'Internet. Mais la récente normalisation du protocole QUIC a mis cette couche en avant et l'usage du chiffrement par QUIC a relancé le débat : quelles sont les conséquences d'un chiffrement de plus en plus poussé de la couche Transport ?
Traditionnellement, la couche Transport ne faisait pas de chiffrement (cf. RFC 8095 et RFC 8922). On chiffrait en-dessous (IPsec) ou au-dessus (TLS, SSH). IPsec ayant été peu déployé, l'essentiel du chiffrement aujourd'hui sur l'Internet est fait par TLS. Toute la mécanique TCP est donc visible aux routeurs sur le réseau. Ils peuvent ainsi mesurer le RTT, découvrir début et fin d'une connexion, et interférer avec celle-ci, par exemple en envoyant des paquets RST (ReSeT) pour mettre fin à la session. Cela permet de violer la vie privée (RFC 6973), par exemple en identifiant une personne à partir de son activité en ligne. Et cette visibilité de la couche Transport pousse à l'ossification : de nombreux intermédiaires examinent TCP et, si des options inhabituelles sont utilisées, bloquent les paquets. Pour éviter cela, QUIC chiffre une grande partie de la couche 4, pour éviter les interférences par les intermédiaires et pour défendre le principe de bout en bout et la neutralité du réseau. Comme souvent en sécurité, cette bonne mesure de protection a aussi des inconvénients, que ce RFC examine. Notons tout de suite que ce qui est un inconvénient pour les uns ne l'est pas forcément pour les autres : pour un FAI, ne pas pouvoir couper les connexions TCP de BitTorrent avec RST est un inconvénient mais, pour l'utilisateur, c'est un avantage, cela le protège contre certaines attaques par déni de service.
On ne peut pas sérieusement aujourd'hui utiliser des communications non-chiffrées (RFC 7258). Personne n'ose dire publiquement le contraire. Par contre, on entend souvent un discours « je suis pour le chiffrement, mais » et, comme toujours avec ce genre de phrase, c'est ce qui est après le « mais » qui compte. Ce RFC essaie de documenter les avantages et les inconvénients du chiffrement de la couche Transport, mais, en pratique, est plus détaillé sur les inconvénients, ce qui était déjà le cas du RFC 8404.
La section 2 du RFC explique quel usage peut être fait des informations de la couche Transport par les équipements intermédiaires. En théorie, dans un modèle en couches idéal, il n'y en aurait aucun : la couche Transport est de bout en bout, les routeurs et autres équipements intermédiaires ne regardent rien au-dessus de la couche Réseau. Mais en pratique, ce n'est pas le cas, comme l'explique cette section. (Question pour mes lecteurices au passage : vous semble-t-il légitime de parler de DPI quand un routeur regarde le contenu de la couche Transport, dont il n'a en théorie pas besoin, ou bien doit-on réserver ce terme aux cas où il regarde dans la couche Application ?)
Première utilisation de la couche Transport par des intermédiaires : identifier des flots de données (une suite d'octets qui « vont ensemble »). Pourquoi en a-t-on besoin ? Il y a plusieurs raisons possibles, par exemple pour la répartition de charge, où on veut envoyer tous les paquets d'un flot donné au même serveur. Cela se fait souvent en prenant un tuple d'informations dans le paquet (tuple qui peut inclure une partie de la couche Transport, comme les ports source et destination) et en le condensant pour avoir un identificateur du flot. Si la couche Transport est partiellement ou totalement chiffrée, on ne pourra pas distinguer deux flots différents entre deux machines. En IPv6, l'étiquette de flot (RFC 6437) est une solution possible (RFC 6438, RFC 7098), mais je n'ai pas l'impression qu'elle soit très utilisée.
Maintenant, passons à la question de l'identification d'un flot. Était-ce un transfert de fichiers, de la vidéo, une session interactive ? Il faut déduire cette identification à partir des informations de la couche Transport (voir le RFC 8558). Mais pourquoi identifier ces flots alors que l'opérateur doit tous les traiter pareil, en application du principe de neutralité ? Cela peut être dans l'intérêt de l'utilisateur (mais le RFC ne donne pas d'exemple…) ou bien contre lui, par exemple à des fins de surveillance, ou bien pour discriminer certains usages (comme le réclament régulièrement certains politiciens et certains opérateurs), voire pour les bloquer complètement. Autrefois, on pouvait souvent identifier un service uniquement avec le numéro de port (43 pour whois, 25 pour le courrier, etc, cf. RFC 7605) mais cela n'a jamais marché parfaitement, plusieurs services pouvant utiliser le même port et un même service pouvant utiliser divers ports. De toute façon, cette identification par le numéro de port est maintenant finie, en partie justement en raison de cette discrimination selon les usages, qui pousse tout le monde à tout faire passer sur le port 443. Certains services ont un moyen simple d'être identifié, par exemple par un nombre magique, volontairement placé dans les données pour permettre l'identification, ou bien simple conséquence d'une donnée fixe à un endroit connu (RFC 3261, RFC 8837, RFC 7983…). Lors de la normalisation de QUIC, un débat avait eu lieu sur la pertinence d'un nombre magique permettant d'identifier du QUIC, idée finalement abandonnée.
Si les équipements intermédiaires indiscrets n'arrivent pas à déterminer le service utilisé, le flot va être considéré comme inconnu et le RFC reconnait que certains opérateurs, en violation de la neutralité de l'Internet, ralentissent ces flots inconnus.
L'étape suivante pour ceux qui veulent identifier à quoi servent les données qu'ils voient passer est d'utiliser des heuristiques. Ainsi, une visio-conférence à deux fera sans doute passer à peu près autant d'octets dans chaque sens, alors que regarder de la vidéo à la demande créera un trafic très asymétrique. Des petits paquets UDP régulièrement espacés permettent de soupçonner du trafic audio, même si on n'a pas pu lire l'information SDP (RFC 4566). Des heuristiques plus subtiles peuvent permettre d'en savoir plus. Donc, il faut se rappeler que le chiffrement ne dissimule pas tout, il reste une vue qui peut être plus ou moins précise (le RFC 8546 décrit en détail cette notion de vue depuis le réseau).
Autre motivation pour analyser la couche Transport, l'amélioration des performances. Inutile de dire que le FAI typique ne va pas se pencher sur les problèmes de performance d'un abonné individuel (si ça rame avec Netflix, appeler le support de son FAI ne déclenche pas de recherches sérieuses). Mais cela peut être fait pour des analyse globales. Là encore, les conséquences peuvent être dans l'intérêt de l'utilisateur, ou bien contre lui. Le RFC note que les mesures de performance peuvent amener à une discrimination de certains services (« QoS », qualité de service, c'est-à-dire dégradation de certains services). Que peut-on mesurer ainsi, qui a un impact sur les performances ? Il y a la perte de paquets, qu'on peut déduire, en TCP, des retransmissions. Dans l'Internet, il y a de nombreuses causes de pertes de paquets, du parasite sur un lien radio à l'abandon délibéré par un routeur surchargé (RFC 7567) en passant par des choix politiques de défavoriser certains paquets (RFC 2475). L'étude de ces pertes peut permettre dans certains cas de remonter aux causes.
On peut aussi mesurer le débit. Bon, c'est facile, sans la couche Transport, uniquement en regardant le nombre d'octets qui passent par les interfaces réseaux. Mais l'accès aux données de la couche Transport permet de séparer le débit total du débit utile (goodput, en anglais, pour le différencier du débit brut, le throughput, cf. section 2.5 du RFC 7928, et le RFC 5166). Pour connaitre ce débit utile, il faut pouvoir reconnaitre les retransmissions (si un paquet est émis trois fois avant enfin d'atteindre le destinataire, il ne contribue qu'une fois au débit utile). Une retransmission peut se voir en observant les numéros de séquence en TCP (ou dans d'autres protocoles comme RTP).
La couche Transport peut aussi nous dire quelle est la latence. Cette information est cruciale pour évaluer la qualité des sessions interactives, par exemple. Et elle influe beaucoup sur les calculs du protocole de couche 4. (Voir l'article « Internet Latency: A Survey of Techniques and their Merits ».) Comment mesure-t-on la latence ? Le plus simple est de regarder les accusés de réception TCP et d'en déduire le RTT. Cela impose d'avoir accès aux numéros de séquence. Dans TCP, ils sont en clair, mais QUIC les chiffre (d'où l'ajout du spin bit).
D'autres métriques sont accessibles à un observateur qui regarde la couche Transport. C'est le cas de la gigue, qui se déduit des observations de la latence, ou du réordonnancement des paquets (un paquet qui part après un autre, mais arrive avant). L'interprétation de toutes ces mesures dépend évidemment du type de lien. Un lien radio (RFC 8462) a un comportement différent d'un lien filaire (par exemple, une perte de paquets n'est pas forcément due à la congestion, elle peut venir de parasites).
Le RFC note que la couche Réseau, que les équipements intermédiaires ont tout à fait le droit de lire, c'est son rôle, porte parfois des informations qui peuvent être utiles. En IPv4, ce sont les options dans l'en-tête (malheureusement souvent jetées par des pare-feux trop fascistes, cf. RFC 7126), en IPv6, les options sont après l'en-tête de réseau, et une option, Hop-by-hop option est explicitement prévue pour être examinée par tous les routeurs intermédiaires.
Outre les statistiques, l'analyse des données de la couche Transport peut aussi servir pour les opérations (voir aussi le RFC 8517), pour localiser un problème, pour planifier l'avitaillement de nouvelles ressources réseau, pour vérifier qu'il n'y a pas de tricheurs qui essaient de grapiller une part plus importante de la capacité, au risque d'aggraver la congestion (RFC 2914). En effet, le bon fonctionnement de l'Internet dépend de chaque machine terminale. En cas de perte de paquets, signal probable de congestion, les machines terminales sont censées réémettre les paquets avec prudence, puisque les ressources réseau sont partagées. Mais une machine égoïste pourrait avoir plus que sa part de la capacité. Il peut donc être utile de surveiller ce qui se passe, afin d'attraper d'éventuels tricheurs, par exemple une mise en œuvre de TCP qui ne suivrait pas les règles habituelles. (Si on utilise UDP, l'application doit faire cela elle-même, cf. RFC 8085. Ainsi, pour RTP, comme pour TCP, un observateur extérieur peut savoir si les machines se comportent normalement ou bien essaient de tricher.)
Autre utilisation de l'observation de la couche Transport pour l'opérationnel, la sécurité, par exemple la lutte contre les attaques par déni de service, l'IDS et autres fonctions. Le RFC note que cela peut se faire en coopération avec les machines terminales, si c'est fait dans l'intérêt de l'utilisateur. Puisqu'on parle de machines terminales, puisque le chiffrement d'une partie de la couche Transport est susceptible d'affecter toutes les activités citées plus haut, le RFC rappelle la solution évidente : demander la coopération des machines terminales. Il y a en effet deux cas : soit les activités d'observation de la couche Transport sont dans l'intérêt des utilisateurs, et faites avec leur consentement, et dans ce cas la machine de l'utilisateur peut certainement coopérer, soit ces activités se font contre l'utilisateur (discrimination contre une application qu'il utilise, par exemple), et dans ce cas le chiffrement est une réponse logique à cette attaque. Bien sûr, c'est la théorie ; en pratique, certaines applications ne fournissent guère d'informations et de moyens de débogage. Les protocoles de transport qui chiffrent une bonne partie de leur fonctionnement peuvent aussi aider, en exposant délibérement des informations. C'est par exemple ce que fait QUIC avec son spin bit déjà cité, ou avec ses invariants documentés dans le RFC 8999.
Autre cas où le chiffrement de la couche Transport peut interférer avec certains usages, les réseaux d'objets contraints, disposant de peu de ressources (faible processeur, batterie qu'il ne faut pas vider trop vite, etc). Il arrive dans ce cas d'utiliser des relais qui interceptent la communication, bricolent dans la couche Transport puis retransmettent les données. Un exemple d'un tel bricolage est la compression des en-têtes, courante sur les liens à très faible capacité (cf. RFC 2507, RFC 2508, le ROHC du RFC 5795, RFC 6846, le SCHC du RFC 8724, etc). Le chiffrement rend évidemment cela difficile, les relais n'ayant plus accès à l'information. C'est par exemple pour cela que le RTP sécurisé du RFC 3711 authentifie l'en-tête mais ne le chiffre pas. (Je suis un peu sceptique sur cet argument : d'une part, les objets contraints ne vont pas forcément utiliser des protocoles de transport chiffrés, qui peuvent être coûteux, d'autre part un sous-produit du chiffrement est souvent la compression, ce qui rend inutile le travail des relais.)
Un dernier cas cité par le RFC où l'observation du fonctionnement de la couche Transport par les machines intermédiaires est utile est celui de la vérification de SLA. Si un contrat ou un texte légal prévoit certaines caractéristiques pour le réseau, l'observation de la couche 4 (retransmission, RTT…) est un moyen d'observer sans avoir besoin d'impliquer les machines terminales. (Personnellement, je pense justement que ces vérifications devraient plutôt se faire depuis les machines terminales, par exemple avec les sondes RIPE Atlas, les SamKnows, etc.)
La section 3 du RFC décrit un autre secteur qui est intéressé par l'accès aux données de transport, la recherche. Par exemple, concevoir de nouveaux protocoles doit s'appuyer sur des mesures faites sur les protocoles existants, pour comprendre leurs forces et leurs faiblesses. C'est possible avec un protocole comme TCP, où l'observation passive permet, via notamment les numéros de séquence, de découvrir le RTT et le taux de perte de paquets. (Passive : sans injecter de paquets dans le réseau. Voir le RFC 7799.) Mais ces mêmes informations peuvent aussi servir contre l'utilisateur. Même s'il n'y a pas d'intention néfaste (par exemple de discrimination contre certains usages), toute information qui est exposée peut conduire à l'ossification, l'impossibilité de changer le protocole dans le futur. Une des motivations des protocoles chiffrés comme QUIC est en effet d'éviter l'ossification : une middlebox ne pourra pas prendre de décisions sur la base d'informations qu'elle n'a pas. QUIC affiche des données au réseau seulement s'il le veut (c'est le cas du spin bit). D'où également le choix délibéré de graisser, c'est-à-dire de faire varier certaines informations pour éviter que des programmeurs de middleboxes incompétents et/ou paresseux n'en déduisent que cette information ne change jamais (le graissage est décrit dans le RFC 8701).
La bonne solution pour récolter des données sans sacrifier la vie
privée est, comme dit plus haut, de faire participer les extrémités,
les machines terminales, ce qu'on nomme en anglais le
endpoint-based logging. Actuellement,
malheureusement, les mécanismes de débogage ou de récolte
d'information sur ces machines terminales sont trop réduits, mais
des efforts sont en cours. Par exemple, pour QUIC, c'est la
normalisation du format « qlog » d'enregistrement des informations
vues par la couche Transport
(Internet-Draft
draft-ietf-quic-qlog-main-schem
)
ou bien le format Quic-Trace. Mais
le RFC note que la participation des machines terminales ne suffit
pas toujours, notamment si on veut déterminer
où, dans le réseau, se produit un problème.
Après qu'on ait vu les utilisations qui sont faites de l'analyse de la couche Trnsport par les équipements intermédiaires, la section 4 du RFC revient ensuite sur les motivations du chiffrement de cette couche. Pourquoi ne pas se contenter de ce que font TLS et SSH, qui chiffrent uniquement la couche Application ? L'une des premières raisons est d'empêcher l'ossification, ce phénomène qui fait qu'on ne peut plus faire évoluer la couche Transport car de stupides équipements intermédiaires, programmés avec les pieds par des ignorants qui ne lisent pas les RFC, rejettent les paquets légaux mais qui ne correspondent pas à ce que ces équipements attendaient. Ainsi, si un protocole de transport permet l'utilisation d'un octet dans l'en-tête, mais que cet octet est à zéro la plupart du temps, on risque de voir des middleboxes qui jettent les paquets où certains bits de ce champ sont à un car « ce n'est pas normal ». Tout ce qui est observable risque de devenir ossifié, ne pouvant plus être modifié par la suite. Chiffrer permet de garantir que les équipements intermédiaires ne vont pas regarder ce qui ne les regarde pas. Le RFC donne plusieurs exemples édifiants des incroyables comportements de ces logiciels écrits par des gens qui ne comprenaient qu'une partie d'un protocole :
Il n'est donc pas étonnant que les concepteurs de protocole cherchent désormais à chiffrer au maximum, pour éviter ces interférences. Le RFC 8546 rappelle ainsi que c'est la vue depuis le réseau (wire image), c'est-à-dire ce que les équipements intermédiaires peuvent observer, pas la spécification écrite du protocole, qui détermine, dans le monde réel, ce qu'un intermédiaire peut observer et modifier. Il faut donc réduire cette vue au strict minimum ; tout ce qui n'est pas chiffré risque fortement d'être ossifié, figé. Et le RFC 8558 affirme lui qu'on ne doit montrer au réseau que ce qui doit être utilisé par le réseau, le reste, qui ne le regarde pas, doit être dissimulé.
Une autre motivation du chiffrement de la couche Transport est évidemment de mieux protéger la vie privée (RFC 6973). L'ampleur de la surveillance massive (RFC 7624) est telle qu'il est crucial de gêner cette surveillance le plus possible. Le RFC note qu'il n'y a pas que la surveillance passive, il y a aussi l'ajout de données dans le trafic, pour faciliter la surveillance. Du fait de cet « enrichissement », il peut être utile, quand un champ doit être observable (l'adresse IP de destination est un bon exemple), d'utiliser quand même la cryptographie pour empêcher ses modifications, via un mécanisme d'authentification. C'est ce que fait TCP-AO (RFC 5925, mais qui semble peu déployé), et bien sûr le service AH d'IPsec (RFC 4302).
Comme on le voit, il y a une tension, voire une lutte, entre les opérateurs réseau et les utilisateurs. On pourrait se dire que c'est dommage, qu'il vaudrait mieux que tout le monde travaille ensemble. Cela a été discuté à l'IETF, avec des expressions comme « un traité de paix entre machines terminales et boitiers intermédiaires ». Pour l'instant, cela n'a pas débouché sur des résultats concrets, en partie parce qu'il n'existe pas d'organisations représentatives qui pourraient négocier, signer et faire respecter un tel traité de paix. On en reste donc aux mesures unilatérales. Les machines terminales doivent chiffrer de plus en plus pour maintenir le principe de bout en bout. Comme dans tout conflit, il y a des dégâts collatéraux (le RFC 8922 en décrit certains). Le problème n'étant pas technique mais politique, il est probable qu'il va encore durer. La tendance va donc rester à chiffrer de plus en plus de choses.
À noter qu'une autre méthode que le chiffrement existe pour taper sur les doigts des boitiers intermédiaires pénibles, qui se mêlent de ce qui ne les regarde pas, et s'en mêlent mal : c'est le graissage. Son principe est d'utiliser délibérément toutes les options possibles du protocole, pour habituer les middleboxes à voir ces variations. Le RFC 8701 en donne un exemple, pour le cas de TLS.
Déterminer ce qu'il faut chiffrer, ce qu'il faut authentifier, et ce qu'il vaut mieux laisser sans protection, autorisant l'observation et les modifications, n'est pas une tâche facile. Autrefois, tout était exposé parce qu'on avait moins de problèmes avec les boitiers intermédiaires et que les solutions, comme le chiffrement, semblaient trop lourdes. Aujourd'hui qu'on a des solutions réalistes, on doit donc choisir ce qu'on montre ou pas. Le choix est donc désormais explicite (cf. RFC 8558).
Au passage, une façon possible d'exposer des informations qui peuvent être utiles aux engins intermédiaires est via un en-tête d'extension. Par exemple en IPv6, l'en-tête Hop-by-hop (RFC 8200, section 4.3) est justement fait pour cela (voir un exemple dans le RFC 8250, quoiqu'avec un autre type d'en-tête). Toutefois, cet en-tête Hop-by-hop est clairement un échec : beaucoup de routeurs jettent les paquets qui le portent (RFC 7872), ou bien les traitent plus lentement que les paquets sans cette information. C'est encore pire si cet en-tête porte des nouvelles options, inconnues de certaines middleboxes, et c'est pour cela que le RFC 8200 déconseille (dans sa section 4.8) la création de nouvelles options Hop-by-hop.
Mais, bon, le plus important est de décider quoi montrer, pas juste comment. Le RFC rappelle qu'il serait sympa d'exposer explicitement des informations comme le RTT ou le taux de pertes vu par les machines terminales, plutôt que de laisser les machines intermédiaires le calculer (ce qu'elles ne peuvent de toute façon plus faire en cas de chiffrement). Cela permettrait de découpler l'information de haut niveau des détails du format d'un protocole de transport. Pourquoi une machine terminale ferait-elle cela, au risque d'exposer des informations qu'on peut considérer comme privées ? Le RFC cite la possibilité d'obtenir un meilleur service, sans trop préciser s'il s'agit de laisser les opérateurs offrir un traitement préférentiel aux paquets portant cette information, ou bien si c'est dans l'espoir que l'information exposée serve à l'opérateur pour améliorer son réseau. (Comme le note le RFC 8558, il y a aussi le risque que la machine terminale mente au réseau. Au moins, avec le chiffrement, les choses sont claires : « je refuse de donner cette information » est honnête.)
Dernière note, cet ajout d'informations utiles pour l'OAM peut être faite par la machine terminale mais aussi (section 6 du RFC) par certains équipements intermédiaires.
En conclusion ? La section 7 du RFC reprend et résume les points importants :
Date de publication du RFC : Juillet 2021
Auteur(s) du RFC : R. Moskowitz (HTT Consulting), M. Komu (Ericsson)
Pour information
Réalisé dans le cadre du groupe de travail IETF hip
Première rédaction de cet article le 15 juillet 2021
Ce RFC propose d'aborder l'architecture de l'Internet en utilisant un nouveau type d'identificateur, le Host Identifier (HI), pour beaucoup d'usages qui sont actuellement ceux des adresses IP. Il remplace le RFC 4423, qui était la description originale du protocole HIP, mais il n'y a pas de changements fondamentaux. HIP était un projet très ambitieux mais, malgré ses qualités, la disponibilité de plusieurs mises en œuvre, et des années d'expérimentation, il n'a pas percé.
Une adresse IP sert actuellement à deux choses : désigner une machine (l'adresse IP sert par exemple à distinguer plusieurs connexions en cours) et indiquer comment la joindre (routabilité). Dans le premier rôle, il est souhaitable que l'adresse soit relativement permanente, y compris en cas de changement de FAI ou de mobilité (actuellement, si une machine se déplace et change d'adresse IP, les connexions TCP en cours sont cassées). Dans le second cas, on souhaite au contraire une adresse qui soit le plus « physique » possible, le plus dépendante de la topologie. Ces deux demandes sont contradictoires.
HIP résout le problème en séparant les deux fonctions. Avec HIP, l'adresse IP ne serait plus qu'un identifiant « technique », ne servant qu'à joindre la machine, largement invisible à l'utilisateur et aux applications (un peu comme une adresse MAC aujourd'hui). Chaque machine aurait un HI (Host Identifier) unique. Contrairement aux adresses IP, il n'y a qu'un HI par machine multi-homée mais on peut avoir plusieurs HI pour une machine si cela correspond à des usages différents, par exemple une identité publique, et une « anonyme ».
Pour pouvoir être vérifié, le nouvel identificateur, le HI sera (dans la plupart des cas) une clé publique cryptographique, qui sera peut-être allouée hiérarchiquement par PKI ou plutôt de manière répartie par tirage au sort (comme le sont les clés SSH ou PGP aujourd'hui, ce qui serait préférable, question vie privée). Ces identificateurs fondés sur la cryptographie permettent l'authentification réciproque des machines (contrairement à IP, où il est trivial de mentir sur son adresse), et d'utiliser ensuite IPsec (RFC 7402) pour chiffrer la communication (HIP n'impose pas IPsec, plusieurs encapsulations des données sont possibles, et négociées dynamiquement, mais, en pratique, la plupart des usages prévus reposent sur IPsec).
L'authentification permet d'être sûr du HI de la machine avec qui on parle et, si le HI était connu préalablement à partir d'une source de confiance, d'être sûr qu'on parle bien à l'interlocuteur souhaité. (Si on ne connait pas le HI à l'avance, on dit que HIP est en mode « opportuniste ».)
Cette séparation de l'identificateur et du localisateur est un sujet de recherche commun et d'autres propositions que HIP existent, comme LISP (RFC 9300) ou ILNP (RFC 6740). Dans tous les cas, les couches supérieures (comme TCP) ne verront que l'identificateur, permettant au localisateur de changer sans casser les sessions de transport en cours. (Un mécanisme ressemblant est le Back to My Mac du RFC 6281.) L'annexe A.1 de notre RFC rappelle les avantages de cette approche. Et l'annexe A.2, lecture très recommandée, note également ses défauts, l'indirection supplémentaire ajoutée n'est pas gratuite, et entraine des nouveaux problèmes. Notamment, il faut créer un système de correspondance - mapping - entre les deux, système qui complexifie le projet. Il y a aussi la latence supplémentaire due au protocole d'échange initial, qui est plus riche. Comparez cette honnêteté avec les propositions plus ou moins pipeau de « refaire l'Internet en partant de zéro », qui ne listent jamais les limites et les problèmes de leurs solutions miracle.
Ce HI (Host Identifier) pourra être stocké dans des annuaires publics, comme le DNS (RFC 8005), ou une DHT (RFC 6537), pour permettre le rendez-vous (RFC 8004) entre les machines.
Notez que ce n'est pas directement le Host Identifier, qui peut être très long, qui sera utilisé dans les paquets IP, mais un condensat, le HIT (Host Identity Tag).
HIP intègre les leçons de l'expérience avec IP, notamment de l'importance d'authentifier la machine avec qui on parle. C'est ce qui est fait dans l'échange initial qui permet à un initiateur et un répondeur de se mettre à communiquer. Notamment, il y a obligation de résoudre un puzzle cryptographique, pour rendre plus difficile certaines attaques par déni de service. Voir à ce sujet « DOS-Resistant Authentication with Client Puzzles » de Tuomas Aura, Pekka Nikander et Jussipekka Leiwo, « Deamplification of DoS Attacks via Puzzles » de Jacob Beal et Tim Shepard ou encore « Examining the DOS Resistance of HIP » de Tritilanunt, Suratose, Boyd, Colin A., Foo, Ernest, et Nieto, Juan Gonzalez.
La sécurité est un aspect important de HIP. Les points à garder en tête sont :
Au sujet du TOFU, le RFC cite « Leap-of-faith security is enough for IP mobility » de Miika Kari Tapio Komu et Janne Lindqvist, « Security Analysis of Leap-of-Faith Protocols » de Viet Pham et Tuomas Aura et « Enterprise Network Packet Filtering for Mobile Cryptographic Identities » de Janne Lindqvist, Essi Vehmersalo, Miika Komu et Jukka Manner.
Notre RFC ne décrit qu'une architecture générale, il est complété par les RFC 7401, qui décrit le protocole, RFC 7402, RFC 8003, RFC 8004, RFC 8005, RFC 8046 et RFC 5207. Si des implémentations expérimentales existent déjà et que des serveurs publics utilisent HIP, aucun déploiement significatif n'a eu lieu (cf. l'article « Adoption barriers of network layer protocols: The case of host identity protocol de T. Leva, M. Komu, A. Keranen et S. Luukkainen). Comme le disait un des relecteurs du RFC, « There's a lot of valuable protocol design and deployment experience packed into this architecture and the associated protocol RFCs. At the same time, actual adoption and deployment of HIP so far appears to have been scarce. I don't find this surprising. The existing Internet network/transport/application protocol stack has already become sufficiently complicated that considerable expertise is required to manage it in all but the simplest of cases. Teams of skilled engineers routinely spend hours or days troubleshooting operational problems that crop up within or between the existing layers, and the collection of extensions, workarounds, identifiers, knobs, and failure cases continues to grow. Adding a major new layer--and a fairly complicated one at that--right in the middle of the existing stack seems likely to explode the already heavily-strained operational complexity budget of production deployments. ». L'annexe A.3 décrit les questions pratiques liées au déploiement. Elle rappelle le compte-rendu d'expérience chez Boeing de Richard Paine dans son livre « Beyond HIP: The End to Hacking As We Know It ». Elle tord le cou à certaines légendes répandues (que HIP ne fonctionne pas à travers les routeurs NAT, ou bien qu'il faut le mettre en œuvre uniquement dans le noyau.)
Ah, question implémentations (RFC 6538), on a au moins HIP for Linux et OpenHIP qui ont été adaptés aux dernières versions de HIP, et des protocoles associés.
Les changements depuis le RFC 4423 sont résumés en section 14. Il n'y en a pas beaucoup, à part l'intégration de l'expérience, acquise dans les treize dernières années (et résumée dans le RFC 6538) et des améliorations du texte. La nouvelle annexe A rassemble plein d'informations concrètes, notamment que les questions pratiques de déploiement de HIP, et sa lecture est très recommandée à tous ceux et toutes celles qui s'intéressent à la conception de protocoles. La question de l'agilité cryptographique (RFC 7696) a également été détaillée.
Première rédaction de cet article le 4 juillet 2021
Dernière mise à jour le 7 octobre 2022
C'est dimanche, il ne fait pas beau, pas question de pique-nique, on va donc faire un peu de JSON. Un des problèmes les plus courants avec les noms de domaine est l'expiration accidentelle du nom. « Nous avons oublié de le renouveler » et paf plus rien ne marche. Pourtant, la date à laquelle le domaine expire est publiquement annoncée, via des protocoles comme whois ou RDAP. Comment utiliser RDAP pour récupérer cette date dans un programme, par exemple un programme d'alerte qui préviendra si l'expiration approche ?
Un peu de contexte d'abord ; un certain nombre (mais pas tous) de
registres de noms de domaine exigent un renouvellement
périodique du nom, avec paiement et parfois acceptation de
nouvelles conditions. L'oubli de ce renouvellement est un gag très
fréquent. On ne paie pas, et, à la date d'expiration, le domaine
disparait ou bien est mis en attente, plus publié dans le DNS, ce qui fait que tous les
services associés cessent de fonctionner. Dans le premier cas, le
pire, le domaine a été supprimé, et un autre peut l'enregistrer
rapidement. Il est donc crucial de ne pas laisser le domaine
expirer. Un des outils indispensables quand on gère un domaine
important est donc une supervision
automatique de l'approche de l'expiration. L'information est
diffusée par le registre, via plusieurs protocoles. Le traditionnel
whois, normalisé dans le RFC 3912 a plusieurs inconvénients notamment le fait que le
format de sortie n'est pas normalisé. Il est donc difficile d'écrire
un programme qui analyse l'information retournée (il existe quand
même des solutions comme, en Perl, Net::DRI). Au
contraire, le plus moderne RDAP a un format
de sortie normalisé (dans le RFC 9083). Utilisons-le, en prenant comme exemple le domaine
de ce blog, bortzmeyer.org
.
RDAP utilise HTTPS et produit du JSON (RFC 8259). D'autre part, pour interroger le bon serveur RDAP
(celui du registre), il faut connaitre son nom, ce qui se trouve
dans un registre
IANA qui associe le TLD à son serveur RDAP. On apprend ainsi que les
informations concernant
.org
sont à demander à
https://rdap.publicinterestregistry.org/rdap/
. Utilisant
le RFC 9082 pour former une requête RDAP
correcte, on va utiliser curl
pour poser la question sur bortzmeyer.org
:
% curl -s https://rdap.publicinterestregistry.org/rdap/domain/bortzmeyer.org
On récupère un gros JSON compliqué, que je ne vous montre pas ici. On veut juste la date d'expiration du domaine. On va se servir pour cela de l'excellent outil jq :
% curl -s https://rdap.publicinterestregistry.org/rdap/domain/bortzmeyer.org | \ jq '.events | map(select(.eventAction == "expiration"))[0] | .eventDate' "2021-08-29T09:32:04.304Z"
OK, j'ai triché, ça m'a pris plus de quelques secondes pour écrire le programme jq qui extrait cette information, et j'ai dû vérifier dans le RFC 9083. Expliquons donc.
Partons du haut de l'objet JSON retourné. Il contient un membre
nommé events
(RFC 9083,
section 4.5) qui indique les évènements passés ou futurs pertinents,
comme la création du domaine ou comme sa future expiration. On doit
donc commencer par demander au programme jq de filtrer sur ce
membre, d'où le .events
au début. Ensuite, on
veut ne garder, parmi les évènements, que l'expiration. On applique
donc (map
) un test (.eventAction ==
"expiration"
) à chaque élement du tableau
events
et on ne garde
(select
) que celui qui nous intéresse. Oui,
« celui » et pas « ceux » car il n'y a normalement qu'un évènement
d'expiration, donc on ne garde que le premier élement
([0]
) du tableau produit. Ce premier élément,
comme tous ceux qui composent le tableau events
est un évènement (RFC 9083, section 4.5), un
objet qui a ici deux membres, eventAction
, son
type (celui sur lequel on filtre, avec .eventAction ==
"expiration"
et eventDate
,
l'information qu'on recherche. On termine donc par un filtre du seul
eventDate
, date qui est au format du RFC 3339. Et voilà. On peut ensuite traiter cette
date comme on veut. Par exemple, le programme GNU date peut vous
traduire cette date en secondes écoulées depuis l'epoch :
% date --date=$(curl -s https://rdap.publicinterestregistry.org/rdap/domain/bortzmeyer.org | \ jq -r '.events | map(select(.eventAction== "expiration"))[0] | .eventDate') \ +%s 1630229524
Abandonnons maintenant curl et jq pour un programme écrit en Python. On utilise la bibliothèque Requests pour faire du HTTPS et les bibliothèques standard incluses dans Python pour faire du JSON, du calcul sur les dates, etc. Récupérer le JSON est simple :
response = requests.get("%s/%s" % (SERVER, domain)) if response.status_code != 200: raise Exception("Invalid RDAP return code: %s" % response.status_code)
Le transformer en un dictionnaire Python également :
rdap = json.loads(response.content)
On va ensuite y chercher la date d'expiration, qu'on transforme en une belle date-et-heure Python sur laquelle il sera facile de faire des calculs :
for event in rdap["events"]: if event["eventAction"] == "expiration": expiration = datetime.datetime.strptime(event["eventDate"], RFC3339) now = datetime.datetime.utcnow() rest = expiration-now
Et on peut ensuite mettre les traitements qu'on veut, ici prévenir si l'expiration approche :
if rest < CRITICAL: print("CRITICAL: domain %s expires in %s, HURRY UP!!!" % (domain, rest)) sys.exit(2) elif rest < WARNING: print("WARNING: domain %s expires in %s, renew now" % (domain, rest)) sys.exit(1) else: print("OK: domain %s expires in %s" % (domain, rest)) sys.exit(0)
Le code complet est disponible (il faut aussi ce module). Notez qu'il n'est pas
tellement robuste, il faudrait prévoir davantage de traitement
d'erreur. Python fait toutefois en sorte que la plupart des erreurs
soient détectées automatiquement (par exemple s'il n'existe pas de
membre events
dans le résultat) donc, au moins,
vous n'aurez pas de résultats erronés. Et puis, par rapport au
programme curl+jq plus haut, un grand avantage de ce programme
Python est qu'il utilise le registre IANA des serveurs (décrit dans le RFC 9224) et qu'il trouve donc tout seul le serveur
RDAP :
% ./expiration-rdap.py bortzmeyer.org OK: domain bortzmeyer.org expires in 55 days, 18:54:01.281920 % ./expiration-rdap.py quimper.bzh WARNING: domain quimper.bzh expires in 6 days, 18:17:25.919080, renew now
Une version plus élaborée de ce programme Python, utilisable depuis des logiciels de supervision automatique comme Nagios, Icinga ou Zabbix est disponible.
Notez qu'un tel outil n'est qu'un élément parmi tout ce qu'il faut faire pour bien gérer l'éventuelle expiration de votre domaine. Il faut aussi mettre les dates de renouvellement dans votre agenda, il est recommandé d'activer l'auto-renouvellement ou, mieux, chez les registres qui le permettent, de louer pour plusieurs années. Je vous recommande également la lecture du « Guide du Titulaire Afnic » ou des « Bonnes pratiques pour l'acquisition et l'exploitation de noms de domaine de l'ANSSI ».
Date de publication du RFC : Juin 2021
Auteur(s) du RFC : J. Arkko (Ericsson), C. Jennings (Cisco), Z. Shelby (ARM)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF core
Première rédaction de cet article le 1 juillet 2021
Voici un nouvel espace de noms pour des URN, dev
, afin de
stocker des identificateurs pour des équipements matériels, par
exemple pour les inventaires.
Les URN, un
sous-ensemble des URI, et des cousins des URL, sont normalisés
dans le RFC 8141. On peut placer des URN
partout où on peut mettre des URI, par exemple comme noms dans
SenML (RFC 8428). Pour
des objets contraints, les URN risquent d'être un peu longs par
rapport à, par exemple, une adresse IPv4,
mais ils sont plus souples. Un URN commence par le plan
urn:
, suivie d'un espace de noms. Ces espaces
sont stockés
dans un registre IANA. Ce nouveau RFC crée un nouvel espace de noms,
dev
. On pourra donc désormais avec des URN
comme urn:dev:os:32473-123456
(qui identifie la
machine 123456 de l'organisation 32473). Ces identificateurs de
machines pourront être utilisés toutes les fois où on a besoin de
désigner une machine, dans les données du RFC 8428, dans
des inventaires, etc.
Passons au concret maintenant, avec la section 3 du RFC, qui
donne la définition formelle de l'espace de noms
dev
. Ces URN sont évidemment conformes à la
norme des URN, le RFC 8141. Comme tous les
URN, ceux sous urn:dev:
ne sont pas prévus pour
être résolus automatiquement. Contrairement aux URL, ils ne
fournissent pas de moyen d'accès à une ressource. Bien sûr, si on
les met dans une base de données, d'inventaire de ses machines, par
exemple, on pourra retrouver l'information, mais ce RFC ne spécifie
aucun mécanisme de résolution standard (section 3.6 du RFC).
Après le urn:dev:
, ces URN prennent
un composant supplémentaire, qui identifie le type d'identificateur
dont dérive l'URN. Cela peut être :
mac
, où l'identificateur est une
adresse MAC, enregistrée
selon les procédures IEEE, au format
EUI-64. C'est par exemple
urn:dev:mac:acde48234567019f
(pour l'adresse MAC
ac:de:48:23:45:67:01:9f
). Si vous faites varier
l'adresse MAC, par exemple pour protéger votre vie privée, l'URN
n'est plus un identifiant stable.ow
, qui s'appuie sur
1-Wire, un système privateur.org
, avec des identificateurs
spécifiques à une organisation, identifiée par son PEN
(les PEN sont normalisés dans le RFC 2578). Les PEN sont enregistrés
à l'IANA. Prenons comme exemple celui d'une entreprise dont
j'étais un co-fondateur, 9319. Si cette entreprise utilise des
noms pour ses machines, la machine marx
aurait comme URN urn:dev:org:9319-marx
.os
, comme les org
mais plutôt prévus pour des numéros de série. Si cette entreprise
numérote toutes ses machines en partant de 1, un URN serait
urn:dev:os:9319-1
. (Notez que des versions
précédentes des URN dev
utilisaient
os
pour les identificateurs LwM2M.) Ainsi, le
RIPE-NCC qui a le PEN 15854 pourrait nommer
ses sondes Atlas
d'après leur numéro unique et donc la sonde 6593
pourrait être désignée par
urn:dev:os:15854-6593
. Notez qu'on pourrait
avoir ici une intéressante discussion sur l'intérêt respectif des
URN (urn:dev:os:15854-6593
) et des URL
(https://atlas.ripe.net/probes/6593/
).ops
, qui ressemble à
l'os
, mais avec un identificateur de produit
entre le PEN et le numéro de série, par exemple
urn:dev:ops:9319-coffeemachine-2
pour la
deuxième machine à café de
l'organisation. (Comme os
, il avait été
utilisé pour l'Open Mobile
Alliance.)example
pour des exemples, comme
urn:dev:example:1234
.
Enfin, une machine identifiée par un de ces URN peut avoir une
partie particulière de la machine désignée par une chaine de
caractères après un tiret bas. Ainsi,
urn:dev:os:9319-1_alimentation
serait
l'alimentation de la machine
urn:dev:os:9319-1
.
Notez que l'équivalence de deux URN est sensible à la casse donc attention, par exemple, à la façon dont vous écrivez les adresses MAC. Le RFC recommande de tout mettre en minuscules.
Idéalement, on veut bien sûr qu'un URN dev
identifie une machine et une seule. Mais, en pratique, cela peut
dépendre du type d'identificateurs utilisé. Ainsi, les adresses MAC
ne sont pas forcément uniques, entre autres parce que certains
fabricants ont déjà réutilisé des adresses.
Petit avertissement sur la vie privée : les identificateurs décrits dans ce RFC sont prévus pour être très stables sur le long terme (évidemment, puisque leur but est de garder trace d'une machine) et leur utilisation imprudente (par exemple si on envoie un de ces URN avec les données d'un utilisateur anonyme) peut permettre une surveillance accrue (sections 3.4 et 6.1 du RFC). Le RFC 7721 détaille les risques de ces identificateurs à longue durée de vie.
Le RFC note (section 1) qu'il existe d'autres catégories
d'identificateurs qui, selon le cas, pourraient concurrencer nos URN
de l'espace de noms dev
. C'est le cas par
exemple des condensats du RFC 6920, des
IMEI du RFC 7254, des
MEID du RFC 8464 et
bien sûr des UUID du RFC 9562. Tous peuvent se
représenter sous forme d'URI, et parfois d'URN. Ils ont leurs
avantages et leurs inconvénients, le choix est vaste.
Pour les gens qui utiisent le SGBD
PostgreSQL, notez qu'il n'a pas de type de
données « URI » donc, si on veut stocker les URN de
notre RFC dans PostgreSQL, il faut utiliser le type
TEXT
, ou bien installer une extension comme
pguri. Selon ce
qu'on veut faire de ces URN, on peut aussi prendre une solution plus
simple qui ne nécessite pas d'installer d'extension, ici pour une
organisation qui met toutes ces machines en
urn:dev:os:9319-…
:
CREATE DOMAIN urndev AS text CHECK (VALUE ~ '^urn:dev:os:9319-[0-9]+(_[a-z0-9]+)?$'); COMMENT ON DOMAIN urndev IS 'URN DEV (RFC 9039) for our devices'; CREATE TABLE Devices (id SERIAL, urn urndev UNIQUE NOT NULL, comments TEXT); INSERT INTO Devices (urn, comments) VALUES ('urn:dev:os:9319-2', 'No comment'); INSERT INTO Devices (urn) VALUES ('urn:dev:os:9319-1_alimentation'); INSERT INTO Devices (urn, comments) VALUES ('urn:dev:os:9319-666', 'Beast');
Première rédaction de cet article le 27 juin 2021
Dès qu'il s'agit de monnaie, on lit n'importe quoi dans les médias, et on entend n'importe quoi aux tribunes des colloques. Songeons par exemple à tous les gens qui ont péroré sur le Bitcoin ou sur les cryptomonnaies sans rien y connaitre. De même quand on parle de « monnaie numérique de banque centrale », la confusion règne. Notons donc un excellent article d'analyse écrit pour la banque centrale suisse (mais qui n'exprime pas la politique officielle de cette institution) expliquant à quoi pourrait ressembler une MNBC (monnaie numérique de banque centrale) et proposant une solution spécifique.
Lorsqu'on parle de « monnaie électronique » (ou numérique), la confusion règne. Parfois, le terme désigne toute monnaie qui n'est pas en pièces ou en billets (à ce compte, toutes les monnaies sont électroniques depuis longtemps). Parfois, on ne le dit que pour les cryptomonnaies ou que pour celles qui tournent sur une chaine de blocs. Ici, on va utiliser le terme pour une monnaie qui a certaines propriétés de l'argent liquide (notamment une certaine protection de la vie privée) tout en étant entièrement numérique. Ainsi, la carte Visa n'entre pas dans cette définition, car elle n'offre aucune vie privée.
L'article dont je parlais au début est « Comment émettre une monnaie numérique de banque centrale ». Oui, l'avantage des études faites pour un organisme officiel suisse, c'est qu'il y a une traduction de qualité en français. Ses auteurs sont David Chaum (celui de DigiCash), Christian Grothoff (celui de GNUnet) et Thomas Moser, des gens qui connaissent leur sujet, donc.
Pour résumer leur article (mais je vous en recommande la lecture complète), leur cahier des charges est celui d'une monnaie émise et gérée par une banque centrale (un cahier des charges, donc, très différent de celui du Bitcoin, qui vise à se passer de banque centrale), garantissant un minimum d'anonymat pour ceux qui paient avec cette monnaie (« la préservation d’une propriété clé de la monnaie physique: la confidentialité des transactions »), mais pas pour ceux qui la reçoivent. Les revenus des commerçants ne sont donc pas dissimulés, ce qui permet de lutter contre la fraude fiscale. La définition même de monnaie ne fait pas consensus mais les auteurs se focalisent sur un rôle, le moyen d'échange (il y en a d'autres rôles à la monnaie, par exemple unité de mesure ou stockage de valeur). De plus, les auteurs veulent appliquer les principes de KYC (connaissance du client), d'AML (lutte contre le blanchiment) et de CFT (lutte contre le financement du terrorisme), oui, il y en a, des sigles, dans le secteur bancaire. On voit que les objectifs mis en avant sont distincts de ceux de Bitcoin et, a fortiori, de Zcash puisque que, comme le note l'article, « La détection de fraude requiert cependant une capacité d’identification du payeur et le traçage des clients, ce qui est incompatible avec le respect de la confidentialité de la transaction. ». Le fait d'avoir un cahier des charges clair est un des intérêts de cette étude. Par exemple, d'innombrables articles ont été écrits sur des projets comme Diem ou le « yuan électronique » alors que leur cahier des charges reste vague. Le problème est d'autant plus grave qu'il y a souvent de la mauvaise foi dans certains discours. Ainsi, les projets de numérisation ont souvent pour but réel d'en finir avec l'argent liquide pour avoir une traçabilité complète des transactions et une surveillance permanente des acheteurs.
Comment les auteurs de l'article voient-ils leur système de MNBC (monnaie numérique de banque centrale) ? Étant donné qu'il n'y a qu'un émetteur, nul besoin d'une chaine de blocs. (La quasi-totalité des projets de « chaine de blocs privée » ou de « chaine de blocs à permission » n'ont aucun sens : comme le dit l'article « La DLT est une architecture intéressante lorsqu’il n’existe pas d’acteur central ou si les parties prenantes ne souhaitent pas s’accorder sur un acteur central de confiance. Ce qui n’est cependant pratiquement jamais le cas pour une monnaie numérique de détail émise par une banque centrale. [...] Recourir à un registre distribué [réparti, plutôt] ne fait qu’augmenter les coûts de transaction; cela n’apporte aucun avantage dans une mise en place par une banque centrale »). Leur système repose à la place sur GNU Taler (développé par un des auteurs) et les signatures en aveugle de Chaum. La sécurité du système dépend donc de ces techniques logicielles. (D'autres propositions font appel à des systèmes physiques spécifiques, mais « les fonctions physiques non clonables ne peuvent pas s’échanger sur Internet (éliminant de fait l’usage principal de la MNBC » et « les tentatives précédentes de verrous matériels pour empêcher la copie ont été compromises de façon répétée », voir les DRM.) Comme la monnaie numérique de banque centrale envisagée dans cet article a beaucoup de propriétés communes avec l'argent physique (le liquide), elle a également une sécurité proche : possession fait loi, ce qui veut dire que, si l'appareil sur lequel vous gardez vos pièces est détruit, vous perdez votre argent. Cette solution, comme l'argent liquide, n'est raisonnable que pour des sommes relativement faibles. Si l'acheteur n'est pas identifiable, le vendeur l'est car il ne peut pas réutiliser directement les « pièces », il doit les remettre à la banque. C'est nécessaire au mécanisme de protection contre la double dépense. Autre nécessité, la banque centrale doit être connectée en permanence, ce qui impose des exigences nouvelles pour les banques centrales (« La détection de doubles dépenses en ligne élimine ce risque mais rend donc les transactions impossibles si la connexion Internet de la banque centrale est indisponible. ») Je ne vous détaille pas les protocoles cryptographiques ici, je n'ai pas le niveau, lisez l'article. Notez qu'ils sont assez complexes, ce qui peut être un obstacle à l'adoption : la plupart des utilisateurs ne peuvent pas comprendre cette solution, ils devront faire confiance à la minorité qui a compris et vérifié. (Ceci dit, dès aujourd'hui, peu de gens comprennent le système monétaire.)
Quelles sont les chances qu'une banque centrale, avec ses messieurs sérieux en costume-cravate, reprenne cette idée et se lance dans un projet de monnaie numérique protégeant la vie privée ? Personnellement, je dirais qu'elles sont à peu près nulles. Les auteurs notent à juste titre que « une MNBC de détail devrait être basée sur un logiciel libre ou ouvert. Imposer une solution propriétaire qui entraînerait une dépendance à un fournisseur spécifique pourrait vraisemblablement constituer dès le départ un obstacle à son adoption. » Mais cette condition suffirait à faire rejeter le projet par toute banque centrale (déjà, le mot « libre »…). Tous ces dirigeants politiques et financiers passent du temps à critiquer le Bitcoin « qui permet la fraude fiscale et le financement du terrorisme » mais ils ne font aucun effort pour développer des alternatives. Le projet décrit dans cet article est sympathique mais n'a aucune chance. Il essaie de plaire aux banques centrales mais celles-ci n'en voudront jamais, attachées qu'elles sont à des solutions fermées, privatrices, et facilitant la surveillance.
Date de publication du RFC : Juin 2021
Auteur(s) du RFC : D. Crocker (Brandenburg InternetWorking)
Expérimental
Première rédaction de cet article le 23 juin 2021
Qui est l'auteur d'un message reçu par courrier
électronique ? La réponse semblait autrefois simple,
c'est forcément la personne ou l'organisation indiquée dans le champ
From:
. Sauf que des changements récents (et pas
forcément bien inspirés) dans le traitement des messages ont amené à
ce que le From:
soit parfois modifié, par
exemple par certaines listes de diffusion. Il
ne reflète donc plus le vrai auteur. D'où ce RFC qui crée un nouvel
en-tête, Author:
, qui identifie le vrai
émetteur.
La norme pertinente est le RFC 5322, qui
définit des en-têtes comme From:
(auteur d'un
message) ou Sender:
(personne ou entité qui n'a
pas écrit le message mais réalise l'envoi, par exemple parce que
l'auteur n'avait pas le temps, ou bien parce que le message a été
relayé par un intermédiaire). Les amateurs d'archéologie noteront
que le courrier électronique est très ancien,
plus ancien que l'Internet, cette ancienneté étant la preuve de son
efficacité et de sa robustesse. Le premier RFC avec la notion formelle d'auteur d'un
message était le RFC 733.
Une particularité du courrier électronique est que le message ne
va pas toujours directement de la machine de l'auteure à celle du
lecteur (cf. le RFC 5598, sur l'architecture
du courrier). Il y a souvent des intermédiaires
(mediators) comme les gestionnaires de
listes de diffusion, qui prennent un message
et le redistribuent aux abonnées. En raison du problème du
spam, plusieurs mécanismes de protection ont
été développés, qui peuvent poser des problèmes pour ces
intermédiaires. SPF (RFC 7208),
contrairement à une légende tenace, n'affecte pas les listes de
diffusion. (C'est en raison de la distinction entre enveloppe et
en-tête d'un message. Si vous entendez quelqu'un pontifier sur SPF
et la messagerie, et qu'il ne connait pas la différence entre
l'émetteur indiqué dans l'enveloppe et celui marqué dans l'en-tête,
vous pouvez être sûre que cette personne est ignorante.) En
revanche, DKIM (RFC 6376), surtout
combiné avec DMARC (RFC 7489), peut poser des problèmes dans certains cas (le
RFC 6377 les détaille). Pour gérer ces
problèmes, certaines listes de diffusion choisissent de carrément
changer le From:
du message et d'y mettre, par
exemple (ici tiré de l'utile liste
outages, informant des pannes Internet) :
From: Erik Sundberg via Outages <outages@outages.org>
Alors que le message avait en fait été écrit par « Erik Sundberg
<ESundberg@nitelusa.com>
». C'est une
mauvaise idée, mais elle est commune. Dans ce cas, la liste s'est
« approprié » le message et on a perdu le vrai auteur, privant ainsi
la lectrice d'une information utile (dans le cas de la liste
Outages, il a toutefois été préservé dans le
champ Reply-To:
). [Personnellement, il me semble
que l'idéal serait de ne pas modifier le message, préservant ainsi
les signatures DKIM, et donc les vérifications DMARC. Dans les cas
où le message est modifié, DMARC s'obstine à vérifier le
From:
et pas le Sender:
,
ce qui serait pourtant bien plus logique.]
Maintenant, la solution (section 3 du RFC) : un nouvel en-tête,
Author:
, dont la syntaxe est la même que celle
de From:
. Par exemple :
Author: Dave Crocker <dcrocker@bbiw.net>
Cet en-tête peut être mis au départ, par le MUA, ou bien ajouté par un intermédiaire
qui massacre le champ From:
mais veut garder
une trace de sa valeur originale en la recopiant dans le champ
Author:
. Cela n'est possible que s'il n'y a pas
déjà un champ Author:
. S'il existe, il est
strictement interdit de le modifier ou de le supprimer.
À la lecture, par le MUA de réception, le RFC conseille
d'utiliser le champ Author:
, s'il est présent,
plutôt que le From:
, pour afficher ou trier sur
le nom de l'expéditrice.
Comme dans le cas du champ From:
, un
malhonnête peut évidemment mettre n'importe quoi dans le champ
Author:
et il faut donc faire attention à ne
pas lui accorder une confiance aveugle.
Author:
a été ajouté au registre
des en-têtes.
On notera qu'une tentative précédente de préservation de
l'en-tête From:
original avait été faite dans
le RFC 5703, qui créait un
Original-From:
mais uniquement pour les
intermédiaires, pas pour les MUA.
Première rédaction de cet article le 18 juin 2021
Le protocole DNS permet d'attacher des métadonnées aux questions ou aux réponses par le biais de l'extension EDNS, normalisée dans le RFC 6891. Un certain nombre d'options sont déjà normalisées et peuvent être manipulées depuis un programme, via une bibliothèque DNS. Mais s'il s'agit d'une option EDNS nouvelle, pas encore traitée par la bibliothèque ?
On va voir cela avec l'option « RRSERIAL » actuellement en cours
de discussion à l'IETF, dans le
draft draft-ietf-dnsop-rrserial
. (Elle
a depuis été renommée ZONEVERSION et normalisée dans le RFC 9660, avec une syntaxe différente.)
Son
but est de récupérer le numéro de série de la zone correspondant à
une réponse. Elle est très simple, la valeur associée étant vide
dans la question, et uniquement un entier sur 32 bits dans la
réponse. Un serveur expérimental existe utilisant cette option,
200.1.122.30
.
Déjà, on peut tester sans programmer avec dig, et son option
+ednsopt
. Les options EDNS ont un code, enregistré
à l'IANA. RRSERIAL n'en a pas encore, donc le serveur de test
utilise le code temporaire 65024 :
% dig +ednsopt=65024 @200.1.122.30 dateserial.example.com ... ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; OPT=65024: 78 49 7a 79 ("xIzy")
Ça marche, on a obtenu une réponse. dig ne sait pas la formater
proprement (« xIzy » est la représentation de 78 49 7a 79 interprété
comme de l'ASCII, alors qu'il s'agit d'un entier, le nombre 2018081401), mais c'est déjà
ça. (Le draft précise que l'option RRSERIAL a une
valeur nulle dans la requête, seule sa présence compte. S'il avait
fallu donner une valeur, dig permet de le faire avec
+ednsopt=CODE:VALEUR
.) Donc, le serveur
fonctionne bien. Maintenant, on voudrait faire mieux et donc
utiliser un client DNS adapté (d'autant plus qu'il y a des cas à
traiter comme la réponse NXDOMAIN, où le numéro de série de la zone
est dans un enregistrement SOA, pas dans
l'option EDNS). On va donc programmer.
Commençons en Python avec la bibliothèque dnspython. On peut fabriquer
l'option dans la requête avec la classe
GenericOption
:
opts = [dns.edns.GenericOption(dns.edns.RRSERIAL, b'')] ... message = dns.message.make_query(qname, qtype, options=opts)
(Le b''
indique une valeur binaire vide.) Pour
lire l'option dans la réponse :
for opt in response.options: if opt.otype == dns.edns.RRSERIAL: print("Serial of the answer is %s" % struct.unpack(">I", opt.data)[0])
On a donc juste à convertir la valeur binaire en chaine (le
>I
signifie un entier
gros-boutien). Le code Python complet est en
.
test-rrserial.py
Pour Go, on va
utiliser la bibliothèque godns. Créer l'option et
l'ajouter à la requête DNS (m
dans le code) se
fait ainsi :
m.Question = make([]dns.Question, 1) // Tout pseudo-enregistrement EDNS a pour nom "." (la racine) o.Hdr.Name = "." o.Hdr.Rrtype = dns.TypeOPT o.SetUDPSize(4096) // Option EDNS générique e := new(dns.EDNS0_LOCAL) e.Code = otype // Requête vide e.Data = []byte{} o.Option = append(o.Option, e) // Extra est la section Additionnelle m.Extra = append(m.Extra, o)
Et pour lire le résultat :
opt := msg.IsEdns0() for _, v := range opt.Option { // Merci à Tom Thorogood pour le rappel qu'il faut forcer le type // et donc avoir une nouvelle variable v (le ':='). switch v := v.(type) { case *dns.EDNS0_LOCAL: if v.Option() == otype { serial := binary.BigEndian.Uint32(v.Data) fmt.Printf("EDNS rrserial found, \"%d\"\n", serial) ...
Le code Go complet est en
.
test-rrserial.go
Date de publication du RFC : Juin 2021
Auteur(s) du RFC : S. Hollenbeck (Verisign Labs), A. Newton (AWS)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 16 juin 2021
Dans l'ensemble des normes sur le protocole RDAP, ce RFC est destiné à décrire le format de sortie, celui des réponses envoyées par le serveur d'information RDAP. Ce format est basé sur JSON et, pour utiliser RDAP en remplacement de whois, il faudra donc se munir de quelques outils pour traiter le JSON. Ce RFC remplace le RFC 7483 mais il y a très peu de changements.
JSON est normalisé dans le RFC 8259 et représente aujourd'hui le format de choix pour les données structurées c'est-à-dire analysables par un programme. (L'annexe E de notre RFC explique en détail le pourquoi du choix de JSON.) Une des caractéristiques importantes de whois est en effet que son format de sortie n'a aucune structure, c'est du texte libre, ce qui est pénible pour les programmeurs qui essaient de le traiter (mais, d'un autre côté, cela ralentit certains usages déplorables, comme la récolte d'adresses de courrier à des fins de spam, jouant ainsi un rôle de semantic firewall). L'utilisation typique de RDAP est en HTTP (RFC 7480) avec les requêtes exprimées dans la syntaxe des URL du RFC 9082. Voici tout de suite un exemple réel, avec la réponse JSON :
% curl https://rdap.afilias.net/rdap/info/domain/kornog-computing.info ... { "entities": [ ... "objectClassName": "entity", "roles": [ "technical", "billing", "administrative" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "KORNOG computing" ], [ "adr", { "cc": "FR" }, "text", {} ] ... "events": [ { "eventAction": "registration", "eventDate": "2007-08-14T17:02:33Z" }, { "eventAction": "last changed", "eventDate": "2014-08-14T01:54:07Z" }, { "eventAction": "expiration", "eventDate": "2015-08-14T17:02:33Z" } ], "handle": "D19378523-LRMS", "lang": "en", "ldhName": "kornog-computing.info", ... "nameservers": [ { "ldhName": "ns1.kornog-computing.net", "objectClassName": "nameserver", "remarks": [ { "description": [ "Summary data only. For complete data, send a specific query for the object." ], "title": "Incomplete Data", "type": "object truncated due to unexplainable reasons" } ] }, { "ldhName": "ns2.kornog-computing.net", "objectClassName": "nameserver", "remarks": [ { "description": [ "Summary data only. For complete data, send a specific query for the object." ], "title": "Incomplete Data", "type": "object truncated due to unexplainable reasons" } ] } ], "notices": [ { "description": [ "Access to AFILIAS WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Afilias registry database. The data in this record is provided by Afilias Limited for informational purposes only, and Afilias does not guarantee its accuracy. [...]" ], "title": "TERMS OF USE" } ], "objectClassName": "domain", ... "rdapConformance": [ "rdap_level_0" ], "secureDNS": { "zoneSigned": false }, "status": [ "clientDeleteProhibited -- http://www.icann.org/epp#clientDeleteProhibited", "clientTransferProhibited -- http://www.icann.org/epp#clientTransferProhibited" ] }
La section 1.2 présente le modèle de données de RDAP. Dans les réponses, on trouve des types simples (comme des chaînes de caractères), des tableaux JSON, et des objets JSON qui décrivent les trucs sur lesquels on veut de l'information (noms de domaine, adresses IP, etc). Ces objets peuvent comporter des tableaux ou d'autres objets et, lorsqu'une réponse renvoie plusieurs objets (cas des recherches ouvertes, cf. RFC 9082, section 3.2), peuvent eux-même être regroupés en tableaux. Il existe plusieurs classes de ces objets. D'abord, les classes communes aux registres de noms de domaine et aux RIR (registres d'adresses IP) :
in-addr.arpa
et
ip6.arpa
),GR283-FRNIC
.Deux classes sont spécifiques aux RIR :
On verra peut-être apparaître d'autres classes avec le temps, si l'usage de RDAP se répand.
La section 2 de notre RFC décrit comment JSON est utilisé. Le
type MIME renvoyé est
application/rdap+json
. La section 2 commence
par un rappel que le client RDAP doit ignorer
les membres inconnus dans les objets JSON, afin de préserver la
future extensibilité. (Cette règle ne s'applique pas au jCard
- cf. RFC 7095 - embarqué.) Si un serveur veut
ajouter des membres qui lui sont spécifiques, il est recommandé
qu'il préfixe leur nom avec un identificateur court suivi d'un
tiret bas. Ainsi, cet objet
RDAP standard :
{ "handle" : "ABC123", "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ] }
S'il est servi par le « registre de la Lune » (registre imaginaire
qui fournit les exemples de ce RFC), celui-ci, lorsqu'il voudra
ajouter des membres, les précédera de
lunarNIC_
:
{ "handle" : "ABC123", "lunarNic_beforeOneSmallStep" : "TRUE THAT!", "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "lunarNic_harshMistressNotes" : [ "In space,", "nobody can hear you scream." ] }
(Je vous laisse décoder les références geeks dans l'exemple.)
La section 3 s'occupe des types de données de base. On utilise du
JSON normal, tel que spécifié dans le RFC 8259, avec ses chaînes de caractères, ses booléens, son
null
... Un handle
(l'identifiant unique - par registre - d'un contact, parfois nommé
NIC handle ou registry ID) est
une chaîne. Les adresses IP se représentent également par une chaîne
de caractères (ne pas oublier le RFC 5952 pour
IPv6). Les pays sont identifiés par le code à
deux lettres de ISO 3166. Les noms de
domaines peuvent être sous une forme ASCII ou bien en
Unicode. Les dates et heures suivent le RFC 3339, et les URI le RFC 3986.
Les informations plus complexes (comme les détails sur un contact) utilisent jCard, normalisé dans le RFC 7095.
Que trouve-t-on dans les objets JSON renvoyés par un serveur RDAP ? Une indication de la version de la norme :
"rdapConformance" : [ "rdap_level_0" ]
(Éventuellement avec d'autres identificateurs pour les extensions locales.) Et des liens vers des ressources situées ailleurs, suivant le cadre du RFC 8288 :
"links": [ { "href": "http://rdg.afilias.info/rdap/entity/ovh53ec16bekre5", "rel": "self", "type": "application/rdap+json", "value": "http://rdg.afilias.info/rdap/entity/ovh53ec16bekre5" }
On peut aussi avoir du texte libre, comme dans l'exemple plus haut
avec le membre remarks
. Ce membre sert aux
textes décrivant la classe, alors que notices
est utilisé pour le service RDAP. Un exemple :
"notices": [ { "description": [ "Access to AFILIAS WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Afilias registry database. The data in this record is provided by Afilias Limited for informational purposes only, and Afilias does not guarantee its accuracy. [...]" ], "title": "TERMS OF USE" } ],
Contrairement à whois, RDAP permet l'internationalisation sous tous ses aspects. Par exemple, on peut indiquer la langue des textes avec une étiquette de langue (RFC 5646) :
"lang": "en",
Enfin, la classe (le type) de l'objet renvoyé par RDAP est
indiquée par un membre objectClassName
:
"objectClassName": "domain",
Ces classes, justement. La section 5 les décrit. Il y a d'abord
la classe Entity
qui correspond aux requêtes
/entity
du RFC 9082. Elle
sert à décrire les personnes et les organisations. Parmi les membres
importants pour les objets de cette classe,
handle
qui est un identificateur de l'instance
de la classe, et roles
qui indique la relation
de cette instance avec l'objet qui la contient (par exemple
"roles": ["technical"]
indiquera que cette
Entity
est le contact technique de
l'objet). L'information de contact sur une
Entity
se fait avec le format
vCard du RFC 7095, dans
un membre vcardArray
. Voici un exemple avec le
titulaire du domaine uba.ar
:
% curl https://rdap.nic.ar/entity/30546666561 ... "objectClassName": "entity", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "UNIVERSIDAD DE BUENOS AIRES" ] ] ], ...
(jCard permet de mentionner plein d'autres choses qui ne sont a priori pas utiles pour RDAP, comme la date de naissance ou le genre.)
La classe Nameserver
correspond aux requêtes
/nameserver
du RFC 9082. Notez qu'un registre peut gérer les serveurs de noms
de deux façons : ils peuvent être vus comme des objets autonomes,
enregistrés tels quel dans le registre (par exemple via le RFC 5732), ayant des attributs par exemple des
contacts, et interrogeables directement par whois ou RDAP (c'est le
modèle de .com
, on dit
alors que les serveurs de noms sont des « objets de première
classe »). Ou bien ils peuvent être simplement des attributs des
domaines, accessibles via le domaine. Le principal attribut d'un
objet Nameserver
est son adresse IP, pour
pouvoir générer des colles dans le DNS (enregistrement DNS d'une
adresse IP, pour le cas où le serveur de noms est lui-même dans la
zone qu'il sert). Voici un exemple avec un des serveurs de noms de
la zone afilias-nst.info
:
% curl https://rdap.afilias.net/rdap/info/nameserver/b0.dig.afilias-nst.info ... "ipAddresses": { "v4": [ "65.22.7.1" ], "v6": [ "2a01:8840:7::1" ] }, ...
Notez que l'adresse IP est un tableau, un serveur pouvant avoir plusieurs adresses.
La classe Domain
correspond aux requêtes
/domain
du RFC 9082. Un
objet de cette classe a des membres indiquant les serveurs de noms,
si la zone est signée avec DNSSEC ou pas, l'enregistrement DS si elle est signée, le
statut (actif ou non, bloqué ou non), les contacts, etc. Voici un
exemple :
% curl http://rdg.afilias.info/rdap/domain/afilias-nst.info ... "nameservers": [ { "ldhName": "a0.dig.afilias-nst.info", ... "secureDNS": { "delegationSigned": false }, ... "status": [ "client transfer prohibited", "server delete prohibited", "server transfer prohibited", "server update prohibited" ], ...
La classe IP network
rassemble les objets
qu'on trouve dans les réponses aux requêtes /ip
du RFC 9082. Un objet de cette classe ne
désigne en général pas une seule adresse IP mais un préfixe, dont on
indique la première (startAddress
) et la
dernière adresse (endAddress
). Personnellement,
je trouve cela très laid et j'aurai préféré qu'on utilise une
notation préfixe/longueur. Voici un exemple :
% curl https://rdap.db.ripe.net/ip/131.111.150.25 ... { "handle" : "131.111.0.0 - 131.111.255.255", "startAddress" : "131.111.0.0/32", "endAddress" : "131.111.255.255/32", "ipVersion" : "v4", "name" : "CAM-AC-UK", "type" : "LEGACY", "country" : "GB", ...
La dernière classe normalisée à ce stade est
autnum
(les AS), en réponse aux requêtes
/autnum
du RFC 9082. Elle
indique notamment les contacts de l'AS. Pour l'instant, il n'y a pas
de format pour indiquer la politique de routage (RFC 4012). Un exemple d'un objet de cette classe :
% curl https://rdap.db.ripe.net/autnum/20766 { "handle" : "AS20766", "name" : "GITOYEN-MAIN-AS", "type" : "DIRECT ALLOCATION", ... "handle" : "GI1036-RIPE", "vcardArray" : [ "vcard", [ [ "version", { }, "text", "4.0" ], [ "fn", { }, "text", "NOC Gitoyen" ], [ "kind", { }, "text", "group" ], [ "adr", { "label" : "Gitoyen\n21 ter rue Voltaire\n75011 Paris\nFrance" }, "text", null ], [ "email", { }, "text", "noc@gitoyen.net" ] ] ], ...
Comme, dans la vie, il y a parfois des problèmes, une section de
notre RFC, la section 6, est dédiée aux formats des erreurs que
peuvent indiquer les serveurs RDAP. Le code de retour HTTP fournit
déjà des indications (404 = cet objet n'existe pas ici, 403 = vous
n'avez pas le droit de le savoir, etc) mais on peut aussi ajouter un
objet JSON pour en indiquer davantage, objet ayant un membre
errorCode
(qui reprend le code HTTP), un membre
title
et un membre
description
. Voici un exemple sur le serveur
RDAP de l'ARIN :
% curl -v http://rdap.arin.net/registry/autnum/99999 < HTTP/1.0 404 Not Found < Mon, 10 May 2021 09:07:52 GMT < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips ... { ... "errorCode" : 404, "title" : "AUTNUM NOT FOUND", "description" : [ "The autnum you are seeking as '99999' is/are not here." ]
Plus positive, la possibilité de demander de l'aide à un serveur
RDAP, en se renseignant sur ses capacités, avec la requête
/help
. Son résultat est décrit dans la section
7 mais tous les serveurs RDAP actuels n'utilisent pas
cette possibilité. En voici un où ça marche, à
l'ARIN :
% curl -s https://rdap.arin.net/registry/help { "rdapConformance" : [ "rdap_level_0" ], "notices" : [ { "title" : "Terms of Service", "description" : [ "By using the ARIN RDAP/Whois service, you are agreeing to the RDAP/Whois Terms of Use" ], "links" : [ { "value" : "https://rdap.arin.net/registry/help", "rel" : "about", "type" : "text/html", "href" : "https://www.arin.net/resources/registry/whois/tou/" } ] }, { "title" : "Whois Inaccuracy Reporting", "description" : [ "If you see inaccuracies in the results, please visit: " ], "links" : [ { "value" : "https://rdap.arin.net/registry/help", "rel" : "about", "type" : "text/html", "href" : "https://www.arin.net/resources/registry/whois/inaccuracy_reporting/" } ] }, { "title" : "Copyright Notice", "description" : [ "Copyright 1997-2021, American Registry for Internet Numbers, Ltd." ] } ] }
Et les résultats des recherches ouvertes (section 3.2 du RFC 9082), qui peuvent renvoyer plusieurs objets ?
Ce sont des tableaux JSON, dans des membres dont le nom se termine
par Results
. Par exemple, en cherchant les noms
de domaines commençant par ra
(ce test a été
fait sur un serveur expérimental qui ne marche plus depuis) :
% curl http://rdg.afilias.info/rdap/domains\?name=ra\*|more "domainSearchResults": [ { "ldhName": "RAINSTRAGE.INFO", ... "objectClassName": "domain", "remarks": [ { "description": [ "Summary data only. For complete data, send a specific query for the object." ], "title": "Incomplete Data", "type": "object truncated due to unexplainable reasons" } ... "ldhName": "RADONREMOVAL.INFO", ... "ldhName": "RANCONDI.INFO", ...
Les vrais serveurs RDAP en production ne répondent pas forcément à ces requêtes trop coûteuses et qui peuvent trop facilement être utilisées pour le renseignement économique :
% curl https://rdap.afilias.net/rdap/info/domains\?name=ra\* ... "errorCode": 422, "title": "Error in processing the request", "description": [ "WildCard search is not supported on sub-zone or tld" ]
Vous avez peut-être noté dans le tout premier exemple le membre
events
(section 4.5 du RFC). Ces événements
comme created
ou
last-changed
donnent accès à l'histoire d'un
objet enregistré. Ici, nous apprenons que le domaine
kornog-computing.info
a été enregistré en
2007.
Certaines valeurs qui apparaissent dans les résultats sont des
chaînes de caractères fixes, stockées dans un nouveau registre
IANA. Elles sont conçues pour être utilisées dans les
notices
, remarks
,
status
, roles
et quelques
autres. Parmi les remarques, on trouvera le cas où une réponse a été
tronquée (section 9 du RFC), comme dans l'exemple ci-dessus avec la
mention Incomplete Data. Parmi les statuts, on
trouvera, par exemple validated
(pour un objet
vérifié, par exemple un nom de domaine dont on a vérifié les
coordonnées du titulaire), locked
(pour un
objet verrouillé), obscured
(qui n'est pas un
statut dans le base du données du registre mais simplement la
mention du fait que le serveur RDAP a délibérement modifié certaines
informations qu'il affiche, par exemple pour protéger la vie
privée), etc. Pour les rôles, on trouvera
registrant
(titulaire),
technical
(contact technique), etc.
Pour ceux qu'intéressent les questions d'internationalisation, la section 12 contient d'utiles mentions. L'encodage des données JSON doit être de l'UTF-8. Et, comme indiqué plus haut, les IDN peuvent être sous la forme Punycode ou bien directement en UTF-8.
Et la vie privée, un problème permanent
avec whois, où il faut toujours choisir entre la distribution de
données utiles pour contacter quelqu'un et les risques pour sa vie
privée ? La section 13 revient sur
cette question. Un point important : RDAP est un protocole, pas une
politique. Il ne définit pas quelles règles suivre (c'est de la
responsabilité des divers registres) mais il fournit les outils pour
mettre en œuvre ces règles. Notamment, RDAP permet de marquer des
parties de la réponse comme étant connues du registre, mais n'ayant
délibérement pas été envoyées (avec les codes
private
et removed
) ou
bien comme ayant été volontairement rendues peu ou pas lisibles
(code obscured
).
Vous avez vu dans les exemples précédents que les réponses d'un serveur RDAP sont souvent longues et, a priori, moins lisibles que celles d'un serveur whois. Il faudra souvent les traiter avec un logiciel qui comprend le JSON. Un exemple très simple et que j'apprécie est jq. Il peut servir à présenter le résultat de manière plus jolie :
% curl -s https://rdap.centralnic.com/pw/domain/centralnic.pw | jq . ... { "objectClassName": "domain", "handle": "D956082-CNIC", "ldhName": "centralnic.pw", "nameservers": [ { "objectClassName": "nameserver", "ldhName": "ns0.centralnic-dns.com", ...
(Essayez ce même serveur RDAP sans jq !)
Mais on peut aussi se servir de jq pour extraire un champ particulier, ici le pays :
% curl -s https://rdap.db.ripe.net/ip/131.111.150.25 | jq ".country" "GB" % curl -s https://rdap.db.ripe.net/ip/192.134.1.1 | jq ".country" "FR"
Il y a évidemment d'autres logiciels que jq sur ce créneau, comme
JSONpath,
jpath
ou, pour les programmeurs Python, python -m
json.tool
.
Un dernier mot, sur le choix de JSON pour le format de sortie, alors que le protocole standard d'avitaillement des objets dans les bases Internet, EPP (RFC 5730) est en XML. L'annexe E de notre RFC, qui discute ce choix, donne comme principaux arguments que JSON est désormais plus répandu que XML (cf. l'article « The Stealthy Ascendancy of JSON ») et que c'est surtout vrai chez les utilisateurs (EPP étant utilisé par une population de professionnels bien plus réduite).
Quels changements depuis le RFC 7483 ? La
plupart sont mineurs et sont de l'ordre de la
clarification. D'autres sont des corrections
d'erreurs, par exemple une coquille
qui avait mis registrant là où il aurait fallu
dire registrar (la proximité des mots en anglais
entraine souvent des erreurs, même chez les professionnels). Il y a
une certaine tendance au durcissement des règles, des éléments qui
étaient optionnels dans le RFC 7483 sont
devenus obligatoires comme, par exemple,
rdapConformance
(dont le statut optionnel avait
causé des
problèmes).
Et question logiciels qui mettent en œuvre RDAP ? Beaucoup de logiciels de gestion de registre le font aujourd'hui, notamment ceux sous contrat avec l'ICANN, puisqu'ils n'ont pas le choix. Mais les logiciels ne sont pas forcément publiquement disponibles. Parmi ceux qui le sont, il y a RedDog, Fred, celui de l'APNIC…
Date de publication du RFC : Juin 2021
Auteur(s) du RFC : S. Hollenbeck (Verisign Labs), A. Newton (AWS)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 16 juin 2021
Le protocole d'information RDAP, qui vise à remplacer whois, est décrit dans un ensemble de RFC. Celui présenté ici normalise la façon de former les requêtes RDAP. Celles-ci ont la forme d'une URL, puisque RDAP repose sur l'architecture REST. Ce RFC remplace l'ancienne norme sur les requêtes RDAP, qui était dans le RFC 7482, mais il n'y a pas de changement significatif.
RDAP peut être utilisé pour beaucoup de sortes d'entités différentes mais ce RFC ne couvre que ce qui correspond aux usages actuels de whois, les préfixes d'adresses IP, les AS, les noms de domaine, etc. Bien sûr, un serveur RDAP donné ne gère pas forcément tous ces types d'entités, et il doit renvoyer le code HTTP 501 (Not implemented) s'il ne sait pas gérer une demande donnée. Ce RFC ne spécifie que l'URL de la requête, le format de la réponse est variable (JSON, XML...) et le seul actuellement normalisé, au-dessus de JSON, est décrit dans le RFC 9083. Quant au protocole de transport, le seul actuellement normalisé pour RDAP (dans le RFC 7480) est HTTP. D'autre part, ces RFC RDAP ne décrivent que le protocole entre le client RDAP et le serveur, pas « l'arrière-cuisine », c'est-à-dire l'avitaillement (création, modification et suppression) des entités enregistrées. RDAP est en lecture seule et ne modifie pas le contenu des bases de données qu'il interroge.
Passons aux choses concrètes. Une requête RDAP est un
URL (RFC 3986). Celui-ci est obtenu en ajoutant un chemin
spécifique à une base. La base (par exemple
https://rdap.example.net/
) va être obtenue par
des mécanismes divers, comme celui du RFC 7484, qui spécifie un registre que vous pouvez
trouver en ligne. On met ensuite un chemin qui dépend du type
d'entité sur laquelle on veut se renseigner, et qui indique
l'identificateur de l'entité. Par exemple, avec la base ci-dessus,
et une recherche du nom de domaine
internautique.fr
, on construirait un URL
complet
https://rdap.example.net/domain/internautique.fr
. Il
y a cinq types d'entités possibles :
ip
: les préfixes IP (notez qu'on peut chercher
un préfixe en donnant juste une des adresses IP couvertes par ce
préfixe),autnum
: les numéros de systèmes autonomes,domain
: un nom de domaine (notez que cela peut être un
domaine dans in-addr.arpa
ou
ipv6.arpa
),nameserver
: un serveur de
noms,entity
: une entité quelconque, comme
un bureau d'enregistrement, ou un contact
identifié par un handle.
La requête est effectuée avec la méthode HTTP
GET
(les méthodes permettant de modifier le
contenu du registre n'ont pas de sens ici, les modifications dans le
registre sont plutôt faites avec EPP). Pour juste savoir si un
objet existe, on peut aussi utiliser la méthode
HEAD
. Si on n'obtient pas de code 404, c'est
que l'objet existe.
Pour ip
, le chemin dans l'URL est
/ip/XXX
où XXX
peut être
une adresse IPv4 ou
IPv6 sous forme texte. Il peut aussi y avoir
une longueur de préfixe à la fin donc
/ip/2001:db8:1:a::/64
est un chemin
valable. Ainsi, sur le service RDAP du RIPE-NCC,
https://rdap.db.ripe.net/ip/2001:4b98:dc0:41::
est un URL possible. Testons-le avec curl (le format de sortie, en JSON, est décrit dans
le RFC 9083, vous aurez peut-être
besoin de passer le résultat à travers jq
pour l'afficher joliment) :
% curl https://rdap.db.ripe.net/ip/2001:4b98:dc0:41:: { "handle" : "2001:4b98:dc0::/48", "startAddress" : "2001:4b98:dc0::/128", "endAddress" : "2001:4b98:dc0:ffff:ffff:ffff:ffff:ffff/128", "ipVersion" : "v6", "name" : "GANDI-HOSTING-DC0", "type" : "ASSIGNED", "country" : "FR", "rdapConformance" : [ "rdap_level_0" ], "entities" : [ { "handle" : "GAD42-RIPE", "vcardArray" : [ "vcard", [ [ "version", { }, "text", "4.0" ], [ "fn", { }, "text", "Gandi Abuse Department" ], [ "kind", { }, "text", "group" ], [ "adr", { "label" : "63-65 Boulevard Massena\n75013 Paris\nFrance" ...
J'ai utilisé curl mais, notamment pour formater plus joliment la
sortie de RDAP, les vrais utilisateurs se serviront plutôt d'un
client RDAP dédié comme RDAPBrowser sur
Android, ou nicinfo. Voici
une vue de RDAPbrowser:
Pour autnum
, on met le numéro de
l'AS après
/autnum/
(au format
« asplain
» du RFC 5396). Toujours dans l'exemple RIPE-NCC,
https://rdap.db.ripe.net/autnum/208069
permet de
chercher de l'information sur l'AS
208069 :
% curl https://rdap.db.ripe.net/autnum/208069 { "handle" : "AS208069", "name" : "ATAXYA", "type" : "DIRECT ALLOCATION", "entities" : [ { "handle" : "mc40833-RIPE", "roles" : [ "administrative", "technical" ], "objectClassName" : "entity" }, { ...
Pour les noms de domaines, on met le nom après
/domain/
. Ainsi, sur le serveur RDAP d'Afilias,
https://rdap.afilias.net/rdap/info/domain/rmll.info
nous donnera de l'information sur le domaine
rmll.info
. On peut mettre un nom en
Unicode donc
https://rdap.example.net/domain/potamochère.fr
est valable, mais il devra être encodé comme l'explique la section
6.1, plus loin (en gros, UTF-8 en
NFC). Si on ne veut pas lire cette
information sur l'encodage, on peut aussi utiliser la forme
Punycode, donc chercher avec
https://rdap.example.net/domain/xn--potamochre-66a.fr
. Un
exemple réel, en Russie :
% curl https://api.rdap.nic.рус/domain/валфекс.рус ... { "eventAction": "registration", "eventDate": "2018-12-26T07:53:41.776927Z" }, ... "adr", { "type": "Registrar Contact" }, "text", [ "", "", "125476, g. Moskva, ul. Vasilya Petushkova, dom 3, str. 1", "", "", "", "RU" ] ] ...
(Attention, le certificat ne sera accepté par curl que si curl a été compilé avec l'option « IDN ».)
On peut aussi se servir de RDAP pour les noms de domaines qui servent à traduire une adresse IP en nom :
% curl https://rdap.db.ripe.net/domain/1.8.a.4.1.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa { "handle" : "0.d.1.4.1.0.0.2.ip6.arpa", "ldhName" : "0.d.1.4.1.0.0.2.ip6.arpa", "nameServers" : [ { "ldhName" : "dns15.ovh.net" }, { "ldhName" : "ns15.ovh.net" } ], "rdapConformance" : [ "rdap_level_0" ], "entities" : [ { "handle" : "OK217-RIPE", "roles" : [ "administrative" ] }, { "handle" : "OTC2-RIPE", "roles" : [ "zone", "technical" ] }, { "handle" : "OVH-MNT", "roles" : [ "registrant" ] } ], "remarks" : [ { "description" : [ "OVH IPv6 reverse delegation" ] } ], ...
Pour un serveur de noms, on met son nom après
/nameserver
donc, chez Afilias :
% curl https://rdap.afilias.net/rdap/info/nameserver/rmll1.rmll.info { ... "ipAddresses": { "v4": [ "80.67.169.65" ] }, "lang": "en", "ldhName": "rmll1.rmll.info", ...
Pour entity
, on indique juste un
identificateur. Voici un exemple :
% curl http://rdg.afilias.info/rdap/entity/81 { "handle": "81", "lang": "en", ... "roles": [ "registrar" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "Gandi SAS" ], [ "adr", {}, "text", [ "", "", "63-65 boulevard Massena", "Paris", "", "F-75013", "FR" ] ...
Certains registres, qui stockent d'autres types d'objets,
pourront ajouter leurs propres requêtes, en prenant soin
d'enregistrer les préfixes de ces requêtes dans le
registre IANA. Par exemple, le logiciel de gestion de
registres FRED permet
d'interroger le registre sur les clés DNSSEC avec les requêtes
/fred_keyset
(la syntaxe des requêtes locales est identificateur du préfixe +
tiret bas + type cherché).
Dernière possibilité, un chemin spécial indique qu'on veut
récupérer de l'aide sur ce serveur RDAP particulier. En envoyant
help
(par exemple
https://rdap.example.net/help
), on obtient un
document décrivant les capacités de ce serveur, ses conditions
d'utilisation, sa politique vis-à-vis de la vie
privée, ses possibilités d'authentification (via les
mécanismes de HTTP), l'adresse
où contacter les responsables, etc. C'est l'équivalent de la
fonction d'aide qu'offrent certains serveurs whois, ici celui de
l'AFNIC :
% whois -h whois.nic.fr -- -h ... %% Option Function %% ------- ------------------------------------- %% -r turn off recursive lookups %% -n AFNIC output format %% -o old fashioned output format (Default) %% -7 force 7bits ASCII output format %% -v verbose mode for templates and help options %% (may be use for reverse query) %% -T type return only objects of specified type %% -P don't return individual objects in case of contact search %% -h informations about server features %% -l lang choice of a language for informations (you can specify US|EN|UK for %% english or FR for french) %% ...
Pour RDAP, voyez par exemple
(qui renvoie de
l'HTML), ou,
plus austères et se limitant à un renvoi à une page Web,
https://rdap.nic.bzh/help
ou
http://rdap.apnic.net/help
.https://rdap.nic.cz/help
Toutes les recherches jusque-là ont été des recherches exactes
(pas complètement pour les adresses IP, où on pouvait chercher un
réseau par une seule des adresses contenues dans le réseau). Mais on
peut aussi faire des recherches plus ouvertes, sur une partie de
l'identificateur. Cela se fait en ajoutant une requête (la partie
après le point
d'interrogation) dans l'URL et en ajoutant un
astérisque (cf. section 4.1). Ainsi,
https://rdap.example.net/domains?name=foo*
cherchera tous les domaines dont le nom commence par la chaîne de
caractères foo
. (Vous avez noté que c'est
/domains
, au pluriel, et non plus
/domain
?) Voici un exemple d'utilisation :
% curl https://rdap.afilias.net/rdap/info/domains\?name=rm\* ... "errorCode": 422, "title": "Error in processing the request", "description": [ "WildCard search is not supported on sub-zone or tld" ] ...
Eh oui, les requêtes ouvertes comme celle-ci posent à la fois des problèmes techniques (la charge du serveur) et politico-juridiques (la capacité à extraire de grandes quantités de la base de données). Elles sont donc typiquement utilisables seulement après une authentification.
On peut aussi chercher un domaine d'après ses serveurs de noms,
par exemple
https://rdap.example.net/domains?nsLdhName=ns1.example.com
chercherait tous les domaines délégués au serveur DNS
ns1.example.com
. Une telle fonction peut être
jugée très indiscrète et le serveur RDAP est toujours libre de
répondre ou pas mais, ici, cela marche, on trouve bien le domaine
qui a ce serveur de noms :
% curl https://rdap.afilias.net/rdap/info/domains\?nsLdhName=ns0.abul.org ... "domainSearchResults": [ { "objectClassName": "domain", "handle": "D10775367-LRMS", "ldhName": "rmll.info", ...
Deux autres types permettent ces recherches ouvertes,
/nameservers
(comme dans
https://rdap.example.net/nameservers?ip=2001:db8:42::1:53
,
mais notez qu'on peut aussi chercher un serveur par son nom) et
/entities
(comme dans
https://rdap.example.net/entities?fn=Jean%20Dupon*
) :
% curl http://rdg.afilias.info/rdap/entities\?fn=go\* { "entitySearchResults": [ { "fn": "Go China Domains, Inc.", ... "fn": "Gotnames.ca Inc.", ...
Notez que ce type de recherche peut représenter un sérieux danger pour la vie privée (comme noté dans le RFC, par exemple en section 4.2) puisqu'elle permet, par exemple de trouver tous les titulaires prénommés Jean. Elle est donc parfois uniquement accessible à des clients authentifiés, et de confiance.
La section 4 détaille le traitement des requêtes. N'oubliez pas qu'on travaille ici sur HTTP et que, par défaut, les codes de retour RDAP suivent la sémantique HTTP (404 pour un objet non trouvé, par exemple). Il y a aussi quelques cas où le code à retourner est moins évident. Ainsi, si un serveur ne veut pas faire une recherche ouverte, il va répondre 422 (Unprocessable Entity).
Vous avez noté plus haut, mais la section 6 le rappelle aux
distraits, que le nom de domaine peut être exprimé en
Unicode ou en ASCII. Donc,
https://rdap.example.net/domain/potamochère.fr
et
https://rdap.example.net/domain/xn--potamochre-66a.fr
sont deux requêtes acceptables.
Enfin, la section 8 rappelle quelques règles de sécurité comme :
Les changements depuis le RFC 7482 sont peu nombreux et sont surtout de clarification.
Première rédaction de cet article le 12 juin 2021
Suite à mes articles sur le protocole QUIC, on a parfois attiré mon attention sur un problème potentiel de vie privée : certes, QUIC protège bien contre la surveillance exercée par un acteur extérieur à la communication, grâce à son chiffrement systématique. Mais qu'en est-il de la surveillance exercée par le serveur sur lequel on se connecte ? Penchons-nous sur la complexité de la conception des protocoles Internet, quand on est soucieux de vie privée.
Au contraire du cas de la surveillance par un tiers, très longuement traité dans les RFC sur QUIC (voir par exemple le RFC 9000, section 9.5), le cas du suivi d'un utilisateur par le serveur auquel il se connecte est absent. Et ce alors que les grosses entreprises capitalistes qui forment un partie très visible du Web d'aujourd'hui sont connues pour pratiquer la surveillance de masse. Mais qu'en est-il exactement ?
Voyons d'abord le principe de l'éventuel problème de suivi d'un
utilisateur par le serveur. Les connexions QUIC peuvent être
longues, peut-être plusieurs heures, voire jours, et elles survivent
même aux changements d'adresses IP, QUIC permettant la migration
d'une adresse à une autre. Le serveur peut donc facilement
déterminer que la demande de /truc.html
à 9 h
est faite par le même utilisateur que la demande de
/machin.html
à 16 h, puisque c'est la même
connexion QUIC. Indiscutablement, ce problème de suivi de
l'utilisateur existe. Mais est-ce spécifique à QUIC et est-ce un vrai
problème en pratique ?
D'abord, le problème est ancien. Si le vieil HTTP original n'envoyait qu'une requête par connexion, cette limitation a disparu il y a longtemps. Ainsi, HTTP/2 (RFC 7540) privilégiait déjà les connexions de longue durée, posant les mêmes problèmes. Toutefois, QUIC, avec sa capacité de survivre aux changements d'adresse IP, étend encore la durée de ces connexions, ce qui peut être vu comme aggravant le problème. (Des techniques assez rares, comme multipath TCP, RFC 8684, fonctionnaient également à travers les changements d'adresses IP.)
Mais surtout, dans l'utilisation typique du Web aujourd'hui, il existe bien d'autres méthodes de suivi de l'utilisateur par le serveur. Il y a évidemment les cookies du RFC 6265. Même si on n'est pas connecté à un service comme YouTube, des cookies sont placés. Et ces cookies, contrairement à la connexion de longue durée de QUIC, permettent un suivi inter-serveurs, via Google Analytics et les boutons de partage des GAFA que tant de webmestres mettent sur leurs pages sans réfléchir. Et il n'y a pas que les cookies, le fingerprinting du navigateur peut également permettre d'identifier un visiteur unique, par toutes les informations que le très bavard HTTP transmet, comme le montre bien le test de l'EFF. Bref, à l'heure actuelle, le serveur indiscret qui veut pister ses utilisateurs a bien des moyens plus puissants à sa disposition.
En revanche, si on utilise un système tout orienté vie privée, tel le Tor Browser, qui débraye beaucoup de services du Web trop indiscrets, et fait tout passer par Tor, alors, la durée des connexions QUIC pourrait devenir le maillon faible de la vie privée.
Pour Tor, le problème est à l'heure actuelle purement théorique puisque Tor ne transmet que TCP et que QUIC utilise UDP. Mais il pourrait se poser dans le futur, le projet Tor a d'ailleurs déjà réfléchi à cela dans le contexte de HTTP/2 (qui s'appelait SPDY à ses débuts).
Un client QUIC soucieux de ne pas être suivi à la trace peut donc, une fois qu'il a géré les problèmes bien plus énormes que posent les cookies et le fingerprinting, envisager des solutions comme de ne pas laisser les connexions QUIC durer trop longtemps et surtout ne pas utiliser la migration (qui permet de maintenir la connexion lorsque l'adresse IP change). Cela peut se faire en raccrochant délibérement la connexion, ou simplement en ne prévoyant pas de réserve de connection IDs (RFC 9000, section 5.1.1). Ceci dit, c'est plus facile à dire qu'à faire car une application n'est pas forcément informée rapidement d'un changement d'adresse IP de la machine. Et, évidemment, cela aura un impact négatif sur les performances totales.
La longue durée des connexions QUIC n'est pas le seul mécanisme par lequel un serveur pourrait suivre à la trace un client. QUIC permet à un client de mémoriser des informations qui lui permettront de se reconnecter au serveur plus vite (ce qu'on nomme le « 0-RTT »). Ces informations (qui fonctionnent exactement comme un cookie HTTP) permettent évidemment également au serveur de reconnaitre un client passé. Cette possibilité et ses conséquences parfois néfastes sont détaillées dans le RFC 9001, sections 4.5 et 9.1. Notez que cela existe également avec juste TLS (ce qu'on nomme le session resumption, RFC 8446, section 2.2) et avec le TCP Fast Open (RFC 7413), avec les mêmes conséquences sur la possibilité de suivi d'un client par le serveur. Le client QUIC qui voudrait protéger sa vie privée doit donc faire attention, quand il démarre une nouvelle connexion, à ne pas utiliser ces possibilités, qui le trahiraient (mais qui diminuent la latence ; toujours le compromis).
Comme souvent en sécurité, on est donc face à un compromis. Si on ne pensait qu'à la vie privée, on utiliserait Tor tout le temps… Les navigateurs Web, par exemple, optimisent clairement pour la vitesse, pas pour la vie privée.
Première rédaction de cet article le 8 juin 2021
Aujourd'hui, entre 1015 et 1110 UTC, le CDN Fastly était en panne, provoquant des dysfonctionnements divers sur quelques sites Web connus. Je ne sais pas ce qui s'est passé, donc je ne vais pas vous l'expliquer mais je voudrais revenir sur la façon dont cet incident a été présenté dans les médias.
Car les titres sensationnalistes n'ont pas manqué, annonçant une
panne massive du Web, voire de tout l'Internet ou au moins d'une
grande partie. Des gens ont ricané en reprenant la légende comme quoi
l'Internet avait été conçu pour résister à une attaque nucléaire ou
déploré que l'Internet soit trop centralisé, ce qu'il n'est
justement pas. La tonalité générale dans les médias était qu'il
s'agissait d'une panne majeure de ce réseau informatique dont tant
de choses dépendent. La réalité est très différente : l'Internet a
très bien tenu, l'écrasante majorité des sites Web marchaient,
quelques gros sites Web commerciaux avaient une drôle
d'allure. Voici par exemple celui du Monde :
L'Internet est le réseau informatique sous-jacent à toutes nos activités en ligne. Si des pannes partielles et localisées l'affectent souvent, il n'a jamais connu de panne généralisée, ou visible à l'échelle mondiale. Pendant l'incident avec Fastly, le courrier électronique passait comme d'habitude, les nœuds Bitcoin se tenaient au courant des transactions financières, les téléchargements BitTorrent se poursuivaient, les informaticiens se connectaient en SSH, les gens continuaient à bavarder sur Signal ou Matrix, et les utilisateurs de Gemini regardaient du contenu en ligne.
Et le Web ? Si
l'Internet est l'infrastructure sous-jacente, le Web est
l'application la plus connue, et même la seule connue de la plupart
des gens qui ont le monopole de l'accès aux médias officiels. En
tout cas, le Web marchait comme d'habitude. Des millions de sites
Web (comme celui que vous visitez en ce moment) n'ont eu aucun
problème. Une infime minorité, ceux qui avaient du contenu sur le
CDN
Fastly était, soit inaccessible, soit
affichait une apparence curieuse car, si le code HTML était bien chargé
par le navigateur, les
feuilles de
style ou le JavaScript ne
suivaient pas. C'est pour cela que la page d'accueil de
GitHub était bizarre :
D'accord, ces gros sites Web commerciaux étaient souvent des sites visibles et connus. Mais même comme cela, Fastly n'est pas le seul fournisseur de CDN et beaucoup d'autres sites continuaient à fonctionner. Il faut arrêter cette présentation erronée comme quoi une poignée de sites Web connus sont « l'Internet » comme cela a souvent été dit.
Des gens ont reproché à ces sites de n'avoir pas de redondance, de dépendre entièrement d'un seul CDN. Mais c'est un détail. Le point important est que les pannes arrivent. On ne peut pas les empêcher toutes. Ce qu'il faut, c'est éviter qu'elles aient des conséquences trop étendues. Il ne faut pas se poser la question de la robustesse de GitHub, il faut au contraire faire en sorte que toute l'activité de programmation mondiale ne cesse pas quand GitHub est en panne. Il faut des milliers de GitLab ou de Gitea, un système réellement décentralisé, où il n'y aura aucun site qui concentrera toute une activité.
Le lendemain, Fastly a publié une explication (sommaire) sur la panne. Notons qu'en attendant cette explication, les médias n'ont pas hésité à avancer des théories fumeuses comme France Inter qui a mis en cause « les serveurs DNS » alors qu'il n'y avait jamais eu aucune indication en ce sens.
Pour se détendre, Natouille avait lancé sur le fédivers (tiens, encore un système décentralisé et qui n'a donc pas eu de problème global) le mot-croisillon « #ExpliqueLaPanneInternet ». Vous pouvez consulter les très amusantes « explications » de la panne sur n'importe quelle instance du fédivers.
Auteur(s) du livre : Julien d'Huy
Éditeur : La Découverte
978-2-348-05966-7
Publié en 2020
Première rédaction de cet article le 3 juin 2021
Il y a longtemps que les folkloristes et les ethnologues ont remarqué des ressemblances troublantes entre des contes et des mythes chez des peuples très lointains. De nombreuses explications ont été proposées. L'auteur, dans ce gros livre très technique, détaille une de ces explications : les mythes ont une origine commune, remontant parfois à des milliers d'années. Il explique ensuite comment étayer cette explication avec des méthodes proches de celles de la phylogénie.
Un exemple frappant est donné par le récit que vous connaissez peut-être grâce à l'Odyssée. Le cyclope Polyphème garde des troupeaux d'animaux. Ulysse et ses compagnons sont capturés par lui et dévorés un à un. Ulysse réussit à aveugler le cyclope en lui brûlant son œil puis s'échappe de la grotte où il était prisonnier en se cachant sous un mouton. Des récits très proches se trouvent chez des peuples qui n'ont aucun lien avec les Grecs de l'Antiquité, notamment chez des Amérindiens, complètement séparés des Européens bien avant Homère. On peut penser à une coïncidence mais de telles ressemblances sont quand même bien fréquentes. On peut aussi se dire que l'unicité physique de l'espèce humaine se traduit par une mentalité identique, et donc une unité des mythes. Mais si les ressemblances sont fréquentes, il y a aussi des différences. Par exemple, lorsqu'on fait des catalogues de mythes, l'Afrique est souvent à part. Si on a un peu bu, on peut aussi imaginer que des extra-terrestres ou bien un être surnaturel ont raconté les mêmes mythes à tous les humains. L'auteur part d'une autre hypothèse : les mythes actuels sont le résultat de l'évolution de mythes très anciens, qui ont divergé à partir d'une souche commune.
La théorie elle-même est ancienne. Mais comment l'étayer ? On peut remarquer que, pour les différentes versions d'un même mythe, des sous-groupes semblent se dessiner. par exemple, dans le mythe de Polyphème, les variantes américaines sont proches les unes des autres, et assez distinctes des variantes eurasiatiques (par exemple, en Amérique, le cyclope est remplacé par un corbeau). Cela évoque fortement un arbre évolutif.
À partir de là, l'auteur utilise une méthode proche de la phylogénie. Les mythes sont découpés en éléments, un peu comme les gènes qu'on utilise en biologie, et on utilise les outils de la phylogénie pour établir des arbres phylogénétiques, dont on étudie ensuite la vraisemblance. Par exemple, les grands mouvements migratoires se retrouvent bien dans cette analyse, avec des mythes amérindiens qui forment un groupe distinct, mais néanmoins souvent rattaché à des mythes qu'on trouve en Asie. De même, les variations génétiques de l'espèce humaine se retrouvent souvent dans les arbres des mythes, non pas évidemment parce que tel ou tel gène dicterait les mythes qu'on raconte, mais parce que les humains font souvent de l'endogamie et que gènes et mythes se transmettent ensemble, au sein des mêmes groupes humains. La place particulière de l'Afrique s'expliquerait par l'ancienneté : Homo sapiens est sorti d'Afrique il y a longtemps et les mythes qu'il avait à ce moment ont tellement évolué qu'on ne les reconnait plus aujourd'hui. Bien, sûr, je schématise beaucoup. Comme souvent en sciences humaines, la situation est plus compliquée que cela, et vous devrez lire le livre pour en apprécier les nuances. D'autant plus que les sujets ethnologiques sont toujours politiquement sensibles, par exemple lorsque l'auteur explique le mythe assez commun du matriarcat originel par un mythe commun, pas par une réalité historique (les mythes ne disent pas la vérité, ils racontent une histoire…).
Un autre exemple de mythe courant est celui de la femme-oiseau. En gros, un homme (un mâle) surprend, souvent au bain, une femme-animal (souvent un oiseau), et cache sa part animale (son manteau de plumes, par exemple). Il peut ainsi la garder près de lui, jusqu'au jour où elle remet la main sur son plumage et peut ainsi se sauver. Là encore, on peut isoler ses élements (les « gènes »), les abstraire (femme-animal au lieu de femme-oiseau car, dans certaines variantes, l'animal est une chèvre ou un éléphant) et les mettre dans le logiciel de phylogénie qui va alors sortir un arbre. Comme toujours, en phylogénie, beaucoup dépend de certaines hypothèses (les paramètres donnés au logiciel) et il est donc important de regarder ensuite les résultats de la reconstruction phylogénétique à la lumière de la génétique, de la connaissance qu'on a des migrations humaines, et des découvertes archéologiques. Dans certains cas, on peut même retrouver la racine de l'arbre, c'est-à-dire le mythe originel.
Le livre n'est pas toujours facile à lire, à pas mal d'endroits, c'est davantage une exposition de résultats de recherche récents qu'un ouvrage de vulgarisation. Avoir fait de la bio-informatique et notamment de la phylogénie, et/ou des statistiques peut aider. Mais les mythes eux-mêmes sont fascinants puisque chacun est un moyen de plonger dans l'esprit de peuples lointains ou même disparus.
(J'ai reçu un message détaillant des critiques sévères à propos de ce livre. Je précise donc que je ne suis moi-même ni folkloriste, ni ethnologue, et que je ne faisais que rendre compte de ce que j'avais compris du livre lu. De toute façon, en sciences humaines, il est rare qu'il existe des consensus, même sur les choses les plus basiques. Je n'ai donc pas modifié mon article.)
Date de publication du RFC : Mai 2021
Auteur(s) du RFC : R. Dobbins (Arbor Networks), D. Migault (Ericsson), R. Moskowitz (HTT Consulting), N. Teague (Iron Mountain Data Centers), L. Xia (Huawei), K. Nishizuka (NTT Communications)
Pour information
Réalisé dans le cadre du groupe de travail IETF dots
Première rédaction de cet article le 31 mai 2021
Le travail autour de DOTS (DDoS Open Threat Signaling) vise à permettre la communication, pendant une attaque par déni de service, entre la victime et une organisation qui peut aider à atténuer l'attaque. Ce nouveau RFC décrit quelques scénarios d'utilisation de DOTS. Autrement, DOTS est normalisé dans les RFC 8811 et ses copains.
Si vous voulez un rappel du paysage des attaque par déni de service, et du rôle de DOTS (DDoS Open Threat Signaling) là-dedans, je vous recommande mon article sur le RFC 8612. Notre RFC 8903 ne fait que raconter les scénarios typiques qui motivent le projet DOTS.
Par exemple, pour commencer, un cas simple où le fournisseur d'accès Internet d'une organisation est également capable de fournir des solutions d'atténuation d'une attaque. Ce fournisseur (ITP dans le RFC, pour Internet Transit Provider) est sur le chemin de tous les paquets IP qui vont vers l'organisation victime, y compris ceux de l'attaque. Et il a déjà une relation contractuelle avec l'utilisateur. Ce fournisseur est donc bien placé, techniquement et juridiquement, pour atténuer une éventuelle attaque. Il peut déclencher le système d'atténuation, soit à la demande de son client qui subit une attaque, soit au contraire contre son client si celui-ci semble une source (peut-être involontaire) d'attaque. (Le RFC appelle le système d'atténuation DMS pour DDoS Mitigation Service ; certains opérateurs ont des noms plus amusants pour le DMS comme OVH qui parle d'« aspirateur ».)
Dans le cas d'une demande du client, victime d'une attaque et qui souhaite l'atténuer, le scénario typique sera qu'une machine chez le client (un pare-feu perfectionné, par exemple), établira une session DOTS avec le serveur DOTS inclus dans le DMS du fournisseur d'accès. Lorsqu'une attaque est détectée (cela peut être automatique, avec un seuil pré-défini, ou bien manuel), la machine du client demandera l'atténuation. Pendant l'atténuation, le client pourra obtenir des informations de la part du DMS du fournisseur. Si l'attaque se termine, le client pourra décider de demander l'arrêt de l'atténuation. Notez que la communication entre le client DOTS (chez la victime) et le serveur DOTS (chez le fournisseur d'accès) peut se faire sur le réseau « normal » (celui qui est attaqué) ou via un lien spécial, par exemple en 4G, ce qui sera plus cher et plus compliqué mais aura l'avantage de fonctionner même si l'attaque sature le lien normal.
Ce scénario simple peut aussi couvrir le cas du réseau domestique. On peut imaginer une box disposant de fonctions de détection d'attaques (peut-être en communiquant avec d'autres, comme le fait la Turris Omnia) et d'un client DOTS, pouvant activer automatiquement l'atténuation en contactant le serveur DOTS du FAI.
Le second cas envisagé est celui où le fournisseur d'accès n'a pas de service d'atténuation mais où le client (mettons qu'il s'agisse d'un hébergeur Web), craignant une attaque, a souscrit un contrat avec un atténuateur spécialisé (de nombreuses organisations ont aujourd'hui ce genre de services, y compris sans but lucratif). Dans ce cas, il faudra « détourner » le trafic vers cet atténuateur, avec des trucs DNS ou BGP, qui sont sans doute hors de portée de la petite ou moyenne organisation. L'accord avec l'atténuateur doit prévoir la technique à utiliser en cas d'attaque. Si c'est le DNS, la victime va changer ses enregistrements DNS pour pointer vers les adresses IP de l'atténuateur (attention au TTL). Si c'est BGP, ce sera à l'atténuateur de commencer à annoncer le préfixe du client (attention aux règles de sécurité BGP, pensez IRR et ROA), et au client d'arrêter son annonce. Le reste se passe comme dans le scénario précédent.
Date de publication du RFC : Mai 2021
Auteur(s) du RFC : J. Gould (VeriSign), M. Casanova (SWITCH)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 30 mai 2021