Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

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


RFC 9154: Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer

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) : gandi-winning-registrar.png Et ici le BE perdant indique à son client le code d'autorisation : gandi-losing-registrar.png (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 :

  • une information d'autorisation vide (représentée par exemple par le NULL dans une base SQL),
  • la possibilité de supprimer l'information d'autorisation avec la commande EPP <update>,
  • la possibilité de valider l'information d'autorisation avec la commande EPP <info>,
  • le refus de tout transfert si l'information d'autorisation est vide,
  • la remise à zéro de l'information d'autorisation lorsque le transfert a été réalisé (mot de passe à usage unique).

Le serveur, lui, en recevant urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0, peut compter que le client EPP saura :

  • générer une information d'autorisation forte (aléatoire, par exemple),
  • ne le faire que lorsqu'un transfert est demandé.

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 :

  • Quand le domaine est créé, l'information d'autorisation est vide (pas de « authinfo »),
  • quand le titulaire veut transférer le nom à un nouveau BE, il demande au BE perdant l'information d'autorisation,
  • le BE perdant génère un mot de passe, qu'il transmet au titulaire et au registre (qui peut répondre avec le code d'erreur EPP 2202 si ce mot de passe ne lui semble pas assez fort), puis qu'il oublie aussitôt,
  • le titulaire donne le mot de passe au BE gagnant,
  • le BE gagnant demande le transfert au registre, en fournissant le mot de passe, ce qui permet au transfert d'être accepté immédiatement,
  • le registre (ou bien le BE perdant), efface le mot de passe.

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.


Téléchargez le RFC 9154


L'article seul

RFC 9167: Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)

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 : afnic-maintenances.png

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,
  • et plusieurs autres éléments.

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.


Téléchargez le RFC 9167


L'article seul

Clé PGP inutilisable ?

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.


L'article seul

RFC 9165: Additional Control Operators for Concise Data Definition Language (CDDL)

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
  

Mais un travail est en cours pour cela.


Téléchargez le RFC 9165


L'article seul

RFC 0810: DoD Internet host table specification

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.


Téléchargez le RFC 0810


L'article seul

RFC 9155: Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2

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


Téléchargez le RFC 9155


L'article seul

Log4Shell, et le financement du logiciel libre

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 :

  • Un appel à financer les développeurs dont on utilise le travail (appel qui n'est pas destiné qu'aux « grosses entreprises »).
  • Un rappel de la situation dans Next Inpact.
  • Un avis d'un employé de Google, qui pointe entre autres les contraintes liées aux grandes entreprises, et qui illustre parfaitement les dangers dont je parle plus haut (en disant explicitement que de payer les développeureuses permettra de leur donner des ordres).
  • Un article de Numérama décrit bien l'opinion dominante (« il faut faire payer les grosses entreprises »).
  • Au contraire, cet article pointe les dangers du financement par les grosses entreprises.
  • Un excellent article de Daniel Stenberg sur le sujet, pointant entre autres les difficultés paperassières à toucher de l'argent, même quand une entreprise ou l'État veut vous en donner, et également le fait que ce n'est pas un hasard si les logiciels touchés sont souvent des logiciels d'infrastructure, sans jolie interface que les décideurs peuvent admirer.
  • Un développeur qui pointe la paperasserie nécessaire pour se faire payer.
  • Dans le débat, des gens disent souvent open source au lieu de logiciel libre, par snobisme, parce que c'est mieux en anglais (ou bien parce qu'ils ne comprennent pas le sujet). C'est pareil.

L'article seul

RFC 9164: Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses

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) :

  • Les adresses à proprement parler, représentées sous forme d'une byte string CBOR (suite d'octets, cf. RFC 8949, section 3.1, type majeur 2) et donc pas sous la forme textuelle (celle avec les points pour IPv4 et les deux-points pour IPv6),
  • Les préfixes, représentés par un tableau de deux éléments, un entier pour la longueur du préfixe et une suite d'octets pour le préfixe lui-même (les octets nuls à la fin doivent être omis),
  • L'interface, sous forme d'un tableau de deux ou trois éléments, qui comporte une adresse IP, la longueur du préfixe sur cette interface et éventuellement un identificateur d'interface (genre 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 :

  • Une chaine de caractères de documentation,
  • l'adresse IP (ici, de l'IPv6, d'où l'étiquette 54 et les 16 octets),
  • le préfixe routé, sous la forme d'une longueur (ici, 32 bits) et des octets non nuls dudit préfixe (ici, au nombre de 4).

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.


