Résumé

  • Le 24 août 2026, l’IESG a approuvé la révision 16 de draft-ietf-masque-connect-udp-listen comme Proposed Standard. Au gel des preuves, le texte restait un Internet-Draft dans la file du RFC Editor ; l’annonce cite Google Quiche et quic-go comme mises en œuvre interopérables.
  • Le mécanisme maintient un socket UDP public pour plusieurs tuples distants dans une seule requête HTTP. Ce socket est une allocation de joignabilité, pas une autorisation générale : négociation, enregistrement du contexte, règle de destination et transfert réellement observé restent des décisions distinctes.

Le paquet imprévu arrive au bon port

Un navigateur demande à son proxy HTTP une adresse UDP utilisable pour une communication WebRTC. Le proxy alloue une adresse publique et un port. Le pair choisi par ICE y envoie un paquet. Un scanner inconnu découvre le même port et en envoie un autre.

Au niveau IP, les deux paquets sont arrivés au bon endroit. Au niveau de l’autorité, ils n’ont pas la même qualité.

Cette scène est un test de raisonnement, pas un incident publié. Elle montre pourquoi le nouveau mécanisme ne peut pas réduire son état à « port ouvert ». Le tuple public indique un lieu d’arrivée. Le droit de transmettre dépend encore de la requête authentifiée, du tuple distant, du Context ID, de la politique du proxy et du choix du client d’accepter ou non des expéditeurs inconnus.

Une approbation précise, pas un déploiement universel

L’annonce de l’IESG date du 24 août à 17 h 58 UTC. Elle approuve « Proxying Bound UDP in HTTP », révision 16, pour le statut Proposed Standard. Le document émane du groupe MASQUE.

RFC 9298 fixe le point de départ : une requête CONNECT-UDP ordinaire vise un hôte et un port. Cette forme convient à un trafic client-serveur, notamment HTTP/3. Elle ne suffit pas toujours à ICE, qui doit essayer plusieurs pairs. Plusieurs requêtes HTTP ne garantissent ni le même serveur proxy ni la même adresse de sortie ; une connectivité qui dépend de cette stabilité peut donc échouer.

L’extension lie un ou plusieurs tuples publics à une requête et fait varier le pair distant à l’intérieur des datagrammes ou par des associations enregistrées. L’annonce mentionne deux implémentations interopérables. C’est une preuve de faisabilité, non une mesure de diffusion, de charge en production ou d’activation dans les navigateurs.

Au 28 août, Datatracker affichait encore un Internet-Draft actif, en RFC Ed Queue. L’action IANA était en cours, les expertises achevées, tandis que le RFC Editor attendait la vérification des références et la mise en forme. La décision normative existe ; le RFC numéroté et son adoption restent à constater.

Le vrai point de départ est un accord bilatéral

Le client envoie Connect-UDP-Bind: ?1. Le proxy renvoie cette même valeur vraie s’il accepte l’extension. Un participant ne l’active qu’après avoir envoyé et reçu le champ. Une autre forme de valeur est traitée comme une absence.

Un code HTTP de succès ne suffit donc pas à inventer la capacité. Le proxy ne peut pas davantage transformer silencieusement une requête à destination fixe en écoute multi-pairs.

La requête peut garder un hôte et un port valides comme solution de repli. Elle peut aussi demander exclusivement la liaison en plaçant * dans les deux variables de destination. Un seul astérisque rend la requête mal formée. Le journal utile doit conserver ce choix : liaison demandée, acceptée, avec repli ou sans repli.

Proxy-Public-Address décrit une ressource

Après acceptation, le proxy sélectionne au moins une adresse IP publique et un port libre. Il les lie à la requête et les annonce dans Proxy-Public-Address. Avec un seul tuple, adresse et port doivent rester stables jusqu’à la fin du tunnel. Avec plusieurs tuples, la stabilité par famille d’adresses est recommandée.

Cette stabilité rend l’adresse exploitable par ICE. Elle ne transforme pas l’adresse en identité. Le pair voulu, un scanner et un paquet égaré peuvent atteindre le même socket. La différence se construit après réception.

Les événements opérationnels doivent donc rester modestes. adresse_publique_allouée prouve l’allocation. paquet_reçu prouve la joignabilité. Aucun des deux ne prouve un contexte accepté, une politique favorable, une remise au client ou une communication WebRTC réussie.

Les Context IDs donnent une mémoire aux tuples

Le client alloue les identifiants pairs ; le proxy, les impairs. En mode sans destination de repli, l’identifiant zéro est interdit. S’il existe une vraie destination fixe, zéro conserve sa signification héritée de RFC 9298.

Trois Capsules organisent le cycle de vie. COMPRESSION_ASSIGN (0x11) propose l’association d’un identifiant. COMPRESSION_ACK (0x12) confirme que le destinataire l’a enregistrée. COMPRESSION_CLOSE (0x13) refuse la proposition ou ferme une association existante.

