Summary

  • La révision de novembre du projet sur les attaques contre les relais MoQ ajoute un scénario précis : un relais donne à de nombreux clients, dans GOAWAY, l’adresse d’un hôte tiers. Celui-ci reçoit leurs tentatives de connexion même s’il ne propose aucun service MoQT.
  • Le projet de transport MoQT impose au client d’utiliser la New Session URI non vide reçue dans un GOAWAY du serveur sur le flux de contrôle. Le champ désigne une destination sans démontrer que celle-ci a accepté la migration.

Un relais dessert un vaste public et prépare une migration. Il ferme les sessions en donnant la prochaine URI. Si ce relais choisit le serveur d’un tiers, ses clients peuvent s’y présenter presque ensemble. Le passage ajouté dans la version 02 précise que la cible n’a même pas besoin d’exécuter MoQT. Une connexion refusée peut encore imposer à l’hôte le traitement de sa tentative.

La spécification de transport du groupe de travail, section 9.2, permet au serveur de mettre une URI dans le GOAWAY du flux de contrôle. Si elle est non vide, le client doit l’utiliser pour la nouvelle session. Un client ne peut pas imposer de la même façon une URI au serveur. Le champ est limité à 8 192 octets et le pair ne peut pas multiplier les GOAWAY sur le même flux de contrôle. Aucune de ces règles ne vérifie que l’hôte nommé appartient au service. Sur un flux de requête, GOAWAY emploie une autre règle : l’émetteur devrait soumettre à nouveau cette requête précise. Le scénario de foule concerne le serveur et ses sessions clientes.

La version 01 de juillet ne contenait pas ce passage sur la cible tierce. La version de novembre relie donc une instruction de migration à une charge concrète pour quelqu’un d’autre. Elle propose que le client ait une assurance sur l’autorité de la nouvelle URI avant de la suivre et laisse ce contrôle à la spécification de transport. TLS peut écarter plus tard un mauvais point d’arrivée ; la tentative aura déjà quitté le client. Ces documents ne rapportent ni attaque observée ni mesure de surcharge. Le suivi de l’IETF classe l’analyse comme projet individuel.

Le registre utile associerait relais initial, URI nouvelle, règle autorisant la destination, nombre et horaire des connexions et charge reçue. « Migration réussie » ne dit pas qui a reçu la facture.