Téléchargez le RFC 9164


L'article seul

RFC 9162: Certificate Transparency Version 2.0

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 https://crt.sh 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).

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 :

  • Les algorithmes cryptographiques utilisés sont désormais dans des registres IANA,
  • certains échanges utilisent désormais le format CMS (RFC 5652),
  • les journaux qui étaient auparavant idenfiés par un condensat de leur clé publique le sont désormais par un OID, enregistrés à l'IANA (aucun n'est encore attribué),
  • nouvelle fonction get-all-by-hash dans l'API,
  • remplacement de l'ancienne extension TLS signed_certificate_timestamp (valeur 18) par transparency_info (valeur 52, et voir aussi le nouvel en-tête HTTP Expect-CT: du RFC 9163,
  • et d'autres changements, dans les structures de données utilisées.

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.


Téléchargez le RFC 9162


L'article seul

Saisie de noms de domaine par Microsoft

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


L'article seul

RFC 9157: Revised IANA Considerations for DNSSEC

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.


Téléchargez le RFC 9157


L'article seul

RFC 9138: Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

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) :

  • Un mécanisme de résolution des noms en de l'information plus concrète (une localisation, un autre nom, etc),
  • un mécanisme de routage vers l'endroit où se trouve le NDO,
  • un mécanisme de récupération du NDO.

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 :

  • Fonctionner avec des structures d'espaces de noms différentes (cf. ma critique ci-dessus),
  • accepter la mobilité des contenus,
  • passer à l'échelle (ce qui est trivial avec des noms hiérarchiques, beaucoup moins avec des noms plats),
  • permettre la mémorisation (caching),
  • accepter que les objets soient identifiés par un nom choisi ou par un condensat du contenu (ce que le RFC nomme les « objets sans nom », ce qui me semble accroitre encore la confusion),
  • permettre enfin de récupérer des métadonnées et pas seulement le localisateur.

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 :

  • Des réponses rapides (« en un temps raisonnable »),
  • des réponses correctes (on voit bien le ridicule de l'approche par cahier des charges, quand il faut préciser explicitement des points aussi évidents), et à jour (là encore, « raisonnablement »),
  • des réponses justes, respectant un principe de neutralité (pas de censure ? L'ARCOM n'aimerait pas),
  • un fonctionnement satisfaisant sur des réseaux de grande taille (le RFC mentionne au moins 10^21 objets),
  • un système gérable (pouvant s'adapter avec par exemple l'ajout et le retrait de nœuds),
  • la capacité à être réellement déployé (là encore, on a envie de dire « encore heureux »),
  • la résistance aux pannes (la panne d'une machine ne doit pas arrêter le NRS), et aux attaques par déni de service,
  • la confidentialité des requêtes (un problème pour le DNS, cf. RFC 7626), mais aussi des données (le RFC mentionne des ACL sur les noms, chose qui n'existe pas vraiment dans le DNS)
  • l'authentification des serveurs, des producteurs de noms (par exemple pour que seule l'entité qui a enregistré un nom puisse modifier les données associées), et des données elle-mêmes (ce que DNSSEC fournit au DNS),

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.


Téléchargez le RFC 9138


L'article seul

Fiche de lecture : Digital roots

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.


L'article seul

Les RFC les plus cités sur ce blog

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 :

  • Le RFC 1918, sur les adresses IPv4 privées, souvent cité car, tant que tout le monde ne se sera pas décidé à déployer IPv6, il reste indispensable, vu la pénurie des adresses IPv4.
  • Le RFC 5246, sur l'ancienne version du protocole de cryptographie TLS, la version 1.2. Depuis, la version 1.3 a été normalisée (dans le RFC 8446) et ce nombre de citations ne devrait donc pas augmenter.
  • Le RFC 1035, sur le DNS, qui normalise le format des enregistrements DNS et les détails concrets du protocole. Il est logique qu'un RFC sur le DNS apparaisse dans cette liste en bonne position, le DNS étant à la fois mon activité professionnelle et un sujet que je connais bien et dont je parle souvent.
  • Le RFC 4271, sur BGP. Avec le DNS, c'est l'autre grand protocole d'infrastructure sur l'Internet, ce qui explique sa présence.
  • Le RFC 5226, sur les règles d'enregistrement dans les registres IANA. Ce RFC ne décrit donc pas un protocole, mais remplit un rôle plus politico-bureaucratique. Là aussi, il a été remplacé par un RFC plus récent, le RFC 8126, et devrait donc logiquement reculer dans le classement.
  • Le RFC 1034, également sur le DNS. C'est le deuxième RFC de la norme originale (qui n'a pas été remplacée par des RFC plus récents), consacré aux concepts.
  • Le RFC 3986, qui normalise les URI. Ces identificateurs sont une invention géniale, et un des trois piliers du Web, avec HTTP et HTML. Ils sont même utilisés en dehors du Web, par exemple pour Gemini.
  • Le RFC 4862, sur l'auto-configuration sans état (SLAAC, StateLess Address AutoConfiguration) d'IPv6, une des nouveautés d'IPv6 qui n'a pas vraiment d'équivalent dans IPv4 (alors que la plupart des concepts sont communs aux deux versions d'IP).
  • Le RFC 8415 décrit un autre moyen en IPv6 d'attribuer une adresse IP à une machine, DHCP.
  • Le RFC 5322, est le RFC sur l'IMF (Internet Message Format), le format des messages de courrier électronique (vous savez, les 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.
  • Le RFC 793 est toujours aujourd'hui le RFC sur TCP, le protocole de transport qui, malgré la concurrence récente de QUIC, fait passer l'essentiel des octets qui circulent sur l'Internet. Il n'a pas été remplacé mais bien d'autres RFC sont aujourd'hui nécessaires pour comprendre TCP, je vous recommande la liste du RFC 7414.
  • Et le RFC 7231, un des RFC sur HTTP 1, qui normalise notamment la sémantique des messages. Là aussi, sa présence est logique, vu l'importance de HTTP dans l'Internet d'aujourd'hui.

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


