Mon blog

Le protocole d'information RDAP, qui vise à remplacer whois, est décrit dans un ensemble de RFC. Celui présenté ici normalise la façon de former les requêtes RDAP. Celles-ci ont la forme d'une URL, puisque RDAP repose sur l'architecture REST. Ce RFC remplace l'ancienne norme sur les requêtes RDAP, qui était dans le RFC 7482, mais il n'y a pas de changement significatif.

RDAP peut être utilisé pour beaucoup de sortes d'entités différentes mais ce RFC ne couvre que ce qui correspond aux usages actuels de whois, les préfixes d'adresses IP, les AS, les noms de domaine, etc. Bien sûr, un serveur RDAP donné ne gère pas forcément tous ces types d'entités, et il doit renvoyer le code HTTP 501 (Not implemented) s'il ne sait pas gérer une demande donnée. Ce RFC ne spécifie que l'URL de la requête, le format de la réponse est variable (JSON, XML...) et le seul actuellement normalisé, au-dessus de JSON, est décrit dans le RFC 9083. Quant au protocole de transport, le seul actuellement normalisé pour RDAP (dans le RFC 7480) est HTTP. D'autre part, ces RFC RDAP ne décrivent que le protocole entre le client RDAP et le serveur, pas « l'arrière-cuisine », c'est-à-dire l'avitaillement (création, modification et suppression) des entités enregistrées. RDAP est en lecture seule et ne modifie pas le contenu des bases de données qu'il interroge.

