Brevet FR3108752A1 — publié le 20211001

Procédé de gestion de communications et dispositifs associés L’invention concerne un procédé de gestion de communications selon un protocole de transport donné mis en œuvre par un premier dispositif et comprenant, suite à une détection d’une attaque informatique, une étape d’activation (F40) au niveau du premier dispositif, d’une collaboration avec au moins une entité du réseau pour mitiger l’attaque informatique, cette collaboration comprenant une exécution (F70) par le premier dispositif d’au moins une action déterminée dite de collaboration, lors d’au moins une dite communication du premier dispositif selon le protocole de transport donné, via le réseau. Figure 6 Procédé de gestion de communications et dispositifs associés L’invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement un mécanisme permettant de faciliter, en cas de détection d’une attaque informatique, la gestion et le fonctionnement de services de sécurité opérant au sein d’un réseau IP (Internet Protocol). Un tel service peut être par exemple un service de détection d’intrusions ou d’attaques informatiques, un service de filtrage de flux via un pare-feu, un service de traductions d’adresses (ou NAT pour Network Address Translation), etc. L’invention s’applique notamment aux attaques informatiques de type déni de service (DoS, (pour « Denial of Service » en anglais) ou DDoS (pour « Distributed DoS » en anglais)). Une attaque DoS peut être définie comme une tentative de rendre des ressources d’un domaine informatique, telles que par exemple des ressources réseau ou de calcul, indisponibles pour leurs utilisateurs. Les attaques DDoS sont de plus en plus massives et de nature à compromettre plusieurs centaines de milliers d’équipements utilisateurs (terminaux fixes ou mobiles, objets connectés, serveurs, ressources réseau, routeurs (CPE (pour « Customer Premises Equipment » en anglais) par exemple), décodeurs numériques de type STB (pour « Set Top Box » en anglais), instances de service (ou « Service Functions », en anglais), etc.), qui peuvent à leur tour être utilisés comme relais pour amplifier le pouvoir de nuisance de ces attaques. A titre indicatif, la société Symantec, dans son rapport annuel de 2019, fait état de près de 24000 applications embarquées dans des terminaux mobiles bloquées quotidiennement par de telles attaques, d’une augmentation de 600% entre 2016 et 2017 des attaques ciblant des objets connectés, et d’une augmentation de la volumétrie du trafic d’attaque entre 2016 et 2017 qui représentait 5% du trafic web global en 2016 contre 7.8% en 2017. Les attaques DDoS sont aussi de plus en plus fréquentes et intenses. Elles sont en outre protéiformes, tant par leur dimensionnement (volumétrie du trafic de l’attaque, amplitude de l’attaque, etc.) que par leur portée de nuisance (une seule machine visée, ou plusieurs en visant le réseau local d’une entreprise, le réseau d’un opérateur, etc.). Les cibles de ces attaques ou les relais utilisés pour les propager sont en outre extrêmement variés : terminaux fixes ou mobiles, objets connectés, serveurs, ressources réseau, etc. Pour protéger leurs ressources informatiques contre de telles attaques, de nombreuses entreprises souscrivent à des offres de services de protection DPS (pour « DDoS Protection Services » en anglais). Lorsqu’un service de protection DPS est souscrit auprès d’un fournisseur d’accès, il est généralement présent sur le chemin emprunté par le trafic entrant et/ou sortant du domaine informatique surveillé et protégé par le service DPS. La tâche d’un tel service DPS peut toutefois s’avérer difficile en cas de chiffrement du trafic entrant et/ou sortant. Or, on assiste aujourd’hui à une augmentation du trafic chiffré, notamment avec l’utilisation croissante du protocole de transport QUIC, en particulier par certaines applications couramment utilisées telles que les navigateurs fournis par des sociétés comme Mozilla ou Google pour accéder aux sites web de l’Internet. Cette augmentation répond à une préoccupation majeure des utilisateurs qui souhaitent s’assurer de la confidentialité de leurs communications et des données échangées lors de celles-ci. De façon connue, le protocole QUIC est un protocole qui repose sur le protocole UDP (User Datagram Protocol). Le protocole QUIC a pour ambition notamment de réduire les temps de latence généralement observés lors de l’établissement de connexions TCP (Transmission Control Protocol) (permettant ainsi d’échanger des données plus rapidement), et de permettre une meilleure accommodation de la présence d’entités intermédiaires (par exemple, pare-feux, NAT) sur les chemins supportant les communications. Le protocole QUIC est décrit par exemple dans le document de l’IETF de J. Iyengar et al. intitulé « QUIC : A UDP-based multiplexed and secure transport », draft-ietf-quic-transport, 2019. Conformément au protocole QUIC, non seulement les données utiles échangées lors des communications sont chiffrées, mais également la plupart des informations de contrôle de la communication (aussi souvent désignée par « connexion » dans le contexte du protocole QUIC). Les informations QUIC envoyées en clair sont limitées, comme illustré sur la figure 1 , qui représente la structure d’un paquet de données QUIC à en-tête court (ou « short header » en anglais). Un tel paquet comporte un en-tête 1 public (c’est-à-dire non chiffré) comprenant trois éléments : un premier octet 1-1 comprenant divers indicateurs |0|1|S|R|C|K|P|P| (ou « Flags » en anglais), un deuxième élément 1-2 correspondant à l’identifiant de la connexion (CID pour Connection IDentifier) qui permet l’acheminement du paquet, et un troisième élément 1-3 contenant le numéro du paquet. Le paquet comporte par ailleurs une partie chiffrée 2, contenant notamment les données utiles transportées par le paquet, ainsi que diverses informations de contrôle de la connexion, comme par exemple des informations concernant le nombre de canaux supportés, des informations relatives à la migration de la connexion, au changement des identifiants de connexion, etc. En outre, le protocole QUIC reposant sur le protocole de transport UDP, un paquet QUIC n’expose pas d’informations utiles pour le filtrage de trafic à l’entrée d’un domaine informatique telles que par exemple des informations de début et de fin de connexion, des acquittements, etc. Ainsi, il est difficile pour un service DPS de déterminer si un trafic QUIC destiné à un équipement utilisateur est légitime (c’est-à-dire reçu avec le consentement du destinataire d’un paquet QUIC) ou s’il est suspect. Le protocole QUIC est donc particulièrement vulnérable aux attaques DDoS, et notamment aux attaques par réflexion et par usurpation d’identité. Une approche pour résoudre ce problème pourrait consister à déployer au sein des réseaux des fournisseurs d’accès des « proxys » chargés d’intercepter, de façon transparente pour les utilisateurs, les données caractéristiques de leurs communications QUIC et d’analyser ces caractéristiques en vue de déterminer si le trafic transitant par eux est légitime (autrement dit, consenti par les utilisateurs) ou suspect (c’est-à-dire susceptible d’être associé à une attaque informatique). A cet effet, chaque proxy devrait maintenir une connexion avec chacun des dispositifs impliqués dans la communication, sans toutefois l’indiquer de façon explicite à ces derniers. Toutefois, une telle approche paraît difficilement viable. En effet, la mise en place de tels proxys serait réalisée à l’insu des utilisateurs sans leur consentement explicite, alors même qu’elle porterait atteinte à la confidentialité de leurs communications et qu’elle pourrait compromettre leurs données personnelles. En outre, cette approche introduirait de nouveaux vecteurs d’attaques, comme le souligne l’article de Z. Durumeric et al. intitulé « The security impact of HTTPS interception », NDSS’2017, selon lequel l’interception de communications chiffrées les rend plus vulnérables aux attaques. Chaque proxy doit par ailleurs maintenir un état pour chacune des connexions qu’il maintient, ce qui nécessite des ressources (réseau, CPU, etc.) importantes. Il constitue ainsi de facto un élément particulièrement sensible et critique en cas de défaillance (aussi désigné par SPOF (« Single Point of Failure » en anglais)). De plus, les dispositifs à l’origine de communications QUIC peuvent être multi-interfaces (c’est-à-dire disposer de plusieurs interfaces d’accès leur offrant une connectivité via un ou plusieurs réseaux), et ainsi établir des communications empruntant des chemins multiples ou au contraire seulement un chemin. Un proxy situé sur l’un des chemins n’a pas de visibilité sur le trafic global associé à un tel dispositif multi-interfaces. Il existe donc un besoin d’un mécanisme permettant d’améliorer la sécurité des domaines informatiques et par là-même des communications de leurs utilisateurs, y compris lorsque ces communications s’appuient sur des protocoles de transport chiffrés tels que QUIC, et ce, sans porter atteinte à la confidentialité de ces communications, ni compromettre les données personnelles des utilisateurs. L’invention répond à ce besoin en proposant, selon un premier aspect, un procédé de gestion de communications selon un protocole de transport donné d’un premier dispositif d’un réseau, ce procédé étant mis en œuvre par le premier dispositif et comprenant, suite à une détection d’une attaque informatique, une étape d’activation au niveau du premier dispositif, d’une collaboration avec au moins une entité du réseau pour mitiger l’attaque informatique, cette collaboration comprenant une exécution par le premier dispositif d’au moins une action déterminée dite de collaboration, lors d’au moins une dite communication du premier dispositif selon le protocole de transport donné, via le réseau. Corrélativement, l’invention concerne aussi un premier dispositif d’un réseau, comprenant un module d’activation, déclenché suite à une détection d’une attaque informatique, et configuré pour activer au niveau du premier dispositif une collaboration avec au moins une entité du réseau pour mitiger l’attaque informatique, ce module d’activation étant configuré pour exécuter, lors de cette collaboration, au moins une action déterminée dite de collaboration, lors d’au moins une communication du premier dispositif selon un protocole de transport donné, via le réseau. Aucune limitation n’est attachée à la nature du premier dispositif ou de l’entité du réseau. Le premier dispositif peut être un équipement utilisateur (agissant indifféremment comme client ou comme serveur) tel un terminal, un serveur, une passerelle, etc., auquel le réseau fournit une connectivité, mais il peut également s’agir d’un équipement de l’infrastructure réseau à proprement parler, participant à la gestion des communications au sein du réseau, telle qu’un routeur. De même, l’entité du réseau peut être n’importe quel équipement du réseau susceptible d’être impliqué dans la gestion de l’attaque informatique détectée, comme par exemple un équipement mettant en œuvre une fonction de détection d’intrusions et/ou de mitigation des attaques (ex. service DPS), une fonction pare-feu, une fonction NAT, ou encore un contrôleur réseau. Le premier dispositif et l’entité du réseau peuvent être sous la responsabilité d’une même entité administrative. C’est typiquement le cas de mise en œuvre au sein d’un réseau d’entreprise. Par ailleurs, l’invention s’applique de façon privilégiée au protocole de transport QUIC, mais elle peut également être mise en œuvre pour d’autres protocoles de transport pour lesquels des problèmes similaires à ceux évoqués précédemment pour le protocole QUIC peuvent se poser (ex. absence d’accès aux informations de contrôle des communications, absence de signal de consentement explicite dans le paquet, etc.). Ainsi, l’invention propose, lorsqu’une attaque informatique est détectée, de solliciter ou d’inciter la collaboration des dispositifs (« premiers dispositifs » au sens de l’invention) communiquant via le réseau avec une ou plusieurs entités du réseau en vue de mitiger l’attaque informatique. Tous les dispositifs participant à une communication ou seulement une partie d’entre eux peuvent être ainsi amenés à collaborer avec le réseau. Cette collaboration consiste en l’exécution d’une ou de plusieurs actions déterminées pouvant dépendre typiquement du protocole de transport utilisé pour établir les communications et de ses caractéristiques, ces actions visant à faciliter la tâche des entités du réseau chargées de mitiger l’attaque informatique, pour distinguer le trafic légitime (c’est-à-dire consenti par l’utilisateur du dispositif) du trafic suspect susceptible d’être imputé à l’attaque. De telles actions (dites de collaboration dans la suite de la description) peuvent être par exemple, pour une communication selon un protocole de transport donné : une divulgation d’informations de contrôle relatives à cette communication ; un gel de la migration des identifiants de communication (ou identifiants de connexion) utilisés lors de la communication ; ou une désactivation de l’utilisation du protocole de transport en question lors de la communication. Ces exemples d’actions ont une application privilégiée dans le contexte du protocole QUIC pour lequel les informations de contrôle relatives aux communications sont chiffrées et inaccessibles par les entités du réseau. Grâce à de telles actions, les entités impliquées dans la mitigation de l’attaque informatique en cours ont une meilleure visibilité sur le trafic global destiné ou émis par les premiers dispositifs et peuvent, en analysant ce trafic, déterminer plus facilement s’il est légitime ou associé à l’attaque, et avoir une action appropriée en conséquence. En outre, très avantageusement, ces actions permettent de préserver la confidentialité des communications, puisque tout au plus, ce sont des informations de contrôle des communications qui sont divulguées ou restent inchangées pour permettre aux entités du réseau de corréler plus aisément les flux de données échangées entre eux avec les dispositifs à l’origine ou destinataires de ces flux. L’invention par le biais des actions de collaboration offre par ailleurs une solution moins radicale et plus efficace en termes de performances que celle consistant en un blocage unilatéral par le réseau de l’utilisation du protocole de transport considéré. Ceci permet avantageusement de préserver la volonté et les intérêts des utilisateurs et notamment d’améliorer sensiblement la qualité du service de connectivité telle que perçue par l’utilisateur. Par exemple dans le cadre du protocole QUIC, certains services ou certaines applications reposent uniquement sur l’utilisation de ce protocole ; un blocage permanent de l’utilisation du protocole QUIC par le réseau conduirait à priver les utilisateurs de ces services et applications et serait contraire au principe de neutralité de l’Internet. En outre, grâce à l’invention, on évite aux dispositifs de subir un délai long lors de l’établissement de leurs communications lié à un filtrage unilatéral par le réseau des communications selon le protocole QUIC (ce délai provenant du temps mis par les dispositifs pour constater l’échec de l’établissement de leurs communications selon le protocole QUIC en raison du filtrage opéré par le réseau). Au contraire, dans le cadre de l’invention, les actions de collaboration sont activées par le dispositif lui-même, y compris la désactivation (temporaire) de l’utilisation du protocole QUIC. On note par ailleurs que ces exemples d’actions (et plus généralement les actions exécutées par les dispositifs dans le cadre de la collaboration stimulée par l’invention) ne sont pas nécessairement destinés à aider une entité spécifique du réseau. Le premier dispositif n’a pas à adresser de messages spécifiques à une entité particulière pour collaborer selon ces exemples, mais tout ou partie des entités du réseau placées sur le chemin des communications peuvent en bénéficier. Ces exemples d’actions ne sont bien entendu donnés qu’à titre indicatif, et d’autres actions peuvent être envisagées en variante, en fonction des protocoles de transport considérés. En outre, la collaboration activée conformément à l’invention peut également consister en l’exécution d’une combinaison d’actions, par exemple une divulgation des informations de contrôle et un gel de la migration des identifiants de communication. La collaboration proposée par l’invention permet donc avantageusement d’améliorer l’efficacité des efforts de mitigation entrepris au sein du réseau en ciblant plus facilement les communications à risque. Elle permet également d’éviter une interruption brutale des communications suite à la détection d’une attaque informatique. En outre, l’invention permet d’associer les (« premiers ») dispositifs communicants à la gestion des attaques. Ce sont eux qui restent maîtres des actions de collaboration qui sont mises en œuvre (c’est-à-dire eux qui les exécutent lors de leurs communications), quand bien même celles-ci peuvent être choisies en association avec les entités du réseau impliquées dans la mitigation de l’attaque ou suggérées par ces dernières. L’invention offre ainsi une transparence quant aux traitements réalisés par le réseau. Dans un mode particulier de réalisation de l’invention, ladite au moins une action de collaboration est exécutée par le premier dispositif pendant une durée déterminée. Cette durée peut être définie par défaut, ou être fixée par le réseau ou par le premier dispositif, et si besoin, être réajustée ou reconduite, par exemple tant que l’attaque informatique est en cours. De la sorte, on s’assure du caractère exceptionnel de la collaboration ainsi mise en place, de sorte à préserver l’intérêt des utilisateurs. Une telle précaution permet au premier dispositif de contrôler les informations qu’il partage lors de la collaboration et d’éviter une exploitation abusive de cette collaboration par le réseau. Dans un mode particulier de réalisation, la durée d’exécution de ladite au moins une action de collaboration est choisie supérieure à 60 minutes. En effet, des études montrent que la grande majorité des attaques récentes ont duré plus d’une heure, un faible pourcentage d’entre elles ayant duré plus de 12h voire plus d’une journée. On note qu’il est également possible, dans un mode particulier de réalisation, de limiter le nombre de collaborations avec le réseau pouvant être activées par le premier dispositif. Par exemple, on peut envisager de ne permettre l’activation que d’une seule collaboration telle que proposée par l’invention toutes les 24h pour éviter les abus de certains réseaux. Dans un mode particulier de réalisation, l’étape d’activation est déclenchée par une réception en provenance de ladite au moins une entité du réseau, d’un message proposant ladite collaboration. Autrement dit, la collaboration peut être à l’initiative d’une entité du réseau impliquée dans la mitigation de l’attaque en cours, par exemple parce qu’elle rencontre des difficultés à qualifier le trafic issu ou destiné au premier dispositif (consenti versus suspect). En variante, la collaboration peut être décidée localement, au niveau du premier dispositif, par exemple parce que celui-ci a été informé ou a détecté une attaque informatique, ou parce qu’il a été sollicité par l’un de ses correspondants lors d’une communication. La mise en œuvre de l’invention est donc particulièrement flexible. Dans un mode particulier de l’invention, le procédé de gestion des communications comprend en outre une étape d’envoi, à un moins un deuxième dispositif participant à au moins une dite communication selon ledit protocole de transport donné avec ledit premier dispositif, d’un message d’information informant ledit deuxième dispositif de l’exécution par le premier dispositif de ladite au moins une action de collaboration. De cette façon, le premier dispositif informe ses correspondants du fait qu’il souhaite ou a accepté de collaborer avec des entités du réseau pour tout ou partie de ses communications, et notamment celles impliquant le deuxième dispositif ainsi informé. De la sorte, la collaboration est mise en œuvre en toute transparence pour chacun des dispositifs impliqués dans les communications concernées par cette collaboration. L’exécution de ladite au moins une action de collaboration par le premier dispositif peut par ailleurs être conditionnée par la réception d’un accord du deuxième dispositif. On note toutefois que selon les actions de collaboration envisagées et leurs conditions d’exécution, l’information des correspondants et la réception de leur accord peuvent être optionnelles. Dans un mode particulier de réalisation, le message d’information envoyé par le premier dispositif au deuxième dispositif comprend au moins une condition d’exécution de ladite action de collaboration. Une telle condition d’exécution est par exemple une durée d’exécution de l’action de collaboration, ou à quelles communications ou applications s’applique ladite action de collaboration (par exemple dans quel sens la collaboration est appliquée, c’est-à-dire premier dispositif vers deuxième dispositif et/ou deuxième dispositif vers premier dispositif), etc. Au vu de ce qui précède, l’invention s’appuie, pour mettre en œuvre une collaboration entre les dispositifs communicants et les entités du réseau, non seulement sur les dispositifs communicants eux-mêmes (premier et deuxième dispositifs au sens de l’invention), mais également sur les entités du réseau bénéficiant de cette collaboration. Ainsi, selon un deuxième aspect, l’invention vise également un procédé de communication avec un premier dispositif d’un réseau, ce procédé étant mis en œuvre par un deuxième dispositif et comprenant : une étape de réception d’un message d’information en provenance du premier dispositif, informant le deuxième dispositif d’une exécution par le premier dispositif d’au moins une action déterminée lors d’au moins une communication selon un protocole de transport donné avec le deuxième dispositif, ladite action, dite de collaboration, permettant une collaboration avec au moins une entité du réseau pour mitiger une attaque informatique ; si ledit deuxième dispositif accepte l’exécution de ladite action de collaboration, une étape d’information du premier dispositif de son accord. Corrélativement, l’invention concerne aussi un dispositif, dit deuxième dispositif, comprenant un module de communication avec un premier dispositif d’un réseau, ce module de communication étant configuré pour : recevoir un message d’information en provenance de ce premier dispositif, informant le deuxième dispositif d’une exécution par le premier dispositif d’au moins une action déterminée lors d’au moins une communication selon un protocole de transport donné avec le deuxième dispositif, ladite action, dite de collaboration, permettant une collaboration avec au moins une entité dudit réseau pour mitiger une attaque informatique ; si ledit deuxième dispositif accepte l’exécution de ladite action de collaboration, informer le premier dispositif de son accord. Le procédé de communication et le deuxième dispositif bénéficient des mêmes avantages cités précédemment que le procédé de gestion et le premier dispositif selon l’invention. Dans un mode particulier de réalisation du procédé de communication et du procédé de gestion, au moins un paquet de données échangé lors d’une dite communication selon le protocole de transport donné entre les premier et deuxième dispositifs comprend au moins un entête indiquant en clair au moins une information de contrôle de cette communication parmi : un état d’un établissement de la communication ; un consentement du premier ou du deuxième dispositif d’envoi et/ou de réception de paquets de données lors de cette communication ; et un consentement ou une absence de consentement du premier ou du deuxième dispositif de cette communication. Ces différentes informations de contrôle fournissent des données utiles aux entités du réseau qui peuvent être exploitées (puisqu’elles sont disponibles en clair) pour améliorer la sécurité et mitiger plus efficacement l’attaque informatique en cours. La présence de ces informations de contrôle dans les en-têtes des paquets échangés entre les premier et deuxième dispositifs permet avantageusement de ne pas augmenter la signalisation échangée sur le réseau. Dans le contexte du protocole QUIC, ces informations peuvent être codées par exemple dans des champs réservés de l’en-tête court ou long des paquets QUIC. Toutefois, en variante, ces informations de contrôle peuvent être transmises dans des messages dédiés, prévus spécifiquement à cet effet. On note que classiquement lorsqu’une communication n’est pas consentie par un dispositif, celui-ci est généralement configuré pour ignorer cette communication. Transmettre une information de contrôle aux entités du réseau reflétant qu’une communication n’est pas consentie par un dispositif peut permettre d’activer une fonction dans le réseau chargée de filtrer tous les flux relatifs à cette communication. Ceci peut être avantageux dans le cas d’un dispositif corrompu qui envoie par exemple à d’autres dispositifs des flux à son insu. Comme mentionné précédemment, selon un troisième aspect, l’invention vise également un procédé de communication par une entité d’un réseau à au moins un dispositif du réseau, ledit procédé comprenant, suite à une incapacité de ladite entité à déterminer si un flux de données destiné audit ou provenant dudit dispositif est associé ou non à une attaque informatique, une étape d’envoi par ladite entité audit dispositif d’un message proposant une collaboration du dispositif pour mitiger ladite attaque informatique, ladite collaboration comprenant une exécution par le dispositif d’au moins une action déterminée dite de collaboration, lors d’au moins une communication dudit dispositif selon un protocole de transport donné via ledit réseau. Corrélativement, l’invention concerne aussi une entité d’un réseau comprenant un module de communication, déclenché par une incapacité de ladite entité à déterminer si un flux de données destiné à ou provenant d’un (premier) dispositif du réseau est associé ou non à une attaque informatique, ce module de communication étant configuré pour envoyer audit dispositif un message proposant une collaboration du dispositif pour mitiger ladite attaque informatique, ladite collaboration comprenant une exécution par le dispositif d’au moins une action déterminée dite de collaboration, lors d’au moins une communication dudit dispositif selon un protocole de transport donné via le réseau. Le procédé de communication par l’entité du réseau et l’entité du réseau bénéficient des mêmes avantages cités précédemment que le procédé de gestion, le premier dispositif, le procédé de communication par le deuxième dispositif et le deuxième dispositif selon l’invention. Dans un mode particulier de réalisation, le procédé de communication par l’entité du réseau comprend en outre une étape de réception d’au moins une information identifiant au moins un flux destiné audit dispositif consenti par celui-ci, ou identifiant au moins un flux destiné audit dispositif et considéré par celui-ci comme étant un flux associé à une attaque informatique. Ce mode de réalisation permet au premier dispositif de partager avec l’entité du réseau, indépendamment ou non de ses communications en cours, la connaissance sur les flux légitimes ou au contraire les flux suspects dont il dispose localement. Cette information peut être fournie par exemple : dans une commande de blocage (« discard » ou « rate-limit », en anglais) par ladite entité dudit au moins un flux considéré par le dispositif comme étant un flux associé à une attaque informatique ; ou dans une commande d’autorisation (« accept », en anglais) d’acheminement dudit au moins un flux consenti par le dispositif. Ce mode de réalisation permet en outre d’activer facilement et rapidement en amont du premier dispositif, au niveau de l’entité du réseau, des mécanismes de filtrage des flux de l’attaque. Dans un mode particulier de réalisation, le procédé de communication par l’entité du réseau comprend en outre une étape d’envoi audit dispositif d’une demande d’autorisation d’acheminement vers ledit dispositif d’au moins un flux de données identifié dans ladite demande. Ce mode de réalisation permet à l’entité du réseau de solliciter un consentement explicite du premier dispositif pour l’acheminement vers ce dernier des flux relatifs à ses communications. Dans un mode particulier de réalisation, le procédé de communication par l’entité du réseau comprend en outre : une étape de réception d’au moins un paquet de données échangé lors de ladite communication comprenant au moins un entête dans lequel au moins une information de contrôle de ladite communication parmi un état d’un établissement de ladite communication, un consentement d’envoi et/ou de réception de paquets de données par ledit dispositif lors de ladite communication, et un consentement ou une absence de consentement par ledit dispositif de ladite communication est indiquée en clair ; et une étape d’utilisation de ladite au moins une information de contrôle pour mitiger l’attaque informatique. Dans un mode particulier de réalisation de l’invention, les procédés de communication et de gestion sont mis en œuvre par un ordinateur. 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 ou plus généralement dans un premier dispositif conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de gestion 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 ou plus généralement dans un deuxième dispositif conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de communication par un deuxième dispositif 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 ou plus généralement dans une entité d’un réseau conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de communication par une entité du réseau 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 d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut 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 un disque dur, ou une mémoire flash. D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel 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. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information 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 des procédés de communication ou de gestion selon l’invention. Selon un quatrième aspect, l’invention concerne un système comprenant : au moins un premier dispositif d’un réseau selon l’invention ; au moins un deuxième dispositif apte à communiquer avec le premier dispositif ; et au moins une entité du réseau ; ledit premier dispositif étant configuré pour exécuter, suite à une détection d’une attaque informatique, au moins une action déterminée lors d’au moins une communication avec le deuxième dispositif, de sorte à collaborer avec ladite au moins une entité pour mitiger ladite attaque informatique. Dans un mode particulier de réalisation, le deuxième dispositif et/ou l’entité du réseau sont conformes à l’invention. Le système bénéficie des mêmes avantages cités précédemment que les procédés de communication et de gestion, les premier et deuxième dispositifs et l’entité du réseau selon l’invention. On peut également envisager, dans d'autres modes de réalisation, que les procédés de communication et de gestion, les premier et deuxième dispositifs, l’entité du réseau et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. 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, déjà décrite, représente, la structure d’un paquet de données QUIC à en-tête court ; la figure 2 représente dans son environnement, un système selon l’invention dans un mode particulier de réalisation ; la figure 3 représente schématiquement l’architecture matérielle de dispositifs et d’une entité d’un réseau conformes à l’invention, appartenant au système de la figure 2 ; la figure 4 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé de communication selon l’invention, tel qu’il est mis en œuvre dans un mode particulier de réalisation par une entité réseau du système de la figure 2 ; la figure 5 représente sous forme d’ordinogramme, les principales étapes d’un procédé de gestion de communications selon l’invention, tel qu’il est mis en œuvre dans un mode particulier de réalisation par l’un des dispositifs du système de la figure 2 ; la figure 6 représente sous forme d’ordinogramme, les principales étapes d’un procédé de communication selon l’invention, tel qu’il est mis en œuvre dans un mode particulier de réalisation par un autre des dispositifs du système de la figure 2 ; la figure 7 représente un exemple de modification d’un en-tête court d’un paquet de données QUIC permettant la divulgation d’informations de contrôle dans un mode particulier de réalisation de l’invention ; la figure 8 représente des exemples de modification d’en-têtes longs d’un paquet de données QUIC permettant la divulgation d’informations de contrôle dans un mode particulier de réalisation de l’invention ; et la figure 9 représente deux exemples d’utilisation des informations de contrôle portées par les en-têtes modifiés de paquets de données QUIC dans un mode particulier de réalisation de l’invention. Description de l’invention La figure 2 représente, dans son environnement, un système 3 conforme à l’invention dans un mode particulier de réalisation, ce système 3 permettant d’établir une collaboration entre un ou plusieurs dispositifs communicants et une ou plusieurs entités d’un réseau de communications NW, impliquées dans la mitigation d’une attaque informatique en cours ciblant, ou susceptible d’affecter, des ressources protégées par lesdites entités. Cette collaboration est mise en place pour gérer les communications transitant via le réseau selon un protocole de transport donné afin de pouvoir partager entre les équipements (dispositifs communicants et entités du réseau) certaines informations permettant de faciliter la mitigation de l’attaque informatique. Dans le mode de réalisation décrit ici, le protocole de transport considéré est le protocole de transport QUIC s’appuyant sur le protocole UDP. Toutefois l’invention s’applique bien entendu à d’autres protocoles de transport. On note que par souci de simplification, on considère ici un unique réseau NW ; toutefois les dispositifs communicants et/ou les entités de réseau considérés peuvent être raccordés ou appartenir à des réseaux différents. Aucune limitation n’est attachée à la nature des dispositifs communicants considérés, qui peuvent être aussi bien des équipements utilisateurs (clients ou serveurs, des terminaux, des CPE (pour « Customer Premises Equipment » en anglais), des décodeurs numériques (ou « set top box » en anglais), etc.) auxquels le réseau NW fournit une connectivité, que des équipements du réseau NW. Par « dispositifs communicants », on entend ici des dispositifs aptes à établir entre eux une communication (aussi désignée dans la suite par connexion dans le contexte du protocole QUIC). On distingue ici ces dispositifs communicants des entités localisées dans le réseau à proprement parler, se trouvant sur des chemins de communication entre des dispositifs communicants et via lesquelles transite le trafic échangé entre les dispositifs communicants sur ces chemins. De même, aucune limitation n’est attachée à la nature du réseau NW qui peut être un réseau fixe ou mobile, quelle que soit la génération (ex. 3G, 4G, 5G, 6G) de ce dernier, etc. Dans le mode de réalisation décrit ici, on suppose que le réseau NW met en œuvre le protocole de transport QUIC. Aucune limitation n’est attachée non plus à la nature de l’attaque informatique en cours que le système 3 s’emploie à mitiger, ni aux ressources informatiques et/ou réseau ciblées par cette attaque. Il peut s’agir par exemple d’une attaque de type DDoS telle que mentionnée précédemment, ou de type usurpation d’identité, ransomware, etc., pouvant impacter tout type de ressources telles que des ressources de calcul ou de mémoire, des ressources réseau (ex. adresses IP, noms de domaine, préfixes IP, etc.), des liens d’interconnexion avec d’autres réseaux, etc. Dans l’exemple envisagé à la figure 2, le système 3 s’appuie, pour mitiger une attaque informatique ATTACK en cours détectée par le réseau NW (soit directement par ce dernier, soit via une entité externe au réseau NW), deux dispositifs communicants 4 et 5 et une entité du réseau 6, l’entité du réseau 6 offrant ici un service DPS de protection contre des attaques informatiques et protégeant les ressources du réseau NW. On note que l’attaque informatique ATTACK ne cible pas nécessairement directement des ressources du réseau NW protégées par l’entité DPS 6 ni les dispositifs communicants 4 et 5. Comme mentionné ci-avant, les ressources ciblées par l’attaque informatique ATTACK peuvent être de n’importe quelle nature : équipements connectés aux dispositifs 4 et 5 si ceux-ci sont des CPE par exemple, applications embarquées dans les dispositifs 4 et 5, tout ou partie des ressources protégées par l’entité DPS 6, etc. Il se peut par exemple que les ressources protégées par l’entité DPS 6 et/ou les dispositifs 4 et 5 ne soient pas directement des cibles de l’attaque mais servent de relais à cette dernière, ou permettent d’atteindre les cibles de l’attaque. On note en outre que l’invention s’applique à d’autres entités du réseau 6 pouvant mettre en œuvre d’autres fonctions qu’une fonction de protection contre des attaques informatiques, et jouant un rôle direct ou indirect dans la mitigation d’une attaque informatique en cours. L’invention s’applique de façon générale à toute entité localisée dans le réseau NW, et configurée pour effectuer des traitements sur le trafic acheminé via ce réseau, tels que des traitements de mitigation, de filtrage (ex. pare-feu) ou encore de classification de trafic (par exemple PCEF (Policy and Charging Enforcement Function)), etc. Dans le mode de réalisation décrit ici, les dispositifs 4 et 5 et l’entité du réseau 6 sont tous conformes à l’invention, et ont l’architecture matérielle d’un ordinateur 7, telle que représentée schématiquement sur la figure 3 . Les dispositifs 4 et 5 sont configurés ici pour agir tantôt comme un premier, respectivement un deuxième, dispositif au sens de l’invention. On note qu’ils peuvent agir ainsi selon qu’ils sont à l’origine de l’établissement d’une communication et/ou destinataire d’une communication. Les dispositifs 4 et 5 et l’entité du réseau 6 comprennent notamment un processeur 8, une mémoire vive 9, une mémoire morte 10, une mémoire non volatile 11, et des moyens de communication 12 leur permettant notamment de communiquer entre eux. Ces moyens de communication 12 s’appuient sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici. En outre, dans le mode de réalisation décrit ici, les moyens de communication 12 sont configurés pour mettre en œuvre le protocole de transport QUIC, et émettre et recevoir des flux de données conformes au protocole QUIC. Chaque flux comprend un ou plusieurs paquets de données QUIC, chaque paquet QUIC pouvant comprendre lui-même une ou plusieurs trames QUIC. Une trame QUIC peut être une trame de contrôle (ex. trame CONNECTION_CLOSE utilisée pour fermer une connexion QUIC) ou une trame de données (ex. trame STREAM). La mémoire morte 10 de l’ordinateur 7 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 8 et sur lequel est ou sont enregistré(s) un ou plusieurs programmes d’ordinateur conformes à l’invention. Plus spécifiquement, la mémoire morte 10 de chacun des dispositifs 4 et 5 comprend un enregistrement de deux programmes d’ordinateur PROG4 et PROG5. Le programme PROG4 définit des modules fonctionnels d’un premier dispositif au sens de l’invention qui s’appuient ou commandent les éléments matériels 8 à 12 de l’ordinateur 7 cités précédemment. Ces modules, déclenchés suite à la détection de l’attaque informatique ATTACK, comprennent notamment dans le mode de réalisation décrit ici (cf. figure 2) : un module 4A d’activation, configuré pour activer au niveau du premier dispositif une collaboration avec au moins une entité du réseau NW (et notamment avec l’entité DPS 6) pour mitiger l’attaque informatique ATTACK. Ce module d’activation 4A est configuré pour exécuter, lors de cette collaboration, au moins une action déterminée dite de collaboration, lors d’au moins une communication du premier dispositif selon un protocole de transport donné (QUIC dans l’exemple considéré ici) via le réseau NW ; un module 4B d’émission/réception, configuré pour émettre et recevoir des messages à destination et en provenance d’autres dispositifs communicants du réseau NW. De tels messages sont décrits plus en détail ultérieurement. Le programme PROG5 définit des modules fonctionnels d’un deuxième dispositif au sens de l’invention qui s’appuient sur ou commandent les éléments matériels 8 à 12 de l’ordinateur 7 cités précédemment. Ces modules, déclenchés suite à la détection de l’attaque informatique ATTACK, comprennent notamment dans le mode de réalisation décrit ici (cf. figure 2), un module 5A d’émission/réception (ou plus généralement de communication) configuré pour : recevoir un message d’information en provenance d’un autre dispositif communicant (premier dispositif au sens de l’invention), informant le deuxième dispositif d’une exécution par le premier dispositif d’au moins une action de collaboration déterminée lors d’au moins une communication selon un protocole de transport donné (QUIC dans l’exemple envisagé ici) avec le deuxième dispositif ; et si ledit deuxième dispositif accepte l’exécution de cette action de collaboration, informer le premier dispositif de son accord. On note que chacun des dispositifs 4 et 5 pouvant tour à tour être un premier et un deuxième dispositif au sens de l’invention, les modules d’émission/réception 4B et 5A peuvent être regroupés au sein d’un seul module dûment configuré pour réaliser les fonctions de chacun des modules 4B et 5A. La mémoire morte 10 de l’entité DPS 6 comprend un enregistrement d’un programme d’ordinateur PROG6. Ce programme PROG6 définit des modules fonctionnels de l’entité DPS 6 qui s’appuient ou commandent les éléments matériels 8 à 12 de l’ordinateur 7 cités précédemment. Ces modules, déclenchés suite à la détection de l’attaque informatique ATTACK, comprennent notamment dans le mode de réalisation décrit ici (cf. figure 2) : un module 6A de détection d’attaques informatiques ciblant des ressources protégées par l’entité DPS 6. Ce module 6A est doté de moyens d’analyse du trafic transitant par l’entité DPS 6 et des informations qui lui sont remontées le cas échéant par des équipements tiers connectés au réseau NW et/ou externes au réseau NW ; un module 6B de mitigation des attaques informatiques détectées par le module 6A ; et un module 6C de communication, déclenché ici sur détection d’une incapacité de l’entité DPS 6 et en particulier de son module 6A à déterminer si un flux de données destiné à ou provenant d’un dispositif du réseau NW est associé ou non à une attaque informatique qu’il a détectée (par exemple ici à l’attaque informatique ATTACK), ce module de communication étant configuré pour envoyer au dispositif un message lui proposant une collaboration pour mitiger ladite attaque informatique, cette collaboration comprenant une exécution par le dispositif d’au moins une action de collaboration déterminée, lors d’au moins une communication du dispositif selon un protocole de transport donné (protocole QUIC dans l’exemple envisagé ici), via le réseau NW. Nous allons maintenant décrire, en référence aux figures 4 à 6, comment est mise en œuvre, dans le mode de réalisation décrit ici, la collaboration entre les dispositifs 4 et 5, et l’entité DPS 6 du réseau, en vue de mitiger une attaque informatique en cours (c’est-à-dire de tenter de la traiter et de la résorber ou tout du moins de réduire ses conséquences), à savoir ici l’attaque informatique ATTACK. La figure 4 représente les principales étapes d’un procédé de communication selon l’invention tel qu’il est mis en œuvre, dans le mode de réalisation décrit ici, par l’entité DPS 6 du réseau NW. La figure 5 représente les principales étapes d’un procédé de gestion des communications selon l’invention tel qu’il est mis en œuvre, dans le mode de réalisation décrit ici, par le dispositif communicant 4 lors de ses communications notamment avec le dispositif communicant 5. La figure 6 représente les principales étapes d’un procédé de communication selon l’invention tel qu’il est mis en œuvre, dans le mode de réalisation décrit ici, par le dispositif communicant 5. Aucune limitation n’est attachée à la façon dont l’attaque informatique ATTACK est détectée (par l’entité DPS 6 directement, par une entité externe au réseau NW qui en informe l’entité DPS 6, par un dispositif communicant, etc.) ni quelles ressources elle cible. On suppose ici qu’elle est susceptible d’affecter des ressources protégées par l’entité DPS 6 (directement ou indirectement, comme évoqué précédemment, en se servant des ressources protégées par l’entité DPS 6 comme relais d’attaque ou pour atteindre d’autres ressources) et déclenche ainsi une intervention de celle-ci en vue de la mitiger. Dans l’exemple envisagé ici, en référence à la figure 4, suite à la détection de l’attaque informatique ATTACK (étape E10), l’entité DPS 6 analyse via son module 6A le trafic échangé via le réseau NW et transitant par elle (étape E20). On suppose notamment ici que l’entité DPS 6 se trouve dans le réseau NW sur un chemin emprunté par les communications du dispositif 4, ces communications étant établies ici selon le protocole de transport QUIC comme évoqué précédemment. Aucune limitation n’est attachée à la nature de ces communications : il peut s’agir de communications vocales, de transfert de données multimédia, etc., unilatérales ou bilatérales. Ces communications se traduisent par l’envoi et/ou la réception par le dispositif 4 de flux de données via le réseau NW, chaque flux de données comprenant un ensemble de paquets de données QUIC. Conformément au protocole QUIC, ces paquets de données sont chiffrés : le protocole QUIC tel que défini par l’IETF chiffre non seulement les données utiles contenues dans ces paquets, mais également les informations de contrôle de connexion (ou de contrôle de la communication, une connexion faisant référence à une communication selon le protocole QUIC), à l’exception d’un petit nombre d’entre elles (ex. identifiants de connexion), comme déjà commenté en référence à la figure 1. L’entité DPS 6 analyse donc en continu ici, via son module 6A, le trafic (c’est-à-dire les flux de données) destiné au dispositif 4 et issu du dispositif 4 (qualifiés dans la suite d’« associés au dispositif 4 » par souci de simplification), pour déterminer s’il est affecté ou non par l’attaque informatique ATTACK (étape test E30). Elle procède à cet effet de façon connue en soi, par exemple en examinant si ce trafic provient d’une cible connue de l’attaque, s’il présente des caractéristiques suspectes (ex. dépassement de la capacité d’un lien local, nombre de connexions attribuées au dispositif 4 sur une période donnée supérieur à la moyenne observée habituellement sur cette période ou supérieur à un seuil, nombre de connexions « embryonnaires » à destination du dispositif 4 supérieur à un seuil, une connexion embryonnaire correspondant à une connexion initialisée par un dispositif communicant distant sans terminer l’envoi des messages nécessaires pour confirmer la connexion, les seuils considérés étant fixés en fonction d’une connaissance de l’attaque ATTACK), etc. On note que lors de cette analyse, le module 6A de l’entité DPS 6 s’appuie sur des statistiques qu’il évalue, ou reçoit d’autres entités aptes à collecter ces statistiques, à partir des données « publiques » sur le trafic associé au dispositif 4 dont il dispose. Il s’appuie par exemple sur les identifiants de connexion (ou de communication) véhiculés en clair dans les paquets de données QUIC destinés à ou issus du dispositif 4, sur les statistiques de trafic collectées par des compteurs associés à l’activation du protocole SNMP (Simple Network Management Protocol) utilisé pour gérer un dispositif, un réseau, sur les statistiques de trafic fournis par les compteurs associés à l’activation du protocole NETCONF (NETwork CONFiguration), etc. Si lors de cette analyse, l’entité DPS 6 est en mesure de qualifier le trafic, c’est-à-dire de décider s’il est associé ou non à l’attaque (réponse « oui » à l’étape test E30), l’entité DPS 6 traite le trafic de façon appropriée en fonction de cette qualification (étape E40). Ainsi : s’il détermine que le trafic est associé à l’attaque ATTACK, il déclenche, par l’intermédiaire de son module 6B de mitigation, une ou plusieurs actions de mitigation de l’attaque informatique ATTACK. De telles actions de mitigation sont connues en soi, et dépendent bien entendu de la nature de l’attaque informatique ATTACK, de son étendue, de la façon dont le trafic associé au dispositif 4, est infecté, etc. De telles actions peuvent consister par exemple à un blocage du trafic de l’attaque (« discard »), à la notification d’autres entités du réseau NW à des fins de redirection de trafic légitime, à la mise en place dynamique de puits de trafic destinés à détruire les paquets caractéristiques du trafic d’attaque, à mettre en place des « pots de miel » (« honeypot » en anglais) destinés à attirer le trafic d’attaque pour le rediriger plus facilement vers un puits de trafic ou pour constituer un dossier « abuse » auprès des autorités compétentes (contexte d’usurpation d‘identité, notamment), etc. ; s’il détermine que le trafic est légitime (« sain »), il achemine ce trafic vers son destinataire. On suppose qu’à un instant donné lors de cette analyse, l’entité DPS 6 détecte qu’elle ne dispose pas des informations nécessaires pour déterminer si le trafic issu ou destiné au dispositif 4 est associé ou non à l’attaque informatique ATTACK (réponse « non » à l’étape test E30). Par exemple, ce trafic présente des caractéristiques suspectes telles que décrites ci-avant mais l’entité DPS 6 n’est pas en mesure à partir de ces caractéristiques de décider s’il s’agit d’un trafic « légitime » ou s’il est associé à l’attaque informatique ATTACK. Conformément à l’invention, l’entité DPS 6 sollicite alors le dispositif 4 pour basculer vers un mode collaboratif (étape E50). Pour ce faire, dans le mode de réalisation décrit ici, l’entité DPS 6, via son module 6C de communication, envoie au dispositif 4 un message proposant une collaboration de ce dernier pour mitiger l’attaque informatique ATTACK (étape E60). Cette collaboration consiste, conformément à l’invention, en l’exécution par le dispositif 4 d’une ou de plusieurs actions déterminées dites de collaboration. Plus particulièrement, dans l’exemple envisagé ici, le message envoyé par l’entité DPS 6 au dispositif 4 est une trame de contrôle QUIC, appelée par exemple ici COMIT (pour « COllaborative MITigation »), et comprenant les éléments suivants : un paramètre « Lifetime » indiquant la durée de la collaboration proposée par l’entité DPS 6 ; à l’issue de cette échéance, la collaboration peut être désactivée automatiquement par le dispositif 4. On suppose ici qu’une valeur par défaut est définie pour ce paramètre au niveau de chaque dispositif 4 (par exemple une valeur supérieure ou égale à 60 minutes), de sorte que si aucune valeur du paramètre « Lifetime » n’est explicitement indiquée dans la trame COMIT, la durée de la collaboration considérée par le dispositif 4 est fixée au moins égale à cette valeur par défaut ; un paramètre « Strategy_ID » indiquant la ou les actions de collaboration que l’entité DPS 6 propose au dispositif 4 d’exécuter pour l’aider à mitiger l’attaque informatique ATTACK. Ces actions peuvent être de différentes natures et comprendre notamment la divulgation d’informations de contrôle des communications du dispositif 4, la désactivation de l’utilisation du protocole de transport chiffré (QUIC ici), ou encore le gel de la migration des identifiants de communication lors des communications du dispositif 4 (pour que l’entité DPS 6 puisse associer plus facilement les flux de données à une même communication, etc.). Ainsi par exemple, le paramètre « Strategy_ID » peut prendre les valeurs suivantes dans le contexte du protocole QUIC : 0x0 : désigne la divulgation des informations de contrôle des communications (connexion) ; 0x1 : désigne la désactivation du protocole de transport QUIC lors des communications ; 0x2 : désigne le gel des identifiants de connexion (CID) lors des communications ; 0x3 : désigne le gel des identifiants de connexion et des informations de contrôle des communications. Bien entendu, cette liste d’actions n’est pas exhaustive et d’autres actions peuvent être envisagées. On peut par ailleurs envisager une pluralité d’actions de collaboration proposées par l’entité DPS 6 du réseau (cf. code 0x3 dans l’exemple donné ci-dessus). On peut en outre considérer, qu’en l’absence de paramètre « Strategy_ID » explicite contenu dans la trame COMIT, une ou plusieurs actions de collaboration par défaut soient destinées à être appliquées par le dispositif 4, à savoir par exemple les actions correspondant au code 0x3 ici. En référence à la figure 5, sur réception de la trame COMIT (étape F10), le dispositif 4 a, dans le mode de réalisation décrit ici, la possibilité d’accepter ou de refuser la collaboration requise par l’entité DPS 6 (étape test F20). De la sorte, même si la collaboration est à l’initiative de l’entité DPS 6, on laisse avantageusement la liberté au dispositif 4 de refuser les actions de collaboration que celle-ci lui demande d’exécuter. On peut toutefois envisager, dans un autre mode de réalisation, que la trame COMIT ait pour conséquence d’activer la collaboration au niveau du dispositif 4, sans requérir d’accord explicite de ce dernier. Si le dispositif 4 refuse la collaboration (réponse « non » à l’étape test F20), il en informe l’entité DPS 6 ou ne tient pas compte du message (étape F30). Si le dispositif 4 accepte la collaboration (réponse « oui » à l’étape test F20), le dispositif 4 sauvegarde les informations contenues dans la trame COMIT (adresse de l’entité DPS 6, durée de la collaboration, actions, etc.) dans sa mémoire non volatile par exemple, et envoie un message de confirmation de la collaboration à l’entité DPS 6 (étape F40). La collaboration est alors activée au sein du dispositif 4 via son module 4A d’activation pour une durée minimum égale à la durée indiquée dans le paramètre « Lifetime ». On note que si besoin, cette durée peut être renouvelée, par exemple à l’initiative de l’entité DPS 6 si l’attaque informatique ATTACK n’est pas résorbée à l’expiration de la durée « Lifetime ». En variante, la trame COMIT ne contient pas de paramètre « Lifetime », aucune valeur n’est définie par défaut, et la collaboration peut être activée pour une durée indéterminée jusqu’à réception d’un message mettant fin à cette collaboration en provenance de l’entité DPS 6. L’activation de la collaboration au niveau du dispositif 4 se traduit par l’exécution par le dispositif 4 des actions de collaboration proposées par l’entité DPS 6 dans la trame COMIT. En outre, le dispositif 4 peut également solliciter lors de cette collaboration l’entité DPS 6 ou une autre entité du réseau NW, pour lui signaler les flux de données qu’il consent et/ou les flux de données qu’il considère comme suspects, autrement dit associés à une attaque informatique et notamment à l’attaque informatique ATTACK, compte tenu de la connaissance locale dont il dispose de ses communications. Ceci peut se faire en dehors de toute communication établie par le dispositif 4. Pour ce faire, dans le mode de réalisation décrit ici, le dispositif 4 envoie à l’entité DPS 6 un message comprenant des informations identifiant au moins un flux destiné au dispositif 4 consenti par celui-ci, ou identifiant au moins un flux destiné au dispositif 4 et considéré par celui-ci comme étant un flux associé à une attaque informatique. Ce message prend ici la forme de l’une des commandes suivantes, chaque commande pouvant être par exemple associée à une trame de contrôle QUIC dédiée : une commande, appelée « DISCARD_ALL », de blocage (filtrage) par l’entité DPS 6 de toutes les communications entrantes vers le dispositif 4 ; une commande, appelée « DISCARD_ALL/Except: ACCEPT_LIST(FLOW_ID) », de blocage (filtrage) par l’entité DPS 6 de toutes les communications entrantes vers le dispositif 4 à l’exception de celles identifiées par les identifiants de flux de données FLOW_ID fournis dans la liste ACCEPT_LIST(FLOW_ID). Les identifiants de flux de données peuvent être renseignés avec les identifiants de connexion (CID) ou d’autres informations permettant d’identifier les flux de données concernés, telles que l’adresse source, le port source, etc. ; une commande, appelée « ACCEPT_ALL », d’autorisation d’acheminement par l’entité DPS 6 de toutes les communications entrantes actives vers le dispositif 4 ; une commande, appelée « ACCEPT_ALL/Except: DISCARD_LIST(FLOW_ID) », d’autorisation d’acheminement par l’entité DPS 6 de toutes les communications entrantes actives vers le dispositif 4 à l’exception de celles identifiées par les identifiants de flux de données FLOW_ID fournis dans la liste « DISCARD_LIST(FLOW_ID) ». Dans un autre mode de réalisation, l’entité DPS 6 peut elle-même solliciter le dispositif 4 pour lui demander son autorisation explicite pour acheminer vers lui une ou plusieurs communications (ou de manière similaire un ou plusieurs flux de données). Elle peut à cet effet lui envoyer par exemple un message sous la forme d’une trame de contrôle QUIC appelée CONSENT_CHECK ici, comprenant les paramètres suivants : un paramètre « FLOW_ID », indiquant l’identifiant d’au moins une communication (ou connexion), cet identifiant pouvant être comme indiqué précédemment, un identifiant de connexion, une adresse source, un port source, etc. ; un paramètre « Magic Nonce » comprenant un identifiant généré de manière aléatoire dont le but est de permettre à l’entité DPS 6 de corréler la trame CONSENT_CHECK avec la réponse à cette trame envoyée par le dispositif 4. Quelle que soit la variante mise en œuvre (commandes « DISCARD/ACCEPT » ou message CONSENT_CHECK), l’entité DPS 6 mémorise dans sa mémoire non volatile les règles de filtrage ou d’acheminement convenues avec le dispositif 4, et les applique dès lors aux communications entrantes destinées au dispositif 4. Nous allons maintenant décrire comment est ou sont exécutées par le dispositif 4 la ou les actions de collaboration requises par l’entité DPS 6 et telles que décrites dans la trame COMIT dans le mode de réalisation envisagé ici. Ces actions peuvent être exécutées dans le cadre de communications QUIC actives ou à venir du dispositif 4 avec d’autres dispositifs communicants, et s’appuyer sur l’envoi de paquets QUIC lors de ces communications contenant des informations susceptibles d’aider l’entité DPS 6 à mitiger l’attaque informatique ATTACK. En variante ou en complément, ces informations peuvent être envoyées par le dispositif 4 à l’entité DPS 6 en dehors des communications du dispositif 4 selon le protocole QUIC, via des messages (ou trames QUIC) dédiés prévus à cet effet. Ces messages peuvent être destinés à l’entité DPS 6 ou être diffusés dans le réseau sur une adresse prédéterminée prévue à cet effet, et partagée par exemple par les entités impliquées dans la sécurité du réseau NW (par exemple une adresse multicast IP réservée à cet effet et correspondant à un groupe multicast auquel les entités du réseau NW concernés sont abonnées). De telles précautions permettent au dispositif 4 de contrôler les informations qu’il partage avec le réseau et d’éviter une exploitation abusive par ce dernier des informations qui lui sont révélées sur une durée limitée. Les actions de collaboration peuvent être exécutées par le dispositif 4 lors de tout ou partie de ses communications. Ainsi, le dispositif 4 peut, dans un mode de réalisation, décider des communications auxquelles il décide d’appliquer les applications de collaboration. Dans le mode de réalisation décrit ici, préalablement à l’exécution des actions de collaboration, une phase de négociation est mise en œuvre entre le dispositif 4, qui a accepté de collaborer avec l’entité DPS 6 du réseau NW, et ses correspondants, autrement dit les dispositifs avec lesquels il a établi des communications au cours desquelles il prévoit d’exécuter les actions de collaboration (étape F50). L’exécution des actions de collaboration par le dispositif 4 est conditionnée ici par le succès de cette phase de négociation (réponse « oui » à l’étape test F60) : autrement dit, les actions de collaboration ne sont exécutées par le dispositif 4 lors de ses communications que si elles sont approuvées par ses correspondants ou dans des conditions approuvées par ses correspondants. Il en résulte qu’il se peut que le dispositif 4 n’applique les actions de collaboration qu’avec certains de ses correspondants. On suppose par exemple ici qu’une telle phase de négociation est mise en œuvre par le dispositif 4 avec le dispositif 5. La figure 6 représente les principales étapes mises en œuvre par le dispositif 5 lors de cette phase de négociation. Ces étapes sont exécutées dans le cadre du procédé de communication selon l’invention mis en œuvre par le dispositif 5. Plus précisément, dans le mode de réalisation décrit ici, lors de la phase de négociation, le dispositif 4 envoie un message au dispositif 5 l’informant de l’exécution d’action(s) de collaboration lors de ses communications avec le dispositif 5. Ce message d’information est reçu par le dispositif 5 via son module 5A d’émission/réception. Il prend la forme ici d’une trame QUIC, chiffrée conformément aux principes du protocole QUIC. Dans le mode de réalisation décrit ici, le message d’information envoyé par le dispositif 4 dépend de l’action de collaboration exécutée par le dispositif 4 (une trame distincte selon l’action), et comprend une ou plusieurs conditions d’exécution de l’action de collaboration. Ainsi, par exemple, si l’action de collaboration exécutée par le dispositif 4 est la divulgation d’informations de contrôle sur les communications du dispositif 4, le message d’information envoyé par le dispositif 4 est une trame QUIC nommée ici CONTROL_REVEAL et comprenant notamment les paramètres suivants pour préciser les conditions d’exécution de la divulgation des informations de contrôle : un paramètre « Lifetime », indiquant comme dans la trame COMIT la durée de la collaboration mise en place par le dispositif 4. Si aucun paramètre « Lifetime » n’est valorisé dans la trame CONTROL_REVEAL, on peut envisager qu’une valeur par défaut, par exemple supérieure ou égale à 60 minutes, est appliquée par le dispositif 4 ; et un paramètre « Direction » indiquant la direction de la communication concernée par l’action de collaboration mise en œuvre par le dispositif 4. Par exemple, ce paramètre peut prendre les valeurs suivantes : 0x0 : seuls les paquets de données envoyés par le dispositif 4 sont concernés par la divulgation des informations de contrôle ; 0x1 : seuls les paquets de données envoyés par le dispositif 5 distant sont concernés par la divulgation des informations de contrôle ; 0x2 : tous les paquets de données envoyés par le dispositif 4 et par le dispositif 5 sont concernés par la divulgation des informations de contrôle. En l’absence de valeur précisée dans la trame CONTROL_REVEAL pour le paramètre « Direction », on considère ici que c’est l’option appliquée par défaut. Bien entendu, ces paramètres ne sont donnés qu’à titre illustratif et d’autres conditions d’exécution peuvent être spécifiées. Par exemple, seuls les paquets partageant une même adresse destination donnée, une même adresse source donnée, un même numéro de port source ou destination ou une combinatoire de ces critères et envoyés par le dispositif 4 (respectivement le dispositif 5) sont concernés par la divulgation des informations de contrôle, etc. Le dispositif 5 peut alors accepter ou refuser (par exemple en ignorant le message CONTROL_REVEAL, étape G40) la collaboration mise en place par le dispositif 4 (étape test G20). En variante, une négociation d’une ou de plusieurs conditions d’exécution de l’action de collaboration peut être déclenchée entre les deux dispositifs. L’acceptation ou le refus de la collaboration met fin à la phase de négociation. On suppose ici que le dispositif 5 accepte la collaboration (réponse « oui » à l’étape test G20 et réponse « oui » à l’étape F60) et l’exécution de l’action de collaboration consistant à divulguer les informations de contrôle de ses communications avec le dispositif 4. Le dispositif 5 envoie alors au dispositif 4 un message d’acquittement pour l’informer de son accord (étape G30). Le message d’acquittement est reçu par le dispositif 4 via son module 4B d’émission/réception. On note que les deux dispositifs 4 et 5 peuvent être sollicités indépendamment pour collaborer par l’entité DPS 6 ou par des entités distinctes du réseau NW, ou encore s’ils appartiennent à des réseaux différents, par des entités distinctes de leurs réseaux respectifs. Les dispositifs 4 et 5 peuvent alors tous les deux s’envoyer respectivement des trames QUIC CONTROL_REVEAL au titre d’une même communication si, par exemple, ils ont accepté respectivement une telle collaboration. La phase de négociation qui vient d’être décrite est effectuée pour les communications (ou connexions) QUIC existantes du dispositif 4, autrement dit pour les communications déjà établies. Une phase de négociation similaire peut également être conduite pour les communications QUIC à venir du dispositif 4 (c’est-à-dire, celles à établir après qu’un évènement déclencheur a été reçu/détecté). Pour ce faire, lorsque le dispositif 4 envoie une demande d’établissement d’une communication QUIC vers un dispositif distant (par exemple vers le dispositif 5), il utilise une trame QUIC dans lequel les informations de contrôle de la communication sont divulguées. Il envoie également, lors de cette demande d’établissement, une trame CONTROL_REVEAL pour informer le dispositif 5 des conditions d’exécution des actions de collaboration (ex. durée, direction). Le traitement de la trame CONTROL_REVEAL par le dispositif 5 est identique à ce qui a été décrit précédemment pour les communications en cours. On note donc que pour le traitement des communications à venir, la négociation vient dans un second temps, et ne s’oppose pas à la divulgation des informations de contrôle de la communication dans la demande d’établissement de la communication. Lorsque la phase de négociation se solde par une acceptation de la collaboration par le dispositif distant (dispositif 5 dans les exemples précédents), le dispositif 4 peut dès lors continuer de divulguer lors de ses communications avec le dispositif 5 les informations de contrôle relatives à ces communications, pendant la durée définie par le paramètre « Lifetime », et selon les conditions d’exécution négociées avec le dispositif 5 (étape F70 sur la figure 5). Dans le mode de réalisation décrit ici, les informations de contrôle des communications sont exposées dans l’en-tête public des paquets de données QUIC envoyés et/ou reçus par le dispositif 4. De la sorte, une fonction localisée dans le réseau NW par laquelle transitent ces paquets de données QUIC (typiquement dans l’exemple envisagé ici, l’entité DPS 6), est en mesure d’accéder aux informations de contrôle divulguées par le dispositif 4 (et/ou par ses correspondants). Plus particulièrement, dans le mode de réalisation décrit ici, les inventeurs proposent de modifier la partie publique des en-têtes des paquets QUIC tels que définis actuellement dans le protocole QUIC pour indiquer explicitement et en clair des informations de contrôle d’une communication. De telles informations sont par exemple : un état d’un établissement de la communication ; un consentement d’envoi et/ou de réception de paquets de données lors de la communication par l’un et/ou l’autre des dispositifs impliqués dans la communication (dispositifs 4 et 5 dans l’exemple envisagé ici) ; et un consentement ou une absence de consentement de ladite communication par l’un et/ou l’autre des dispositifs impliqués dans la communication (dispositifs 4 et 5 dans l’exemple envisagé ici). La figure 7 illustre un exemple d’une telle modification pour un en-tête court d’un paquet QUIC. Dans cet exemple, l’indicateur (réservé) C du premier octet de l’en-tête court (cf. octet 1-1 représenté sur la figure 1) est valorisé à « 1 » pour indiquer que le paquet QUIC contient un nouveau champ appelé ici « Public Control Status » reflétant diverses informations de contrôle de la communication (dans l’état actuel de la technique, l’indicateur réservé C est généralement valorisé à 0 ; s’il est valorisé à 1, il n’est pas pris en compte). Le champ « Public Control Status » peut être renseigné par exemple avec les valeurs suivantes : 0x0 : pour indiquer que la communication (ou connexion) est en cours d’établissement ; 0x1 : pour indiquer le consentement du dispositif 4 à recevoir de paquets de données en provenance du dispositif distant (dispositif 5 dans l’exemple envisagé ici) ; 0x2 : pour indiquer le consentement du dispositif 4 à envoyer et recevoir des paquets de données ; 0x3 : pour indiquer une communication établie avec consentement mutuel des dispositifs 4 et 5 ; et 0x4 : pour indiquer une communication non consentie. On note que, dans l’état de la technique, une communication non consentie par un dispositif est en général ignorée par ce dernier. Au contraire, les inventeurs proposent d’exploiter avantageusement cette information et de la porter à la connaissance d’une ou de plusieurs fonctions du réseau NW (par exemple ici de l’entité DPS 6) qui peuvent alors se charger de filtrer tous les flux relatifs à cette communication non consentie par le dispositif 4 (voire relatifs à toutes les communications établies avec le dispositif distant 5). D’autres valeurs peuvent bien entendu être envisagées en variante pour fournir d’autres informations de contrôle de la communication aux entités du réseau impliquées dans la mitigation de l’attaque informatique ATTACK. Il convient toutefois de noter qu’il n’apparaît pas utile de divulguer les sous-états de contrôle de la communication comme par exemple la création ou la clôture d’un nouveau canal ou STREAM, la retransmission de paquets QUIC, etc., ces informations n’étant a priori pas exploitables par de telles entités du réseau. Une modification des en-têtes longs pour inclure un nouveau champ « Public Control Status » peut également être envisagée en variante, comme illustrée par la figure 8 . Ce champ est positionné à « 0x0 » pour les paquets Initial (illustré par la figure 8B ) et 0-RTT (illustré par la figure 8A ). L’avantage de cette variante est de permettre à la fonction réseau de détecter à l’avance les connexions établies selon un mode collaboratif. Ainsi, ladite fonction peut garder en mémoire les identifiants CID (Source et Destination) pour faciliter la corrélation des paquets émis avec les paquets reçus et caractéristiques d’une même communication QUIC. On note qu’afin d’éviter d’utiliser la collaboration mise en place entre le dispositif 4 et l’entité DPS 6 pour introduire dans le réseau NW des attaques par réflexion, on peut configurer les dispositifs communicants impliqués dans une communication transitant par l’entité DPS 6, pour qu’ils n’envoient pas plus de trois paquets QUIC révélant les informations de contrôle de cette communication. La figure 9 montre des exemples d’utilisations par une entité du réseau, par exemple ici, par l’entité DPS 6, des informations de contrôle divulguées dans les en-têtes des paquets QUIC échangés entre les dispositifs 4 et 5, pour mitiger une attaque informatique. En référence à la figure 9A , une communication collaborative consentie, à l’origine du dispositif 4, est caractérisée par l’observation par l’entité DPS 6 des éléments suivants : Envoi (QUIC1) d’un message QUIC d’initialisation d’une communication du dispositif 4 vers le dispositif 5 : dans ce message, le flag C est valorisé à 1 et le champ « Public Control Status » (ou PCS sur la figure) est valorisé à PCS=0x0 (ou 0). L’identifiant de connexion du dispositif 4 (SCID ou Source CID) est valorisé à Val4 et celui du dispositif 5 distant (DCID) à 0 ; Envoi (QUIC2) d’un message QUIC par le dispositif 5 au dispositif 4 dans lequel le flag C est valorisé à 1 et le champ « Public Control Status » est valorisé à PCS=0x1 (reflétant une information de consentement d’envoi ou de réception) ; Envoi (QUIC3) d’un message QUIC par le dispositif 4 au dispositif 5 dans lequel le flag C est valorisé à 1 et le champ « Public Control Status » est valorisé à PCS=0x2 (reflétant une information de consentement d’envoi et de réception de paquets) ; Envois (QUIC4) et (QUIC5) de messages QUIC par le dispositif 5 au dispositif 4, et par le dispositif 4 au dispositif 5 dans lesquels le flag C est valorisé à 1 et le champ « Public Control Status » est valorisé à PCS=0x03 (reflétant une communication établie avec consentement mutuel). Un échange similaire peut être décrit pour une communication établie à l’initiative du dispositif 5. L’entité DPS 6, placée sur le chemin des échanges ayant lieu entre les dispositifs 4 et 5, peut détecter une anomalie dans le trafic destiné ou issu du dispositif 4 si le message de consentement (correspondant au champ « Public Control Status » positionné à 0x3) n’est pas échangé entre les deux dispositifs, ou si le dispositif 4 n’a pas explicitement indiqué son consentement à recevoir du trafic au titre d’une communication établie avec le dispositif 5. Si une telle anomalie est détectée, l’entité DPS 6 peut décider de rediriger les paquets de données de ladite communication vers un centre de nettoyage (plus couramment appelé « Scrubbing center » en anglais) pour traitement de ces paquets de données ou de bloquer ces paquets de données. Selon un autre exemple illustré sur la figure 9B , le dispositif 4 peut envoyer, après avoir reçu divers paquets de données en provenance du dispositif 5 (envois (QUIC6) et (QUIC7)), un message QUIC avec le champ « Public Control Status » positionné à PCS=0x4 (envoi (QUIC8)). Ce message est intercepté par l’entité DPS 6 qui en extrait les informations de contrôle de la communication avant de supprimer le message. Tous les paquets de cette communication, voire les paquets de toutes les communications reçues du dispositif 5 sont alors bloqués par l’entité DPS 6 et rejetés (rejets des envois (QUIC9) et (QUIC10)). Ces filtrages peuvent être supprimés après l’expiration d’une échéance spécifique. On note que préférentiellement, le message intercepté par l’entité DPS 6 n’est pas acheminé vers le dispositif 5 pour éviter que celui-ci ne l’utilise pour ajuster sa stratégie d’attaque. Au regard de ces deux exemples, il apparaît clairement que la divulgation des informations de contrôle dans le cadre du protocole QUIC permet avantageusement à l’entité DPS 6 de mieux différencier le trafic consenti par le dispositif 4 du trafic de l’attaque, et de prendre des actions appropriées et efficaces en vue de mitiger l’attaque. Comme mentionné précédemment, outre la divulgation d’informations de contrôle des communications, l’entité DPS 6 peut proposer au dispositif 4 (et le cas échéant au dispositif 5) d’autres actions de collaboration, et notamment le gel de la migration des identifiants de communication lors des communications établies par le dispositif 4 (correspondant au paramètre « Strategy_ID » valorisé à 0x2 dans la trame COMIT transmise par l’entité DPS 6 au dispositif 4). Pour cette action également, on peut envisager la mise en œuvre d’une phase de négociation entre les dispositifs 4 et 5 suite à l’acceptation par le dispositif 4 de la collaboration proposée par l’entité DPS 6. De façon connue en soi, le protocole QUIC offre la possibilité aux dispositifs communicants de changer lors de leurs communications les identifiants de communication (plus communément désignés par identifiants de connexion ou CID dans le contexte du protocole QUIC) qu’ils utilisent pour caractériser celles-ci. Ce changement, aussi connu sous le nom de « migration des identifiants de connexion », se fait classiquement via l’échange de trames QUIC prévues à cet effet et dont le contenu est chiffré, notamment les identifiants de connexion vers lesquels la communication est destinée à migrer de sorte qu’il n’est pas possible aux entités du réseau de faire le lien entre les nouveaux identifiants de connexion d’une communication utilisés après migration par les dispositifs communicants et les précédents identifiants de connexion utilisés avant migration. L’invention offre la possibilité de geler la migration des identifiants de connexion relatifs à une communication durant une durée déterminée qui peut être égale à la valeur du paramètre « Lifetime » fournie dans la trame COMIT, ou en variante, correspondre au temps que durera la communication. En maintenant les mêmes identifiants de connexion pendant la durée de la communication QUIC, la classification par une fonction réseau telle que l’entité DPS 6 des paquets de données caractéristiques de cette communication est simplifiée, car cela permet de corréler les paquets envoyés avec les paquets reçus au cours d’une même communication. Ainsi une même communication est identifiée de façon unique pendant qu’une ou plusieurs action(s) mitigation est/sont en cours. L’analyse des paquets par l’entité DPS6 pour déterminer s’ils appartiennent à un trafic consenti par le dispositif 4 ou à un trafic d’attaque est de ce fait grandement simplifiée. Comme pour la divulgation des informations de contrôle, préalablement à l’application du gel de la migration des identifiants de connexion relatifs à ses communications en cours, le dispositif 4 peut engager une phase de négociation avec ses correspondants, et en particulier ici avec le dispositif 5 (étape F50 figure 5, étapes G10 et G20 figure 6). Pour ce faire, le dispositif 4 envoie au dispositif 5 un message l’informant du gel des identifiants de connexion qu’il envisage d’exécuter. Ce message prend la forme ici d’une trame QUIC chiffrée appelée FREEZE_CID et comprenant notamment un paramètre « Lifetime » indiquant la durée pendant laquelle le dispositif 4 envisage de maintenir un unique identifiant de connexion CID lors de sa communication avec le dispositif 5. Préférentiellement, la durée « Lifetime » est choisie de sorte que l’identifiant de connexion CID reste le même durant toute la communication (on note que de ce fait, la durée « Lifetime » de maintien de l’identifiant de connexion CID ne correspond pas nécessairement à la durée d’activation de la collaboration fournie par l’entité DPS 6 dans le message COMIT. Elle peut notamment être inférieure à la durée fournie dans le message COMIT). En variante, la trame FREEZE_CID peut contenir d’autres paramètres. Ainsi, de façon connue de l’homme du métier, un identifiant de connexion CID comprend deux parties, un identifiant de connexion source ou SCID et un identifiant de connexion destinataire ou DCID. La trame FREEZE_CID peut indiquer comme condition d’exécution, à quelle partie s’applique le maintien préconisé par l’action de collaboration. A l’issue de la durée « Lifetime », la collaboration est désactivée automatiquement au niveau du dispositif 4. Le dispositif 4 peut alors générer s’il le souhaite de nouveaux identifiants de connexion et procéder à une migration d’identifiants de connexion à l’aide des trames QUIC connues NEW_CONNECTION_ID et RETIRE_CONNECTION_ID, selon la mécanique protocolaire QUIC classique connue de l’homme du métier. Le dispositif distant 5 peut accepter (réponse « oui » à l’étape test G20), respectivement refuser (réponse « non » à l’étape test G20), le gel des identifiants de connexion en répondant avec un message d’acquittement ACK (étape G30), ou respectivement en ignorant le message FREEZE_CID (étape G40). Une fois la phase de négociation terminée avec succès, les deux dispositifs 4 et 5 maintiennent un et un seul identifiant de connexion CID composé ici d’un identifiant de connexion généré par le dispositif 4 et d’un identifiant de connexion généré par le dispositif 5 (servant tour à tour de SCID et de DCID selon le sens des messages échangés lors de la communication) (étapes G50 et F70). On note qu’une phase de négociation similaire ou identique à celles qui viennent d’être décrites pour des actions de collaboration de type divulgation d’informations de contrôle et gel des identifiants de connexion peut être mise en œuvre également lorsque l’entité DPS 6 propose dans son message COMIT une combinaison de plusieurs actions de collaboration (par exemple, paramètre « Strategy_ID » valorisé à 0x3 pour requérir le gel des identifiants de connexion et la divulgation d’informations de contrôle). Dans ce cas, le dispositif distant 5 peut, lors de la phase de négociation, accepter ou refuser une ou plusieurs de ces actions de collaboration. Comme évoqué précédemment, une autre action de collaboration possible peut consister pour le dispositif 4 à désactiver le protocole de transport QUIC pour établir ses communications et à utiliser un autre protocole de transport que QUIC, comme par exemple le protocole de transport TCP pour établir ses communications à venir (c’est-à-dire, celles à établir après qu’un évènement déclencheur a été reçu/détecté). Comme pour les autres actions de collaboration, une négociation préalable peut être mise en place entre le dispositif 4 et ses correspondants pour s’assurer que ces derniers acceptent la désactivation du protocole QUIC. Suite à l’acceptation de la collaboration proposée par l’entité DPS 6, et le cas échéant, si ses correspondants sont d’accord, le dispositif 4 utilise le protocole TCP pour l’établissement de ses nouvelles communications, tant que la collaboration est active. A l’expiration de la collaboration (autrement dit de la durée « Lifetime »), le dispositif 4 peut réutiliser le protocole QUIC pour l’établissement de ses communications avec ses correspondants. Les actions de collaboration qui viennent d’être évoquées ne sont pas limitatives en soi. Elles ont une application privilégiée dans le cadre du protocole QUIC mais ne sont toutefois pas limitées à ce protocole. Par ailleurs, d’autres actions de collaboration peuvent bien entendu être envisagées, en variante ou en complément de celles qui viennent d’être citées et détaillées. En outre, dans le mode de réalisation décrit ici, le déclenchement de la collaboration du dispositif 4 avec le réseau NW et plus particulièrement avec l’entité DPS 6, est à l’initiative de l’entité DPS 6. En variante, la collaboration peut être déclenchée par le dispositif 4 lui-même. Dans ce cas, le dispositif 4 ne reçoit pas de message explicite en provenance du réseau, mais s’appuie sur des évènements qu’il a observés localement (par exemple la détection d’une attaque) ou qui lui sont rapportés par un dispositif distant ou une entité tierce (externe ou non au réseau). Dans ce mode de réalisation, la collaboration concerne alors par défaut l’ensemble des communications QUIC du dispositif 4 via le réseau NW. Le dispositif 4 peut toutefois à tout moment décider de n’activer cette collaboration que pour un sous-ensemble de ses communications, par exemple selon la nature des événements rapportés par ses correspondants ou par le réseau utilisé pour acheminer les données d’une communication. On note par ailleurs, que dans le mode de réalisation décrit ici, le dispositif 4 n’est raccordé qu’à un seul réseau NW et n’est sollicité que par une seule fonction réseau à savoir l’entité DPS 6. En variante, un même dispositif peut être raccordé à plusieurs réseaux distincts et décider d’activer une collaboration avec une ou plusieurs entités distinctes de ces réseaux. Procédé de gestion de communications selon un protocole de transport donné d’un premier dispositif (4) d’un réseau, ledit procédé étant mis en œuvre par le premier dispositif et comprenant, suite à une détection d’une attaque informatique (E10), une étape d’activation (F40) au niveau dudit premier dispositif, d’une collaboration avec au moins une entité dudit réseau pour mitiger ladite attaque informatique, ladite collaboration comprenant une exécution (F70) par ledit premier dispositif d’au moins une action déterminée dite de collaboration, lors d’au moins une dite communication dudit premier dispositif selon ledit protocole de transport donné, via ledit réseau. Procédé de gestion selon la revendication 1 dans lequel ladite étape d’activation est déclenchée par une réception (F10) en provenance de ladite au moins une entité du réseau, d’un message proposant ladite collaboration. Procédé de gestion selon la revendication 1 ou 2 comprenant en outre une étape d’envoi (F50), à un moins un deuxième dispositif (5) participant à au moins une dite communication selon ledit protocole de transport donné avec ledit premier dispositif, d’un message d’information informant ledit deuxième dispositif de l’exécution par le premier dispositif de ladite au moins une action de collaboration. Procédé de gestion selon la revendication 3 dans lequel l’exécution de ladite au moins une action de collaboration est conditionnée par la réception d’un accord du deuxième dispositif. Procédé de gestion selon la revendication 3 ou 4 dans lequel ledit message d’information comprend au moins une condition d’exécution de ladite action de collaboration. Procédé de communication avec un premier dispositif (4) d’un réseau, ledit procédé étant mis en œuvre par un deuxième dispositif (5) et comprenant : une étape de réception (G10) d’un message d’information en provenance du premier dispositif, informant le deuxième dispositif d’une exécution par le premier dispositif d’au moins une action déterminée lors d’au moins une communication selon un protocole de transport donné avec le deuxième dispositif, ladite action, dite de collaboration, permettant une collaboration avec au moins une entité du réseau pour mitiger une attaque informatique ; si ledit deuxième dispositif accepte l’exécution de ladite action de collaboration, une étape d’information (G30) du premier dispositif de son accord. Procédé selon l’une quelconque des revendications 1 à 6 dans lequel au moins un paquet de données échangé lors d’une dite communication selon ledit protocole de transport donné comprend au moins un entête indiquant en clair au moins une information de contrôle de ladite communication parmi : un état d’un établissement de ladite communication ; un consentement d’envoi et/ou de réception de paquets de données lors de ladite communication ; et un consentement ou une absence de consentement de ladite communication. Procédé de communication par une entité (6) d’un réseau à au moins un dispositif du réseau, ledit procédé comprenant, suite à une incapacité de ladite entité à déterminer si un flux de données destiné audit ou provenant dudit dispositif est associé ou non à une attaque informatique, une étape d’envoi (E60) par ladite entité audit dispositif d’un message proposant une collaboration du dispositif pour mitiger ladite attaque informatique, ladite collaboration comprenant une exécution par le dispositif d’au moins une action déterminée dite de collaboration, lors d’au moins une communication dudit dispositif selon un protocole de transport donné via ledit réseau. Procédé de communication selon la revendication 8 comprenant en outre une étape de réception d’au moins une information identifiant au moins un flux destiné audit dispositif consenti par celui-ci, ou identifiant au moins un flux destiné audit dispositif et considéré par celui-ci comme étant un flux associé à une attaque informatique. Procédé de communication selon la revendication 9 dans lequel ladite au moins une information est fournie : dans une commande de blocage par ladite entité dudit au moins un flux considéré par le dispositif comme étant un flux associé à une attaque informatique ; ou dans une commande d’autorisation d’acheminement dudit au moins un flux consenti par le dispositif. Procédé de communication selon l’une quelconque des revendications 8 à 10 comprenant en outre une étape d’envoi audit dispositif d’une demande d’autorisation d’acheminement vers ledit dispositif d’au moins un flux de données identifié dans ladite demande. Procédé de communication selon l’une quelconque des revendications 8 à 11 comprenant en outre : une étape de réception d’au moins un paquet de données échangé lors de ladite communication comprenant au moins un entête dans lequel au moins une information de contrôle de ladite communication parmi un état d’un établissement de ladite communication, un consentement d’envoi et/ou de réception de paquets de données par ledit dispositif lors de ladite communication, et un consentement ou une absence de consentement par ledit dispositif de ladite communication est indiquée en clair ; et une étape d’utilisation de ladite au moins une information de contrôle pour mitiger l’attaque informatique. Procédé selon l’une quelconque des revendications 1 à 12 dans lequel ladite au moins une action de collaboration comprend : une divulgation d’informations de contrôle de ladite au moins une communication ; et/ou un gel d’une migration des identifiants de communication utilisés lors de ladite au moins une communication ; ou une désactivation d’une utilisation dudit protocole de transport donné par ledit dispositif lors de ladite au moins une communication. Procédé selon l’une quelconque des revendications 1 à 13 dans lequel ladite au moins une action de collaboration est exécutée pendant une durée déterminée. Procédé selon l’une quelconque des revendications 1 à 14 dans lequel ledit protocole de transport donné est le protocole QUIC. Programme d’ordinateur (PROG4, PROG5, PROG6) comportant des instructions pour l’exécution d’un procédé selon l’une quelconque des revendications 1 à 15, lorsque ledit programme est exécuté par un ordinateur. Dispositif (4) d’un réseau, comprenant un module d’activation, déclenché suite à une détection d’une attaque informatique, et configuré pour activer au niveau dudit dispositif une collaboration avec au moins une entité du réseau pour mitiger ladite attaque informatique, ledit module d’activation (4A) étant configuré pour exécuter, lors de ladite collaboration, au moins une action déterminée dite de collaboration, lors d’au moins une communication dudit dispositif selon un protocole de transport donné, via ledit réseau. Dispositif (5), dit deuxième dispositif, comprenant un module de communication (5A) avec un premier dispositif d’un réseau, ledit module de communication étant configuré pour : recevoir un message d’information en provenance de ce premier dispositif, informant le deuxième dispositif d’une exécution par le premier dispositif d’au moins une action déterminée lors d’au moins une communication selon un protocole de transport donné avec le deuxième dispositif, ladite action, dite de collaboration, permettant une collaboration avec au moins une entité dudit réseau pour mitiger une attaque informatique ; si ledit deuxième dispositif accepte l’exécution de ladite action de collaboration, informer le premier dispositif de son accord. Entité (6) d’un réseau comprenant un module de communication, déclenché par une incapacité de ladite entité à déterminer si un flux de données destiné à ou provenant d’un dispositif du réseau est associé ou non à une attaque informatique, ledit module de communication (6C) étant configuré pour envoyer audit dispositif un message proposant une collaboration du dispositif pour mitiger ladite attaque informatique, ladite collaboration comprenant une exécution par le dispositif d’au moins une action déterminée dite de collaboration, lors d’au moins une communication dudit dispositif selon un protocole de transport donné via ledit réseau. Système (3) comprenant : au moins un premier dispositif (4) d’un réseau selon la revendication 17 ; au moins un deuxième dispositif (5) apte à communiquer avec le premier dispositif ; et au moins une entité (6) du réseau ; ledit premier dispositif étant configuré pour exécuter, suite à une détection d’une attaque informatique, au moins une action déterminée lors d’au moins une communication avec le deuxième dispositif, de sorte à collaborer avec ladite au moins une entité pour mitiger ladite attaque informatique. Système (3) selon la revendication 20 dans lequel le deuxième dispositif est conforme à la revendication 18 et/ou l’entité du réseau est conforme à la revendication 19.