L'article seul

RFC 9156: DNS Query Name Minimisation to Improve Privacy

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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.


Téléchargez le RFC 9156


L'article seul

RFC 9141: Updating References to the IETF FTP Service

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


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

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

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

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

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

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

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

Téléchargez le RFC 9141


L'article seul

L'offre d'hébergement nua.ge

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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 : nuage-conso.png

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

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

Autres articles sur ce service :


L'article seul

Fiche de lecture : Les Fans

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


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

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

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

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

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

Les fans, on l'a dit, ne sont pas des spectateurs passifs. Une des parties les plus intéressantes du livre est consacré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.


L'article seul

Combinaison d'analyseurs syntaxiques en Elixir avec NimbleParsec

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Et ça donne :

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

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

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


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

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

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

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

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

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

Tandis qu'optional permettra de rendre un analyseur facultatif :

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

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

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

Voici le résultat :

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

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

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

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

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

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

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

Qui donnera :

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

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

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

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

Des limites ou des défauts de cette solution ? Les deux principaux me semblent :

  • Les messages d'erreur retournés par défaut ne me semblent pas idéaux et il est difficile d'insérer son propre traitement d'erreur.
  • Il ne semble pas y avoir de moyen de faire de l'analyse incrémentale (« streaming ») ce qui est notamment génant pour l'analyse de protocoles réseau. De même, on ne peut pas facilement modifier la grammaire en fonction des données lues.

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.


L'article seul

Mesurer l'efficacité du pare-feu national chinois

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


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

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

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

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

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

%  dig @113.113.113.113 A scratch.mit.edu

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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


L'article seul

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

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


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

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

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

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

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

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

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

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

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

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

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

On peut alors lancer le serveur :

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

Et le client, le Raspberry Pi :

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

  

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

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

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


Téléchargez le RFC 9097


L'article seul

Fiche de lecture : L'École sans école

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


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

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

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


L'article seul

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

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


Téléchargez le RFC 9120


L'article seul

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

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


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

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

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

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

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

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

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

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

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

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

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

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


L'article seul

Tempête solaire sur l'Internet ?

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


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

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

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

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

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

