Résumé

  • Le projet IETF propose le port UDP 8738 comme port commun : le groupe de destination distingue une application ASM, tandis qu’une application SSM est distinguée par la source et le groupe réunis.
  • Une autorisation fondée sur le seul port est donc plus large que l’application annoncée. Un reçu local d’admission multicast doit conserver le sélecteur exact, le comportement de l’hôte, la sécurité et la durée de la décision.

Le projet draft-ietf-intarea-multicast-application-port-08 part d’un constat d’économie : attribuer un numéro de port à chaque application multicast répète souvent une distinction déjà portée par le canal multicast. Il demande le numéro UDP 8738 et le nom de service multicast-app, afin que plusieurs applications puissent partager un port compatible avec les piles IP et les API de sockets existantes.

Partager n’équivaut pas à fusionner. Pour l’Any-Source Multicast, le texte identifie l’application par l’adresse multicast de destination. Pour le Source-Specific Multicast, l’identifiant est le couple formé par l’adresse unicast source et l’adresse multicast de destination. Dans les deux cas, le numéro 8738 complète le contexte de transport sans suffire à lui seul.

Cette nuance déplace la charge de preuve. Le registre peut expliquer à quoi sert le port commun. Il ne peut pas dire quel groupe une organisation a autorisé, quelle source elle a reconnue, sur quelle interface cette adresse a du sens, ni quel propriétaire devra retirer la règle. Une politique qui conserve uniquement le port perd la partie discriminante du modèle.

Le raccourci historique du numéro de port ne fonctionne plus

De nombreuses pratiques d’exploitation traitent un port comme une étiquette d’application. La convention est imparfaite même en unicast, mais elle permet souvent de lire rapidement une règle de pare-feu, une classe QoS ou une fiche d’inventaire. Avec le port multicast partagé, cette lecture devient explicitement fausse.

Une règle « destination UDP 8738 » couvre toutes les applications utilisant ce port. Le projet le dit dans ses considérations de sécurité : une règle qui ne tient pas compte de l’adresse multicast de destination est trop large. Le dossier d’évaluation de l’IESG précise encore le problème. Puisque le texte définit SSM par la source et la destination, un filtre d’application ou de pare-feu destiné au SSM devrait également préserver la source. Une observation de scrutin demande cette correction et relève que les classificateurs réseau, notamment QoS, ont besoin d’autres critères que le port.

Il faut garder la bonne valeur probante de ces documents. La révision 08 a été publiée le 19 juillet 2026 ; elle reste un Internet-Draft du groupe INTAREA, destiné au statut de Proposed Standard, en évaluation IESG avec demande de révision. Les commentaires montrent une question ouverte. Ils ne constituent ni un texte final, ni la preuve d’un déploiement, ni une décision déjà tranchée.

L’hôte et l’application se partagent aussi la frontière

Le partage du port impose une discipline aux sockets. Un hôte conforme doit exiger un usage non exclusif. Sur une API de type POSIX, l’application active SO_REUSEADDR ou SO_REUSEPORT avant le bind. L’hôte doit refuser l’adresse générique pour ce port, empêcher l’émission non multicast qui l’emploie et éliminer les paquets entrants non multicast concernés.

La transition ne sera pas instantanée. Sur un hôte qui n’applique pas ces protections, l’application doit permettre aux autres applications de partager le port et rejeter les datagrammes destinés à un autre groupe. Pour une réception SSM, la logique de l’identité impose aussi de vérifier la source attendue. Le même flux vu par le réseau peut donc être protégé par le noyau sur une machine et par du code applicatif sur une autre.

Ce détail doit entrer dans l’autorisation. « L’application utilise 8738 » ne dit pas si l’hôte bloque un bind générique, si le filtre de groupe a été testé, ou si une autre application locale peut écouter le même flux. L’identité réseau et la garantie offerte sur l’hôte sont deux faits liés, mais distincts.

Le projet répertorie des prototypes Linux, macOS et Windows qui montrent la réception d’un groupe et le rejet d’un autre sur des systèmes non modifiés. Sa section d’état d’implémentation rappelle toutefois que ces informations sont déclaratives, non vérifiées et non exhaustives. Elles attestent une expérimentation utile, pas une population installée.

Les réponses unicast révèlent la limite pratique

