FR 3109255 A1 20211015 FR 2003621 A 20200410 Ce procédé de gestion d’une communication entre au moins un premier dispositif de communication (PT 1 ) et au moins un deuxième dispositif de communication (PT 2 ) dans un réseau de communication est mis en œuvre par une entité dite intermédiaire (EI) placée sur au moins un chemin emprunté par des paquets de données de ladite communication. Il comporte : - une étape (F1107, F1106) d’obtention d’un identifiant de communication (SCID, DCID) compris dans un paquet de données échangé au cours de ladite communication; et - une étape de traitement dudit paquet de données en fonction d’un résultat d’une vérification d’une conformité dudit identifiant de communication (SCID, DCID) avec au moins un masque d’identifiant de communication accessible par ladite entité intermédiaire (EI). Fig. 11 Procédé mis en œuvre par une entité intermédiaire pour gérer une communication entre deux dispositifs de communication L’invention se rapporte au domaine général des télécommunications. Elle vise plus particulièrement la gestion d’une communication entre deux dispositifs de communication (points de terminaison de la communication) par une entité placée sur au moins un chemin de cette communication. La présente demande ne fait pas d’hypothèse quant au type de ces dispositifs de communication. Ils peuvent être constitués par des équipements terminaux utilisés par les clients d’un opérateur réseau, comme par exemple, un décodeur numérique (ou « Set Top Box » (STB) en anglais), un équipement utilisateur (ou « User Equipment » (UE) en anglais), un ordinateur personnel (ou « Personal Computer » (PC) en anglais), un téléphone intelligent (ou « Smartphone » en anglais), une télévision connectée ou une tablette, mais également par des équipements gérés par un opérateur d’un réseau de télécommunications (par exemple, serveur, pare-feu, routeur), ces équipements pouvant être fixes ou mobiles. Les dispositifs de communication peuvent également être des applications logicielles, ou des instances de service hébergées dans un équipement. La présente demande ne fait pas non plus d’hypothèse quant à la nature de l’entité placée sur le(s) chemin(s) de la communication. Toute entité placée sur le chemin emprunté par les paquets échangés entre des dispositifs de communication dans le cadre de leur communication peut mettre en œuvre l’invention. L’entité, ci-après appelée « entité intermédiaire » peut être ou non intégrée à l’un des dispositifs de communication. L’invention trouve une application privilégiée mais non limitative dans les réseaux de télécommunications dans lesquels les adresses (IP) des dispositifs de communication sont susceptibles de changer au cours d’une communication. Elle s’applique en particulier dans le contexte d’un réseau IP. Dans un tel réseau, on sait en effet qu’une voire plusieurs adresses IP affectées à un terminal sont susceptibles de changer au cours d’une communication, par exemple lorsque le terminal est en mouvement, notamment dans un contexte d’itinérance (« handover » ou « roaming », en anglais). Des solutions pour s’adapter à de telles situations, par exemple les solutions qui reposent sur l’activation de protocoles tels que le protocole QUIC, identifient une communication entre deux dispositifs de communication par un identifiant spécifique (« Connection IDentifier » (CID) en anglais dans le cas du protocole QUIC). Cet identifiant est indépendant des adresses IP et des numéros de port utilisés par les dispositifs de communication durant une communication donnée. Cet identifiant est appelé ci-après, « identifiant de communication ». Pour renforcer la sécurité des communications et rendre plus difficile leur traçage, le protocole QUIC permet de faire varier l’identifiant de communication au cours d’une communication, sans clôturer ladite communication. Plus précisément, un dispositif de communication communique à l’autre dispositif de communication une liste d’identifiants que ce dernier peut utiliser au cours de la communication. Dans le cas du protocole QUIC (qui chiffre non seulement les données utiles mais également la plupart des informations caractéristiques de la communication), cette liste d’identifiants est transmise par un dispositif de communication à l’autre dispositif de communication de façon sécurisée, via un mécanisme de chiffrement. Il est donc très difficile pour une entité telle qu’un pare-feu ou un répartiteur de charge, placée sur un chemin emprunté par les communications établies entre les deux dispositifs de communication, d’être impliquée dans la gestion de telles communications (par exemple, afin d’optimiser l’usage des ressources mobilisées pendant le temps que dure la communication) ou d’appliquer des traitements déterministes sur les paquets caractéristiques de ces communications (un tel traitement est par exemple, la sélection d’une même instance de service pour servir la communication tout au long de la durée de vie de cette communication). En effet, si dans le cas du protocole QUIC, les identifiants de communication utilisés par les dispositifs de communication lors d’une communication sont véhiculés en clair et peuvent être exploités par les entités précitées, celles-ci ne disposent pas en revanche de moyens pour corréler ces identifiants et donc les associer à une même communication, lorsque ces identifiants de communication sont modifiés lors de la communication. En effet, et comme indiqué précédemment, la liste des identifiants de communication autorisés pour la communication QUIC a été échangée de manière chiffrée par les deux dispositifs de communication, ce qui rend difficile voire impossible pour une entité intermédiaire d’associer les différents identificants de communication à une même communication QUIC. Pour remédier à ce problème, il peut être envisagé d’impliquer l’entité intermédiaire dans le mécanisme de chiffrement précité (l’entité intermédiaire se comportant alors comme un « proxy » ayant accès aux données chiffrées par les dispositifs de communication). Cependant, cette solution n’est pas satisfaisante car elle impacte fortement les performances de cette entité (et donc l’experience perçue par les utilisateurs) en raison des opérations de déchiffrement (et éventuellement, de chiffrement) qu’elle doit mettre en œuvre. Elle fragilise aussi la robustesse des communications en cas d’indisponibilité de cette entité intermédiaire. Il peut aussi être envisagé d’introduire une entité de contrôle dans le réseau (typiquement un contrôleur SDN (pour « Software-Defined Networking » en anglais)), chargée d’informer les entités intermédiaires d’une modification à venir d’un identifiant de communication. Mais une telle solution nécessite de prévenir cette entité de contrôle avant toute migration de connexion (c-à-d., modification et utilisation effective de l’identifiant de communication), ce qui augmente considérablement le trafic de signalisation et pénalise de fait la durée nécessaire pour effectuer la migration de connexion. En outre, l’entité de contrôle peut échouer à communiquer les nouveaux identifiants de communication à l’entité intermédiaire. L’invention vise une solution qui ne présente pas les inconvénients précités. Ainsi selon un premier aspect, l’invention concerne un procédé de gestion d’une communication entre au moins un premier dispositif de communication et au moins un deuxième dispositif de communication dans un réseau de communication, le procédé étant mis en œuvre par une entité dite intermédiaire placée sur au moins un chemin emprunté par des paquets de données de cette communication. Ce procédé comporte : - une étape d’obtention d’un identifiant de communication véhiculé dans un paquet de données échangé au cours de cette communication, et - une étape de traitement du paquet de données en fonction d’un résultat d’une vérification d’une conformité de l’identifiant de communication avec au moins un masque d’identifiant de communication accessible par l’entité intermédiaire. Corrélativement, l’invention concerne une entité dite intermédiaire configurée pour être placée sur au moins un chemin emprunté par des paquets de données d’une communication entre au moins un premier dispositif de communication et au moins un deuxième dispositif de communication dans un réseau de communication, cette entité comportant : - un module d’obtention configuré pour obtenir un identifiant de communication véhiculé dans un paquet de données échangé au cours de cette communication; et - un module de traitement configuré pour traiter ce paquet de données en fonction d’un résultat d’une vérification d’une conformité de l’identifiant de communication avec au moins un masque d’identifiant de communication accessible par cette entité intermédiaire. Au sens de l’invention, on considère qu’un masque d’identifiant de communication est accessible par une entité intermédiaire dès lors que l’entité intermédiaire peut avoir connaissance de ce masque d’identifiant. Le masque d’identifiant de communication peut par exemple être mémorisé par l’entité intermédiaire, ou être obtenu par l’entité intermédiaire auprès d’un autre équipement via le réseau de communication. Selon un deuxième aspect, l’invention concerne un procédé de communication mis en œuvre par un premier dispositif de communication dans un réseau de communication, ce procédé comportant : - une étape de génération d’au moins un identifiant destiné à être utilisé comme identifiant de communication dans une communication entre ce premier dispositif de communication et au moins un deuxième dispositif de communication, cet identifiant étant conforme à au moins un masque d’identifiant de communication accessible par au moins une entité intermédiaire placée sur au moins un chemin emprunté par des paquets de données de cette communication ; et - une étape d’envoi d’au moins un paquet de données comportant cet identifiant dans le cadre de cette communication. Corrélativement, l’invention concerne un dispositif de communication comportant : - un module de génération d’identifiants de communication configuré pour générer au moins un identifiant destiné à être utilisé comme identifiant de communication dans une communication entre ce dispositif de communication et au moins un deuxième dispositif de communication dans un réseau de communication, cet identifiant étant conforme à au moins un masque d’identifiant de communication accessible par au moins une entité intermédiaire placée sur au moins un chemin emprunté par des paquets de données de cette communication; et - un module d’envoi de paquets de données configuré pour envoyer au moins un paquet de données comportant cet identifiant dans le cadre de cette communication. Selon un troisième aspect, l’invention vise un système de communication comportant au moins : - un dispositif de communication tel que mentionné ci-dessus, ce dispositif de communication étant configuré pour communiquer avec au moins un deuxième dispositif de communication ; et - une entité intermédiaire telle que mentionnée ci-dessus configurée pour être placée sur au moins un chemin emprunté par les paquets de données d’une communication établie entre ces dispositifs de communication. Ainsi, et d’une façon générale, l’entité intermédiaire conforme à l’invention, vérifie, pour gérer une communication établie entre deux dispositifs de communication, si un identifiant de communication véhiculé dans un paquet de cette communication est conforme ou non à un masque d’identifiant. Par exemple, dans un mode particulier de réalisation, l’entité intermédiaire vérifie si l’identifiant de communication est formé à partir d’au moins un masque d’identifiant de communication auquel elle peut accéder. Une telle entité intermédiaire est par exemple une entité se trouvant sur un chemin de la communication envisagée et apte à traiter des paquets de données échangés lors cette communication. Le recours à un tel masque permet à l’entité intermédiaire de gérer une communication entre les dispositifs de communication en appliquant des traitements particuliers à au moins certains de ces paquets même si les identifiants de communication varient au cours de la communication. En effet, l’entité intermédiaire n’a pas besoin de mettre en œuvre une logique ou une structure qui établirait un historique ou un quelconque lien entre les identifiants de communication utilisés par les différents dispositifs au cours d’une même communication. Cette logique est remplacée par la simple vérification de la conformité de l’identifiant au masque. Cette solution permet donc, en particulier et à moindre coût, de respecter les contraintes en matière de confidentialité du protocole QUIC telles que décrites précédemment. L’invention n’impose en aucune façon à l’entité intermédiaire de procéder à une quelconque opération de chiffrement/déchiffrement, le rôle de cette entité étant essentiellement de vérifier la conformité d’un identifiant de communication à un ou plusieurs masques d’identifiant. Dans un mode particulier de réalisation, cette opération de vérification de ladite conformité peut consister essentiellement en une comparaison et peut être effectuée en réalisant un simple « ET » logique (opérande « AND » en anglais) entre l’identifiant et le masque. On note en outre qu’avantageusement, les entités intermédiaires ne jouent pas un rôle de « proxy » pour la mise en œuvre de l’invention. L’invention ne nécessite pas non plus l’introduction d’une entité de contrôle (qu’elle soit centralisée ou distribuée) dont le rôle serait d’informer les entités intermédiaires des modifications à venir des identifiants de communication (migration de connexion décrite précédemment). Les dispositifs de communication peuvent par conséquent modifier les identifiants de communication à tout moment, sans notification préalable à une entité externe. Ainsi, et de façon très avantageuse, l’invention ne complique pas l’ingénierie du réseau. En particulier, les clefs cryptographiques utilisées par les dispositifs de communication pour chiffrer leurs communications ne sont pas communiquées aux entités intermédiaires : l’invention évite ainsi avantageusement d’introduire une faille sécuritaire liée à l’utilisation de ces entités intermédiaires. Pour tous ces avantages notamment, l’invention permet d’améliorer la gestion des ressources du réseau et d’améliorer la qualité du service rendue et perçue par les utilisateurs. Dans un mode particulier de mise en œuvre du procédé de communication selon l’invention, un identifiant de communication généré par un dispositif de communication peut être utilisé en tant qu’identifiant de communication source dans un paquet envoyé par ce dispositif de communication. Dans un autre mode de réalisation du procédé de communication selon l’invention, le premier dispositif de communication envoie, au deuxième dispositif de communication avec lequel la communication a été établie, l’identifiant de communication chiffré dans un paquet de données. A la réception du paquet, le dispositif de communication distant utilise l’identifiant reçu en tant qu’identifiant de communication destination pour un paquet ultérieur de la communication. Conformément à l’invention, le traitement d’un paquet de données tient compte de la conformité de l’identifiant de communication avec le masque d’identifiant de communication. Par exemple, tous les paquets reçus par l’entité intermédiaire, et dont l’identifiant de communication n’est pas conforme au masque (par exemple parce que l’identifiant n’a pas été formé à partir du masque d’identifiant de communication ad hoc) peuvent être bloqués. Par exemple, dans un mode particulier de réalisation du procédé de gestion selon l’invention, l’entité intermédiaire met en œuvre une fonction pare-feu, et reçoit un masque d’un dispositif de communication dont elle gère la communication. L’étape de traitement d’un paquet de données comporte le filtrage de ce paquet en fonction de la conformité ou non de l’identifiant de communication selon par exemple qu’il a été formé ou non à partir du masque reçu de ce dispositif de communication. Dans ce mode de réalisation, le pare-feu peut par exemple communiquer une ou des consignes de génération de masques aux dispositifs de communication qu’il protège et recevoir, d’au moins un de ces dispositfs, un masque d’identifiant de communication généré à partir de ces consignes, le pare-feu pouvant être configuré pour bloquer les paquets entrants et/ou sortants qui véhiculent un ’identifiant de communication qui ne respecte pas un tel masque. Ce mode de réalisation de l’invention peut en particulier être mis en œuvre pour : - filtrer les paquets reçus par un dispositif de communication, en vérifiant la conformité de l’identifiant de communication destination avec le masque; et/ou pour - filtrer les paquets émis par un dispositif de communication en vérifiant la conformité de l’identifiant de communication source avec le masque. Dans un mode de réalisation du procédé de gestion selon l’invention, l’entité intermédiaire reçoit le masque d’identifiant de communication en provenance d’un dispositif de communication et associe ce masque à ce dispositif de communication, et l’étape de traitement est en outre déterminée en fonction du dispositif de communication associé audit masque. Dans un mode particulier de réalisation, le procédé de communication selon l’invention comporte : - une étape de génération, par le premier dispositif de communication, d’au moins un masque d’identifiant de communication en appliquant au moins une consigne de génération de masques d’identifiants de communication ; et - une étape d’enregistrement de ce masque auprès de l’entité intermédiaire. Par exemple, dans une mise en œuvre de ce mode particulier de réalisation, le procédé de gestion selon l’invention comporte : - une étape d’envoi d’un message d’annonce comportant au moins une consigne de génération de masques d’identifiants de communication ; - le masque d’identifiant de communication étant reçu en provenance du dispositif de communication en réponse au message d’annonce. Corrélativement, dans une mise en œuvre particulière, le procédé de communication selon l’invention comporte une étape de réception, par le premier dispositif de communication, d’un message d’annonce comportant au moins une consigne de génération de masques en provenance d’une entité intermédiaire. Ce mode particulier de réalisation de l’invention est particulièrement avantageux lorsque l’entité intermédiaire met en œuvre une fonction d’acheminement de trafic (« forwarding » en anglais), ou une fonction de répartition de charge du trafic destiné à plusieurs dispositifs de communication, chacun de ces dispositifs de communication générant son propre masque d’identifiant de communication en appliquant la ou les consignes reçues. Dans ce mode de réalisation, le traitement d’un paquet par l’entité intermédiaire peut comporter la vérification qu’un identifiant de communication d’un paquet correspond à un masque d’un dispositif de communication donné puis l’acheminement de ce paquet vers ce dispositif de communication donné. Le message d’annonce peut par exemple être reçu en réponse à un message de découverte envoyé par le premier dispositif de communication. Ce mode particulier de réalisation permet à une entité intermédiaire de s’annoncer dans le réseau et de communiquer sa ou ses consignes aux dispositifs de communication. Dans un mode particulier de réalisation du procédé de gestion selon l’invention, ce message d’annonce comporte un identifiant de service qui identifie un service dont les paquets peuvent être traités par l’entité intermédiaire. Une entité intermédiaire conforme à l’invention ne définit pas nécessairement elle-même la ou les consignes qu’elle utilise pour vérifier la conformité d’un identifiant de communication véhiculé par un paquet qu’elle traite. Dans un mode particulier de réalisation dans lequel l’entité intermédiaire offre une fonction déterminée, le procédé de gestion selon l’invention peut comporter une étape de réception, en provenance d’au moins un dispositif de communication, d’au moins un masque d’identifiant de communication généré par ce dispositif de communication à partir d’au moins une consigne de génération de masques d’identifiants de communication fournie par une autre entité intermédiaire offrant cette fonction déterminée. Par exemple, dans un mode particulier de mise en œuvre du procédé de communication selon l’invention, le premier dispositif de communication : - détermine qu’une première entité intermédiaire offre la même fonction qu’une autre entité intermédiaire ; et - enregistre auprès de cette première entité intermédiaire un masque d’identifiant de communication en application de ladite au moins une consigne de génération de masques utilisée par cette autre entité intermédiaire. Ainsi, et de façon très avantageuse : - les deux entités intermédiaires utilisent les mêmes masques d’identifiant de communication ; - les paquets d’une même communication peuvent être acheminés vers un même dispositif de communication quelle que soit l’entité intermédiaire impliquée dans l’acheminement des paquets ; et - le premier dispositif de communication utilise le même masque d’identifiant de communication pour communiquer avec les entités intermédiaires offrant la même fonction. Ce mode de réalisation de l’invention est particulièrement avantageux car il permet à la première entité intermédiaire d’obtenir des masques générés en application de consigne(s) de génération fournie(s) par une autre entité intermédiaire sans qu’il n’y ait de communication préétablie entre ces entités intermédiaires. Si la première entité intermédiaire reçoit, de plusieurs dispositifs de communication, une pluralité de masques d’identifiant de communication générés par ces dispositifs de communication selon la ou les consignes de génération de masques d’identifiants de communication fournies par une autre entité intermédiaire, cette première entité intermédiaire peut déduire la ou les consignes de génération de masques d’identifiants de communication de cette autre entité intermédiaire. Ce mode de réalisation peut par exemple être mis en œuvre lorsqu’une deuxième entité intermédiaire est introduite pour remplacer une première entité intermédiaire. Dans ce cas-là, la deuxième entité intermédiaire peut simplement s’annoncer aux dispositifs de communication, lesquels enregistrent auprès d’elle des masques d’identifiants de communication en application de la ou des consignes qu’ils avaient reçues de la première entité intermédiaire. Dans un mode particulier de réalisation de l’invention, le premier dispositif de communication peut générer un masque d’identifiant de communication et l’enregistrer auprès d’une entité intermédiaire sans recevoir la ou les consignes de cette entité intermédiaire. Dans un mode particulier de réalisation, le procédé de gestion selon l’invention comporte : - une étape de détection de conflit, un conflit étant détecté si un masque d’identifiant de communication reçu en provenance d’un dispositif de communication constituant une instance d’un service a déjà été associé par l’entité intermédiaire avec au moins un autre dispositif de communication constituant une instance différente du même service ; et - une étape de déclenchement d’une modification dudit masque d’identifiant de communication par au moins un de ces dispositifs de communication. Dans un mode particulier de réalisation, si l’entité intermédiaire reçoit d’un dispositif de communication une demande d’enregistrement d’un masque d’identifiant de communication déjà utilisé, elle peut rejeter cette demande d’enregistrement ou demander au dispositif de communication de lui proposer un nouveau masque. Dans un mode particulier de réalisation, le premier dispositif de communication vérifie, avant d’enregistrer, auprès d’une première entité intermédiaire, pour un service déterminé, un masque généré en application d’une ou de premières consignes, qu’il n’a pas déjà enregistré auprès d’une autre intermédiaire, un masque pour le même service et généré en appliquant des consignes différentes. Ce mode de réalisation permet d’éviter des conflits de génération de masques et par conséquent d’identifiants de communication pour un même service. Dans un mode particulier de réalisation, si le premier dispositif de communication détermine qu’il a déjà enregistré un masque pour le même service auprès d’une autre entité intermédiaire, il enregistre auprès de la première entité intermédiaire un masque généré selon ces autres consignes, de sorte à garantir la cohérence des masques. Dans un mode particulier de réalisation, le procédé de gestion d’une communication selon l’invention comporte : - une étape de vérification pour vérifier si l’entité intermédiaire peut traiter les paquets de données d’une communication impliquant le dispositif de communication en fonction : (i) d’un nombre de dispositifs de communication déjà enregistrés par l’entité intermédiaire en association avec un masque d’identifiant de communication généré en application de ladite au moins une consigne de génération de masques; et (ii) d’un nombre de bits définis par ladite au moins une consigne; et - si ce n’est pas le cas, une étape d’envoi d’un message de renouvellement avec au moins une nouvelle consigne de génération de masques définissant un nombre supérieur de bits, ledit message de renouvellement demandant au dispositif de communication et aux dispositifs de communication déjà enregistrés de générer un nouveau masque d’identifiant de communication en appliquant ladite au moins une nouvelle consigne. Ce mode de réalisation permet avantageusement à l’entité intermédiaire de procéder à la migration d’identifiants de communication pour pouvoir traiter plus de dispositifs de communication et éviter ainsi de rejeter les demandes d’enregisrement reçues des nouveaux dispositifs de communication. Il est important de noter que l’entité intermédiaire selon l’invention ne génère pas elle-même les identifiants de communication. Tout au plus, elle définit des consignes, typiquement les bits qu’elle utilisera pour exécuter son service (par ex. vérifier la conformité d’identifiants de communication formés à partir d’un masque, traiter les paquets qu’elle achemine en fonction du masque). Ces bits sont les bits des identifiants de communication que l’entité intermédiaire considère comme « significatifs » car ce sont ceux qu’elle analyse pour déterminer si ils sont conformes ou non au(x) masque(s) d’identifiants qu’elle considère. Dans la suite de la description, on désigne ces bits par « bits significatifs » de l’identifiant de communication. Les consignes de génération de masque d’un identifiant de communication définies dans l’invention permettent ainsi par exemple de déterminer la position et la valeur des bits significatifs de l’identifiant de communication. Par exemple ces consignes peuvent comporter : - des entiers permettant d’obtenir la position des premier et dernier bits significatifs d’une séquence de bits comportant les bits significatifs dudit identifiant de communication ; et - un entier optionnel indiquant les positions des bits significatifs dudit identifiant de communication au sein de ladite séquence. Dans un mode de réalisation de l’invention, ladite au moins une consigne de génération d’un masque comporte au moins une information parmi : - une information représentative d’une position d’un premier bit d’un identifiant de communication correspondant à un masque de cet identifiant ; - une information représentative d’une position d’un dernier bit de cet identifiant de communication correspondant à ce masque; et - une information représentative des positions ou d’un nombre de bits de cet identifiant de communication correspondant à ce masque. Dans un mode particulier de réalisation, la communication entre le premier dispositif de communication et le deuxième dispositif de communication est conforme à un protocole de communication reposant sur le protocole de transport UDP, par exemple le protocole QUIC. On rappelle que le protocole QUIC est un protocole de transport qui repose sur le protocole UDP (User Datagram Protocol) et dont la conception et l’utilisation ont notamment pour objectif de réduire les temps de latence généralement observés lors de l’établissement de connexions TCP (Transmission Control Protocol). Pour plus de renseignements sur le protocole QUIC, l’homme du métier peut se reporter au document « Iyengar, J. and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport”, draft-ietf-quic-transport (work in progress), 2019 ». Toutefois, le protocole QUIC est cité à titre d’exemple, et l’invention peut s’appliquer également à d’autres protocoles, notamment d’autres protocoles reposant sur le protocole UDP, avec une application privilégiée dans le cadre de protocoles mettant en œuvre, comme QUIC, un chiffrement des données utiles et de certaines informations de contrôle de la communication. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur. Ce premier programme comporte des instructions adaptées à la mise en œuvre d’un procédé de gestion de communication tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur. Ce deuxième programme comporte des instructions adaptées à la mise en œuvre d’un procédé de communication tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions du premier ou du deuxième programme d'ordinateur tel que mentionné ci-dessus. Les supports d'information ou d’enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur, ou une mémoire flash. D'autre part, les supports d'information ou d’enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, chaque support d'informations ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l’un des procédés conformes à l’invention. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente une communication QUIC conforme à l’état actuel de la technique ; la figure 2 représente un paquet QUIC conformément à l’état actuel de la technique ; la figure 3 représente une communication QUIC entre deux dispositifs de communication conformément à l’état actuel de la technique ; la figure 4 illustre un mécanisme de découverte pouvant être mis en œuvre dans un mode particulier de réalisation de l’invention ; la figure 5 représente un message d’annonce pouvant être utilisé dans un mode particulier de réalisation de l’invention ; la figure 6 représente une table d’instances d’entités intermédiaires pouvant être utilisée dans un mode particulier de réalisation de l’invention ; la figure 7 représente un message d’enregistrement pouvant être utilisé dans un mode particulier de réalisation de l’invention ; la figure 8 représente une table d’instances de dispositifs de communication pouvant être utilisée dans un mode particulier de réalisation de l’invention ; la figure 9 représente un format d’une consigne de génération de masques pouvant être utilisé dans un mode particulier de réalisation de l’invention ; les figures 10A à 10E représentent des exemples de consignes conformes au format de la figure 9 ; la figure 11 illustre des étapes d’un procédé de gestion d’une communication conforme à un mode particulier de réalisation de l’invention ; la figure 12 représente une table de dispositifs de communication utilisée dans un exemple de mise en œuvre de l’invention ; la figure 13 représente un processus pouvant être mis en œuvre pour l’activation d’une entité intermédiaire dans un mode particulier de réalisation de l’invention ; la figure 14 illustre un mécanisme pouvant être mis en œuvre par un dispositif de communication conforme à un mode particulier de réalisation de l’invention pour optimiser le traitement du trafic lorsqu’il reçoit des paquets de plusieurs entités intermédiaires conformes à l’invention ; la figure 15 illustre un processus pouvant être mis en œuvre dans l’invention pour retirer une entité intermédiaire ; la figure 16 illustre un exemple de mise à jour d’une table d’instances de service dans un mode particulier de mise en œuvre de l’invention ; la figure 17 illustre un premier exemple pour remplacer une entité intermédiaire par une autre dans un mode particulier de réalisation de l’invention ; la figure 18 illustre un deuxième exemple pour remplacer une entité intermédiaire par une autre dans un autre mode particulier de réalisation de l’invention ; la figure 19 illustre un exemple pour remplacer un dispositif de communication par un autre dans un autre mode particulier de réalisation de l’invention ; la figure 20 représente un processus de renouvellement d’un masque d’identifiant de communication à l’initiative d’un dispositif de communication conformément à un mode particulier de réalisation de l’invention ; la figure 21 illustre la mise à jour d’une table de dispositifs de communication dans un mode particulier de réalisation de l’invention suite à une modification d’un masque d’identifiant de communication ; la figure 22 représente un processus de renouvellement d’un masque d’identifiant de communication à l’initiative d’une entité intermédiaire dans un mode particulier de réalisation de l’invention; la figure 23 représente un processus d’introduction d’un nouveau dispositif de communication conformément à un mode particulier de réalisation de l’invention; la figure 24 illustre un mode particulier de mise en œuvre de l’invention dans lequel l’entité intermédiaire est un pare-feu ; la figure 25 illustre une table de dispositifs de communication pouvant être utilisée dans le contexte du mode de réalisation de la figure 24 ; la figure 26 représente l’architecture matérielle d’une entité intermédiaire conforme à un mode particulier de réalisation de l’invention ; la figure 27 représente l’architecture matérielle d’un dispositif de communication conforme à un mode particulier de réalisation de l’invention ; et la figure 28 représente un système conforme à un mode particulier de réalisation de l’invention. Description détaillée de plusieurs modes de réalisation de l’invention L’invention est décrite à présent dans le contexte particulier dans lequel les dispositifs de communication établissent une communication selon le protocole QUIC. La présente invention vise notamment un procédé de gestion d’une communication et un procédé de communication. Dans la présente demande, une « communication » entre deux équipements désigne l’ensemble des échanges entre l’établissement, la maintenance et la terminaison de cette communication. Dans le contexte particulier du protocole QUIC, une communication au sens de l’invention est également appelée « connexion ». Par conséquent, si le mot connexion est utilisé dans la suite de la description, il désigne une communication au sens de l’invention. Ainsi, un « identifiant de connexion » dans le contexte particulier du protocole QUIC est un identifiant de communication au sens de l’invention. Corrélativement, lorsque dans la suite de la description on fait référence à un identifiant de communication dans le cadre du protocole QUIC, il s’agit d’un identifiant de connexion (ou CID pour « Connection Identifier » en anglais) au sens du protocole QUIC. La figure 1 représente une connexion (ou communication) QUIC CQ entre deux dispositifs de communication PT 1 et PT 2 . Une communication QUIC permet de multiplexer différents canaux de communication C i (en anglais « streams ») dans lesquels des paquets P de données sont acheminés. Les dispositifs de communication PT 1 et PT 2 peuvent par exemple être un terminal (référencé ci-après PT UT ), un client (référencé PT CT ) ou une instance de service (référencée PT IS ). L’un ou l’autre des dispositifs de communication peut établir un canal de communication C i . Le dispositif de communication qui est à l’origine de l’établissement d’un canal est appelé « source » et sera référencé PT SO ; l’autre dispositif de communication avec lequel ce canal est établi est appelé « destination » et sera référencé PT DE . Sur une figure, un même dispositif de communication pourra avoir plusieurs références, par exemple PT IS et PT SO pour un dispositif de communication source de type instance de service. Un paquet P QUIC, représenté sur la figure 2 comporte un en-tête public ETP et des données utiles DU. Dans un tel paquet, les données utiles DU sont chiffrées, et incluent les informations de contrôle de communication. Un paquet QUIC comporte un en-tête public ETP comportant lui-même, des drapeaux (flags FL), un identifiant de communication (ou « identifiant de connexion » comme indiqué ci-dessus) et un numéro de paquet PN. L’identifiant de communication est envoyé en clair. L’identifiant d’un canal de communication C i , non représenté dans la figure 2, est chiffré. L’identifiant de connexion QUIC est un exemple d’identifiant de communication décrit précédemment. La spécification QUIC distingue l’identifiant de communication associé à la source (et désigné « SCID » pour « Source Connection Identifier ») de l’identifiant de communication associé à la destination (et désigné « DCID » pour « Destination Connection Identifier »). Le paquet de la figure 2 est un paquet QUIC avec un en-tête ETP court. Dans de tels paquets, l’en-tête public ETP ne comporte que l’identifiant de communication de la destination, soit le DCID. La spécification QUIC définit également un en-tête long comportant l’identifiant de communication de la destination DCID et l’identifiant de communication de la source SCID. On note qu’il est usuel pour l’homme du métier de désigner par « identifiant de communication CID, « Connection IDentifier » en anglais) » le couple {DCID, SCID}. Par abus de langage, on dit parfois que l’identifiant de communication CID comporte deux parties, une partie source SCID et une partie destination DCID. Dans la description de l’invention, la notion d’identifiant de communication (ou d’identifiant de connexion) inclut donc aussi bien le couple {DCID, SCID} que chacun des identifiants DCID et SCID indépendamment. La figure 3 représente une communication QUIC établie entre deux dispositifs de communication PT 1 et PT 2 , une entité intermédiaire EI placée sur le chemin emprunté par les paquets caractéristiques de cette communication et un paquet QUIC P de cette communication tel que vu par l’entité intermédiaire EI. Pour cette entité intermédiaire EI, toutes les données du paquet QUIC (représentées hachurées) sont chiffrées, à l’exception de l’identifiant de communication SCID ou DCID (dans l’exemple d’un en-tête ETP court). Au sens du protocole QUIC, une communication est identifiée par : - le quadruplet constitué par l’adresse IP source et le numéro de port source du dispositif de communication source et l’adresse IP destination et le numéro de port destination du dispositif de communication destinataire du paquet ; et par - l’identifiant de communication SCID ou DCID. Dans la description de cette présente demande on désigne par @E le couple {adresse IP, numéro de port} d’un équipement ou d’une fonction E. Certaines figures seront décrites dans des modes de réalisation particuliers dans lesquels les entités intermédiaires mettent en œuvre une fonction de répartition de charge de trafic ou une fonction pare-feu. Ces entités intermédiaires pourront alors être simplement désignées « répartiteur de charge » (en anglais « load balancer ») ou « pare-feu » (en anglais « firewall ») et référencées respectivement EI LB ou EI FW . Dans la description ci-après, les étapes références EXX sont mises en œuvre par un dispositif de communication et les étapes référencées FXX sont mises en œuvre par une entité intermédiaire. La figure 3 illustre aussi qu’un dispositif de communication peut fournir plusieurs services par exemple serv1, serv2, serv3, …. Dans la suite de la description on désignera par serv_id, l’identifiant désignant un tel service. La figure 4 illustre comment, dans un mode particulier de mise en œuvre de l’invention, un dispositif de communication PT conforme à l’invention peut : - découvrir des entités intermédiaires EI conformes à l’invention ; - générer un ou plusieurs masques d’identifiants de communication en application d’une ou de consignes de génération de masque reçues d’une entité intermédiaire. Dans l’exemple envisagé ici, on considère une pluralité de consignes de génération de masques, toutefois l’invention peut s’appliquer également dans un contexte où une seule consigne de génération de masque est reçue de l’entité intermédiaire ; et - demander à cette entité d’intermédiaire EI d’enregistrer un ou plusieurs de ces masques en l’absence de détection de conflit. Dans la figure 4 , on se place dans le contexte d’un réseau comportant un dispositif de communication PT et deux entités intermédiaires, à savoir un pare-feu EI FW et un répartiteur de charge EI LB . Dans le mode de réalisation décrit ici, au cours d’une étape E0400, le dispositif de communication PT conforme à l’invention envoie un message de découverte QUERY pour détecter d’éventuelles entités intermédiaires EI conformes à l’invention. Dans le mode de réalisation décrit ici, le message de découverte QUERY est envoyé à une adresse de diffusion ADDR_S écoutée par tous les entités intermédiaires EI. Si le dispositif de communication ne cherche à découvrir que des entités intermédiaires mettant en œuvre une fonction déterminée (par exemple une fonction de répartition de charge), le message de découverte QUERY comporte une clause de service fn_id identifiant cette fonction de répartition de charge de trafic. Cette clause est optionnelle. On suppose que les entités intermédiaires EI écoutent sur l’adresse de diffusion ADDR_S vers laquelle les dispositifs de communication PT envoient les messages de découverte QUERY. Au cours d’une étape F0400, les entités intermédiaires EI reçoivent le message de découverte QUERY. Dans le mode de réalisation décrit ici : - toutes les entités intermédiaires EI qui reçoivent le message de découverte QUERY y répondent si ce message ne comporte pas de clause de service ; et - lorsque le message de découverte QUERY comporte une telle clause, seules les entités intermédiaires EI mettant en œuvre la fonction identifiée par cette clause, y répondent. Dans le mode de réalisation décrit ici, pour répondre au message de découverte QUERY et annoncer sa présence aux dispositifs de communication PT, une entité intermédiaire EI envoie, au cours d’une étape F0410, un message d’annonce ANNOUNCE à une adresse broadcast ou à une adresse multicast réservée à cet usage ADDR_L, l’adresse source de ce message étant une adresse IP unicast @EI de l’entité intermédiaire EI. Pour simplifier la figure 4 , on a représenté un cas où seul le répartiteur de charge EI LB répond, par l’envoi d’un message ANNOUNCE, au message de découverte QUERY. La figure 5 représente un message d’annonce ANNOUNCE pouvant être utilisé dans l’invention. Dans le mode de réalisation décrit ici, le message d’annonce ANNOUNCE peut comporter un identifiant ID EI de l’entité intermédiaire EI (par exemple son adresse IP @EI), un identifiant fn_id de la fonction mise en œuvre par cette entité intermédiaire (par exemple fonction répartiteur de charge, fonction pare-feu ,…) et un ou plusieurs identifiants serv_id des services du dispositif de communication PT auxquels l’entité intermédiaire EI est autorisée à offrir sa fonction (par exemple sa fonction de répartition de charge ou sa fonction pare-feu). Ces identifiants de service peuvent être définis par un administrateur d’un réseau qui héberge des dispositifs de communication conformes à l’invention et fournissant ces services. Par exemple, si l’entité intermédiaire EI offre une fonction de répartition de charge de trafic, les messages d’annonce ANNOUNCE envoyés par cette entité intermédiaire peuvent comporter des identifiants des services dont la charge peut être répartie par cette entité. Ces identifiants de service peuvent être structurés sous forme d’un alias, un FQDN (en anglais Fully Qualified Domain Name), etc. Le message d’annonce ANNOUNCE peut également comporter une ou des consignes de génération de masques DG_MASK permettant à un dispositif de communication de créer un ou plusieurs de ces masques d’identifiants de communication en application de ces consignes. Selon les scénarios de mise en œuvre de l’invention, les identifiants de communication créés à partir de ce masque peuvent être des identifiants de communication source SCID et/ou des identifiants de communication de destination DCID. En envoyant ses consignes pour la génération de masques aux dispositifs de communication, l’entité intermédiaire s’attend à ce que ces dispositifs de communication génèrent des masques d’identifiant de communication en application de ces consignes puis qu’ils les enregistrent auprès d’elle. Ces consignes sont destinées à être utilisées par l’entité intermédiaire pour, lorsqu’elle intercepte un paquet, déterminer le masque de l’identifiant de communication SCID ou DCID véhiculé dans ce paquet à partir de cet identifiant de communication et pour vérifier si cet identifiant est conforme au masque d’identifiant ainsi déterminé. Un exemple de format de consigne DG_MASK sera décrit en référence à la figure 9 et des exemples de consignes utilisant ce format seront décrits en référence aux figures 10A à 10E. Dans le mode de réalisation décrit ici, le message d’annonce ANNOUNCE peut comporter un champ « mode de diffusion » MD (en anglais « broadcast mode ») qui définit comment un dispositif de communication PT doit répondre à ce message d’annonce. Dans le mode de réalisation décrit ici, le mode de diffusion MD peut prendre deux valeurs qui définissent si le dispositif de communication PT doit répondre à ce message en utilisant l’adresse de diffusion ADDR_S utilisée à l’étape E0400 ou en utilisant une adresse unicast @EI de l’entité intermédiaire. Dans le mode de réalisation décrit ici, le message d’annonce ANNOUNCE comporte un paramètre définissant si l’entité intermédiaire EI réécrit ou non l’adresse des paquets qu’elle relaye vers un dispositif de communication PT. En référence à la figure 4, le dispositif de communication PT reçoit le message d’annonce ANNOUNCE annonçant la présence de l’entité intermédiaire EI LB au cours d’une étape E0410. Si le message d’annonce ANNOUNCE comporte un identifiant fn_id d’une fonction qui ne correspond pas à celle recherchée par le dispositif de communication PT, le dispositif de communication PT ignore le message d’annonce ANNOUNCE. On suppose dans l’exemple de la figure 4 que ce n’est pas le cas. Dans le mode de réalisation décrit ici, au cours d’une étape E0420, le dispositif de communication PT enregistre un identifiant ID EI de l’entité intermédiaire EI LB dans une table d’instances d’entités intermédiaires notée EI_INST et représentée par la figure 6. Dans le mode de réalisation décrit ici, le dispositif de communication PT y enregistre en outre l’adresse @EI de l’entité intermédiaire et d’autres informations non représentées, par exemple un contexte de sécurité et un horodatage du dernier message reçu de cette entité intermédiaire. L’identifiant ID EI de l’entité intermédiaire peut être généré localement par le dispositif de communication PT sur la base des informations véhiculées dans le message d’annonce ANNOUNCE. Les dispositifs de communication PT peuvent utiliser localement des identifiants ID EI différents pour identifier une même entité intermédiaire EI. Au cours d’une étape E0430, le dispositif de communication PT génère au moins un masque d’identifiant de communication CID_MASK EI en application une ou des consignes de génération de masque DG_MASK EI . Ce masque d’identifiant de communication est destiné à être utilisé par le dispositif de communication PT pour ses communications impliquant l’entité intermédiaire EI LB . Dans le mode de réalisation décrit ici, ce masque est également destiné à être utilisé par le dispositif de communication PT pour ses communications impliquant une ou plusieurs autres entités intermédiaires offrant la même fonction (répartition de charge de trafic) que l’entité intermédiaire EI LB . Par conséquent, le dispositif de communication PT enregistre le masque d’identifiant de communication CID_MASK EI dans la table d’instances d’entités intermédiaires EI_INST en association avec l’entité intermédiaire EI LB et en association avec les autres entités intermédiaires offrant la fonction de répartition de charge de trafic. Dans le mode de réalisation décrit ici, ce masque est initialement associé dans la table EI_INST à un état OFF représentant le fait qu’il n’a pas encore été accepté par l’entité intermédiaire EI. Dans le mode de réalisation décrit ici, l’état associé à un masque d’identifiant de communication dans une table d’instances d’entités intermédiaires EI_INST gérée par un dispositif de communication peut prendre trois valeurs, à savoir : - l’état « OFF » représentant le fait que le masque n’est pas encore utilisé ou n’est plus utilisé par le dispositif de communication par exemple parce qu’il n’a pas été accepté par l’entité intermédiaire EI. Lorsque le masque est associé à l’état OFF, on dit aussi que ce masque est « inactif » ; - l’état « ON » si le masque est effectivement utilisé par le dispositif de communication ; et - l’état de fin d’activité « OBT » (pour l’expression anglaise « On But Terminating ») indiquant que le masque est actif mais destiné à devenir inactif par exemple après une échéance déterminée ou après la terminaison de la dernière communication active entre le dispositif de communication et l’entité intermédiaire concernée. Dans le mode de réalisation décrit ici, la table d’instances d’entités intermédiaires EI_INST mémorise également les identifiants serv_id des services fournis par des dispositifs de communication qui peuvent être accédés selon l’exécution de la fonction offerte par l’entité intermédiaire (répartition de charge de trafic, pare-feu, …). Au cours d’une étape E0440, le dispositif de communication PT envoie selon un mode unicast (ou diffuse) un message d’enregistrement REGISTER comportant le masque d’identifiant de communication CID_MASK EI pour enregistrer ce masque auprès de l’entité intermédiaire EI, à savoir ici auprès du répartiteur de charge EI LB . Ce message peut comporter un identifiant de service serv_id correspondant au service fourni le cas échéant par le dispositif de communication PT. Dans le mode de réalisation décrit ici, le dispositif de communication envoie selon un mode unicast (ou diffuse) le message d’enregistrement REGISTER conformément au mode de diffusion MD compris dans le message d’annonce ANNOUNCE reçu à l’étape E0410 : l’adresse de destination est soit l’adresse IP unicast @EI de l’entité intermédiaire EI LB soit l’adresse de diffusion ADDR_S. L’adresse source du message REGISTER est une adresse IP unicast @PT affectée au dispositif de communication. Ce message d’enregistrement REGISTER peut être envoyé plusieurs fois pour rafraîchir l’enregistrement du masque d’identifiant de communication CID_MASK EI auprès des entités intermédiaires EI concernées, ici, auprès du répartiteur de charge EI LB . Dans le mode de réalisation décrit ici, le message d’enregistrement REGISTER comporte en outre un identifiant ID PT du dispositif de communication PT. Dans un mode de réalisation de l’invention et comme représenté à la figure 7 , l’identifiant du dispositif de communication utilisé dans le message d’entregistrement REGISTER est l’adresse IP (et le port) @PT utilisée par ledit dispositif de communication. Cet identifiant peut également être un alias, un nom de domaine, etc. L’identifiant utilisé par une entité intérmédiaire pour identifier un dispositif de communication est une décision locale à l’éntité. Dans un autre mode particulier de réalisation de l’invention, si un tunnel sécurisé, par exemple de type TLS (« Transport Layer Security » en anglais), est utilisé pour l’envoi du message d’enregistrement REGISTER, cet identifiant peut être le champ DNS-ID du Message ClientHello. Le message d’enregistrement REGISTER est reçu par une ou plusieurs entités intermédiaires EI au cours d’une étape F0440 ; cette entité intermédiaire EI enregistre l’identifiant du dispositif de communication PT dans une table d’instances de dispositifs de communication PT_INST dont un exemple est illustré par la figure 8. Dans le mode de réalisation décrit ici, l’entité intermédiaire EI enregistre également dans la table d’instances de dispositifs de communication PT_INST une adresse IP @PT du dispositif de communication PT. Elle peut aussi y enregistrer une adresse MAC du dispositif de communication ainsi qu’un contexte de sécurité ; ces dernières informations ne sont pas représentées dans la table PT_INST de la figure 8. Dans le mode de réalisation décrit ici, si le dispositif de communication PT est une instance PT IS d’un service déterminé, l’entité intermédiaire EI vérifie, au cours d’une étape F0450, si le masque d’identifiant de communication CID_MASK EI reçu à l’étape F0440 est identique à un masque d’identifiant de communication déjà reçu pour une autre instance du même service. Cette situation constitue un conflit au sens de l’invention. Dans le mode de réalisation décrit ici, si l’entité intermédiaire détecte un tel conflit, elle envoie, au cours d’une étape F0460 un message CONFLICT de signalement de conflit au dispositif de communication PT IS . Sinon elle enregistre le masque d’identifiant de communication CID_MASK EI dans la table d’instances de dispositifs de communication PT_INST en association avec un état ON représentatif de l’utilisation de ce masque par le dispositif de communication PT IS et envoie un accusé de réception (acquittement, ACK pour « acknowledgment » en anglais) à ce dispositif de communication PT IS . Dans le mode de réalisation décrit ici, l’état associé à un masque d’identifiant de communication dans une table d’instances de dispositifs de communication PT_INST gérée par une entité intermédiaire EI peut prendre trois valeurs, à savoir : - l’état « ON » si le masque est actif, c’est-à-dire en cours d’utilisation par le dispositif de communication ; - l’état « OFF » si le masque est inactif, par exemple parce qu’il n’a pas été accepté par l’entité intermédiaire EI ; - l’état de fin d’activité « OBT » indiquant que le masque est actif mais qu’il va devenir inactif par exemple après une échéance déterminée ou après la terminaison de la dernière communication active entre cette entité intermédiaire et le dispositif de communication. En pratique, dans le mode de réalisation décrit ici, une entité intermédiaire EI détecte un conflit si elle identifie dans sa table d’instances de dispositifs de communication PT_INST, deux enregistrements comportant un même masque d’identifiant de communication à l’état ON associé à deux instances différentes d’un même service. Le message CONFLICT de signalement de conflit ou l’accusé de réception positif ACK est reçu par le dispositif de communication au cours d’une étape E0460. Si le dispositif de communication reçoit un message CONFLICT de signalement de conflit, le dispositif de communication PT exécute à nouveau : - l’étape E0430 pour générer au moins un autre masque d’identifiant de communication CID_MASK EI2 en utilisant les consignes de génération de masque DG_MASK EI , puis pour enregistrer ce nouveau masque d’identifiant de communication CID_MASK EI2 dans la table d’instances d’entités intermédiaires EI_INST ; et - l’étape E0440 pour envoyer un message d’enregistrement REGISTER comportant le nouveau masque d’identifiant de communication CID_MASK EI2 pour l’enregistrer auprès de l’entité intermédiaire EI. Cette procédure peut être réitérée plusieurs fois, jusqu’à ce que l’entité intermédiaire EI considère que le masque d’identifiant de communication CID_MASK EI2 reçu du dispositif de communication PT à l’étape F0440 n’est pas en conflit avec un masque d’identifiant de communication utilisé par un autre point de terminaison. Dans le mode de réalisation décrit ici, si le dispositif de communication PT reçoit à l’étape E0460 un message d’acquittement ACK, il considère que le masque d’identifiant de communication CID_MASK EI est confirmé et il modifie son état à ON dans sa table EI_INST d’instances d’entités intermédiaires. La figure 9 représente un format de consignes de génération de masques DG_MASK pouvant être fournies par une entité intermédiaire EI à un dispositif de communication PT pour lui permettre de générer un masque d’identifiant de communication à partir duquel il pourra générer des identifiants de communication . Dans le mode de réalisation décrit ici, ces consignes DG_MASK EI peuvent comporter : - une information représentative d’une position d’un premier bit d’un identifiant de communication formé à partir d’un masque de cet identifiant ; - une information représentative d’une position d’un dernier bit de cet identifiant de communication correspondant à ce masque; et - une information représentative des positions ou d’un nombre de bits de cet identifiant de communication correspondant à ce masque. Dans les exemples ci-après, les entiers optionnels suivants peuvent être utilisés : (i) nb_sb : entier indiquant le nombre de bits « significatifs » de l’identifiant de communication, c’est-à-dire, comme mentionné précédemment, ceux qu’il convient de considérer pour vérifier la conformité de l’identifiant au masque ; (ii) offset_sb : entier indiquant le décalage du premier bit significatif de l’identifiant de communication ; (iii) demux_sb : entier indiquant la position des bits significatifs de l’identifiant de communication. La figure 10A fournit un exemple dans lequel le décalage offset_sb n’est pas fourni, le nombre nb_sb de bits significatifs est égal à 32 et l’entier demux_sb n’est pas fourni : les bits significatifs du masque sont les 32 premiers bits d’un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les valeurs comprises entre « 0 » et « 4294967295 », soit 2 32 valeurs. La valeur choisie par un dispositif de communication sera positionnée dans les 32 premiers bits de tous les identifiants de communication choisis par ce dispositif de communication. La figure 10B fournit un exemple dans lequel le décalage offset_sb est égal à 32, le nombre nb_sb est égal à 32 alors que l’entier demux_sb n’est pas fourni : les bits significatifs sont les bits de position 33 à 64 d’un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les valeurs comprises entre « 0 » et « 4294967295 », soit 2 32 valeurs. La valeur choisie par un dispositif de communication sera toujours positionnée dans les bits 33 à 64 de tous les identifiants de communication choisis par ce dispositif de communication. La figure 10C fournit un exemple dans lequel le décalage offset_sb est égal à 48, le nombre nb_sb de bits significatifs est égal à 16 alors que l’entier demux_sb n’est pas fourni : les bits significatifs sont les bits de position 49 à 64 d’un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les valeurs comprises entre « 0 » et « 65535 », soit 2 16 valeurs. La valeur choisie par un dispositif de communication sera toujours positionnée dans les bits 49 à 64 de tous les identifiants de communication choisis par ce dispositif de communication. La figure 10D fournit un exemple dans lequel le décalage offset_sb est égal à 32, le nombre nb_sb de bits significatifs est égal à 32, et l’entier demux_sb est égal à 1897 (à savoir la valeur binaire 00000….11101101001) : les bits significatifs sont les bits 54, 55, 56, 58, 59, 61 et 64 d’un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les 128 valeurs possibles en respectant la position des 7 bits significatifs, par exemple 1793, 1856, 1889, 18896, … La figure 10E fournit un exemple dans lequel le décalage offset_sb n’est pas fourni, le nombre nb_sb de bits significatifs est égal à 32 et l’entier demux_sb est égal à 789 (à savoir la valeur binaire 0000000….1100010101) : les bits significatifs sont les bits 23, 24, 28, 30 et 32 d’un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les 32 valeurs possibles en respectant la position des 5 bits significatifs, par exemple 21, 533, 722, 788, … De même, on peut utiliser une position last_sb du dernier bit significatif au lieu de l’entier demux_sb. La figure 11 illustre des étapes d’un procédé de gestion d’une communication conforme à un mode de réalisation de l’invention. Pour décrire cette figure on reprend l’exemple de la figure 10E, et on considère qu’une entité intermédiaire EI envoie au cours d’une étape F1100 un message d’annonce ANNOUNCE avec des consignes de génération de masques DG_MASK dans lesquelles le décalage offset_sb n’est pas fourni, le nombre nb_sb de bits significatifs est égal à 32 et l’entier demux_sb est égal à 789. On suppose qu’un premier dispositif de communication PT 1 reçoit ce message d’annonce (étape E1100), génère un masque 21 en application des consignes DG_MASK, et demande l’enregistrement de ce masque 21 par l’entité intermédiaire EI à l’étape E1102. On suppose également qu’un deuxième dispositif de communication PT 2 reçoit ce message d’annonce (étape E1103), génère le masque 533 en application des consignes DG_MASK et demande l’enregistrement de ce masque 533 par l’entité intermédiaire EI LB à l’étape E1104. L’entité intermédiaire EI enregistre au cours d’une étape F1105 ces masques dans sa table d’instances de dispositifs de communication PT_INST, celle-ci étant représentée par la figure 12. On suppose que le premier dispositif de communication PT 1 génère, au cours d’une étape E1106, un identifiant de communication égal à 16415 et utilise cet identifiant en tant qu’identifiant de communication source SCID pour communiquer avec un dispositif de communication PT CT , cet identifiant de communication SCID étant effectivement conforme car formé à partir du masque 21. On suppose que ce dispositif de communication PT CT envoie, à l’étape E1107 au premier dispositif de communication PT 1 , un paquet de données comportant comme identifiant de communication destination DCID la valeur 16415. Dans cet exemple, l’entité intermédiaire EI intercepte ce paquet à l’étape F1107 et vérifie si l’identifiant de communication DCID véhiculé en clair dans ce paquet est conforme, c’est-à-dire formé (ou encore produit ou généré) à partir d’un masque enregistré dans sa table d’instances de dispositifs de communication PT_INST. A cet effet, dans cet exemple, l’entité intermlédiaire EI applique les consignes de génération de masques DG_MASK EI (paramètres offset_sb non défini, nb_sb=32, demux_sb=789) pour extraire le masque de l’identifiant à partir de l’identifiant 16415, comme illustré ci-dessous: 16415 (32 bits) = 00000000000000001000000000011111 ; 789 = 00000000000000000000001100010101 Elle en déduit (opérande « ET ») dans cet exemple la valeur 21 (10101) du masque et, en consultant sa table d’instances PT_INST, que ce paquet est destiné au premier dispositif de communication PT1. Elle envoie donc ce paquet au premier dispositif de communication PT1. Par conséquent, une fois que l’entité intermédiaire EI a construit sa table PT_INST d’instances de dispositifs de communication, elle peut traiter les communications reçues et les diriger vers les différents dispositifs de communication PT 1 , PT 2 . L’invention est particulièrement avantageuse lorsque l’entité intermédiaire EI est un répartiteur de charge EI LB et les dispositifs de communication des instances PT IS1 , PT IS2 d’un même service. En effet, quand une nouvelle communication est interceptée par cette entité intermédiaire répartiteur de charge, typiquement avec un identifiant de communication destination DCID égal à 0, celle-ci sélectionne une instance de service PT IS1 ou PT IS2 en fonction d’un algorithme de répartition de charge de trafic avec lequel elle a été configurée. La communication est alors établie avec l’instance sélectionnée. Cette instance de service sélectionne un identifiant de communication qu’elle transmet au dispositif de communication distant PT CT en tant qu’identifiant de communication source SCID, cet identifiant étant conforme parce que formé à partir du masque généré en application des consignes de génération de masque DG_MASK EI reçues du répartiteur de charge. Le répartiteur de charge EI LB n’a pas besoin de maintenir un état pour traiter le trafic reçu du dispositif de communication distant PT CT pour cette communication. En effet, quand un paquet d’une communication déjà établie est reçu par le répartiteur de charge EI LB , au cours d’une nouvelle occurrence de l’étape F1107, cette dernière extrait l’identifiant de communication destination DCID, en extrait le masque, et consulte ensuite sa table PT_INST pour identifier l’instance de service qui correspond à ce masque. On suppose maintenant que, lors de cette même communication, la première instance de service PT IS1 génère de nouveaux identifiants de communication (16381 et 11223) correspondant au masque généré à partir des consignes DG_MASK EI reçues du répartiteur de charge EI LB , et propose au dispositif de communication distant PT CT ces nouveaux identifiants de communication (16381 et 11223) dans un message chiffré (étape E1108). Il convient de noter que le(s) message(s) transmettant les nouveaux identifiants de communication étant chiffré(s), son contenu n’est pas accessible par le répartiteur de charge EI LB . Le dispositif de communication distant PT CT utilise dès lors l’identifiant de communication 16381 (respectivement, 11223) comme DCID inséré dans les paquets de cette communication établie avec la première instance de service PT IS1 . Lors de l’interception des paquets par l’entité intermédiaire EI LB , cette dernière extrait l’identifiant de communication DCID 16381 (respectivement, 11223), en extrait le masque 21, et consulte ensuite sa table d’instances de dispositifs de communication PT_INST pour trouver l’instance de service qui correspond à ce masque. De la sorte, tous les paquets interceptés sont envoyés vers la même instance de service PT IS1. Dans le mode de réalisation décrit ici, une entité intermédiaire EI peut en outre vérifier (comme illustré aux étapes F1106 et F1108) si l’identifiant de communication source SCID utilisé par un dispositif de communication PT correspond au masque qui lui a été communiqué. Si ce n’est pas le cas, l’entité intermédiaire peut déclencher une procédure de négociation de masque d’identifiants de communication. Cette variante permet de détecter une anomalie dans sa table PT_INST d’instances de dispositifs de communication. Par exemple, toujours en référence à la figure 11, on suppose que l’entité intermédiaire EI détecte à l’étape F1110 qu’un paquet envoyé par l’instance de service PTIS1 comporte un identifiant de communication (SCID=16000, en binaire 11111010000000) qui ne correspond pas au masque (21, en binaire 10101). En conséquence, l’entité intermédiaire EILB déclenche une procédure de négociation de masque FE1111. A l’issue de cette procédure, l’instance de service PTIS1 enregistre un nouveau masque (1664, en binaire 11010000000)) auprès de l’entité intermédiaire EILB. L’entité intermédiaire EILB met à jour sa table de dispositifs de communication PT_INST avec le nouveau masque 1664. Les paquets reçus par l’entité intermédiaire avec un identifiant de communication destination DCID égal à 16000 sont envoyés à l’instance de service PTIS1. La figure 13 représente sous forme d’organigramme un processus pouvant être mis en œuvre pour l’activation d’une entité intermédiaire EI 2 dans un mode particulier de réalisation de l’invention. On suppose dans cet exemple que cette nouvelle entité intermédiaire EI 2 envoie, au cours d’une étape F1300 un message d’annonce ANNOUNCE du même type que celui envoyé à l’étape F0410 déjà décrite. Ce message d’annonce ANNOUNCE peut comporter des consignes de génération de masques DG_MASK EI2 et un ou plusieurs identifiants serv_id des services de dispositifs de communication qui peuvent être traités par la fonction supportée par l’entité intermédiaire (répartition de charge de trafic, pare-feu). On suppose dans cet exemple que le message d’annonce ANNOUNCE est reçu au cours d’une étape E1300 par un dispositif de communication PT qui fournit plusieurs services par exemple serv1, serv2, serv3, …. Sur réception de ce message d’annonce, le dispositif de communication PT vérifie (étape E1310) si le message d’ANNONCE comporte un identifiant de service serv_id et, le cas échéant, si la table d’instances EI_INST d’entités intermédiaires maintenue par ce dispositif de communication, du type de celle décrite dans la figure 6 , comporte déjà une entrée pour le service identifié par serv_id, associé à une ou des consignes de génération de masques DG_MASK EI1 différentes de celles DG_MASK EI2 reçues dans ce message d’annonce. Si c’est le cas, dans le mode de réalisation décrit ici, et afin d’éviter un conflit, le dispositif de communication PT ne crée pas de nouvelle entrée dans la table d’instances EI_INST, pour garantir que cette table ne comporte pas des consignes de génération de masques DG_MASK EI1 , DG_MASK EI2 différentes pour un même service serv_id. En effet, dans le mode de réalisation décrit ici, plusieurs entités intermédiaires EI 1 , EI 2 peuvent offrir une même fonction (répartition de charge de trafic, pare-feu) à un même service serv_id, à condition qu’elles fournissent des consignes de génération de masques DG_MASK EI cohérentes. Dans le mode de réalisation décrit ici, lorsqu’une telle situation se produit, le dispositif de communication PT répond au message d’annonce en envoyant à l’entité intermédiaire EI 2 , au cours d’une étape E1320 un message d’enregistrement REGISTER comportant un masque d’identifiant de communication CID_MASK EI1 généré en application des consignes de génération de masques reçues de l’entité intermédiaire EI 1 . Si le dispositif de communication PT détermine à l’étape E1310 qu’il n’y a pas de conflit, il génère un masque d’identifiant de communication CID_MASK EI2 en application des consignes véhiculées dans le message d’annonce reçu à l’étape E1300 puis l’enregistre. En référence à la figure 14 , on se place dans le contexte dans lequel deux entités intermédiaires EI 1 , EI 2 , placées sur le chemin emprunté par le trafic caractéristique des communications établies entre deux mêmes dispositifs de communication, ici un client PT CT et une instance de service PT IS , modifient l’adresse IP source des paquets envoyés à cette instance de service PT IS . Dans l’exemple de la figure 14, les paquets reçus par l’instance de service PT IS comportent une adresse IP source @EI 1 lorsqu’ils sont reçus de l’entité intermédiaire EI 1 et une adresse IP source @EI 2 lorsqu’ils sont reçus de l’entité intermédiaire EI 2 , ces paquets comportant le même identifiant de communication SCID ou DCID. Lorsque l’invention est mise en œuvre dans le cas de communications établies selon le protocole QUIC, ce protocole prévoit, dans une telle situation, que le dispositif de communication PT IS émette des messages PATH_CHALLENGE à l’occasion de chaque changement d’adresse IP source. Le but de ces messages PATH_CHALLENGE est de vérifier que le client PT CT est légitimement autorisé à utiliser un chemin pour envoyer ses paquets. Dans le mode de réalisation de l’invention décrit ici, et afin d’optimiser l’acheminement du trafic dans le réseau, le dispositif de communication PT IS n’envoie pas, au moins pendant une durée D déterminée, par exemple 60s, un tel message PATH_CHALLENGE mais maintient (étape E1410) deux entrées dans sa table EI_INST d’instances d’entités intermédiaires. Dans le mode de réalisation, le dispositif de communication instance de service PT IS migre la communication QUIC vers la nouvelle adresse IP s’il n’a pas reçu de paquet avec une autre adresse source pendant la durée D. Cette migration consiste à supprimer, à l’étape E1420, l’entrée correspondant à l’ancienne adresse IP dans la table EI_INST. L’homme du métier comprendra qu’il n’est pas indispensable de supprimer l’entrée correspondant à l’ancienne adresse IP mais que ceci est avantageux pour ne pas charger inutilement la table d’instances EI_INST. Dans le mode de réalisation décrit ici, à l’expiration de la durée D, par exemple au cours de la même étape E1420, l’instance de service PT IS peut envoyer le message PATH CHALLENGE au client PT CT afin de détecter une éventuelle attaque. Mais cette opération n’est pas nécessaire à la mise en œuvre de ce mode particulier de réalisation de l’invention. La figure 15 représente sous forme d’organigramme un processus pouvant être mis en œuvre pour retirer une entité intermédiaire EI. Pour ce faire, l’entité intermédiaire EI souhaitant se retirer envoie en unicast (ou diffuse), au cours d’une étape F1500, un message de retrait BYE aux dispositifs de communication PT associés à un masque d’identifiant de communication actif dans sa table d’instances de dispositifs de communication PT_INST. Un dispositif de communication PT reçoit ce message de retrait BYE au cours d’une étape E1500. Au cours d’une étape E1510, le dispositif de communication PT met à jour la table EI_INST d’instances d’entités intermédiaires, et plus précisément l’état associé au masque d’identifiant de communication CID_MASK EI utilisé pour cette entité intermédiaire EI. Dans le mode de réalisation décrit ici, l’état est modifié pour prendre la valeur de fin d’activité OBT pour lui permettre de continuer de traiter temporairement les communications avec cette entité intermédiaire EI. La figure 16 illustre la mise à jour E1510 de la table EI_INST d’instances de service. Dans le mode de réalisation décrit ici, le dispositif de communication PT envoie un accusé de réception ACK à l’entité intermédiaire EI pour l’informer de la prise en compte du message de retrait BYE. Dans le mode de réalisation décrit ici, lorsqu’un dispositif de communication PT reçoit un message de retrait BYE d’une entité intermédiaire, il continue d’utiliser le masque CID_MASK EI actif pour cette entité intermédiaire soit pendant une durée déterminée indiquée dans le message de retrait BYE, soit aussi longtemps qu’il existe une communication établie avec cette entité intermédiaire EI. La figure 17 illustre un exemple de remplacement d’une entité intermédiaire EI 1 par une entité intermédiaire EI 2 pouvant être mis en œuvre dans un mode particulier de réalisation de l’invention. Dans cet exemple, l’entité intermédiaire EI 2 envoie à un dispositif de communication PT, au cours d’une étape F1700, un message d’annonce ANNOUNCE comportant une ou des consignes de génération de masques DG_MASK EI1 identiques à celles annoncées précédemment par l’entité intermédiaire EI 1 . On suppose que le dispositif de communication PT traite ce message d’annonce comme décrit en référence à la figure 4 pour générer un masque d’identifiant en application de ces consignes puis qu’il demande l’enregistrement de ce masque auprès de l’entité intermédiaire EI 2 au cours d’une étape E1702. L’entité intermédiaire EI 2 accuse réception de cet enregistrement au cours d’une étape F1706. Au cours d’une étape F7104 similaire à l’étape F1500, l’entité intermédiaire EI 1 envoie un message de retrait BYE au dispositif de communication PT pour l’informer qu’elle se retire. Le dispositif de communication PT accuse réception de ce retrait au cours d’une étape E1708. La figure 18 illustre un exemple de remplacement d’une première entité intermédiaire EI 1 par une deuxième entité intermédiaire EI 2, cet exemple pouvant être mis en œuvre dans un autre mode particulier de réalisation de l’invention. On suppose dans cet exemple qu’un dispositif de communication PT a reçu précédemment un message d’annonce ANNOUNCE de la première entité intermédiaire EI 1 comportant des premières consignes de génération de masque DG_MASK 1 pour une fonction fn_id et que ce dispositif de communication a généré un masque d’identifiant de communication CID_MASK EI1 en application de ces premières consignes. Conformément à l’étape E0420 illustrée par la figure 4, la table d’instances d’entités intermédiaires EI_INST du dispositif de communication PT comporte un enregistrement de ce masque CID_MASK EI1 en association avec l’entité intermédiaire EI 1. On suppose maintenant que le dispositif de communication reçoit en provenance de l’entité intermédiaire EI 2 , au cours d’une étape E1802, un message d’annonce ANNOUNCE comportant des consignes de génération de masques DG_MASK 2 différentes des consignes DG_MASK 1 , pour la même fonction fn_id. On suppose que le dispositif de communication PT détermine au cours d’une étape F1803 que les entités intermédiaires EI 1 et EI 2 offrent la même fonction. Dans le mode de réalisation décrit ici, le dispositif de communication répond au message d’annonce ANNONCE reçu de la deuxième entité EI 2 , au cours d’une étape E1804, par un message d’enregistrement REGISTER comportant les mêmes informations que celles envoyées précédemment à la première entité EI 1 et en particulier le masque d’identifiant de communication CD_MASK EI1 généré en application des consignes DG_MASK 1 de la première entité intermédiaire EI 1 et non pas en application des consignes DG_MASK 2 de la deuxième entité intermédiaire EI 2 . L’entité intermédiaire EI 2 accuse réception de cet enregistrement au cours d’une étape F1807. Au cours d’une étape F1806 similaire à l’étape F1704, l’entité intermédiaire EI 1 envoie un message de retrait BYE au dispositif de communication PT pour l’informer qu’elle se retire. Le dispositif de communication PT accuse réception de ce retrait au cours d’une étape E1809. Les exemples des figures 17 et 18 illustrent des situations dans lesquelles une entité intermédiaire EI 1 doit être retirée alors qu’une entité intermédiaire EI 2 doit être activée. Le dispositif de communication reçoit un message de retrait BYE en provenance de l’entité intermédiaire EI 1 et un message d’annonce ANNOUNCE en provenance de l’entité intermédiaire EI 2 . Dans ces deux modes de réalisation, le dispositif de communication PT peut mettre à jour sa table EI_INST d’instances d’entités intermédiaires pour indiquer que l’entité intermédiaire EI 1 sera bientôt indisponible. Le dispositif de communication peut alors procéder à la migration de communications vers l’entité intermédiaire EI 2 ou au maintien des deux contextes pendant une période de transition. Par exemple, une communication ayant été établie avec un identifiant de communication SCID ou DCID peut être acheminée via l’entité intermédiaire EI 2 sans modification d’identifiant de communication et sans interruption de communication. Les deux messages d’annonce LB_ANNOUNCE et de retrait BYE peuvent être reçus dans n’importe quel ordre chronologique. La figure 19 représente sous forme d’organigramme un processus pouvant être mis en œuvre pour retirer un dispositif de communication PT. Pour ce faire, le dispositif de communication PT diffuse (ou envoie selon un mode unicast), au cours d’une étape E1900 un message de retrait BYE aux entités intermédiaires concernées EI, c’est-à-dire associées à un masque d’identifiant de communication actif tel que consigné dans la table d’instances d’entités intermédiaires EI_INST maintenue par le dispositif de communication. Une entité intermédiaire EI reçoit ce message de retrait BYE au cours d’une étape F1900. Au cours d’une étape F1910, l’entité intermédiaire EI met à jour la table PT_INST d’instances de dispositifs de communication, et plus précisément l’état associé au masque d’identifiant de communication CID_MASK EI actif pour le dispositif de communication PT. Dans le mode de réalisation décrit ici, l’état est modifié pour prendre la valeur de fin d’activité OBT indiquant que le masque est toujours actif mais destiné à devenir inactif par exemple après une échéance déterminée ou après la terminaison de la dernière communication active établie entre cette entité intermédiaire et le dispositif de communication. La figure 20 représente un processus de renouvellement d’un masque d’identifiant de communication à l’initiative d’un dispositif de communication PT. Dans un mode particulier de réalisation de l’invention, un dispositif de communication PT peut modifier un masque d’identifiant de communication CID_MASK EI en envoyant à une entité intermédiaire EI associée à un masque d’identifiant de communication actif tel que consigné dans la table d’instances EI_INST maintenue par le dispositif de communication, au cours d’une étape E2000, un message UPDATE de modification de masque pour enregistrer auprès de cette entité un nouveau masque CID_MASK EI ’ généré en application des même consignes que CID_MASK EI utilisées par le dispositif de communication pour cette entité. L’entité intermédiaire EI reçoit ce message au cours d’une étape F2000. Le message UPDATE de modification de masque comporte le nouveau masque CID_MASK EI ’ et éventuellement une échéance pour l’activation de ce nouveau masque. Dans le mode de réalisation de l’invention décrit ici, cette échéance est optionnelle et en l’absence d’échéance, l’entité intermédiaire considère que la demande de modification doit être traitée immédiatement. Cependant, dans le mode de réalisation décrit ici, même si l’échéance est immédiate, l’entité intermédiaire EI ne remplace pas immédiatement l’ancien masque CID_MASK EI par le nouveau masque CID_MASK’ EI dans sa table d’instances de dispositifs de communication PT_INST. La figure 21 illustre la table d’instances de dispositifs de communication PT_INST gérée par l’entité intermédiaire EI après réception du message UPDATE : le nouveau masque est associé à un état « ON » et l’ancien à un état de fin d’activité « OBT ». L’entité intermédiaire EI envoie un message d’acquittement au dispositif de communication au cours d’une étape F2010 pour lui indiquer la bonne réception du message de modification de masque. Lorsque le dispositif de communication reçoit cet accusé de réception (étape E2010), il peut commencer à utiliser le nouveau masque CDI_MASK’ EI . Ces paquets sont traités par l’entité intermédiaire, l’état de ce nouveau masque étant actif dans la table PT_INST. La figure 22 représente sous forme d’organigramme un processus de renouvellement d’un masque d’identifiant de communication à l’initiative d’une entité intermédiaire. Dans un mode particulier de réalisation de l’invention, une entité intermédiaire EI peut demander aux dispositifs de communication de modifier leur masque d’identifiant de communication CID_MASK EI en leur envoyant un message de renouvellement RESET, au cours d’une étape E2200. Si ce message ne comporte pas d’argument, le dispositif de communication PT enregistre (étape F2210) un nouveau masque CID_MASK’ EI auprès de cette entité EI, celui-ci étant généré en application des dernières consignes fournies par cette entité. Si ce message comporte de nouvelles consignes DG_MASK’ EI , le dispositif de communication PT enregistre ces nouvelles consignes, génère un nouveau masque CID_MASK’ EI en application de ces nouvelles consignes et enregistre ce nouveau masque auprès de l’entité EI. Le message de renouvellement de masque RESET peut comporter une échéance pour son activation. Dans le mode de réalisation de l’invention décrit ici, cette échéance est optionnelle et en l’absence d’échéance, l’entité intermédiaire considère que la demande de renouvellement doit être traitée immédiatement. Si le message de renouvellement RESET comporte de nouvelles consignes DG_MASK’ EI , il est préférable de choisir une échéance suffisamment longue pour éviter des conflits d’identifiants de communication. Comme pour un renouvellement de masque à l’initiative du dispositif de communication décrit précédemment en référence aux figures 20 et 21, l’entité intermédiaire EI ne remplace pas immédiatement l’ancien masque CID_MASK EI par le nouveau masque CID_MASK’ EI dans sa table d’instances de dispositifs de communication PT_INST : le nouveau masque est associé à un état « ON » et l’ancien à un état de fin d’activité « OBT ». La figure 23 représente sous forme d’organigramme un processus pouvant être mis en œuvre pour introduire un nouveau dispositif de communication PT, par exemple une nouvelle instance de service PT IS pour remplacer une autre instance de service ou augmenter la capacité de traitement d’un service. Dans le mode de réalisation décrit ici, lorsqu’un nouveau dispositif de communication PT est introduit, il envoie, au cours d’une étape E2300, un message de découverte QUERY identique à celui envoyé à l’étape E0400 déjà décrite. Une entité intermédiaire EI y répond par un message d’annonce ANNOUNCE identique à celui décrit en référence à l’étape F0410 (étape F2310) et le dispositif de communication PT procède à l’enregistrement de son masque d’identifiant de communication (étape E2320). Dans le mode de réalisation décrit ici, lorsque le nouveau dispositif de communication PT héberge une nouvelle instance de service PT IS , l’entité intermédiaire EI vérifie au cours d’une étape F2330 si les consignes de génération de masques d’identifiants de communication qu’elle fournit aux instances de service qui se déclarent auprès d’elle pour générer des masques d’identifiants de communication (voir étapes F0410 ou F1300) comportent suffisamment de bits pour permettre aux instances de service actives auprès d’elle et à la nouvelle instance de service de générer des masques et lui permettre ainsi de traiter les paquets émis par ou à destination de ces différentes instances de service. Au cours de cette étape, l’entité intermédiaire EI détermine : - le nombre d’instances actives en recherchant celles associées à un masque d’identifiant de communication à l’état « ON » dans sa table d’instances de dispositifs de communication PT_INST ; et - le nombre n de bits significatifs de ses consignes DG_MASK EI de génération de masques. Ces informations sont suffisantes pour permettre à l’entité intermédiaire EI de déterminer si les consignes ont suffisamment de bits significatifs pour répondre aux besoins d’une nouvelle instance de service, sachant que le nombre maximum théorique d’instances de service pouvant être servies est de 2 n . Si ce n’est pas le cas, l’entité intermédiaire EI envoie, au cours d’une étape F2340, un message de renouvellement RESET avec de nouvelles consignes DG_MASK’ EI comportant suffisamment de bits significatifs pour demander aux dispositifs de communication PT IS concernés de générer un nouveau masque CID_MASK EI et de l’enregistrer auprès de cette entité EI. Par exemple, si nb est le nombre d’instances de services devant être servies par l’entité intermédiaire, le nombre de bits significatifs des nouvelles consignes DG_MASK’ EI peut être choisi égal à : (nb+1)/2 mod(2). En référence à la figure 11 il a été expliqué comment l’invention pouvait, dans un mode particulier de réalisation, être mise en œuvre par une fonction de répartition de charge de trafic. La figure 24 illustre un mode particulier de mise en œuvre de l’invention dans lequel l’entité intermédiaire est un pare-feu EI FW , pour améliorer le niveau de sécurité offert à des dispositifs de communication, par exemple des terminaux PT UT1 , PT UT2 et PT UT3 protégés par ce pare-feu. Ce mode de réalisation de l’invention peut notamment être utilisé pour se prémunir contre des attaques connues sous l’expression anglaise « connection injection », dans lesquelles, même en présence d’un pare-feu, un attaquant SA envoie avec succès du trafic émis avec une adresse IP usurpée d’un dispositif de communication légitime, par exemple une instance de PT IS . Dans le mode de réalisation décrit ici, l’entité intermédiaire EI FW de type pare-feu peut maintenir dans sa table PT_INST d’instances de dispositifs de communication : - des masques d’identifiants de communication CID_MASK IN EI pour contrôler les communications entrantes vers un terminal PT UT ; - et/ou des masques d’identifiants de communication CID_MASK OUT EI pour contrôler les communications sortantes depuis un terminal PU UT . La table PT_INST peut en particulier contenir deux masques CID_MASK IN EI et CID_MASK OUT EI pour contrôler les communications entrantes et les communications sortantes d’un même terminal. Dans le mode de réalisation décrit ici, et comme représenté à la figure 25 , la table PT_INST de dispositifs de communication comporte un attribut IN/OUT permettant de déterminer si un masque d’identifiant de communication associé à un terminal doit être utilisé pour contrôler les communications entrantes ou sortantes de ce terminal. Dans l’exemple de la figure 26, un même masque est utilisé pour filtrer les communications entrantes et sortantes d’un dispositif de communication mais l’invention ne l’impose pas. Dans l’exemple de la figure 24 , le pare-feu EI FW obtient (étape F2400) l’identifiant de communication SCID, DCID véhiculé dans les paquets échangés entre les terminaux PT UT1 , PT UT2 et PT UT3 d’une part et l’instance de service PT IS d’autre part pour contrôler les communications entrantes et sortantes des terminaux PT UT1 et PT UT2 . Le pare-feu est en mesure de bloquer : - un paquet P1 envoyé au terminal PT UT1 par un serveur SA qui aurait usurpé l’adresse IP affectée à l’instance de service PT IS si l’identifiant de communication destination DCID ne correspond pas au masque CID_MASK EI1 négocié entre ce terminal et le pare-feu EI FW ; et - un paquet P2 envoyé par un terminal PT UT3 usurpant l’adresse IP affectée au terminal PT UT1 si l’identifiant de communication source SCID ne correspond pas au masque négocié entre le terminal PT UT1 et le pare-feu EI FW . Plusieurs messages ont été proposés dans les différents modes de réalisation de l’invention présentés ci-avant, uniquement à titre illustratif. Un ou plusieurs de ces messages pourraient être introduits dans le protocole QUIC pour la mise en œuvre de l’invention. Il s’agit en particulier : - du message de découverte QUERY envoyé par les dispositifs de communication pour découvrir des entités intermédiaires ; - du message d’annonce ANNOUNCE envoyé par les entités intermédiaires pour annoncer leur présence ; - du message d’enregistrement REGISTER utilisé par un dispositif de communication pour enregistrer un masque d’identifiant de communication auprès d’une ou plusieurs entités intermédiaires ; - du message CONFLICT utilisé par les entités intermédiaires pour signaler un conflit - du message BYE envoyé par une entité intermédiaire ou par un dispositif de communication pour se retirer ; - du message UPDATE envoyé par un dispositif de communication PT pour modifier un masque d’identifiant de communication ; - du message RESET envoyé par une entité intermédiaire pour demander aux dispositifs de communication de modifier leur masque d’identifiant de communication. La figure 26 représente l’architecture matérielle d’une entité intermédiaire EI conforme à un mode particulier de réalisation de l’invention. Dans ce mode de réalisation particulier, cette entité intermédiaire a l’architecture matérielle d’un ordinateur. Elle comporte un processeur 261, une mémoire morte de type ROM 262, une mémoire vive 263 et une mémoire non volatile réinscriptible 264, et des moyens de communication 265. La mémoire morte 262 comporte un programme d’ordinateur 266 comportant des instructions qui lorsqu’elles sont exécutées par le processeur 261 mettent en œuvre un procédé de gestion de communication conforme à l’invention et notamment les étapes FXX décrites précédemment. La mémoire non volatile réinscriptible 264 comporte notamment : - les identifiants serv_id des services qui peuvent être traités par la fonction de l’entité intermédiaire EI ; - une ou des consignes DG_MASK EI de génération de masques ; - une table PT_INST d’instances de dispositifs de communication du type de celle représentée dans la figure 8; Les paquets P et les différents messages rappelés ci-dessus sont mémorisés dans la mémoire vive 263 le temps de leur traitement par le processeur 261. La figure 27 représente l’architecture matérielle d’un dispositif de communication PT conforme à un mode particulier de réalisation de l’invention. Dans ce mode de réalisation particulier, ce dispositif de communication a l’architecture matérielle d’un ordinateur. Il comporte un processeur 271, une mémoire morte de type ROM 272, une mémoire vive 273, une mémoire non volatile réinscriptible 274, et des moyens de communication 275. La mémoire morte 272 comporte un programme d’ordinateur 276 comportant des instructions qui lorsqu’elles sont exécutées par le processeur 271 mettent en œuvre un procédé de communication conforme à l’invention et notamment les étapes EXX décrites précédemment. La mémoire non volatile réinscriptible 274 comporte : - une table EI_INST d’instances d’entités intermédiaires du type de celle représentée dans la figure 6. Les paquets P et les différents messages rappelés ci-dessus sont mémorisés dans la mémoire vive 273 le temps de leur traitement par le processeur 271. Dans le mode de réalisation décrit ici, les moyens de communication 265 et 275 sont configurés pour communiquer selon le protocole QUIC. Les moyens de communication 265 de l’entité intermédiaire sont configurés pour intercepter les paquets P conformes au protocole QUIC échangés par les moyens de communication 275 de dispositifs de communication PT. Ces moyens de communication sont également configurés pour pouvoir envoyer ou recevoir les messages rappelés ci-dessus. La figure 28 représente un système SYS conforme à un mode particulier de réalisation de l’invention. Ce système comporte deux dispositifs de communication PT 1 , PT 2 et une entité intermédiaire EI conformes à un mode particulier de réalisation de l’invention, l’entité intermédiaire étant placée sur un chemin utilisé pour établir des communications entre ces dispositifs de communication. Sur cette figure 28, on a représenté l’architecture fonctionnelle de l’entité intermédiaire EI et l’architecture fonctionnelle des dispositifs de communication PT 1 et PT 2. L’entité intermédiaire EI comporte : - un module MO d’obtention configuré pour obtenir un identifiant de communication SCID, DCID véhiculé dans un paquet échangé au cours de ladite communication; - un module de traitement MT configuré pour traiter ce paquet en fonction d’un résultat d’une vérification d’une conformité dudit identifiant de communication SCID, DCID selon au moins un masque CID_MASK EI d’identifiant de communication accessible par l’entité intermédiaire EI. Ces modules peuvent être implémentés par les moyens matériels et logiciels d’une entité intermédiaire représentés dans la figure 26. Le dispositif de communication PT 1 comporte : - un module MG de génération d’identifiants de communication configuré pour générer au moins un identifiant de communication destiné à être utilisé comme identifiant de communication SCID, DCID dans une communication établie entre le dispositif de communication PT 1 et le dispositif de communication PT 2 dans un réseau de communication, cet identifiant étant conforme selon au moins un masque CID_MASK EI d’identifant de communication accessible à l’entité intermédiaire EI; et - un module ME d’envoi de paquets configuré pour envoyer au moins un paquet de données comportant cet identifiant de communication SCID, DCID dans le cadre de cette communication. Ces modules peuvent être impémentés par les moyens matériels et logiciels d’un dispositif de communication représentés à la figure 26. Procédé de gestion d’une communication entre au moins un premier dispositif de communication (PT 1 ) et au moins un deuxième dispositif de communication (PT 2 ) dans un réseau de communication, ledit procédé étant mis en œuvre par une entité dite intermédiaire (EI) placée sur au moins un chemin emprunté par des paquets de données de ladite communication, ledit procédé comportant : - une étape (F1107, F1106, F2400) d’obtention d’un identifiant de communication (SCID, DCID) véhiculé dans un paquet de données échangé au cours de ladite communication; et - une étape de traitement dudit paquet de données en fonction d’un résultat d’une vérification d’une conformité dudit identifiant de communication (SCID, DCID) avec au moins un masque (CID_MASK EI ) d’identifiant de communication accessible par ladite entité intermédiaire (EI). Procédé de gestion selon la revendication 1, dans lequel ledit masque d’identifiant de communication (CID_MASK EI ) est reçu (F0440) en provenance d’un dit dispositif de communication (PT1, PT2) et associé par ladite entité intermédiaire avec ledit dispositif de communication ; - ladite étape de traitement étant en outre déterminée en fonction du dispositif de communication associé audit masque (CID_MASK EI ). Procédé de gestion selon la revendication 2, caractérisé en ce qu’il comporte : - une étape (F0410) d’envoi d’un message d’annonce (ANNOUNCE) comportant au moins une consigne (DG_MASK) de génération de masques d’identifiants de communication ; - ledit masque (CID_MASK EI ) d’identifiant de communication (CID_MASK EI ) étant reçu (F0440) en provenance dudit dispositif de communication (PT1, PT2) en réponse audit message d’annonce. Procédé de gestion selon la revendication 3, dans lequel ladite entité intermédiaire (EI 2 ) offre une fonction déterminée (fn_id), caractérisé en ce qu’il comporte une étape (F1804) de réception en provenance d’au moins un dit dispositif de communication d’au moins un masque d’identifiant de communication généré par ce dispositif de communication à partir d’au moins une consigne de génération de masques d’identifiants de communication fournie par une autre entité intermédiaire offrant ladite fonction déterminée. Procédé de gestion d’une communication selon la revendication 3 ou 4, dans lequel ledit message d’annonce (ANNOUNCE) comporte un identifiant (serv_id) d’un service qui identifie un service dont des paquets de données peuvent être traités par ladite entité intermédiaire (EI). Procédé de gestion d’une communication selon l’une quelconque des revendications 2 à 5 comportant une étape (F0450) de détection de conflit, un conflit étant détecté si ledit masque d’identifiant de communication reçu (F0440) en provenance d’un dispositif de communication constituant une instance d’un service a déjà été associé par ladite entité intermédiaire avec au moins un autre dispositif de communication constituant une instance différente du même service ; et - une étape de déclenchement d’une modification dudit masque d’identifiant de communication par au moins un de ces dispositifs de communication. Procédé de gestion d’une communication selon l’une quelconque des revendications 2 à 6 dans lequel ladite entité intermédiaire met en œuvre une fonction de répartition de charge de trafic, ladite étape de traitement dudit paquet comportant l’acheminement dudit paquet vers un dit dispositif de communication associé à un masque d’identifiant de communication (CID_MASK EI ) auquel est conforme ledit identifiant de communication (SCID,DCID), et d’un algorithme de répartition de charge de trafic. Procédé de gestion d’une communication selon l’une quelconque des revendications 1 à 6 dans lequel ladite entité intermédiaire met en œuvre une fonction pare-feu, ladite étape de traitement dudit paquet de données comportant le filtrage dudit paquet en fonction de la conformité ou non dudit identifiant de communication (SCID, DCID) avec ledit au moins un masque d’identifiant de communication. Procédé de gestion d’une communication selon l’une quelconque des revendications 3 à 8 comportant : - une étape de vérification (F2330) pour vérifier si ladite entité intermédiaire (EI) peut servir ledit dispositif de communication (PT 1 , PT 2 ) en fonction : (i) d’un nombre de dispositifs de communication déjà enregistrés par ladite entité intermédiaire (EI) en association avec un masque d’identifiant de communication (CID_MASK EI ) généré en application de ladite au moins une consigne (DG_MASK EI ) de génération de masques ; et (ii) d’un nombre de bits définis par ladite au moins une consigne (DG_MASK EI ) ; et - si ce n’est pas le cas, une étape (F2340) d’envoi d’un message de renouvellement (RESET) avec au moins une nouvelle consigne (DG_MASK’ EI ) définissant un nombre supérieur de bits, ledit message de renouvellement demandant audit dispositif de communication (PT1) et auxdits dispositifs de communication déjà enregistrés de générer un nouveau masque (CID_MASK EI ) en application de ladite au moins une nouvelle consigne (DG_MASK’ EI ). Procédé de communication mis en œuvre par un premier dispositif de communication (PT1) dans un réseau de communication, ledit procédé comportant : - une étape (E1106, E1108) de génération d’au moins un identifiant destiné à être utilisé comme identifiant de communication (SCID, DCID) dans une communication entre ledit premier dispositif de communication (PT1) et au moins un deuxième dispositif de communication (PT2), ledit identifiant étant conforme à au moins un masque (CID_MASK EI ) d’identifiant de communication accessible par au moins une entité dite intermédiaire (EI) placée sur au moins un chemin emprunté par des paquets de données de ladite communication ; et - une étape (E1106, E1108) d’envoi d’au moins un paquet de données comportant ledit identifiant (SCID, DCID) dans le cadre de ladite communication. Procédé de communication selon la revendication 10, caractérisé en ce que ledit dispositif de communication (PT1) utilise (E1106) ledit identifiant de communication (SCI) en tant qu’identifiant de communication source (SCID) dans ledit paquet de données. Procédé de communication selon la revendication 10, caractérisé en ce que ledit dispositif de communication (PT1) envoie (E1108) ledit identifiant de communication (SCI) chiffré dans ledit paquet de données au dit deuxième dispositif de communication pour que celui-ci utilise ledit identifiant en tant qu’identifiant de communication destination (DCID) dans un paquet de données ultérieur de la communication. Procédé de communication selon l’une quelconque des revendications 10 à 12, ledit procédé comportant : - une étape (E0430, E1804) de génération d’au moins un masque (CID_MASK EI ) d’identifiant de communication en appliquant au moins une consigne (DG_MASK EI ) de génération de masques d’identifiants de communication ; et - une étape (E0430, E1804) d’enregistrement dudit masque (CID_MASK EI ) auprès de ladite entité (EI) intermédiaire. Procédé de communication selon la revendication 13, caractérisé en ce que ledit dispositif de communication : - détermine (E1803) que ladite entité intermédiaire (EI) offre la même fonction qu’une autre entité intermédiaire ; et en ce qu’il - enregistre (E1804) auprès de ladite entité intermédiaire (EI) un masque (CID_MASK EI ) d’identifiant de communication en application de ladite au moins une consigne (DG_MASK EI ) de génération de masques utilisée pour cette autre entité intermédiaire. Procédé de communication selon la revendications 13 ou 14 dans lequel dispositif de communication : - ledit premier dispositif de communication (PT1) vérifie (E1310), avant d’enregistrer pour un service (serv_id) déterminé, un masque (CID_MASK EI ) généré en application de ladite au moins une consigne (DG_MASK EI ), auprès de ladite entité intermédiaire, qu’il n’a pas déjà enregistré auprès d’une autre entité intermédiaire un masque pour le même service et généré en application d’au moins une deuxième consigne différente de ladite au moins une consigne (DG_MASK EI ) ; et - si ledit premier dispositif de communication (PT1) détermine qu’il a déjà enregistré un masque pour le même service auprès d’une autre entité intermédiaire, il enregistre auprès de ladite entité intermédiaire un masque généré en application de ladite au moins une deuxième consigne. Procédé selon l’une quelconque des revendications 3 à 9 et 13 à 15 dans lequel ladite au moins une consigne (DG_MASK EI ) de génération de masques d’identifiants de communication comporte au moins une information parmi : - une information représentative d’une position d’un premier bit d’un identifiant de communication (SCID, DCID) correspondant à un masque (CID_MASK EI ) de cet identifiant ; - une information représentative d’une position d’un dernier bit dudit identifiant de communication (SCID, DCID) correspondant audit masque (CID_MASK EI ) ; et - une information représentative des positions ou d’un nombre de bits dudit identifiant de communication (SCID, DCID) correspondant audit masque (CID_MASK EI ). Entité dite intermédiaire (EI) configurée pour être placée sur au moins un chemin emprunté par des paquets de données d’une communication entre au moins un premier dispositif de communication (PT 1 ) et au moins un deuxième dispositif de communication (PT 2 ) dans un réseau de communication, ladite entité comportant : - un module (MO) d’obtention configuré pour obtenir un identifiant de communication (SCID, DCID) véhiculé dans un paquet échangé au cours de ladite communication ; et - un module de traitement (MT) configuré pour traiter ledit paquet de données en fonction d’un résultat d’une vérification d’une conformité dudit identifiant de communication (SCID, DCID) avec au moins un masque (CID_MASK EI ) d’identifiant de communication accessible par ladite entité intermédiaire (EI). Dispositif de communication (PT1) comportant : - un module (MG) de génération d’identifiants de communication configuré pour générer au moins un identifiant destiné à être utilisé comme identifiant de communication (SCID, DCID) dans une communication entre ledit dispositif de communication (PT1) et au moins un deuxième dispositif de communication (PT2) dans un réseau de communication, ledit identifiant étant conforme à au moins un masque (CID_MASK EI ) d’identifiant de communication accessible par au moins une entité intermédiaire placée sur au moins un chemin emprunté par des paquets de données de ladite communication ; et - un module (E1106, E1108) d’envoi configuré pour envoyer au moins un paquet de données comportant ledit identifiant (SCID, DCID) dans le cadre de ladite communication. Système de communication comportant au moins : - un dispositif de communication (PT1) selon la revendication 18, ledit dispositif de communication étant configuré pour communiquer avec au moins un deuxième dispositif de communication (PT2) ; et - une entité intermédiaire (EI) selon la revendication 17 configurée pour être placée sur au moins un chemin emprunté par des paquets de données d’une communication entre lesdits dispositifs de communication (PT1, PT2). Procédé selon l’une quelconque des revendications 1 à 16 dans lequel ladite communication entre ledit au moins un premier dispositif de communication et ledit au moins un deuxième dispositif de communication est établie selon le protocole QUIC. Procédé mis en œuvre par une entité intermédiaire pour gérer une communication entre deux dispositifs de communication