Je vous résume quelques conclusions :

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

Dans l'état actuel de la science, on ne sait pas prédire les tempêtes solaires, uniquement déterminer des probabilités. On ne peut donc pas se préparer longtemps à l'avance. Toutefois, en cas de tempête solaire, comme la masse coronale éjectée voyage plus lentement que la lumière, on voit la tempête plusieurs heures, voire plusieurs jours, avant d'en ressentir les effets. Il existe des services d'alarme utilisés, par exemple, par l'aviation. C'est le cas du service 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 : presto-gemini.png

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

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

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


L'article seul

Panne de routage OVH d'octobre 2021

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


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


L'article complet

RFC 9137: Considerations for Cancellation of IETF Meetings

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


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

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

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

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

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

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

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


Téléchargez le RFC 9137


L'article seul

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Évidemment, DOTS est critique en matière de sécurité. S'il ne fonctionne pas, on ne pourra pas réclamer une action de la part du service de protection. Et s'il est mal authentifié, on risque de voir le méchant envoyer de faux messages DOTS, par exemple en demandant l'arrêt de l'atténuation. La section 8 du RFC rappelle donc l'importance de sécuriser DOTS par TLS ou plutôt, la plupart du temps, par son équivalent pour UDP, DTLS (RFC 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.


Téléchargez le RFC 9132


L'article seul

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

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


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

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

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