Passons aux choses concrètes. Une requête RDAP est un URL (RFC 3986). Celui-ci est obtenu en ajoutant un chemin spécifique à une base. La base (par exemple https://rdap.example.net/) va être obtenue par des mécanismes divers, comme celui du RFC 7484, qui spécifie un registre que vous pouvez trouver en ligne. On met ensuite un chemin qui dépend du type d'entité sur laquelle on veut se renseigner, et qui indique l'identificateur de l'entité. Par exemple, avec la base ci-dessus, et une recherche du nom de domaine internautique.fr, on construirait un URL complet https://rdap.example.net/domain/internautique.fr. Il y a cinq types d'entités possibles :

• ip : les préfixes IP (notez qu'on peut chercher un préfixe en donnant juste une des adresses IP couvertes par ce préfixe),
• autnum : les numéros de systèmes autonomes,
• domain : un nom de domaine (notez que cela peut être un domaine dans in-addr.arpa ou ipv6.arpa),
• nameserver : un serveur de noms,
• entity : une entité quelconque, comme un bureau d'enregistrement, ou un contact identifié par un handle.

La requête est effectuée avec la méthode HTTP GET (les méthodes permettant de modifier le contenu du registre n'ont pas de sens ici, les modifications dans le registre sont plutôt faites avec EPP). Pour juste savoir si un objet existe, on peut aussi utiliser la méthode HEAD. Si on n'obtient pas de code 404, c'est que l'objet existe.

Pour ip, le chemin dans l'URL est /ip/XXX où XXX peut être une adresse IPv4 ou IPv6 sous forme texte. Il peut aussi y avoir une longueur de préfixe à la fin donc /ip/2001:db8:1:a::/64 est un chemin valable. Ainsi, sur le service RDAP du RIPE-NCC, https://rdap.db.ripe.net/ip/2001:4b98:dc0:41:: est un URL possible. Testons-le avec curl (le format de sortie, en JSON, est décrit dans le RFC 9083, vous aurez peut-être besoin de passer le résultat à travers jq pour l'afficher joliment) :

% curl https://rdap.db.ripe.net/ip/2001:4b98:dc0:41:: 
{
  "handle" : "2001:4b98:dc0::/48",
  "startAddress" : "2001:4b98:dc0::/128",
  "endAddress" : "2001:4b98:dc0:ffff:ffff:ffff:ffff:ffff/128",
  "ipVersion" : "v6",
  "name" : "GANDI-HOSTING-DC0",
  "type" : "ASSIGNED",
  "country" : "FR",
  "rdapConformance" : [ "rdap_level_0" ],
  "entities" : [ {
    "handle" : "GAD42-RIPE",
    "vcardArray" : [ "vcard", [ [ "version", { }, "text", "4.0" ], [ "fn", { }, "text", "Gandi Abuse Department" ], [ "kind", { }, "text", "group" ], [ "adr", {
      "label" : "63-65 Boulevard Massena\n75013 Paris\nFrance"
...

J'ai utilisé curl mais, notamment pour formater plus joliment la sortie de RDAP, les vrais utilisateurs se serviront plutôt d'un client RDAP dédié comme RDAPBrowser sur Android, ou nicinfo. Voici une vue de RDAPbrowser:

Pour autnum, on met le numéro de l'AS après /autnum/ (au format « asplain » du RFC 5396). Toujours dans l'exemple RIPE-NCC, https://rdap.db.ripe.net/autnum/208069 permet de chercher de l'information sur l'AS 208069 :

% curl https://rdap.db.ripe.net/autnum/208069
{
  "handle" : "AS208069",
  "name" : "ATAXYA",
  "type" : "DIRECT ALLOCATION",
  "entities" : [ {
    "handle" : "mc40833-RIPE",
    "roles" : [ "administrative", "technical" ],
    "objectClassName" : "entity"
  }, {
...

Pour les noms de domaines, on met le nom après /domain/. Ainsi, sur le serveur RDAP d'Afilias, https://rdap.afilias.net/rdap/info/domain/rmll.info nous donnera de l'information sur le domaine rmll.info. On peut mettre un nom en Unicode donc https://rdap.example.net/domain/potamochère.fr est valable, mais il devra être encodé comme l'explique la section 6.1, plus loin (en gros, UTF-8 en NFC). Si on ne veut pas lire cette information sur l'encodage, on peut aussi utiliser la forme Punycode, donc chercher avec https://rdap.example.net/domain/xn--potamochre-66a.fr. Un exemple réel, en Russie :

% curl https://api.rdap.nic.рус/domain/валфекс.рус
...
         {
      "eventAction": "registration",
      "eventDate": "2018-12-26T07:53:41.776927Z"
    },
    ...
                "adr",
            {
              "type": "Registrar Contact"
            },
            "text",
            [
              "",
              "",
              "125476, g. Moskva, ul. Vasilya Petushkova, dom 3, str. 1",
              "",
              "",
              "",
              "RU"
            ]
          ]
...
  

(Attention, le certificat ne sera accepté par curl que si curl a été compilé avec l'option « IDN ».)

On peut aussi se servir de RDAP pour les noms de domaines qui servent à traduire une adresse IP en nom :

% curl https://rdap.db.ripe.net/domain/1.8.a.4.1.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa
{
  "handle" : "0.d.1.4.1.0.0.2.ip6.arpa",
  "ldhName" : "0.d.1.4.1.0.0.2.ip6.arpa",
  "nameServers" : [ {
    "ldhName" : "dns15.ovh.net"
  }, {
    "ldhName" : "ns15.ovh.net"
  } ],
  "rdapConformance" : [ "rdap_level_0" ],
  "entities" : [ {
    "handle" : "OK217-RIPE",
    "roles" : [ "administrative" ]
  }, {
    "handle" : "OTC2-RIPE",
    "roles" : [ "zone", "technical" ]
  }, {
    "handle" : "OVH-MNT",
    "roles" : [ "registrant" ]
  } ],
  "remarks" : [ {
    "description" : [ "OVH IPv6 reverse delegation" ]
  } ],
...

Pour un serveur de noms, on met son nom après /nameserver donc, chez Afilias :

% curl https://rdap.afilias.net/rdap/info/nameserver/rmll1.rmll.info
{
...
   "ipAddresses": {
      "v4": [
         "80.67.169.65"
      ]
   }, 
   "lang": "en", 
   "ldhName": "rmll1.rmll.info", 
...

Pour entity, on indique juste un identificateur. Voici un exemple :

% curl  http://rdg.afilias.info/rdap/entity/81
{
   "handle": "81", 
   "lang": "en", 
...
   "roles": [
      "registrar"
   ], 
   "vcardArray": [
      "vcard", 
      [
         [
            "version", 
            {}, 
            "text", 
            "4.0"
         ], 
         [
            "fn", 
            {}, 
            "text", 
            "Gandi SAS"
         ], 
         [
            "adr", 
            {}, 
            "text", 
            [
               "", 
               "", 
               "63-65 boulevard Massena", 
               "Paris", 
               "", 
               "F-75013", 
               "FR"
            ]
...
  

Certains registres, qui stockent d'autres types d'objets, pourront ajouter leurs propres requêtes, en prenant soin d'enregistrer les préfixes de ces requêtes dans le registre IANA. Par exemple, le logiciel de gestion de registres FRED permet d'interroger le registre sur les clés DNSSEC avec les requêtes /fred_keyset (la syntaxe des requêtes locales est identificateur du préfixe + tiret bas + type cherché).

Dernière possibilité, un chemin spécial indique qu'on veut récupérer de l'aide sur ce serveur RDAP particulier. En envoyant help (par exemple https://rdap.example.net/help), on obtient un document décrivant les capacités de ce serveur, ses conditions d'utilisation, sa politique vis-à-vis de la vie privée, ses possibilités d'authentification (via les mécanismes de HTTP), l'adresse où contacter les responsables, etc. C'est l'équivalent de la fonction d'aide qu'offrent certains serveurs whois, ici celui de l'AFNIC :

% whois -h whois.nic.fr  -- -h
...
%% Option   Function
%% -------  -------------------------------------
%% -r       turn off recursive lookups
%% -n       AFNIC output format
%% -o       old fashioned output format (Default)
%% -7       force 7bits ASCII output format
%% -v       verbose mode for templates and help options
%%          (may be use for reverse query)
%% -T type  return only objects of specified type
%% -P       don't return individual objects in case of contact search
%% -h       informations about server features
%% -l lang  choice of a language for informations (you can specify US|EN|UK for
%%          english or FR for french)
%%
...

Pour RDAP, voyez par exemple 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.

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 :

• Réseaux IP, identifiés par leur préfixe,
• Systèmes autonomes.

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…

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

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.

Le protocole EPP, qui sert notamment lors de la communication entre un registre (par exemple de noms de domaine) et son client, est extensible : on peut rajouter de nouveaux types d'objets et de nouvelles informations. Normalement, le serveur EPP n'envoie au client ces nouveautés que si le client a annoncé, lors de la connexion, qu'il savait les gérer. Et s'il ne l'a pas fait, que faire de ces données, ces unhandled namespaces ? Ce nouveau RFC propose de les envoyer quand même, mais dans un élément XML prévu pour des informations supplémentaires, et qui ne devrait donc rien casser chez le client.

Le but est de rester compatible avec l'EPP standard, tel que normalisé dans le RFC 5730. Prenons l'exemple de l'extension pour DNSSEC du RFC 5910. Comme toutes les extensions EPP, elle utilise les espaces de noms XML. Cette extension particulière est identifiée par l'espace de noms urn:ietf:params:xml:ns:secDNS-1.1. À l'établissement de la connexion, le serveur annonce les extensions connues :

    
<greeting 
    <svcMenu>
       ...
         <svcExtension>
            <extURI>urn:ietf:params:xml:ns:secDNS-1.1</ns0:extURI>

  

Et le client annonce ce qu'il sait gérer :

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
 <command>
   <login>
...
    <svcs>
      <svcExtension><extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI></svcExtension>
...

  

(<svcExtension> est décrit dans le RFC 5730, sections 2.4 et 2.9.1.1). Ici, le serveur a annoncé l'extension DNSSEC et le client l'a acceptée. Tout le monde va donc pouvoir envoyer et recevoir des messages spécifiques à cette extension, comme l'ajout d'une clé :

   <extension>
      <update xmlns="urn:ietf:params:xml:ns:secDNS-1.1"> 
         <add xmlns="urn:ietf:params:xml:ns:secDNS-1.1">
            <dsData xmlns="urn:ietf:params:xml:ns:secDNS-1.1">
               ...
              <digest xmlns="urn:ietf:params:xml:ns:secDNS-1.1">076CF6DA3692EFE72434EA1322177A7F07023400E4D1A1F617B1885CF328C8AA</digest>
    ...

  

Mais, si le client ne gère pas une extension (et ne l'a donc pas indiquée dans son <login>), que peut faire le serveur s'il a quand même besoin d'envoyer des messages spécifiques à cette extension inconnue du client, ce unhandled namespace ? C'est particulièrement important pour la messagerie EPP (commande <poll>) puisque le serveur peut, par exemple, mettre un message dans la boite sans connaitre les capacités du client, mais cela peut affecter également d'autres activités.

La solution de notre RFC est d'utiliser un élément EPP déjà normalisé (RFC 5730, secton 2.6), <extValue>, qui permet d'ajouter des informations que le client ne pourra pas analyser automatiquement, comme par exemple un message d'erreur lorsque le serveur n'a pas pu exécuter l'opération demandée. Notre RFC étend cet <extValue> au cas des espaces de noms non gérés. Le sous-élément <value> contiendra l'élément XML appartenant à l'espace de noms que le client ne sait pas gérer, et le sous-élément <reason> aura comme contenu un message d'information dont la forme recommandée est NAMESPACE-URI not in login services où NAMESPACE-URI est le unhandled namespace. Par exemple, le RFC cite un cas où le registre ne gère pas l'extension DNSSEC du RFC 5910 et répond :

<response>
   ...
      <extValue>
        <value>
           <secDNS:infData
               xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
             <secDNS:dsData>
                   ...
                   <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
             </secDNS:dsData>
           </secDNS:infData>
        </value>
        <reason>
           urn:ietf:params:xml:ns:secDNS-1.1 not in login services
        </reason>
      </extValue>

  

(Le RFC a aussi un autre exemple, avec l'extension de rédemption du RFC 3915.)

Ce RFC ne change pas le protocole EPP : il ne fait que décrire une pratique, compatible avec les clients actuels, pour leur donner le plus d'informations possible. Toutefois, pour informer tout le monde, cette pratique fait l'objet elle-même d'une extension, urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0, que le serveur va inclure dans son <greeting> et que le client mettra dans sa liste d'extensions acceptées. (Cet espace de nom a été mis dans le registre IANA créé par le RFC 3688. L'extension a été ajoutée au registre des extensions EPP introduit par le RFC 7451.) De toute façon, le client a tout intérêt à inclure dans sa liste toutes les extensions qu'il gère et à regarder s'il y a des <extValue> dans les réponses qu'il reçoit (même si la commande EPP a été un succès) ; cela peut donner des idées aux développeurs sur des extensions supplémentaires qu'il serait bon de gérer. Quant au serveur, il est bon que son administrateur regarde s'il y a eu des réponses pour des unhandled namespaces et prenne ensuite contact avec l'administrateur du client pour lui signaler ce manque.

Notez que ce RFC s'applique aux extensions portant sur les objets manipulés en EPP (par exemple les noms de domaine) et à celles portant sur les séquences de commandes et de réponses EPP, mais pas aux extensions portant sur le protocole lui-même (cf. RFC 3735).

Question mises en œuvre de ce RFC, le SDK de Verisign inclut le code nécessaire (dans le fichier gen/java/com/verisign/epp/codec/gen/EPPFullExtValuePollMessageFilter.java). D'autre part, le registre du .ch utilise ce concept d'espaces de noms inconnus pour indiquer au BE les changements d'un domaine provoqués par l'utilisation du CDS du RFC 7344, puisque ces changements ne sont pas passés par EPP.

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 faillite, qui fait que plus rien ne marche. Le registre doit donc envoyer régulièrement des données à l'opérateur de séquestre qui, au cas où la catastrophe survient, enverra ces données au nouveau registre, qui sera en mesure (en théorie…) de charger les données dans une nouvelle base et de reprendre les opérations. Sous quel format sont envoyées ces données ? Car il faut évidemment un format ouvert et documenté, pour que le nouveau registre ait pu développer un programme d'importation des données. C'est le but du RFC 8909 et de notre nouveau RFC 9022. Ils spécifient un format à base de XML (avec possibilité de CSV).

Par rapport au format générique du RFC 8909, notre RFC ajoute les objets spécifiques de l'industrie des noms de domaine (il est recommandé de réviser la terminologie du RFC 8499) :

• Les noms de domaine, tels que manipulés en EPP selon le RFC 5731.
• Les serveurs de noms (pour les registres où ils sont enregistrés comme objets séparés, ce qui n'est pas obligatoire), tels que gérés via EPP selon le RFC 5732.
• Les contacts (le titulaire du nom de domaine, le contact technique avec qui on verra les problèmes DNS, etc), selon le modèle utilisé en EPP par le RFC 5733.
• Les BE (Bureaux d'Enregistrement). Le cas est un peu différent car ils ne sont typiquement pas gérés via EPP puisque les sessions EPP sont justement établies par un BE, qui a donc dû être créé par un autre moyen.
• Les noms spéciaux, qui sont des noms de domaine qui ne sont pas des noms de domaines habituels mais, par exemple, des gros mots dont l'enregistrement est interdit. En anglais, le sigle officiel est NNDN, qui veut récursivement dire NNDN's Not a Domain Name.
• Les tables liées à IDN, pour les registres qui maintiennent des informations restreignant l'usage de ces noms de domaine en Unicode (cf. RFC 6927).
• Certains paramètres de configuration des serveurs EPP du registre.
• Des compteurs du nombre d'objets enregistrés.
• Des objets qui sont importants pour le registre mais pas assez répandus pour avoir fait l'objet d'une normalisation.

Le format concret du séquestre se décline en deux « modèles », un en XML et un en CSV (RFC 4180), mais j'ai l'impression que le XML est nettement plus utilisé. Dans tous les cas :

• Les dates sont au format du RFC 3339.
• Les noms des pays sont les identificateurs à deux lettres de ISO 3166.
• Les numéros de téléphone sont au format E.164.
• Les adresses IP doivent suivre le format du RFC 5952. Pour IPv4, le RFC est vague, car il n'y a pas de format standard (vous ne verrez pas une seule adresse IP dans le RFC 791, que cite notre RFC…).

Pour CSV, chaque fichier CSV représente une table (les noms de domaine, les contacts, les serveurs de noms…) et chaque ligne du fichier un objet. Le modèle de données est décrit plus précisément en section 4.6. Voici un exemple d'une ligne extraite du fichier des noms de domaine, décrivant le domaine domain1.example, créé le 3 avril 2009, et dont le titulaire a pour identificateur (handle) registrantid :

domain1.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z 
  

Les contacts seraient mis dans un autre fichier CSV, avec un fichier de jointure pour faire le lien entre domaines et contacts.

Et pour XML ? Il s'inspire beaucoup des éléments XML échangés avec EPP, par exemple pour la liste des états possibles pour un domaine. Voici un exemple (RDE = Registry Data Escrow, et l'espace de noms correspondant rdeDom est urn:ietf:params:xml:ns:rdeDomain-1.0) :

<rdeDom:domain>
      <rdeDom:name>jdoe.example</rdeDom:name>
      <rdeDom:roid>DOM03-EXAMPLE</rdeDom:roid>
      <rdeDom:status s="ok"/>
      <rdeDom:registrant>IZT01</rdeDom:registrant>
      <rdeDom:contact type="tech">IZT01</rdeDom:contact>
      <rdeDom:contact type="billing">IZT01</rdeDom:contact>
      <rdeDom:contact type="admin">IZT01</rdeDom:contact>
      <rdeDom:ns>
        <domain:hostObj>ns.jdoe.example</domain:hostObj>
      </rdeDom:ns>
      <rdeDom:clID>RAR03</rdeDom:clID>
      <rdeDom:crRr>RAR03</rdeDom:crRr>
      <rdeDom:crDate>2019-12-26T14:18:40.65647Z</rdeDom:crDate>
      <rdeDom:exDate>2020-12-26T14:18:40.509742Z</rdeDom:exDate>
</rdeDom:domain>

  

On voit que cela ressemble en effet beaucoup à ce qui avait été envoyé en EPP pour créer le domaine (cf. RFC 5731). Si vous voulez un exemple complet et réaliste, regardez les sections 14 et 15 du RFC.

Et voici un exemple de contact (RFC 5733) :

    
<rdeContact:contact>
      <rdeContact:id>IZT01</rdeContact:id>
      <rdeContact:status s="ok"/>
      <rdeContact:postalInfo type="loc">
        <contact:name>John Doe</contact:name>
        <contact:addr>
          <contact:street>12 Rue de la Paix</contact:street>
          <contact:city>Paris</contact:city>
          <contact:pc>75002</contact:pc>
          <contact:cc>FR</contact:cc>
        </contact:addr>
      </rdeContact:postalInfo>
      <rdeContact:voice>+33.0353011234</rdeContact:voice>
      <rdeContact:email>john.doe@foobar.example</rdeContact:email>
      <rdeContact:clID>RAR03</rdeContact:clID>
      <rdeContact:crRr>RAR03</rdeContact:crRr>
      <rdeContact:crDate>2019-12-26T13:47:05.580392Z</rdeContact:crDate>
      <rdeContact:disclose flag="0">
        <contact:name type="loc"/>
        <contact:addr type="loc"/>
        <contact:voice/>
        <contact:fax/>
        <contact:email/>
      </rdeContact:disclose>
</rdeContact:contact>

  

On notera l'élement <disclose> qui indique qu'on ne doit pas diffuser le nom, l'adresse ou d'autres éléments sur le contact (normal, il s'agit d'une personne physique, et la loi Informatique & Libertés s'applique, cf. section 14 du RFC). La jointure avec les domaines dont il est contact (comme le jdoe.example plus haut), se fait sur l'identificateur (élément <id>, dit aussi handle). L'information sur l'adresse a le type loc, ce qui veut dire qu'elle peut utiliser tout le jeu de caractères Unicode. Avec le type int, elle serait restreinte à l'ASCII (une très ancienne erreur fait que EPP appelle loc - local, ce qui est internationalisé et int - international ce qui est restreint aux lettres utilisées en anglais).

Et enfin, un objet représentant un serveur de noms (RFC 5732) :

<rdeHost:host>
      <rdeHost:name>ns1.foobar.example</rdeHost:name>
      <rdeHost:status s="ok"/>
      <rdeHost:addr ip="v6">2001:db8:cafe:fada::53</rdeHost:addr>
      <rdeHost:clID>RAR02</rdeHost:clID>
      <rdeHost:crRr>RAR02</rdeHost:crRr>
      <rdeHost:crDate>2020-05-13T12:37:41.788684Z</rdeHost:crDate>
</rdeHost:host>         

  

Ce format de séquestre permet aussi de représenter des objets qui n'ont pas d'équivalent en EPP, comme les bureaux d'enregistrement, qui ne peuvent pas être créés en EPP puisque la session EPP est liée au client du registre, donc au bureau d'enregistrement. Un exemple de BE (Bureau d'Enregistrement) :

<rdeRegistrar:registrar>
      <rdeRegistrar:id>RAR21</rdeRegistrar:id>
      <rdeRegistrar:name>Name Business</rdeRegistrar:name>
      <rdeRegistrar:status>ok</rdeRegistrar:status>
      <rdeRegistrar:postalInfo type="loc">
        <rdeRegistrar:addr>
          <rdeRegistrar:street>1 rue du Test</rdeRegistrar:street>
          <rdeRegistrar:city>Champignac</rdeRegistrar:city>
          <rdeRegistrar:cc>FR</rdeRegistrar:cc>
        </rdeRegistrar:addr>
      </rdeRegistrar:postalInfo>
      <rdeRegistrar:voice>+33.0639981234</rdeRegistrar:voice>
      <rdeRegistrar:fax>+33.0199001234</rdeRegistrar:fax>
      <rdeRegistrar:email>master-of-domains@namebusiness.example</rdeRegistrar:email>
</rdeRegistrar:registrar>    
 
  

On peut aussi mettre dans le séquestre des références vers ses tables IDN (que l'ICANN exige mais qui n'ont aucun intérêt). Plus intéressant, la possibilité de stocker dans le séquestre les listes de termes traités spécialement, par exemple interdits ou bien soumis à un examen manuel. Cela se nomme NNDN pour « NNDN's not domain name », oui, c'est récursif. Voici un exemple :

<rdeNNDN:NNDN>
     <rdeNNDN:uName>gros-mot.example</rdeNNDN:uName>
     <rdeNNDN:nameState>blocked</rdeNNDN:nameState>
     <rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:crDate>
   </rdeNNDN:NNDN>

  

Tous les registres n'ont pas les mêmes règles et le RFC décrit également les mécanismes qui permettent de spécifier dans le séquestre les contraintes d'intégrité spécifiques d'un registre. L'opérateur de séquestre, qui reçoit le fichier XML ou les fichiers CSV, est censé vérifier tout cela (autrement, il ne joue pas son rôle, s'il se contente de stocker aveuglément un fichier). La section 8 de notre RFC décrit plus en profondeur les vérifications recommandées, comme de vérifier que les contacts indiqués pour chaque domaine sont bien présents. Pour vérifier un séquestre, il faut importer beaucoup de schémas. Voici, la liste, sous forme d'une commande shell :

for schema in contact-1.0.xsd  host-1.0.xsd		rdeDomain-1.0.xsd     rdeIDN-1.0.xsd	    rgp-1.0.xsd domain-1.0.xsd	 rde-1.0.xsd		rdeEppParams-1.0.xsd  rdeNNDN-1.0.xsd	    secDNS-1.1.xsd epp-1.0.xsd	 rdeContact-1.0.xsd	rdeHeader-1.0.xsd     rdePolicy-1.0.xsd   eppcom-1.0.xsd	 rdeDnrdCommon-1.0.xsd	rdeHost-1.0.xsd       rdeRegistrar-1.0.xsd); do
   wget https://www.iana.org/assignments/xml-registry/schema/${schema}
done   
  

Ensuite, on importe (fichier escrow-wrapper.xsd) et on utilise xmllint sur l'exemple de séquestre de la section 14 du RFC (fichier escrow-example.xml) :

% xmllint --noout --schema wrapper.xsd escrow-example.xml                            
escrow-example.xml validates
  

Ouf, tout va bien, le registre nous a envoyé un séquestre correct.

Enfin, la syntaxe formelle de ce format figure dans la section 9 du RFC, dans le langage XML Schema.

Ce format est mis en œuvre par tous les TLD qui sont liés par un contrat avec l'ICANN. 1 200 TLD envoient ainsi un séquestre une fois par semaine à l'ICANN.

Le concept de séquestre pose de sérieux problèmes de sécurité car le ou les fichiers transmis sont typiquement à la fois confidentiels, et cruciaux pour assurer la continuité de service. Lors du transfert du fichier, le registre et l'opérateur de séquestre doivent donc vérifier tous les deux l'authenticité du partenaire, et la confidentialité de la transmission. D'autant plus qu'une bonne partie du fichier est composée de données personnelles.

Le protocole de transport QUIC est toujours sécurisé par la cryptographie. Il n'y a pas de communication en clair avec QUIC. Cette sécurisation se fait actuellement par TLS mais QUIC utilise TLS d'une manière un peu spéciale, documentée dans ce RFC.

Fini d'hésiter entre une version avec TLS ou une version sans. Avec QUIC, c'est forcément chiffré et, pour l'instant, avec TLS (dans le futur, QUIC pourra utiliser d'autres protocoles, mais ce n'est pas encore défini). QUIC impose en prime au minimum TLS 1.3 (RFC 8446), qui permet notamment de diminuer la latence, la communication pouvant s'établir dans certains cas dès le premier paquet. Petit rappel de TLS, pour commencer : TLS permet d'établir un canal sûr, fournissant authentification du serveur et confidentialité de la communication, au-dessus d'un media non-sûr (l'Internet). TLS est normalement constitué de deux couches, la couche des enregistrements (record layer) et celle de contenu (content layer), qui inclut notamment le mécanisme de salutation initial. On établit une session avec le protocole de salutation (handshake protocol), puis la couche des enregistrements chiffre les données (application data) avec les clés issues de cette salutation. Les clés ont pu être créées par un échange Diffie-Helman, ou bien être pré-partagées (PSK, pour Pre-Shared Key), ce dernier cas permettant de démarrer la session immédiatement (« 0-RTT »).

QUIC utilise TLS d'une façon un peu spéciale. Certains messages TLS n'existent pas comme ChangeCipherSpec ou KeyUpdate (QUIC ayant ses propres mécanismes pour changer la cryptographie en route, cf. section 6), et, surtout, la couche des enregistrements disparait, QUIC faisant le chiffrement selon son format, mais avec les clés négociées par TLS.

La poignée de mains qui établit la session TLS peut donc se faire de deux façons :

• « 1-RTT » où le client et le serveur peuvent envoyer des données après un aller-retour (RTT). Rappelez-vous que c'est ce temps d'aller-retour qui détermine la latence, donc la « vitesse » perçue par l'utilisateur, au moins pour les transferts de faible taille (comme le sont beaucoup de ressources HTML).
• « 0-RTT », où le client peut envoyer des données dès le premier datagramme transmis. Cette façon de faire nécessite que client et serveur se soient parlés avant, et que le client ait stocké un jeton généré par le serveur (sept jours maximum, dit le RFC 8446), qui permettra au serveur de trouver tout de suite le matériel cryptographique nécessaire. Attention, le 0-RTT ne protège pas contre le rejeu, mais ce n'est pas grave pour des applications comme HTTP avec la méthode GET, qui est idempotente. Et le 0-RTT pose également problème avec la PFS (la confidentialité même en cas de compromission ultérieure des clés).

La section 3 du RFC fait un tour d'horizon général du protocole TLS tel qu'utilisé par QUIC. Comme vu plus haut, la couche des enregistrements (record layer) telle qu'utilisée avec TCP n'est plus présente, les messages TLS comme Handshake et Alert sont directement transportés sur QUIC (qui, contrairement à TCP, permet d'assurer confidentialité et intégrité). Avec TCP, la mise en couches était stricte, TLS étant entièrement au-dessus de TCP, avec QUIC, l'intégration est plus poussée, QUIC et TLS coopèrent, le premier chiffrant avec les clés fournies par le second, et QUIC transportant les messages de TLS. De même, quand on fait tourner un protocole applicatif sur QUIC, par exemple HTTP/3, celui-ci est directement placé sur QUIC, TLS s'effaçant complètement. Les applications vont donc confier leurs données à QUIC, pas à TLS. En simplifiant (beaucoup…), on pourrait dire que TLS ne sert qu'au début de la connexion. Pour citer Radia Perlman, « It is misleading to regard this as a specification of running QUIC over TLS. It is related to TLS in the same way that DTLS is related to TLS: it imports much of the syntax, but there are many differences and its security must be evaluated largely independently. My initial reaction to this spec was to wonder why it did not simply run QUIC over DTLS . I believe the answer is that careful integration improves the performance and is necessary for some of the address agility/transition design. ».

La section 4 explique plus en détail comment les messages TLS sont échangés via QUIC. Les messages cryptographiques sont transportés dans des trames de type CRYPTO. Par exemple, le ClientHello TLS sera dans une trame CRYPTO elle-même située dans un paquet QUIC de type Initial. Les Alert sont dans des trames CONNECTION_CLOSE dont le code d'erreur est l'alerte TLS. Ce sont les seuls messages que QUIC passera à TLS, il fait tout le reste lui-même.

On a vu que le principal travail de TLS est de fournir du matériel cryptographique à QUIC. Plus précisément, TLS fournit, après sa négociation avec son pair :

• Un secret, d'où la clé sera dérivée,
• une fonction de chiffrement intègre, par exemple AEAD_AES_128_GCM (AES avec GCM) ou AEAD_CHACHA20_POLY1305 (ChaCha20, RFC 8439),
• une fonction de dérivation des clés.

QUIC se servira de tout cela pour chiffrer.

QUIC impose une version minimale de TLS : la 1.3, normalisée dans le RFC 8446. Les versions ultérieures sont acceptées mais elles n'existent pas encore.

Ah et, comme toujours avec TLS, le client doit authentifier le serveur, typiquement via son certificat. Le serveur ne doit pas utiliser les possibilités TLS de ré-authentification ultérieure (message CertificateRequest) car le multiplexage utilisé par QUIC empêcherait de corréler cette demande d'authentification avec une requête précise du client.

Outre le « 0-RTT » de QUIC, qui permet au client d'envoyer des données applicatives dès le premier paquet, QUIC+TLS fournit un autre mécanisme pour gagner du temps à l'établissement de la connexion, la reprise de session (session resumption, RFC 8446, section 2.2). Si le client a enregistré les informations nécessaires depuis une précédente session avec ce serveur, il peut attaquer directement avec un NewSessionTicket dans une trame CRYPTO et abréger ainsi l'établissement de session TLS.

Les erreurs TLS, comme bad_certificate, unexpected_message ou unsupported_extension, sont définies dans le RFC 8446, section 6. Dans QUIC, elles sont transportées dans des trames de type CONNECTION_CLOSE, et mises dans le champ d'erreur (Error Code, RFC 9000, section 19.19). Notez que ces trames mènent forcément à la coupure de toute la session QUIC, et il n'y a donc pas moyen de transporter un simple avertissement TLS.

Bien, maintenant qu'on a vu le rôle de TLS, comment QUIC va-t-il utiliser les clés pour protéger les paquets ? La section 5 répond à cette question. QUIC va utiliser les clés fournies par TLS (je simplifie, car QUIC effectue quelques dérivations avant) comme clés de chiffrement intègre (RFC 5116). Il utilisera l'algorithme de chiffrement symétrique indiqué par TLS. Tous les paquets ne sont pas protégés (par exemple ceux de négociation de version, inutiles pour l'instant puisque QUIC n'a qu'une version, ne bénéficient pas de protection puisqu'il faudrait connaitre la version pour choisir les clés de protection). Le cas des paquets Initial est un peu plus subtil puisqu'ils sont chiffrés, mais avec une clé dérivée du connection ID, qui circule en clair. Donc, en pratique, seule leur intégrité est protégée, par leur confidentialité (cf. section 7 pour les conséquences).

J'ai dit que QUIC n'utilisait pas directement les clés fournies par TLS. Il applique en effet une fonction de dérivation, définie dans la section 7.1 du RFC 8446, elle-même définie à partir des fonctions du RFC 5869.

Il existe plein de pièges et de détails à prendre en compte quand on met en œuvre QUIC+TLS. Par exemple, en raison du réordonnancement des datagrammes dans le réseau, et des pertes de datagrammes, un paquet chiffré peut arriver avant le matériel cryptographique qui permettrait de le déchiffrer, ou bien avant que les affirmations du pair aient été validées. La section 5.7 du RFC explique comment gérer ce cas (en gros, jeter les paquets qui sont « en avance », ou bien les garder pour déchiffrement ultérieur mais ne surtout pas tenter de les traiter). Autre piège, QUIC ignore les paquets dont la vérification d'intégrité a échoué, alors que TLS ferme la connexion. Cela a pour conséquences qu'avec QUIC un attaquant peut essayer plusieurs fois. Il faut donc compter les échecs et couper la connexion quand un nombre maximal a été atteint (section 6.6). Bien sûr, pour éviter de faciliter une attaque par déni de service (où l'attaquant enverrait plein de mauvais paquets dans l'espoir de fermer la connexion), ces limites doivent être assez hautes (2^23 paquets pour AEAD_AES_128_GCM), voir « Limits on Authenticated Encryption Use in TLS » ou « Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3 », ainsi que l'annexe B du RFC.

Encore question détails subtils, la poignée de mains de TLS n'est pas tout à fait la même quand elle est utilisée par QUIC (section 8). Ainsi, ALPN doit être utilisé et avec succès, autrement on raccroche avec l'erreur no_application_protocol.

Le but de TLS est de fournir de la sécurité, notamment confidentialité et authentification, donc il est recommandé de bien lire la section 9, qui traite de la sécurité de l'ensemble du RFC. Ainsi, si on utilise les tickets de session de TLS (RFC 8446, section 4.6.1), comme ils sont transmis en clair, ils peuvent permettre à un observateur de relier deux sessions, même si les adresses IP sont différentes.

Le « 0-RTT » est formidable pour diminuer la latence, mais il diminue aussi la sécurité : il n'y a pas de protection contre le rejeu. Si QUIC lui-même n'est pas vulnérable au rejeu, l'application qui travaille au-dessus de QUIC peut l'être. Prenez un protocole applicatif qui aurait des services comme, en HTTP, « envoyez-moi une pizza » (sans doute avec la méthode POST), on voit bien que le rejeu serait problématique. Bref, les applications qui, contrairement au protocole QUIC, ne sont pas idempotentes, ont tout intérêt à désactiver le 0-RTT.

QUIC tournant sur UDP, qui ne protège pas contre l'usurpation d'adresse IP, il existe en théorie un risque d'attaque par réflexion, avec amplification. Par exemple, la réponse à un ClientHello peut être bien plus grande que le ClientHello lui-même. Pour limiter les risques, QUIC impose que le premier paquet du client ait une taille minimale (pour réduire le facteur d'amplification), en utilisant le remplissage, et que le serveur ne réponde pas avec plus de trois fois la quantité de données envoyée par le client, tant que l'adresse IP de celui-ci n'a pas été validée.

Plus sophistiquées sont les attaques par canal auxiliaire. Par exemple, si une mise en œuvre de QUIC jette trop vite les paquets invalides, un attaquant qui mesure les temps de réaction pourra en déduire des informations sur ce qui n'allait pas exactement dans son paquet. Il faut donc que toutes les opérations prennent un temps constant.

Et puis, bien sûr, comme tout protocole utilisant la cryptographie, QUIC+TLS a besoin d'un générateur de nombres aléatoires correct (cf. RFC 4086).

Question mise en œuvre, notez qu'on ne peut pas forcément utiliser une bibliothèque TLS quelconque. Il faut qu'elle permette de séparer signalisation et chiffrement et qu'elle permette d'utiliser QUIC comme transport. (Et il n'y a pas d'API standard pour cela.) C'est par exemple le cas de la bibliothèque picotls. Pour OpenSSL, il faut attendre (un patch existe) et cela bloque parfois l'intégration de certains logiciels.

Et question tests, à ma connaissance, on ne peut pas actuellement utiliser openssl s_client ou gnutls-cli avec un serveur QUIC. Même problème avec le fameux site de test TLS https://ssllabs.com/.

Pour terminer, voici l'analyse d'une communication QUIC+TLS, analyse faite avec Wireshark. D'abord, le premier paquet, de type QUIC Initial, qui contient le ClientHello dans une trame de type CRYPTO :

QUIC IETF
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    .... 00.. = Reserved: 0
    .... ..11 = Packet Number Length: 4 bytes (3)
    Version: 1 (0x00000001)
    Destination Connection ID Length: 8
    Destination Connection ID: 345d144296b90cff
...
    Length: 1226
    Packet Number: 0
    TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 384
        Crypto Data
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 380
            ...
            Extension: quic_transport_parameters (len=85)
                Type: quic_transport_parameters (57)
                Length: 85
                Parameter: initial_max_stream_data_bidi_local (len=4) 2097152
                    Type: initial_max_stream_data_bidi_local (0x05)
                    Length: 4
                    Value: 80200000
                    initial_max_stream_data_bidi_local: 2097152
             ...
  

Dans les extensions TLS, notez l'extension spécifique à QUIC, quic_transport_parameters. QUIC « abuse » de TLS en s'en servant pour emballer ses propres paramètres. (La liste de ces paramètres de transport figure dans un registre IANA.)

La réponse à ce paquet Initial contiendra le ServerHello TLS. La poignée de mains se terminera avec les paquets QUIC de type Handshake. TLS ne servira plus par la suite, QUIC chiffrera tout seul.

Pour tout protocole de transport, détecter les pertes de paquets, et être capable d'émettre et de réémettre des paquets sans provoquer de congestion sont deux tâches essentielles. Ce RFC explique comment le protocole QUIC assure cette tâche.

Pour l'instant, TCP reste le principal protocole de transport sur l'Internet. Mais QUIC pourrait le dépasser. QUIC est normalisé dans une série de RFC et notre RFC 9002 se charge d'une tâche délicate et cruciale : expliquer comment détecter les pertes de paquets, et comment ne pas contribuer à la congestion. Voyons d'abord la conception générale (section 3 du RFC). Les messages QUIC sont mis dans des trames, une ou plusieurs trames sont regroupées dans un paquet (qui n'est pas un paquet IP) et un ou plusieurs paquets sont dans un datagramme UDP qu'on envoie à son correspondant. Les paquets ont un numéro (RFC 9000, section 12.3). Ces numéros ne sont pas des numéros des octets dans les données envoyées, notamment, un numéro de paquet ne se répète jamais dans une connexion. Alors qu'on peut envoyer les mêmes données plusieurs fois, s'il y a perte et réémission ; en cas de retransmission, les données sont renvoyées dans un nouveau paquet, avec un nouveau numéro, contrairement à TCP. Cela permet de savoir facilement si c'est une retransmission. (TCP, lui, essaie de déduire l'ordre de distribution du numéro de séquence, et ce n'est pas trivial.)

La plupart des paquets QUIC feront l'objet d'un accusé de réception mais attention. Il y a des trames dont le type exige un accusé de réception et d'autres non. Si un paquet ne contient que des trames n'exigeant pas d'accusé de réception, ce paquet ne sera confirmé par le récepteur qu'indirectement, lors de la réception d'un paquet ultérieur contenant au moins une trame exigeant un accusé de réception.

QUIC n'est pas TCP, cela vaut la peine de le rappeler. La très intéressante section 4 du RFC enfonce le clou en énumérant les différences entre les algorithmes de TCP et ceux de QUIC, pour assurer les mêmes fonctions. Ainsi, dans TCP, tous les octets sont numérotés selon un seul espace de numérotation (les numéros de séquence) alors que QUIC a plusieurs espaces, les paquets servant à établir la connexion ne partagent pas leurs numéros avec ceux des données. QUIC fonctionne ainsi car les premiers sont moins protégés par la cryptographie.

Pour TCP, le numéro de séquence indique à la fois l'ordre d'émission et l'ordre de l'octet dans le flux de données. Le problème de cette approche est que, en cas de retransmission, le numéro de séquence n'indique plus l'ordre d'émission, rendant difficile de distinguer une émission initiale et une retransmission (ce qui serait pourtant bien utile pour estimer le RTT). Au contraire, dans QUIC, le numéro de paquet n'identifie que l'ordre d'émission. La retransmission a donc forcément un numéro supérieur à l'émission initiale. Pour déterminer la place des octets dans le flux de données, afin de s'assurer que l'application reçoive les données dans l'ordre, QUIC utilise le champ Offset des trames de type STREAM, celles qui transmettent les données (RFC 9000, section 19.8). QUIC a ainsi moins d'ambiguités, par exemple quand il faut mesurer le taux de pertes.

QUIC, comme TCP, doit estimer le temps optimum pour décider qu'un paquet est perdu (RTO, pour Retransmission TimeOut). QUIC est plus proche de l'algorithme du RFC 8985 que du TCP classique. La section 5 du RFC détaille l'estimation du RTT.

La section 6 porte sur le problème délicat de la détection des pertes de paquets. La plupart des paquets QUIC doivent faire l'objet d'un accusé de réception. S'il n'est pas arrivé avant un temps limite, le paquet est décrété perdu, et il faudra demander une réémission (RFC 9000, section 13.3). Plus précisement, le paquet est considéré comme perdu s'il avait été envoyé avant un paquet qui a fait l'objet d'un accusé de réception et s'il s'est écoulé N paquets depuis ou bien un temps suffisamment long. (TCP fait face à exactement le même défi, et la lecture des RFC 5681, RFC 5827, RFC 6675 et RFC 8985 est recommandée.) La valeur recommandée pour N est 3, pour être proche de TCP. Mais attention si le réseau fait que les paquets arrivent souvent dans le désordre, cela pourrait mener à des paquets considérés à tort comme perdus. Le problème existait déjà pour TCP mais il est pire avec QUIC puisque des équipements intermédiaires sur le réseau qui remettaient les paquets dans l'ordre ne peuvent plus fonctionner avec QUIC, qui chiffre le plus de choses possibles pour éviter ces interventions souvent maladroites. Et le délai avant lequel on déclare qu'un paquet est perdu ? Il doit tenir compte du RTT qu'on doit donc mesurer.

Une fois la ou les pertes détectées, on réémet les paquets. Simple, non ? Sauf qu'il faut éviter que cette réémission n'aggrave les problèmes et ne mène à la congestion (le réseau, trop chargé, perd des paquets, les émetteurs réémettent, chargeant le réseau, donc on perd davantage de paquets, donc les émetteurs réémettent encore plus…). L'algorithme actuellement spécifié pour QUIC (section 7 du RFC) est proche du NewReno de TCP (normalisé dans le RFC 6582). Mais le choix d'un algorithme de contrôle de l'émetteur est unilatéral, et une mise en œuvre de QUIC peut toujours en choisir un autre, comme Cubic (RFC 8312). Évidemment, pas question d'être le gros porc qui s'attribue toute la capacité réseau pour lui seul, et cet algorithme doit de toute façon respecter les principes du RFC 8085 (en résumé : ne soyez pas égoïste, et pensez aux autres, laissez-leur de la capacité).

Pour aider à cette lutte contre la congestion, QUIC, comme TCP, peut utiliser ECN (RFC 3168 et RFC 8311).

Comme TCP, QUIC doit démarrer une nouvelle session doucement (RFC 6928) et non partir bille en tête avec une fenêtre de grande taille.

La réaction aux pertes de paquets peut avoir des conséquences sur la sécurité (section 8 du RFC). Par exemple, les « signaux » utilisés par QUIC pour décider qu'il y a eu une perte (l'absence d'un paquet, le RTT, ECN) ne sont pas protégés par la cryptographie, contrairement aux données transportées et à certaines métadonnées. Un attaquant actif peut fausser ces signaux et mener QUIC à réduire son débit. Il n'y a pas vraiment de protection contre cela. Autre risque de sécurité, alors que QUIC est normalement conçu pour priver un observateur de beaucoup d'informations qui, avec TCP étaient en clair, il n'atteint pas 100 % de succès dans ce domaine. Par exemple les paquets ne contenant que des accusés de réception (trames de type ACK) peuvent être identifiés par leur taille (ils sont tout petits), et l'observateur peut alors en déduire des informations sur les performances du chemin. Si on veut éviter cela, il faut utiliser le remplissage des accusés de réception.

Vous aimez lire des programmes ? L'annexe A du RFC contient du pseudo-code mettant en œuvre les mécanismes de récupération décrits dans le RFC.

Ce RFC, qui fait partie de la première fournée sur QUIC, décrit les invariants du protocole QUIC, les choses qui ne changeront pas dans les futures versions de QUIC.

Comme tous les protocoles Internet, QUIC doit faire face à l'ossification, cette tendance à rendre les changements impossibles, en raison du nombre de composants du réseau qui refusent tout comportement qu'ils n'attendaient pas, même si c'était une évolution prévue ou en tout cas possible. Une des méthodes pour limiter cette ossification est la documentation d'invariants, des parties du protocole dont on promet qu'elles ne changeront pas dans les futures versions. Tout le reste peut bouger et les équipements comme les middleboxes peuvent donc s'appuyer sur ce RFC pour faire les choses proprement, en sachant ce qui durera longtemps, et ce qui est susceptible d'évoluer.

La section 15 du RFC 9000 explique le principe des versions de QUIC. QUIC est actuellement à la version 1. C'est la seule pour l'instant. Mais si une version 2 (puis 3, puis 4…) apparait un jour, il faudra négocier la version utilisée entre les deux parties (section 6 du RFC 9000). Ces nouvelles versions pourront améliorer le protocole, répondant à des phénomènes qui ne sont pas forcément prévisibles. Par exemple QUIC v1 utilise forcément TLS pour la sécurité (RFC 9001), mais les futures versions pourront peut-être utiliser un autre protocole cryptographique, plus sûr, ou plus rapide. L'expérience de nombreux protocoles IETF est qu'il est difficile de déployer une nouvelle version d'un protocole déjà en place, car il y a toujours des équipements dans le réseau qui faisaient des suppositions sur le protocole, qui ne sont plus vraies avec la nouvelle version (et, souvent même pas avec l'ancienne…) et qui pertuberont, voire couperont la communication. D'où cette idée de documenter les invariants, en indiquant donc clairement que tout ce qui n'est pas invariant… peut changer. Un exemple d'invariant est « A QUIC packet with a long header has the high bit of the first byte set to 1. All other bits in that byte are version specific. ». Actuellement (version 1), le deuxième bit vaut forcément 1 (RFC 9000, section 17.2), mais ce n'est pas un invariant : les autres versions feront peut-être différemmment.

Concevoir des invariants est tout un art. Trop d'invariants et QUIC ne peut plus évoluer. Pas assez d'invariants et ils ne servent plus à rien. Ainsi, il semble difficile de faire un répartiteur de charge qui marche avec toutes les futures versions de QUIC (pas assez d'invariants pour lui).

Et dans les paquets, qu'est-ce qui sera invariant ? (Petit rappel au passage, un datagramme UDP peut contenir plusieurs paquets QUIC.) Il y a deux sortes de paquets, les longs et les courts. (Plus rigoureusement, ceux à en-tête long et ceux à en-tête court.) On les distingue par le premier bit. Tous les autres bits du premier octet sont spécifiques d'une version particulière de QUIC, et ne sont donc pas invariants. Ce premier octet est suivi d'un numéro de version sur 32 bits (aujourd'hui, forcément 1, sauf en cas de négociation de version, non encore spécifiée), puis du connection ID de la destination (attention : longueur variable, dans les paquets longs, il est encodé sous forme longueur puis valeur, cela permettra d'avoir des identificateurs de connexion très longs dans le futur) puis, mais seulement pour les paquets longs, du connection ID de la source. Tout le reste du paquet dépend de la version de QUIC utilisée.

Notez que la longueur des paquets n'étant pas dans les invariants, on ne peut même pas trouver combien il y a de paquets QUIC dans un datagramme de manière indépendante de la version.

L'identificateur de connexion est une donnée opaque : la façon de le choisir pourra varier dans le futur.

Bien sûr, spécifier rigoureusement les invariants n'empêchera pas les middleboxes de tirer des fausses conclusions et, par exemple, de généraliser des comportements de la version 1 de QUIC à toutes les versions ultérieures (section 7 du RFC). L'annexe A donne une liste (sans doute incomplète) des suppositions qu'un observateur pourrait faire mais qui sont erronées. QUIC essaie de réduire ce qu'on peut observer, en chiffrant au maximum, afin de limiter ces suppositions erronées, mais il reste des choses visibles, qui ne sont pas forcément invariantes. Le RFC écrit ces suppositions de manière neutre, en notant qu'elles sont fausses. J'ai préféré rédiger en insistant sur leur fausseté. Donc, rappelez-vous que, notamment dans les futures versions de QUIC :

• QUIC n'utilise pas forcément TLS,
• les paquets longs peuvent apparaitre même après l'établissement de la connexion,
• il n'y aura pas toujours de phase de connexion au début,
• le dernier paquet avant une période de silence n'est pas forcément uniquement un accusé de réception,
• les numéros de paquet ne croissent pas forcément de un à chaque paquet,
• ce n'est pas toujours le client qui parle le premier,
• les connection ID peuvent changer très vite,
• le second bit du premier octet, parfois appelé à tort le « QUIC bit », n'est pas forcément à un, et il avait même été proposé de le faire varier (ce qu'on appelle le graissage, cf. RFC 8701),
• et plusieurs autres points.

À noter que le numéro de version n'apparait que dans les paquets longs. Un programme qui observe des paquets QUIC de versions différentes ne peut donc analyser les paquets courts que s'il a mémorisé les numéros de versions correspondant à chaque connection ID de destination qu'il voit.

Autre point important : il n'y a pas d'invariant qui identifie un paquet QUIC. Pas de nombre magique ou de chose équivalente. Donc, aucun moyen d'être raisonnablement sûr que ce qui passe est du QUIC. C'est bien sûr volontaire, pour augmenter les chances que la neutralité soit respectée. Mais cela peut amener des middleboxes agressives à essayer de deviner si c'est bien du QUIC ou pas, en se trompant. (Le « QUIC bit » n'est évidemment pas une preuve suffisante, il peut s'agir d'un autre protocole où ce bit vaut 1.)

Le protocole de transport QUIC vient d'être normalisé, dans une série de quatre RFC. J'ai écrit un résumé synthétique de QUIC, cet article porte sur le principal RFC du groupe, celui qui normalise le cœur de QUIC, le mécanisme de transport des données. QUIC, comme TCP, fournit aux protocoles applicatifs un service de transport des données fiable, et en prime avec authentification et confidentialité.

L'un des buts principaux de QUIC est de réduire la latence. La capacité des réseaux informatiques augmente sans cesse, et va continuer de la faire, alors que la latence sera bien plus difficile à réduire. Or, elle est déterminante dans la perception de « vitesse » de l'utilisateur. Quels sont les problèmes que pose actuellement l'utilisation de TCP, le principal protocole de transport de l'Internet ?

• Head-of-line blocking, quand une ressource rapide est bloquée par une lente située avant elle dans la file, ou quand la perte d'un seul paquet TCP bloque toute la connexion en attendant que les données manquantes soient réémises. Si on multiplexe au-dessus de TCP, comme le fait HTTP/2 (RFC 7540), tous les ruisseaux d'une même connexion doivent attendre.
• Latence due à l'ouverture de la session TLS, d'autant plus que TCP et TLS étant découplés, TLS doit attendre que TCP ait fini pour commencer sa négociation.

Le cahier des charges de QUIC était à peu près :

• Déployable aujourd'hui, sans changement important de l'Internet. Compte-tenu du nombre de boitiers intermédiaires intrusifs (cf. RFC 7663), cela exclut le développement d'un nouveau protocole de transport reposant directement sur IP : il faut passer sur TCP ou UDP. Les solutions « révolutionnaires » ont donc été abandonnées immédiatement.
• Faible latence, notamment pour le démarrage de la session.
• Meilleure gestion de la mobilité (ne pas casser les sessions si on change de connectivité).
• Assurer la protection de la vie privée au moins aussi bien qu'avec TCP+TLS (donc, tout chiffrer). Le chiffrement ne sert d'ailleurs pas qu'à gêner la surveillance : il a aussi pour but d'empêcher les modifications que se permettent bien des FAI.
• Services aux applications à peu près semblables à ceux de TCP (distribution fiable et ordonnée des données).
• Coexistence heureuse avec TCP, aucun des deux ne doit prendre toute la capacité au détriment de l'autre (cf. RFC 5348). QUIC, comme TCP, contrôle la quantité de données envoyées, pour ne pas écrouler le réseau.

Certains de ces objectifs auraient pu être atteints en modifiant TCP. Mais TCP étant typiquement mis en œuvre dans le noyau du système d'exploitation, tout changement de TCP met un temps trop long à se diffuser. En outre, si les changements à TCP sont importants, ils peuvent être bloqués par les boitiers intermédiaires, comme si c'était un nouveau protocole.

QUIC peut donc, plutôt qu'à TCP, être comparé à SCTP tournant sur DTLS (RFC 8261), et on peut donc se demander pourquoi ne pas avoir utilisé ce système. C'est parce que :

• La latence pour établir une session est très élevée. SCTP et DTLS étant deux protocoles séparés, il faut d'abord se « connecter » avec DTLS, puis avec SCTP (RFC 8261, section 6.1).
• Cette séparation de SCTP et DTLS fait d'ailleurs que d'autres tâches sont accomplies deux fois (alors que dans QUIC, chiffrement et transport sont intégrés, cf. RFC 9001).

Pour une comparaison plus détaillée de SCTP et QUIC, voir l'Internet-Draft draft-joseph-quic-comparison-quic-sctp. (SCTP peut aussi tourner sur UDP - RFC 6951 mais j'ai plutôt utilisé SCTP sur DTLS comme point de comparaison, pour avoir le chiffrement.) Notez que ces middleboxes intrusives sont particulièrement répandues dans les réseaux pour mobiles, type 4G (où elles sont parfois appelée TCP proxies), puisque c'est un monde où on viole bien plus facilement la neutralité du réseau.

Faire mieux que TCP n'est pas évident. Ce seul RFC fait 207 pages, et il y a d'autres RFC à lire. Déjà, commençons par un peu de terminologie :

• Client et serveur ont le sens habituel, le client est l'initiateur de la connexion QUIC, le serveur est le répondeur,
• Un paquet QUIC n'est pas forcément un datagramme IP ; plusieurs paquets peuvent se trouver dans un même datagramme envoyé sur UDP,
• Certains paquets déclenchent l'émission d'un accusé de réception (ACK-eliciting packets) mais pas tous,
• Dans un paquet, il y a plusieurs unités de données, les trames. Il existe plusieurs types de trames, par exemple PING sert uniquement à déclencher l'accusé de réception, alors que STREAM contient des données de l'application.
• Une adresse est la combinaison d'une adresse IP, et d'un port. Elle sert à identifier une extrémité du chemin entre client et serveur mais pas à identifier une connexion.
• L'identifiant de connexion (CID, connection ID) joue ce rôle. Il permet à QUIC de gérer les cas où un routeur NAT change le port source, ou bien celui où on change de type de connexion.
• Un ruisseau (stream) est un canal de données à l'intérieur d'une connexion QUIC. QUIC multiplexe des ruisseaux. Par exemple, pour HTTP/3 (le RFC n'est pas encore publié), chaque ressource (image, feuille de style, etc) voyagera dans un ruisseau différent.

Maintenant, plongeons dans le RFC. Rappelez-vous qu'il est long ! Commençons par les ruisseaux (section 2 du RFC). Ils ressemblent aux ruisseaux de HTTP/2 (RFC 7540), ce qui est logique, QUIC ayant été conçu surtout en pensant à HTTP. Chaque ruisseau est un flux ordonné d'octets. Dans une même connexion QUIC, il y a plusieurs ruisseaux. Les octets d'un ruisseau sont reçus dans l'ordre où ils ont été envoyés (plus exactement, QUIC doit fournir ce service mais peut aussi fournir un service dans le désordre), ce qui n'est pas forcément le cas pour les octets d'une même connexion. (Dans le cas de HTTP, cela sert à éviter qu'une ressource lente à se charger ne bloque tout le monde.) Comme avec TCP, les données sont un flot continu, même si elles sont réparties dans plusieurs trames. La création d'un ruisseau est très rapide, il suffit d'envoyer une trame avec l'identifiant d'un ruisseau et hop, il est créé. Les ruisseaux peuvent durer très longtemps, ou au contraire tenir dans une seule trame.

J'ai parlé de l'identifiant d'un ruisseau. Ce numéro, ce stream ID est pair pour les ruisseaux créés par le client, impair s'ils sont créés par le serveur. Cela permet à client et serveur de créer des ruisseaux sans se marcher sur les pieds. Un autre bit dans l'identifiant indique si le ruisseau est bidirectionnel ou unidirectionnel.

Une application typique va donc créer un ou plusieurs ruisseaux, y envoyer des données, en recevoir, et fermer les ruisseaux, gentiment (trame STREAM avec le bit FIN) ou brutalement (trame RESET_STREAM). La machine à états complète des ruisseaux figure dans la section 3 du RFC.

Comme avec TCP, il ne s'agit pas d'envoyer des données au débit maximum, sans se soucier des conséquences. Il faut se contrôler, à la fois dans l'intérêt du réseau (éviter la congestion) et dans celui du récepteur, qui a peut-être du mal à traiter tout ce qu'on lui envoie. D'où, par exemple, la trame STOP_SENDING qui dit à l'émetteur de se calmer.

Plus fondamentalement, le système de contrôle de QUIC est décrit dans la section 4. Il fonctionne aussi bien par ruisseau qu'au niveau de toute la connexion. C'est le récepteur qui contrôle ce que l'émetteur peut envoyer, en disant « j'accepte au total N octets ». Il le fait à l'établissement de la connexion puis, lorsqu'il peut à nouveau traiter des données, via les trames MAX_DATA (pour l'ensemble de la connexion) et MAX_STREAM_DATA (valables, elles, pour un seul ruisseau). Normalement, les quantités d'octets que l'émetteur peut envoyer sont toujours croissantes. Par exemple, à l'établissement de la connexion, le récepteur annonce qu'il peut traiter 1 024 octets. Puis, une fois qu'il a des ressources disponibles, il signalera qu'il peut traiter 2 048 octets. Si l'émetteur ne lui avait transmis que 1 024, cette augmentation lui indiquera qu'il peut reprendre l'émission. Si l'émetteur envoie plus de données qu'autorisé, le récepteur ferme brutalement la connexion. À noter que les trames de type CRYPTO ne sont pas concernées car elles peuvent être nécessaires pour changer les paramètres cryptographiques (RFC 9001, section 4.1.3).

J'ai parlé des connexions QUIC mais pas encore dit comment elles étaient établies. La section 5 le détaille. Comme QUIC tourne sur UDP, un certain nombre de gens n'ont pas compris le rôle d'UDP et croient que QUIC est sans connexion. Mais c'est faux, QUIC impose l'établissement d'une connexion, c'est-à-dire d'un état partagé entre l'initiateur (celui qui sollicite une connexion) et le répondeur. La négociation initiale permettra entre autres de se mettre d'accord sur les paramètres cryptographiques, mais aussi sur le protocole applicatif utilisé (par exemple HTTP). QUIC permet d'envoyer des données dès le premier paquet (ce qu'on nomme le « 0-RTT ») mais rappelez-vous que, dans ce cas, vous n'êtes plus protégé contre les attaques par rejeu. Ce n'est pas grave pour un GET HTTP mais cela peut être gênant dans d'autres cas.

Une fonction essentielle aux connexions QUIC est le connection ID. Il s'agit d'un identificateur de la connexion, qui lui permettra notamment de survivre aux changements de connectivité (passage de 4G dehors en WiFi chez soi, par exemple) ou aux fantaisies des routeurs NAT qui peuvent subitement changer les ports utilisés. Quand un paquet QUIC arrive sur une machine, c'est ce connection ID qui sert à démultiplexer les paquets entrants, et à trouver les paramètres cryptographiques à utiliser pour le déchiffrer. Il n'y a pas qu'un connection ID mais tout un jeu, car, comme il circule en clair, il pourrait être utilisé pour suivre à la trace un utilisateur. Ainsi, quand une machine change d'adresse IP, la bonne pratique est de se mettre à utiliser un connection ID qui faisait partie du jeu de départ, mais n'a pas encore été utilisé, afin d'éviter qu'un surveillant ne fasse le rapprochement entre les deux adresses IP. Notez que le jeu de connection ID négocié au début peut ensuite être agrandi avec des trames NEW_CONNECTION_ID.

Dans quel cas un port peut-il changer ? QUIC utilise UDP, pour maximiser les chances de passer à travers les pare-feux et les routeurs NAT. Cela pose des problèmes si le boitier intermédiaire fait des choses bizarres. Par exemple, si un routeur NAT décide de mettre fin à une connexion TCP qui n'a rien envoyé depuis longtemps, il peut génerer un message RST (ReSeT) pour couper la connexion. Rien de tel en UDP, où le routeur NAT va donc simplement supprimer de sa table de correspondance (entre adresses publiques et privées) une entrée. Après cela, les paquets envoyés par la machine externe seront jetés sans notification, ceux envoyés par la machine interne créeront une nouvelle correspondance, avec un port source différent et peut-être même une adresse IP source différente. La machine externe risque donc de ne pas les reconnaitre comme des paquets appartenant à la même connexion QUIC. En raison des systèmes de traduction d'adresses, l'adresse IP source et le port source vus par le pair peuvent changer pendant une même « session ». Pour permettre de reconnaitre une session en cours, QUIC utilise donc le connection ID, un nombre de longueur variable généré au début de la connexion (un dans chaque direction) et présent dans les paquets. (Le connection ID source n'est pas présent dans tous les paquets.)

Vous avez vu qu'une connexion QUIC peut parfaitement changer d'adresse IP en cours de route. Cela aura certainement des conséquences pour tous les systèmes qui enregistrent les adresses IP comme identificateur d'un dialogue, du journal d'un serveur HTTP (qu'est-ce que Apache va mettre dans son access_log ?) aux surveillances de la HADOPI.

Pour limiter les risques qu'une correspondance dans un routeur faisant de la traduction d'adresses n'expire, QUIC dispose de plusieurs moyens de keepalive comme les trames de type PING.

Comment l'application qui utilise QUIC va-t-elle créer des connexions et les utiliser ? La norme QUIC, dans notre RFC, ne spécifie pas d'API. Elle expose juste les services que doit rendre QUIC aux applications, notamment :

• Ouvrir une connexion (si on est initiateur),
• Attendre des demandes de connexions (si on est répondeur),
• Activer les données early data, c'est-à-dire envoyées dès le premier paquet (rappelez-vous que le rejeu est possible donc l'application doit s'assurer que cette première requête est idempotente),
• Configurer certaines valeurs comme le nombre maximal de ruisseaux ou comme la quantité de données qu'on est prêt à recevoir,
• Envoyer des trames PING, par exemple pour s'assurer que la connexion reste ouverte,
• Fermer la connexion.

Le RFC ne le spécifie pas, mais il faudra évidemment que QUIC permette à l'application d'envoyer et de recevoir des données.

Il n'y a actuellement qu'une seule version de QUIC, la 1, normalisée dans notre RFC 9000 (cf. section 15). Dans le futur, d'autres versions apparaitront peut-être, et la section 6 du RFC explique comment se fera la future négociation de version (ce qui sera un point délicat car il faudra éviter les attaques par repli). Notez que toute version future devra se conformer aux invariants du RFC 8999, une garantie de ce qu'on trouvera toujours dans QUIC.

Un point important de QUIC est qu'il n'y a pas de mode « en clair ». QUIC est forcément protégé par la cryptographie. L'établissement de la connexion impose donc la négociation de paramètres cryptographiques (section 7). Ces paramètres sont mis dans une trame CRYPTO qui fait partie du premier paquet envoyé. QUIC version 1 utilise TLS (RFC 9001). Le serveur est toujours authentifié, le client peut l'être. C'est aussi dans cette négociation cryptographique qu'est choisie l'application, via ALPN (RFC 7301).

Dans le cas courant, quatre paquets sont échangés, Initial par chacun des participants, puis Handshake. Mais, si le 0-RTT est accepté, des données peuvent être envoyées par l'initiateur dès le premier paquet.

Puisqu'UDP, comme IP, ne protège pas contre l'usurpation d'adresse IP, QUIC doit valider les adresses IP utilisées, pour éviter, par exemple, les attaques par réflexion (section 8). Si un initiateur contacte un répondeur en disant « mon adresse IP est 2001:db8:dada::1 », il ne faut pas le croire sur parole, et lui envoyer plein de données sans vérification. QUIC doit valider l'adresse IP de son correspondant, et le revalider lorsqu'il change d'adresse IP. À l'établissement de la connexion, c'est la réception du paquet Handshake, proprement chiffré, qui montre que le correspondant a bien reçu notre paquet Initial et a donc bien l'adresse IP qu'il prétend avoir. En cas de changement d'adresse IP, la validation vient du fait que le correspondant utilise un des connection ID qui avait été échangés précédemment ou d'un test explicite de joignabilité avec les trames PATH_CHALLENGE et PATH_RESPONSE. Sur ces migrations, voir aussi la section 9.

Pour les futures connexions, on utilisera un jeton qui avait été transmis dans une trame NEW_TOKEN et qu'on a stocké localement. (C'est ce qui permet le 0-RTT.) Le RFC ne spécifie pas le format de ce jeton, seule la machine qui l'a créé et qui l'envoie à sa partenaire a besoin de le comprendre (comme pour un cookie). Le RFC conseille également de n'accepter les jetons qu'une fois (et donc de mémoriser leur usage) pour limiter le risques de rejeu.

Tant que la validation n'a pas été faite, une machine QUIC ne doit pas envoyer plus de trois fois la quantité de données reçue (pour éviter les attaques avec amplification). C'est pour cela que le paquet Initial est rempli de manière à atteindre une taille (1 200 octets, exige le RFC) qui garantit que l'autre machine pourra répondre, même si elle a beaucoup à dire.

Une fois qu'on est connectés, on peut s'échanger des données, qui feront l'objet d'accusés de réception de la part du voisin (trames de type ACK). Contrairement au TCP classique, les accusés de réception ne sont pas forcément contigus, comme dans l'extension SACK du RFC 2018. Si l'accusé de réception n'est pas reçu, l'émetteur réémet, comme avec TCP.

Bon, une fois qu'on a ouvert la connexion, et échangé des données, quand on n'a plus rien à dire, que fait-on ? On raccroche. La section 10 du RFC explique comment se terminent les connexions QUIC. Cela peut se produire suite à une inactivité prolongée, suite à une fermeture explicite normale, ou bien avec le cas particulier de la fermeture sans état. Chacun des partenaires peut évidemment estimer que, s'il ne s'est rien passé depuis longtemps, il peut partir. (Cette durée maximale d'attente peut être spécifiée dans les paramètres à l'établissement de la connexion.) Mais on peut aussi raccrocher explicitement à tout moment (par exemple parce que le partenaire n'a pas respecté le protocole QUIC), en envoyant une trame de type CONNECTION_CLOSE. Cela fermera la connexion et, bien sûr, tous ses ruisseaux.

Pour que la trame CONNECTION_CLOSE soit acceptée par l'autre machine, il faut que son émetteur connaisse les paramètres cryptographiques qui permettront de la chiffrer proprement. Mais il y a un cas ennuyeux, celui où une des deux machines a redémarré, tout oublié, et reçoit des paquets d'une ancienne connexion. Comment dire à l'autre machine d'arrêter d'en envoyer ? Avec TCP, on envoie un paquet RST (ReSeT) et c'est bon. Mais cette simplicité est dangereuse car elle permet également à un tiers de faire des attaques par déni de service en envoyant des « faux » paquets RST. Des censeurs ou des FAI voulant bloquer du trafic pair-à-pair ont déjà pratiqué ce genre d'attaque. La solution QUIC à ce double problème est la fermeture sans état (stateless reset). Cela repose sur l'envoi préalable d'un jeton (cela peut se faire via un paramètre lors de l'établissement de la connexion, ou via une trame NEW_CONNECTION_ID). Pour pouvoir utiliser ces jetons, il faudra donc les stocker, mais il ne sera pas nécessaire d'avoir les paramètres cryptographiques : on ne chiffre pas le paquet de fermeture sans état, il est juste authentifié (par le jeton). Si la perte de mémoire est totale (jeton stocké en mémoire non stable, et perdu), il ne reste plus que les délais de garde pour mettre fin à la connexion. Évidemment, le jeton ne peut être utilisé qu'une fois, puisqu'un surveillant a pu le copier. Notez que les détails de ce paquet de fermeture sans état sont soigneusement conçus pour que ce paquet soit indistinguable d'un paquet QUIC « normal ».

Dans un monde idéal, tout fonctionnera comme écrit dans le RFC. Mais, dans la réalité, des machines ne vont pas suivre le protocole et vont faire des choses anormales. La section 11 du RFC couvre la gestion d'erreurs dans QUIC. Le problème peut être dans la couche de transport, ou dans l'application (et, dans ce cas, il peut être limité à un seul ruisseau). Lorsque l'erreur est dans la couche transport et qu'elle semble irrattrapable, on ferme la connexion avec une trame CONNECTION_CLOSE. Si le problème ne touche qu'un seul ruisseau, on peut se contenter d'une trame RESET_STREAM, qui met fin juste à ce ruisseau.

On a parlé de paquets et de trames. La section 12 précise ces termes :

• Les deux machines s'envoient des datagrammes UDP,
• chaque datagramme contient un ou plusieurs paquets QUIC,
• chaque paquet QUIC peut contenir une ou plusieurs trames. Chacune d'elle a un type, la liste étant dans un registre IANA.

Parmi les paquets, il y a les paquets longs et les paquets courts. Les paquets longs, qui contiennent tous les détails, sont Initial, Handshake, 0-RTT et Retry. Ce sont surtout ceux qui servent à établir la connexion. Les paquets courts sont le 1-RTT, qui ne peut être utilisé qu'après l'établissement complet de la connexion, y compris les paramètres cryptographiques. Bref, les paquets longs (plus exactement, à en-tête long) sont plus complets, les paquets courts (à en-tête court) plus efficaces.

Les paquets sont protégés par la cryptographie. (QUIC n'a pas de mode en clair.) Mais attention, elle ne protège pas la totalité du paquet. Ainsi, le connection ID est en clair puisque c'est lui qui sera utilisé à la destination pour trouver la bonne connexion et donc les bons paramètres cryptographiques pour déchiffrer. (Mais il est protégé en intégrité donc ne peut pas être modifié par un attaquant sans que ce soit détecté.) De même, les paquets Initial n'ont de protection que contre la modification, pas contre l'espionnage. En revanche, les paquets qui transportent les données (0-RTT et 1-RTT) sont complètement protégés. Les détails de ce qui est protégé et ce qui ne l'est pas figurent dans le RFC 9001.

La coalescence de plusieurs paquets au sein d'un seul datagramme UDP vise à augmenter les performances en diminuant le nombre de datagrammes à traiter. (J'en profite pour rappeler que la métrique importante pour un chemin sur le réseau n'est pas toujours le nombre d'octets par seconde qui peuvent passer par ce chemin. Parfois, c'est le nombre de datagrammes par seconde qui compte.) Par contre, si un datagramme qui comprend plusieurs paquets, qui eux-mêmes contiennent des trames de données de ruisseaux différents, est perdu, cela va évidemment affecter tous ces ruisseaux.

Les paquets ont un numéro, calculé différemment dans chaque direction, et partant de zéro. Ce numéro est chiffré. Les réémissions d'un paquet perdu utilisent un autre numéro que celui du paquet original, ce qui permet, contrairement à TCP, de distinguer émission et réémission.

Avec QUIC, les datagrammes ne sont jamais fragmentés (en IPv4), on met le bit DF à 1 pour éviter cela. QUIC peut utiliser la PLPMTUD (RFC 8899) pour trouver la MTU du chemin.

Le format exact des paquets est spécifié en section 17. Un paquet long (plus exactement, à en-tête long) se reconnait par son premier bit mis à 1. Il comprend un type (la liste est dans le RFC, elle n'est pas extensible, il n'y a pas de registre IANA), les deux connection ID et les données, dont la signification dépend du type. Les paquets de type Initial comportent entre autres dans ces données un jeton, qui pourra servir, par exemple pour les futurs connexions 0-RTT. Les paquets de type Handshake contiennent des trames de type CRYPTO, qui indiquent les paramètres cryptographiques. Quant aux paquets courts, leur premier bit est à 0, et ils contiennent moins d'information, par exemple, seul le connection ID de destination est présent, pas celui de la source.

Dans sa partie non chiffrée, le paquet a un bit qui a suscité bien des débats, le spin bit. Comme c'est un peu long à expliquer, ce bit a son propre article.

QUIC chiffre beaucoup plus de choses que TCP. Ainsi, pour les paquets à en-tête court, en dehors du connection ID et de quelques bits dont le spin bit, rien n'est exposé. Par exemple, les accusés de réception sont chiffrés et on ne peut donc pas les observer. Le but est bien de diminuer la vue offerte au réseau (RFC 8546), alors que TCP expose tout (les accusés de réception, les estampilles temporelles, etc). QUIC chiffre tellement qu'il n'existe aucun moyen fiable, en observant le trafic, de voir ce qui est du QUIC et ce qui n'en est pas. (Certaines personnes avaient réclamé, au nom de la nécessité de surveillance, que QUIC se signale explicitement .)

Les différents types de trames sont tous listés en section 19. Il y a notamment :

• PADDING qui permet de remplir les paquets pour rendre plus difficile la surveillance,
• PING qui permet de garder une connexion ouverte, ou de vérifier que la machine distante répond (il n'y a pas de PONG, c'est l'accusé de réception de la trame qui en tiendra lieu),
• ACK, les accusés de réception, qui indiquent les intervalles de numéros de paquets reçus,
• CRYPTO, les paramètres cryptographiques de la connexion,
• STREAM, qui contiennent les données, et créent les ruisseaux ; envoyer une trame de type STREAM suffit, s'il n'est pas déjà créé, à créer le ruisseau correspondant (ils sont identifiés par un numéro contenu dans cette trame),
• CONNECTION_CLOSE, pour mettre fin à la connexion.

Les types de trame figurent dans un registre IANA. On notera que l'encodage des trames n'est pas auto-descriptif : on ne peut comprendre une trame que si on connait son type. C'est plus rapide, mais moins souple et cela veut dire que, si on introduit de nouveaux types de trame, il faudra utiliser des paramètres au moment de l'ouverture de la connexion pour être sûr que l'autre machine comprenne ce type.

Bon, les codes d'erreur, désormais (section 20 du RFC). La liste complète est dans un registre IANA, je ne vais pas la reprendre ici. Notons quand même le code d'erreur NO_ERROR qui signifie qu'il n'y a pas eu de problème. Il est utilisé lorsqu'on ferme une connexion sans que pour autant quelque chose de mal se soit produit.

Si vous voulez une vision plus concrète de QUIC, vous pouvez regarder mon article d'analyse d'une connexion QUIC.

L'une des principales motivations de QUIC est la sécurité, et il est donc logique qu'il y ait une longue section 21 consacrée à l'analyse détaillée de la sécurité de QUIC. D'abord, quel est le modèle de menace ? C'est celui du RFC 3552. En deux mots : on ne fait pas confiance au réseau, tout intermédiaire entre deux machines qui communiquent peut être malveillant. Il y a trois sortes d'attaquants : les attaquants passifs (qui ne peuvent qu'écouter), les attaquants actifs situés sur le chemin (et qui peuvent donc écouter et écrire) et les attaquants actifs non situés sur le chemin, qui peuvent écrire mais en aveugle. Voyons maintenant les attaques possibles.

La poignée de mains initiale est protégée par TLS. La sécurité de QUIC dépend donc de celle de TLS.

Les attaques par réflexion, surtout dangereuses quand elles se combinent avec une amplification sont gênées, sinon complètement empêchées, par la validation des adresses IP. QUIC ne transmet pas plus de trois fois le volume de données à une adresse IP non validée. Ce point n'a pas forcément été compris par tous, et certains ont paniqué à la simple mention de l'utilisation d'UDP. C'est par exemple le cas de cet article, qui est surtout du FUD d'un vendeur.

Du fait du chiffrement, même un attaquant actif qui serait sur le chemin et pourrait donc observer les paquets, ne peut pas injecter de faux paquets ou, plus exactement, ne peut pas espérer qu'ils seront acceptés (puisque l'attaquant ne connait pas la clé de chiffrement). L'attaquant actif qui n'est pas sur le chemin, et doit donc opérer en aveugle, est évidemment encore plus impuissant. (Avec TCP, l'attaquant actif situé sur le chemin peut insérer des paquets qui seront acceptés. Des précautions décrites dans le RFC 5961 permettent à TCP de ne pas être trop vulnérable à l'attaquant aveugle.)

La possibilité de migration des connexions QUIC (changement de port et/ou d'adresse IP) apporte évidemment de nouveaux risques. La validation du chemin doit être refaite lors de ces changements, autrement, un méchant partenaire QUIC pourrait vous rediriger vers une machine innocente.

Bien sûr, les attaques par déni de service restent possibles. Ainsi, un attaquant actif sur le chemin qui a la possibilité de modifier les paquets peut tout simplement les corrompre de façon à ce qu'ils soient rejetés. Mais il y a aussi des attaques par déni de service plus subtiles. L'attaque dite Slowloris vise ainsi à épuiser une autre machine en ouvrant beaucoup de connexions qui ne seront pas utilisées. Un serveur utilisant QUIC doit donc se méfier et, par exemple, limiter le nombre de connexions par client. Le méchant client peut aussi ouvrir, non pas un grand nombre de connexions mais un grand nombre de ruisseaux. C'est d'autant plus facile que d'ouvrir le ruisseau de numéro N (ce qui ne nécessite qu'une seule trame de type STREAM) ouvre tous les ruisseaux jusqu'à N, dans la limite indiquée dans les paramètres de transport.

On a vu que dans certains cas, une machine QUIC n'a plus les paramètres qui lui permettent de fermer proprement une connexion (par exemple parce qu'elle a redémarré) et doit donc utiliser la fermeture sans état (stateless reset). Dans certains cas, un attaquant peut mettre la main sur un jeton qu'il utilisera ensuite pour fermer une connexion.

Le chiffrement, comme toute technique de sécurité, a ses limites. Ainsi, il n'empêche pas l'analyse de trafic (reconnaitre le fichier récupéré à sa taille, par exemple). D'où les trames de type PADDING pour gêner cette attaque.

QUIC a plusieurs registres à l'IANA. Si vous voulez ajouter des valeurs à ces registres, leur politique (cf. RFC 8126) est :

• Pour les ajouts provisoires, ce sera « Examen par un expert », et le RFC donne l'instruction d'être assez libéral,
• Pour les ajouts permanents, il faudra écrire une spécification (« Spécification nécessaire »). Là aussi, le RFC demande d'être assez libéral, les registres ne manquent pas de place. Par exemple, les paramètres de transport jouissent de 62 bits.
• Pour les types de trame, si la majorité de l'espace prévu suit cette politique « Spécification nécessaire », une petite partie est reservée pour enregistrement via une politique plus stricte, « Action de normalisation ».

L'annexe A de notre RFC contient du pseudo-code pour quelques algorithmes utiles à la mise en œuvre de QUIC. Par exemple, QUIC, contrairement à la plupart des protocoles IETF, a plusieurs champs de taille variable. Les encoder et décoder efficacement nécessite des algorithmes astucieux, suggérés dans cette annexe.

Il existe d'ores et déjà de nombreuses mises en œuvre de QUIC, l'écriture de ce RFC ayant été faite en parallèle avec d'innombrables hackathons et tests d'interopérabilité. Je vous renvoie à la page du groupe de travail, qui indique également des serveurs QUIC publics. Elles sont dans des langages de programmation très différents, par exemple celle de Cloudflare, Quiche, est en Rust. À ma connaissance, toutes tournent en espace utilisateur mais ce n'est pas obligatoire, QUIC pourrait parfaitement être intégré dans le noyau du système d'exploitation. Une autre bonne source pour la liste des mises en œuvre de QUIC est le Wikipédia anglophone. Notez que le navigateur Web libre Firefox a désormais QUIC.

Quelques lectures pour aller plus loin :

• Une très bonne explication de QUIC, avec des dessins très parlants à l'Université catholique de Louvain (en anglais).
• Autre très bon article d'introduction à QUIC et à ses choix principaux, celui de Cloudflare.
• Beaucoup d'articles sur QUIC ne mentionnent que ses avantages. Cet article très détaillé expose honnêtement les limites de QUIC et les problèmes qu'il pourrait rencontrer.
• QUIC soulève des problèmes politiques intéressants comme, par exemple, « vu sa complexité, peut-on encore innover s'il faut les moyens de Google ? » En effet, qui d'autre aurait pu développer et surtout pousser QUIC et faire qu'il soit déployé ? Ces problèmes stratégiques se posent à beaucoup d'endroits dans le Web, vu son importance dans nos vies. Ils sont discutés (avec d'autres) dans l'Internet-Draft draft-martini-hrpc-quichr (dont je remercie d'ailleurs les auteurs, qui m'ont bien aidé à comprendre QUIC).
• Sur l'histoire du développement de QUIC à l'IETF et notamment sur les différents choix effectués, les décisions prises, et leurs raisons, je recommande l'article de Fastly (par un des auteurs de ce RFC).
• Sur les performances, je recommande « Taking a long look at QUIC: an approach for rigorous evaluation of rapidly evolving transport protocols » de Arash Molavi Kakhki, Samuel Jero et David Choffnes , qui analysait la version Google de QUIC, avec plein de mesures concrètes (leur code est en ligne).
• Toujours question performance, Uber a ajouté QUIC dans son application et détaille les résultats obtenus.
• Sur la question de l'exposition de données aux machines intermédiaires situées sur le chemin (la « vue depuis le réseau » du RFC 8546), l'article « "A Path Layer for the Internet: Enabling Network Operations on Encrypted Protocols » explore le problème et propose des solutions, notamment dans le contexte de QUIC.

La représentation traditionnelle des humains de la préhistoire montre les hommes en train de chasser et les femmes en train de coudre, faire la cuisine ou s'occuper des enfants. Est-ce que cette représentation repose sur des données scientifiques sérieuses sur la répartition des tâches à la préhistoire ? Pas forcément, dit l'auteure.

Dans ce livre, Marylène Patou-Mathis examine ce que l'on sait de la répartition genrée des activités chez nos ancêtres. Je vous le dis tout de suite : il y a beaucoup de choses qu'on ne sait pas. On n'a pas de photos prises sur le vif des humains préhistoriques. On n'a que leurs squelettes, leurs outils et les produits de leur activité, par exemple les peintures pariétales ou les statuettes, produits qui ne sont pas faciles à interpréter. La représentation traditionnelle des rôles des deux genres reflétait davantage ce qui se faisait dans la société où vivait les auteurs de ces représentations que ce qui se faisait à la préhistoire. Souvent, on plaquait donc notre conception de la division du travail entre genres sur nos ancêtres. Ou bien on supposait qu'ils étaient forcément comme les peuples « primitifs », ou plutôt comme on voyait les peuples « primitifs » contemporains.

Bon, mais maintenant qu'on a progressé, est-ce que la science peut répondre à des questions comme « Les femmes chassaient-elles ? Autant que les hommes ? » Là, c'est plus délicat. L'auteure note que, pour la majorité des squelettes retrouvés, on n'est pas sûr de leur sexe. Et ce n'est pas mieux pour les dessins qu'on retrouve. Souvent, on suppose, justement en fonction de ce qu'on estime être la société du passé. Une tombe contient des armes ? On suppose que le défunt était un homme. (L'excellent chapitre 2 est une véritable « histoire de la misogynie chez les penseurs » et montre bien que les hommes, même scientifiques, étaient largement aveuglés par leurs préjugés sexistes.) Et, par un raisonnement circulaire, on en déduit que les hommes chassaient et faisaient la guerre. Lorsqu'on examine de plus près (comme dans le cas de la fameuse guerrière de Birka p. 169), on a parfois des surprises. Une fois qu'on a déterminé le sexe de la personne dont on retrouve le squelette, on peut étudier des choses comme les déformations liées à une activité physique répétée (le lancer de javelot semblait pratiqué par les hommes et par les femmes chez les Néandertal). Mais il est difficile, avec ce qu'on retrouve de nos ancêtres, de décrire avec précision comment les deux genres se répartissaient les tâches. L'ADN peut aider (cas de Birka), ou certaines caractéristiques du corps (la forme différente des mains entre les deux sexes montre que certaines images de mains sur les parois des grottes étaient faites par des femmes, p. 144) mais il n'y aura pas de certitude, d'autant plus que rien n'indique que toutes les sociétés préhistoriques étaient identiques.