Le port commun convient mieux à certaines formes d’application qu’à d’autres. Une application peut diffuser en multicast puis attendre des réponses unicast sur des ports dynamiques. Le pare-feu qui a observé le premier paquet ne peut pas toujours déduire une règle sûre pour le retour. Ouvrir automatiquement le port source indiqué par n’importe quel émetteur créerait une capacité d’élargissement abusive.

Le projet en tire une conclusion pragmatique : pour une application mêlant multicast et unicast dans un environnement filtré, un port dédié peut rester plus simple. L’usage de 8738 est facultatif. Ce n’est donc pas une migration universelle où le partage serait moderne et l’attribution dédiée archaïque. Chaque option possède une surface de contrôle différente.

Une décision d’architecture devrait documenter ce choix avant d’ouvrir le réseau. L’application est-elle strictement multicast ? Les réponses unicast sont-elles nécessaires ? Les équipements savent-ils exprimer la source et le groupe ? Le mécanisme de retour peut-il être limité sans créer une autorisation dynamique générale ? Si les réponses sont négatives, conserver un port dédié peut être la décision la plus sobre.

La non-exclusivité change ce que prouve le socket

Un bind exclusif peut constituer une protection locale rudimentaire : une deuxième application ne reçoit pas facilement le même trafic en prenant le même port. Le port partagé retire cette hypothèse. Le projet suggère que l’application puisse ajouter des mesures de sécurité, et observe que la protection contre l’écoute en transit peut souvent couvrir aussi l’écoute locale.

Cela ne permet pas d’étiqueter 8738 comme « non sûr ». La conclusion exacte est que la possession du port ne prouve plus l’exclusivité de l’application. L’authentification, l’intégrité, la confidentialité et la portée des clés doivent être attachées au canal et au protocole applicatif. Recevoir un datagramme n’accorde pas automatiquement la capacité de le comprendre, de l’altérer ou de participer légitimement.

L’adresse multicast n’est pas davantage une identité institutionnelle mondiale. Sa portée, son interface et son domaine d’usage comptent ; une même valeur peut porter des significations locales différentes. En SSM, l’adresse source précise le canal mais ne démontre pas à elle seule l’autorité d’une organisation. Le sélecteur décrit le trafic ; le propriétaire et l’approbateur doivent être prouvés séparément.

Construire un reçu d’admission multicast

Le bon objet local commence par la sélection réelle. Pour ASM : famille d’adresses, groupe de destination, UDP 8738, portée, interface et VRF. Pour SSM : les mêmes éléments, plus la source exacte ou l’ensemble de sources explicitement admis. Le reçu associe ce sélecteur à une application nommée et à une version de protocole.

Il enregistre ensuite la responsabilité du filtrage. Le système applique-t-il les contraintes du projet, ou l’application compense-t-elle un hôte non conforme ? Quels paramètres de réutilisation de socket et quels tests ont été utilisés ? Quelle projection a créé les règles de pare-feu et de QoS ? Une règle déployée doit pouvoir remonter à ce reçu ; sinon, sa précision ne peut pas être auditée.

La sécurité applicative complète l’ensemble : méthode d’authentification, gestion et rotation des clés, exigence de confidentialité, propriétaire et condition de révocation. Le reçu nomme aussi le demandeur, le réviseur, la finalité, la date d’activation, l’expiration et le chemin de retour arrière. Un changement de groupe, de source, de VRF, de version ou de modèle de réponse ouvre une nouvelle décision au lieu d’hériter silencieusement de l’ancienne.

Ce reçu n’est ni un champ IANA ni une extension IETF. Il respecte au contraire la séparation des rôles : le standard conserve un rendez-vous minimal et interopérable ; l’organisation garde localement l’autorité, le contexte et la réversibilité qui n’ont aucune raison de voyager dans chaque datagramme.

Sources

  1. Projet actuel, historique et fiche API Datatracker
  2. Révision 08 en HTML, texte brut, XML et comparaison des révisions
  3. Scrutin IESG, rapport du shepherd et groupe INTAREA
  4. Dépôt des prototypes et registre IANA
  5. RFC 7605, RFC 6335, RFC 1122 et RFC 1112
  6. RFC 4607, RFC 3493, RFC 3678, RFC 7288 et RFC 7942
  7. Minimum Initial Specification et The Policy Mirror