Bon, OK mais, même si la moyenne n'a pas de sens et que les déclarations sensationnalistes « envoyer un courrier, c'est relâcher X grammes de dioxyde de carbone dans l'atmosphère » sont à côté de la plaque, il n'en reste pas moins que le numérique a une empreinte environnementale, non ? Oui, la construction et l'exploitation des réseaux informatiques a un coût (y compris environnemental). Ce n'est pas un coût à l'utilisation, d'accord. Mais si les gens augmentent leur activité en ligne, par exemple si ce blog double son nombre de visiteurs, il faudra déployer davantage de matériels (dont la construction est le principal facteur d'empreinte environnementale du numérique) et il y aura donc bien un résultat (néfaste…) sur l'environnement. (Le matériel nouveau sera plus efficace : un routeur capable de 100 Gb/s ne consommera pas dix fois 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.

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

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

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

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


L'article seul

Plusieurs domaines de premier niveau en panne

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


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

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

Pour le dé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 :


L'article seul

La panne Facebook du 4 octobre 2021

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Articles dans les médias :

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


L'article seul

RFC 9117: Revised Validation Procedure for BGP Flow Specifications

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


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

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

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

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

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

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


Téléchargez le RFC 9117


L'article seul

Fiche de lecture : L'enfer numérique

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


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

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

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

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

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

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

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

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

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

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


L'article seul

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Téléchargez le RFC 9115


L'article seul

RFC 9098: Operational Implications of IPv6 Packets with Extension Headers

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, dans draft-ietf-opsec-ipv6-eh-filtering mais aussi dans des RFC, le RFC 7113 et le RFC 8900. Cela a mené à plusieurs changements dans la norme, je vous renvoie aux RFC 5722, RFC 7045, RFC 8021, etc. Plusieurs changements ont été intégrés dans la dernière révision du RFC principal de la norme, le RFC 8200. Ainsi, celui-ci dispense désormais les routeurs de chercher un éventuel en-tête d'extension Hop-by-hop options.

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

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

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

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

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

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

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

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

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

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

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


Téléchargez le RFC 9098


L'article seul

Utiliser les « middleboxes » de censure pour des attaques par déni de service

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 : uae-web-blocked.jpg

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.


L'article seul

Version 14 d'Unicode

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

L'article seul

RFC 9109: Network Time Protocol Version 4: Port Randomization

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

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

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

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

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


Téléchargez le RFC 9109


L'article seul

RFC 9107: BGP Optimal Route Reflection (BGP ORR)

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.


Téléchargez le RFC 9107


L'article seul

RFC 9103: DNS Zone Transfer over TLS

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 :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Les mécanismes possibles sont :

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

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

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

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

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

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

  

Parfait, tout marche. Et le transfert de zones ?


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

  

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

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

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

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

Téléchargez le RFC 9103


L'article seul

RFC 9108: YANG Types for DNS Classes and Resource Record Types

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


Téléchargez le RFC 9108


L'article seul

RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications

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.


Téléchargez le RFC 9106


L'article seul

RFC 9096: Requirements for Customer Edge Routers to Mitigate IPv6 Renumbering Events

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.


Téléchargez le RFC 9096


L'article seul

RFC 9099: Operational Security Considerations for IPv6 Networks

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). 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 (ISATAPRFC 5214, 6to4RFC 3056, mais aussi 6rdRFC 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 TeredoRFC 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 NAT64RFC 6146 ou 464XLATRFC 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.


Téléchargez le RFC 9099


L'article seul

RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2

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 :

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

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

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

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

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

import imaplib

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

Téléchargez le RFC 9051


L'article seul

Le registre Afrinic attaqué

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 :


L'article seul

RFC 9079: Source-Specific Routing in Babel

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.


Téléchargez le RFC 9079


L'article seul

RFC 9043: FFV1 Video Coding Format Version 0, 1, and 3

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.


Téléchargez le RFC 9043


L'article seul

RFC 9102: TLS DNSSEC Chain Extension

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. Le port indiqué par le client doit être le port original, avant toute traduction ou redirection.

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

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

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

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

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

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

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

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

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

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

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

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

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


Téléchargez le RFC 9102


L'article seul

RFC 9078: Reaction: Indicating Summary Reaction to a Message

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 ?).


Téléchargez le RFC 9078


L'article seul

RFC 9095: Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration

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.


Téléchargez le RFC 9095


L'article seul

RFC 9077: NSEC and NSEC3: TTLs and Aggressive Use

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 :


Téléchargez le RFC 9077


L'article seul

RFC 9076: DNS Privacy Considerations

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


Téléchargez le RFC 9076


L'article seul

RFC 9075: Report from the IAB COVID-19 Network Impacts Workshop 2020

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 : decix-covid-2020.png

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) : franceix-covid-2020.png

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 :

  • Une augmentation de l'utilisation de l'Internet par 9 utilisateurs sur 10 (le dixième était peut-être déjà connecté tout le temps ?) et des usages nouveaux par 1 utilisateur sur 5 (des gens comme moi qui se mettent à la vidéo-conférence alors qu'ils détestaient cela avant).
  • Peu de plaintes concernant les performances.
  • Évidemment un changement dans les applications utilisées, les applications de vidéo-conférence voient leur usage s'accroitre, celles liées à la location d'hôtels ou de restaurants (ou, note le RFC, celles permettant la recherche d'une place de parking) le voient diminuer.

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 :

  • En continuant à étudier le fonctionnement de l'Internet. Le caractère critique de l'Internet pour tant d'activités humaines justifie qu'on continue à analyser ses caractéristiques et ses faiblesses.
  • Le partage d'informations et la communication sont essentiels et doivent être accrus.
  • La lutte contre la fracture numérique doit se poursuivre, puisqu'en période de confinement, être coupé du réseau, ou y accéder dans de mauvaises conditions (accès lent, matériel inadapté, manque de littératie numérique), aggrave encore l'isolement.

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


Téléchargez le RFC 9075


L'article seul

Les problèmes gris dans les réseaux informatiques

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…


L'article seul

RFC 8984: JSCalendar: A JSON Representation of Calendar Data

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 4122). 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 4122).
  • 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).
  • Tous les évènements ne sont pas dans le monde physique, certains se produisent en ligne, d'où le 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 :

  • Les évènements (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).
  • Les tâches (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…).
  • Les groupes (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.


Téléchargez le RFC 8984


L'article seul

RFC 9065: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols

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 , 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 :

  • Pendant le développement de TLS 1.3 (qui mènera au RFC 8446), il a fallu concevoir 1.3 de manière à ce qu'il ressemble à 1.2, car certaines middleboxes rejettaient du TLS légal, mais différent de ce qu'elles attendaient.
  • MPTCP (RFC 8684) a également dû être modifié pour tenir compte de boitiers intermédiaires qui observaient le fonctionnement de la fenêtre TCP et se permettaient de couper les connexions qui leur semblaient anormales.
  • D'une manière générale, tout protocole qui permet des options est confronté à des middleboxes qui interfèrent dès qu'on utilise des options nouvelles. C'est le cas par exemple de TCP Fast Open (RFC 7413).
  • Encore pire, si c'est possible, on a vu des équipements intermédiaires qui changeaient les numéros de séquence TCP, ce qui cassait les accusés de réception SACK (RFC 2018).

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 :

  • Le chiffrement et l'authentification dans la couche de Transport sont une bonne chose. Personne n'ose dire ouvertement qu'il faudrait rester à des protocoles de transport non sécurisés. C'est un point sur lequel le document a beaucoup évolué. Dans les versions antérieures, comme le notait Christian Huitema, « Much of the draft reads like a lamentation of the horrible consequences of encrypting transport headers », reflétant unilatéralement le point de vue des opérateurs réseau, et des vendeurs de middleboxes. Une relecture par Christopher Wood au début du projet avait déjà pointé ce problème, notant que le document était très anti-chiffrement. Cette question a, fort logiquement, été le principal point de discussion à l'IETF.
  • Le RFC, officiellement, ne tranche pas sur la pertinence et l'éthique des pratiques qu'il décrit, il explique juste ce qui se fait. (Le même argument, que je trouve un peu hypocrite, avait été utilisé pour le très contestable RFC 8404.)
  • Comme souvent en sécurité, il n'y a pas de solution idéale, il faudra trouver un compromis, par exemple entre la vie privée et l'OAM. Le RFC cite le spin bit de QUIC, qui avait été très chaudement discuté, comme un exemple de compromis, en tout cas par le sérieux de l'analyse de ses coûts et de ses bénéfices.
  • Le RFC reconnait que tout ce qui est exposé au réseau s'ossifiera et deviendra une spécification de fait, qu'on ne pourra plus changer. Qu'un protocole choisisse d'exposer beaucoup ou au contraire très peu, il doit de toute façon faire ce choix explicitement.
  • Même le chiffrement de la couche Transport ne cache pas tout, et les couches inférieures exposent toujours des métadonnées. Un surveillant déterminé n'est donc pas désarmé. (Même si des organisations comme Interpol prétendent que le chiffrement rend la police « aveugle ».)
  • Les opérationnels se sont habitués depuis longtemps à disposer de certaines informations, que le chiffrement de la couche Transport peut rendre inutilisables. Il faudra donc changer certaines pratiques et certains outils, par exemple avec davantage de coopération des machines terminales (sinon, les opérations seront affectées).
  • Le RFC rappelle aussi qu'il existe différents types de réseaux, et qui n'ont pas forcément les mêmes contraintes et les mêmes buts. Entre le réseau d'une entreprise qui veut contrôler tout ce que font les employés et le réseau d'un FAI qui doit respecter (en théorie…) le principe de neutralité, il n'est pas du tout sûr qu'on puisse trouver des solutions qui plaisent à tout le monde. (A priori, l'IETF travaille et normalise pour l'Internet ouvert, pas forcément pour chaque réseau connecté à l'Internet avec ses règles spécifiques.)
  • L'Internet est un réseau partagé et son bon fonctionnement dépend donc du respect de certaines règles par tous. Par exemple, un protocole de transport doit penser aux autres, en ne noyant pas le réseau sous les paquets de retransmission. Si un fournisseur de logiciels était tenté de développer un protocole de transport égoïste, qui tente d'obtenir plus que sa part de la capacité du réseau, la tricherie pourrait se détecter en observant le fonctionnement de ce protocole. Le chiffrement de la couche Transport rend évidemment la vérification plus complexe.
  • Le bon fonctionnement de l'Internet sur le long terme dépend également d'une activité de recherche et développement, qui s'appuie sur des mesures, que le chiffrement de la couche Transport peut gêner. (C'est bien, de se préoccuper des chercheurs.)

Téléchargez le RFC 9065


L'article seul

RFC 9063: Host Identity Protocol Architecture

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 6830) 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 :

  • Protection contre certaines attaques par déni de service via le puzzle cryptographique à résoudre.
  • Protection contre les attaques de l'homme du milieu si le HI a été obtenu par un mécanisme sûr. Cela ne marche évidemment pas en mode opportuniste, où l'initiateur ne connait pas le HI de son correspondant, et le découvre une fois la connexion faite.
  • Le mode opportuniste peut être renforcé, question sécurité, par le TOFU (RFC 7435).
  • Tout mécanisme de séparation de l'identificateur et du localisateur ouvre de nouveaux problèmes : que se passe-t-il si le correspondant ment sur son localisateur ? Est-ce que cela permet des attaques par réflexion ? C'est pour éviter cela que les systèmes à séparation de l'identificateur et du localisateur prévoient, comme HIP, un test de l'existence d'une voie de retour (Cf. RFC 4225).
  • Enfin, on peut évidemment mettre des ACL sur des HI mais leur structure « plate » fait qu'il n'y a pas d'agrégation possible de ces ACL (il faut une ACL par machine avec qui on correspond).

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.