Une version IP égale à zéro crée un contexte non compressé : chaque datagramme transporte adresse et port. Du client vers le proxy, ils désignent la destination ; dans l’autre sens, ils décrivent la source. Avec IPv4 ou IPv6, le contexte est compressé : le tuple est enregistré une fois, puis l’identifiant suffit.

Les interdictions sont des garanties d’interprétation. Un identifiant ne peut pas être attribué deux fois. Un seul identifiant peut représenter un tuple. Un identifiant fermé ne renaît pas. Les datagrammes réordonnés qui arrivent après fermeture sont éliminés en silence.

L’émission avant l’accusé est permise pour gagner du temps, mais elle n’anticipe pas l’autorisation. Les datagrammes peuvent disparaître si l’association n’est pas encore installée ou si elle est refusée. La tentative et l’acceptation doivent apparaître dans deux colonnes différentes.

Le client conserve le veto sur l’inconnu

Seul le client peut ouvrir le contexte non compressé, et il ne peut y en avoir qu’un. Ce contexte autorise la description d’un nouveau tuple dans chaque datagramme reçu. Il élargit donc fortement la surface des expéditeurs possibles.

Si le client ne l’ouvre jamais, ou le ferme, le proxy joue de fait le rôle de pare-feu contre les sources inconnues. Les contextes compressés déjà établis continuent de fonctionner. Le proxy ne peut toutefois en ouvrir de nouveaux après cette fermeture, car il contournerait le veto du client.

Le socket public peut ainsi rester vivant pendant que le droit d’entrer se resserre. Voilà la séparation essentielle : l’allocation survit, les pairs autorisés conservent leur association, l’inconnu perd son chemin.

La politique de destination ne disparaît pas

Dans une requête à destination fixe, le proxy peut refuser l’hôte avant d’ouvrir le tunnel. Avec une destination variable, il doit répéter cette protection au bon endroit. Il contrôle chaque destination d’un datagramme non compressé et chaque tuple proposé dans un COMPRESSION_ASSIGN compressé.

Les règles locales peuvent bloquer les adresses de boucle locale, privées, réservées, administratives ou certains services. Le projet IETF ne définit pas toute la politique de l’opérateur ; il rend déterministe le point où elle s’applique.

TURN fournit un parallèle instructif. L’allocation d’une adresse relais, les permissions de pairs et les associations de canal sont des états séparés. Les protocoles diffèrent, mais ils refusent la même erreur conceptuelle : posséder une adresse relais ne donne pas une autorisation illimitée sur les pairs.

Mémoire, buffers et MTU font partie du contrôle

Chaque Context ID accepté consomme de la mémoire. Chaque ACK ou CLOSE retenu par le contrôle de flux ou de congestion consomme un buffer. Le texte exige donc une limite sur les contextes ouverts et sur les réponses en attente. Lorsque la limite de réponses du proxy est atteinte, le flux de requête doit être interrompu.

Une limite invisible ressemble à une panne aléatoire. Il faut enregistrer budget configuré, occupation, refus, pression de file, interruption et version du client. Cette comptabilité permet de distinguer une défense contre l’épuisement d’un défaut de transport.

Le passage entre représentation non compressée et compressée modifie aussi le MTU effectif. Il peut perturber DPLPMTUD. Demander tôt la compression réduit ce changement en cours de chemin ; seul le suivi des tailles, pertes et résultats confirme que le choix fonctionne.

Une adresse partagée exige une preuve plus fine

RFC 6269 rappelle qu’une IP partagée dégrade l’attribution et mélange les réputations. Ici, une même IP de proxy peut couvrir plusieurs clients, tunnels, ports, contextes et pairs. Bloquer ou accuser sur la seule IP publique peut donc viser la mauvaise partie.

Pour instruire un abus, l’opérateur a besoin du port, du tunnel, du client authentifié, de l’identifiant de contexte, du tuple distant, du verdict de politique et du résultat de transfert. Un paquet rejeté à l’entrée ne doit pas devenir, dans le rapport, un paquet remis à l’utilisateur.

La chaîne de preuve d’un datagramme

Une trace défendable relie au moins :

  1. requête authentifiée et identité du tunnel ;
  2. négociation de liaison dans les deux sens ;
  3. mode avec repli ou liaison seule ;
  4. tuple public et durée de vie ;
  5. origine et valeur unique du Context ID ;
  6. assignation, accusé et fermeture ;
  7. sémantique compressée ou non ;
  8. tuple source ou destination exact ;
  9. version et verdict de la politique ;
  10. budgets mémoire et réponses ;
  11. acceptation, rejet ou mise en attente ;
  12. émission ou réception sur le socket ;
  13. remise au client puis résultat ICE ou applicatif.

Un mapping valide peut encore mener à une perte réseau ou à un échec ICE. L’état du protocole autorise le traitement ; le fonctionnement observé prouve le chemin. C’est la discipline du code en fonctionnement : le standard fixe le minimum commun, l’opérateur doit démontrer localement l’effet réel.

Sources