Téléchargez le RFC 9063


L'article seul

Récupérer la date d'expiration d'un domaine en RDAP

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


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.net/rdap/org/. 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.net/rdap/org/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.net/rdap/org/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.net/rdap/org/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 7484) 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 ».


L'article seul

RFC 9039: Uniform Resource Names for Device Identifiers

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.)
  • Un autre type, qui sera défini dans le futur (cf. section 7 du RFC). En attendant, on peut utiliser 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 4122. 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');
  

Téléchargez le RFC 9039


L'article seul

Une « monnaie numérique de banque centrale », c'est quoi ?

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.


L'article seul

RFC 9057: Email Author Header Field

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.


Téléchargez le RFC 9057


L'article seul

Traiter des options EDNS nouvelles dans un programme

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


L'article seul

RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP)

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) :

  • Domaines (oui, même pour les RIR, pensez à in-addr.arpa et ip6.arpa),
  • Serveurs de noms,
  • Entités diverses, comme les handles, les identificateurs des contacts, genre 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


Téléchargez le RFC 9083


L'article seul

RFC 9082: Registration Data Access Protocol (RDAP) Query Format

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/XXXXXX 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: rdapbrowser.png

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 https://rdap.nic.bzh/help (qui renvoie de l'HTML), ou, plus austères et se limitant à un renvoi à une page Web, http://rdap.apnic.net/help ou 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 requêtes ouvertes peuvent mener à une forte consommation de ressources sur le serveur. Le serveur qui ne vaut pas se faire DoSer doit donc faire attention avant de les accepter.
  • Les requêtes RDAP, et surtout les requêtes ouvertes, peuvent soulever des questions liées à la vie privée. Les serveurs RDAP doivent donc réfléchir avant de renvoyer de l'information. Rappelez-vous que RDAP, contrairement à whois, peut avoir un mécanisme d'authentification, donc peut envoyer des réponses différentes selon le client.
  • Et, corollaire du précédent point, les gérants de serveurs RDAP doivent définir une politique d'autorisation : qu'est-ce que je renvoie, et à qui ?

Les changements depuis le RFC 7482 sont peu nombreux et sont surtout de clarification.


Téléchargez le RFC 9082


L'article seul

QUIC et le suivi des utilisateurs par le serveur

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.


L'article seul

L'Internet était-il en panne aujourd'hui ?

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 : fastly-outage-lemonde.png

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 : fastly-outage-github.png

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.


L'article seul

Fiche de lecture : Cosmogonies

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


L'article seul

RFC 8903: Use cases for DDoS Open Threat Signaling

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.


Téléchargez le RFC 8903


L'article seul

RFC 9022: Domain Name Registration Data (DNRD) Objects Mapping

Date de publication du RFC : Mai 2021
Auteur(s) du RFC : G. Lozano (ICANN), J. Gould, C. Thippeswamy (VeriSign)
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


Le RFC 8909 normalisait un format générique pour les séquestres d'objets enregistrés dans un registre. Ce nouveau RFC 9022 précise ce format pour le cas spécifique des registres de noms de domaine (dont les objets enregistrés sont les noms de domaine, les contacts, les serveurs de noms, etc).

Rappelons que le but d'un séquestre est de permettre à un tiers de reprendre les opérations d'un registre (par exemple un registre de noms de domaine) en cas de défaillance complète de celui-ci. Pas juste une panne matérielle qui fait perdre des données, non, une défaillance grave, par exemple une