Brevet FR3131023A1 — publié le 20230623

Procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique, dispositifs, signal et dispositifs correspondants Des services de détection et de mitigation d’attaques informatiques sont proposés par certains fournisseurs d’accès à leurs clients. Cependant, il arrive parfois qu’un message de sollicitation d’une assistance pour la gestion d’attaques émis par un nœud d’un domaine client subissant une attaque informatique soit envoyé vers un serveur de mitigation qui n’est pas capable de le traiter. Une telle demande sera alors systématiquement rejetée et aucune action de mitigation ne sera mise en œuvre. La présente solution permet de s’assurer qu’aucun message de sollicitation émis par un nœud ne reste sans réponse même s’il est transmis à destination d’un serveur de mitigation incapable de le traiter. Pour cela, lorsqu’un serveur de mitigation détermine qu’il n’est pas capable de traiter un message de sollicitation plutôt que de rejeter cette sollicitation, il va chercher à identifier au moins un autre serveur de mitigation qui serait en mesure de traiter ce message de sollicitation. FIGURE 1 Procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique, dispositifs, signal et dispositifs correspondants Domaine de l'invention Le domaine de l’invention est celui des communications établies sur un réseau, par exemple un réseau IP, et notamment celui des services IP à valeur ajoutée. L’invention trouve notamment des applications dans le domaine de la mitigation d’attaques par déni de service distribuées (en anglais DDoS, pour « Distributed Denial of Service »), mettant par exemple en œuvre, mais non exclusivement, une architecture de type DOTS (en anglais « DDoS Open Threat Signaling »), telle que normalisée par l’IETF, ou la mitigation d’attaques par intrusion. Plus précisément, l’invention offre une solution permettant de faciliter la coordination des actions de mitigation engagées afin de contrer des attaques informatiques impactant un domaine client. Art antérieur et ses inconvénients Pour rappel, une attaque DDoS est une tentative de rendre des ressources, par exemple des ressources réseau ou de calcul, indisponibles pour leurs utilisateurs. De telles attaques peuvent être massivement déployées en compromettant un grand nombre d’hôtes, et en utilisant ces hôtes pour amplifier les attaques. Afin de pallier ces attaques DDoS, des services de détection et de mitigation sont proposés par certains fournisseurs d’accès ou de services à leurs clients. De tels services de mitigation (en anglais DPS pour « DDoS Protection Services ») peuvent être hébergés au sein des infrastructures exploitées par les fournisseurs d’accès ou dans le « cloud » (en français « nuage »). Ils permettent notamment de distinguer le trafic « légitime », i.e., les données consenties par l’utilisateur, du trafic « suspect ». Lorsqu’un service de type DPS est hébergé dans le « cloud », il est difficile d’identifier une attaque DDoS de façon anticipée, car les composantes de détection mises en œuvre par un tel service ne sont pas forcément présentes sur les chemins empruntés par les données caractéristiques du trafic d’attaque pour atteindre sa ou ses victimes. Pour résoudre ce problème, il a été notamment proposé de mettre en place des tunnels au travers desquels le trafic en provenance ou à destination d’un site ou d’un réseau est acheminé. De tels tunnels constituent ainsi une ressource de transport du trafic que le service DPS peut alors inspecter. Toutefois, l’établissement et l’utilisation de tunnels augmentent considérablement la latence observée par les utilisateurs et imposent des contraintes de dimensionnement du service DPS pour être en mesure de traiter tout le trafic en provenance ou à destination de l’ensemble des terminaux utilisateurs de tels tunnels. En outre, lesdits tunnels sont considérés comme des vecteurs d’attaque potentiels. Lorsqu’un service de type DPS est hébergé au sein d’une infrastructure exploitée par un fournisseur d’accès, même si le service DPS est présent sur le chemin emprunté par le trafic en provenance ou à destination d’un réseau, des difficultés peuvent survenir pour l’identification du trafic suspect. Notamment, avec l’augmentation du trafic chiffré, transporté en particulier sur UDP (pour « User Datagram Protocol » en anglais) tel que par exemple le trafic QUIC, il est difficile de distinguer le trafic légitime du trafic suspect. La difficulté d’accéder en clair aux messages de contrôle, similaires aux messages « SYN/SYN-ACK/ACK » du protocole TCP (pour « Transmission Control Protocol » en anglais), peut en effet compliquer la vérification du consentement d’un nœud du réseau à recevoir du trafic, par exemple. Afin d’aider à l’identification du trafic suspect, une architecture spécifique a été normalisée au sein de l’IETF, appelée architecture DOTS. Une telle architecture, permet à un nœud client, dit client DOTS, d’informer un serveur de mitigation, dit serveur DOTS, qu’il a détecté une attaque DDoS et que des actions de mitigation appropriées sont requises. Lorsqu’un domaine client est la cible d’une attaque DDoS, un client DOTS faisant partie de ce domaine client peut ainsi envoyer un message à un serveur DOTS pour demander de l’aide. Ce dernier coordonne, avec une entité de mitigation (en anglais « mitigator »), les actions à effectuer pour que le trafic de l’attaque de déni de service ne soit plus acheminé vers le domaine client, alors que le trafic légitime continue d’être acheminé normalement vers le domaine client. L’architecture DOTS repose sur l’utilisation de deux canaux de communication pour l’échange de messages de signalisation entre un client DOTS et un serveur DOTS : - un canal de données DOTS (en anglais « DOTS Data Channel »), et - un canal de signalisation DOTS (en anglais « DOTS Signal Channel »). Le canal de données DOTS peut être utilisé lorsqu’aucune attaque DDoS n’est détectée par un client DOTS, notamment pour faciliter la mise en place d’actions préventives, telles que l’installation de filtres de trafic. Le canal de données peut aussi être utilisé pour préinstaller des règles de filtrage à activer lors d’une mitigation (par exemple, identifier une partie du trafic qui ne doit pas être supprimée par les actions de mitigation). Par exemple, un client DOTS peut utiliser ce canal pour installer des règles de filtrage du trafic reçu de certaines adresses ou celui destiné à un nœud donné, ou pour demander au serveur de bloquer tout le trafic à destination du préfixe « 1.2.3.0/24 » ou encore tout le trafic UDP à destination du numéro de port 443, couramment utilisé par les attaques de déni de service. Le canal de signalisation DOTS, quant à lui, est utilisé particulièrement quand une attaque DDoS est en cours. Ainsi, un client DOTS peut utiliser ce canal pour demander de l’aide auprès du serveur DOTS. Par exemple, un client DOTS utilise le canal de signalisation pour envoyer une requête de mitigation au serveur l’informant que le préfixe « 1.2.3.0/24 » subit une attaque DDoS, afin que le serveur puisse engager des actions pour mettre fin à l’attaque. Une telle requête est associée à un client DOTS identifié par un identifiant unique parmi la pluralité des clients actifs d’un domaine client, noté CUID (« Client Unique IDentifier »). Si l’entité de mitigation n’est pas colocalisée avec le serveur DOTS, ce dernier relaye la requête à une entité de mitigation qui peut ainsi prendre les mesures de mitigation adéquates pour mettre fin à une attaque DDoS d’une part, si la requête émanant du client DOTS n’est pas en conflit avec d’autres demandes émanant d’autres clients DOTS faisant partie du même domaine client, ou avec une règle de filtrage installée préalablement par le serveur DOTS en réponse à une requête d’un autre client du même domaine client, et d’autre part, si le serveur est habilité à/configuré pour honorer la dernière requête reçue. Lorsque le serveur DOTS n’est pas habilité à traiter une telle requête, il la rejette et émet un message d’erreur 4.03 (Bad Request). Il existe par conséquent un risque qu’un serveur DOTS refuse de traiter des messages de signalisation provenant d’un client DOTS, comme par exemple une requête de mitigation d’attaque émise par un client DOTS alors que l’attaque est réelle, ou des requêtes de filtrage émises par un client DOTS (un objectif des requêtes de filtrage étant d’anticiper des attaques DDoS). Un tel refus peut notamment survenir lorsque le domaine client utilise une adresse « anycast » pour joindre un serveur DOTS ou en cas de défaillance d’un algorithme permettant d’identifier un équipement de sortie du domaine client, par exemple. Une adresse « anycast » est une adresse configurée avec plusieurs interfaces réseau et qui permet donc de joindre plusieurs équipements. Ainsi, un paquet de données ayant pour destination une adresse « anycast » sera traité par un seul équipement ayant été configuré avec cette adresse, mais qui se trouve être le plus proche de la source émettrice du paquet au sens de la politique de routage dynamique mise en œuvre au sein du réseau. Dans de tels cas de figure, une requête émise par un client DOTS du domaine client peut être envoyée vers un serveur DOTS qui n’est pas habilité à la traiter. Une telle requête sera alors systématiquement rejetée par ledit serveur DOTS et aucune action de mitigation ne pourra être mise en œuvre, que ce soit de manière préventive ou de manière curative pour mitiger une attaque détectée. Il existe donc un besoin d’une nouvelle technique permettant d’améliorer la coordination des actions de mitigation engagées afin de contrer des attaques impactant ou susceptibles d’impacter un domaine client. L'invention répond à ce besoin en proposant un procédé d’identification d’au moins un serveur de mitigation d’attaques habilité à protéger un domaine client contre une attaque informatique. Un tel procédé est particulier en ce qu’il est mis en œuvre par un premier serveur de mitigation d’attaques et qu’il comprend : - la réception d’un message de sollicitation d’une assistance pour la gestion d’attaques en provenance d’un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n’est pas capable de traiter ledit message de sollicitation : - l’obtention, au moyen d’au moins un premier identifiant dudit domaine client obtenu par le premier serveur de mitigation, d’au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation. Une telle solution, désignée dans la suite de la description par LOST (pour « Liberal prOcessing of ddos mitigation requeSTs »), permet de s’assurer qu’aucun message de sollicitation d’une assistance pour la gestion d’attaques (ex. demande de mitigation d’attaque ou de mise en place de règles de filtrage) émis par un nœud client ne reste sans réponse même s’il est transmis à destination d’un serveur de mitigation incapable de le traiter. Aucune limitation n’est attachée à la nature du message de sollicitation. Il peut s’agir par exemple, dans le contexte d’une architecture DOTS telle que citée précédemment, de l’un quelconque des messages de signalisation évoqués avant, comme un message de sollicitation envoyé via le canal de signalisation (par ex. une requête de mitigation) ou un message de sollicitation envoyé via le canal de données (par ex. une requête de filtrage). On note par ailleurs que, bien que l’invention ait été introduite en référence à l’architecture DOTS, elle s’applique également à d’autres architectures conçues pour l’échange entre différentes entités de messages de signalisation en lien avec la gestion d’un trafic d’attaque (gestion préventive et/ou curative) telles que par exemple des architectures exploitant une signalisation reposant sur le protocole NETCONF ou encore d’autres architectures propriétaires conçues à cet effet. Aussi, la solution s’applique indépendamment de l’architecture interne du service de mitigation. Particulièrement, la solution s’applique si les actions de mitigation sont entreprises directement par le serveur de mitigation ayant reçu le message de sollicitation ou par une entité externe (« mitigator », typiquement) vers laquelle le message de sollicitation a été relayé par ledit serveur de mitigation. L’incapacité d’un serveur de mitigation à traiter un tel message de sollicitation peut avoir différentes origines. Ainsi, dans un mode particulier de réalisation, un serveur de mitigation est dans l’incapacité de traiter un message de sollicitation émis par le nœud client (ex. un message de sollicitation d’attaque), car il ne dispose pas des autorisations (ou habilitations) nécessaires pour le faire. C’est le cas, par exemple, lorsque le serveur de mitigation n’est pas autorisé à appliquer certaines politiques relatives à des ressources (par ex. des préfixes IP, URI, FQDN) du domaine client telles que des politiques de routage, de filtrage ou de redirection de trafic, etc. Autrement dit, dans ce mode de réalisation, l’incapacité du serveur de mitigation à traiter le message de sollicitation émis par le nœud client provient du fait qu’il n’est pas habilité à traiter ce message de sollicitation. Dans un autre mode de réalisation, un serveur de mitigation est dans l’incapacité de traiter un message de sollicitation émis par le nœud client (ex. une demande de mitigation d’attaque) car il ne dispose pas des ressources structurelles (par ex. les capacités de calcul, les ressources réseau) et/ou fonctionnelles pour le faire, ou d’une interface avec une entité disposant de telles ressources (ex. « mitigator » évoqué précédemment). Dans la suite de la description, un tel serveur de mitigation est désigné comme n’étant pas apte à traiter le message de sollicitation émis par le nœud client. Dans un autre mode de réalisation, on s’intéresse aux deux conditions évoquées ci-dessus (habilitation et aptitude) pour déterminer si un serveur de mitigation est capable ou non de traiter un message de sollicitation. Autrement dit, dans cet autre mode de réalisation, un serveur de mitigation capable de traiter un message de sollicitation d’une assistance pour la gestion d’attaques au sens de l’invention est d’une part, habilité à le faire, et d’autre part, dispose des ressources structurelles (ex. matérielles, logicielles, etc.) et fonctionnelles pour le faire ou d’une interface avec une entité externe (ex. « mitigator ») disposant de telles ressources. Conformément à l’invention, lorsqu’un premier serveur de mitigation détermine qu’il n’est pas capable de traiter un message de sollicitation d’attaque, c’est-à-dire selon le mode de réalisation envisagé, parce qu’il n’est pas habilité à le faire et/ou parce qu’il n’est pas apte à le faire (directement ou indirectement via une interface avec une entité externe chargée d’élaborer et/ou de mettre en œuvre un plan de mitigation), il cherche à identifier un deuxième serveur de mitigation habilité à traiter le message de sollicitation d’attaque qu’il a reçu. En effet, dans le cas présent, lorsque le premier serveur de mitigation détermine qu’il n’est pas capable de traiter un message de sollicitation, c’est-à-dire, par exemple, qu’il n’est pas habilité à traiter cette demande, plutôt que de rejeter cette demande, il va chercher à identifier au moins un autre serveur de mitigation qui serait en mesure de traiter ce message de sollicitation. Cet autre serveur de mitigation peut à son tour mettre en œuvre la présente méthode de manière récursive jusqu’à ce qu’un serveur de mitigation effectivement capable de traiter le message de sollicitation soit identifié. Pour cela, le serveur de mitigation utilise au moins un identifiant du domaine client cible de l’attaque (premier identifiant au sens de l’invention). Cet identifiant est spécialement créé pour permettre une telle identification d’un autre serveur de mitigation. Ce nouvel identifiant du domaine client est associé à au moins un service de mitigation protégeant des ressources du domaine client (par exemple, un service DPS pour des attaques de type DDoS) et permet de faire le lien entre le domaine client et au moins un serveur de mitigation d’attaques mettant en œuvre ledit au moins un service de mitigation et habilité à traiter un message de sollicitation émis par un nœud client du domaine client en question. Un tel identifiant du domaine client auquel est rattaché le nœud client ayant émis le message de sollicitation peut être commun à plusieurs services de mitigation (ex. à plusieurs services DPS), par exemple à plusieurs services de mitigation fournis par une même entité administrative. Dans un autre exemple, un identifiant du domaine client auquel est rattaché le nœud client ayant émis le message de sollicitation peut être spécifique à un service de mitigation (ex. à un service DPS) mis en œuvre, par exemple par le deuxième serveur de mitigation et ne sera, par conséquent, pas reconnu par un autre service de mitigation mis en œuvre, par exemple par un troisième serveur de mitigation. Dans un autre exemple encore, un identifiant du domaine client peut être spécifique à un serveur de mitigation contribuant à mettre en œuvre un service de mitigation. Le premier serveur de mitigation ayant mis en œuvre la présente solution se retrouve alors en possession de données permettant le traitement du message de sollicitation qu’il a reçu mais qu’il ne peut traiter, évitant ainsi que ce dernier reste sans réponse, un tel traitement étant effectué par un autre serveur de mitigation (deuxième serveur de mitigation au sens de l’invention). Dans un exemple, au moins un dit premier identifiant dudit domaine client est obtenu par interrogation d’une première base de données au moyen d’un nom de domaine associé audit domaine client. Dans un tel exemple, une première base de données maintient un registre dans lequel un nom de domaine associé au domaine client du nœud client ayant émis le message de sollicitation est associé à au moins un identifiant dudit domaine client. Une telle première base de données est par exemple maintenue par un serveur DNS (Domain Name System). Dans un autre exemple, au moins un dit premier identifiant dudit domaine client est extrait dudit message de sollicitation. Dans cet exemple, le premier identifiant en question dudit domaine client est véhiculé dans un champ du message de sollicitation. Ainsi, il suffit au premier serveur de mitigation d’extraire cette information du message de sollicitation. Dans une implémentation du présent procédé, au moins un dit premier identifiant dudit domaine client peut être obtenu par le premier serveur de mitigation au moyen d’un deuxième identifiant dudit domaine client extrait du message de sollicitation. Ce mode de réalisation a une application privilégiée lorsque le message de sollicitation comprend un deuxième identifiant du domaine client commun à plusieurs serveurs ou services de mitigation (c-à-d. qui identifie plusieurs serveurs/services de mitigation), dont le premier serveur de mitigation ayant reçu le message de sollicitation, et que le premier serveur de mitigation n’est pas en mesure de traiter ce message. Il est en effet important de pouvoir identifier un autre serveur de mitigation habilité à le traiter. Dans cette situation, le premier serveur de mitigation peut utiliser le deuxième identifiant extrait du message de sollicitation pour obtenir un nom de domaine associé audit domaine client. Puis, à partir de ce nom de domaine il peut, par exemple en interrogeant la première base de données, obtenir un ou plusieurs identifiants du domaine client associés au nom de domaine obtenu (premiers identifiants au sens de l’invention), et à partir de ces identifiants du domaine client, identifier un ou plusieurs serveurs de mitigation habilités à traiter le message de sollicitation. Le choix du ou des serveurs de mitigation vers lesquels orienter le message de sollicitation pour traitement peut dépendre de différents paramètres (politiques de mitigation, accords existants avec le domaine client et/ou entre les services de protection, etc.) Dans une variante de réalisation, lorsque le message de sollicitation comprend un identifiant du domaine client commun à plusieurs serveurs ou services de mitigation dont le premier serveur de mitigation ayant reçu le message de sollicitation, et que le premier serveur de mitigation n’est pas en mesure de traiter ce message, il utilise cet identifiant du domaine client pour identifier les autres serveurs de mitigation habilités à traiter le message de signalisation. Dans un exemple, le procédé comprend en outre une étape d’obtention d’au moins une information de localisation dudit deuxième serveur de mitigation par interrogation d’une deuxième base de données au moyen dudit premier identifiant dudit domaine client. Une telle information de localisation dudit deuxième serveur de mitigation peut comprendre au moins une adresse réseau dudit deuxième serveur de mitigation et/ou au moins un numéro de port dudit deuxième serveur de mitigation. Ainsi, il est possible de contacter ce deuxième serveur de mitigation afin de l’informer de la survenue d’une attaque ayant pour cible des ressources du domaine client. Dans un exemple, les informations d’identification et/ou de localisation dudit deuxième serveur sont transmises par le premier serveur au nœud client. Ainsi à réception de ces informations, le nœud client peut émettre un nouveau message de sollicitation directement à destination du deuxième serveur. Dans un autre exemple, le premier serveur de mitigation agit comme un relai pour le nœud client en transmettant le message de sollicitation à destination du deuxième serveur. Cette deuxième variante a pour avantage de réduire le délai de traitement du message de sollicitation. L’invention concerne également un procédé de protection d’un domaine client contre une attaque informatique, ledit procédé étant mis en œuvre par un nœud client hébergé par le domaine client et comprenant : - la transmission d’un message de sollicitation d’une assistance pour la gestion d’attaques à destination d’un premier serveur de mitigation d’attaques; et - la réception d’au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d’attaques étant associés à des services de mitigation distincts ; et - la transmission dudit message de sollicitation destination dudit deuxième serveur de mitigation. Les services de mitigation distincts peuvent être par exemple gérés par des entités administratives distinctes. Dans un exemple, message de sollicitation comprend au moins un identifiant dudit domaine client au moyen duquel ladite au moins une information d’identification dudit deuxième serveur de mitigation est obtenue par le premier serveur de mitigation. L’invention concerne encore un serveur de mitigation d’attaques, dit premier serveur de mitigation, habilité à protéger un domaine client contre une attaque informatique, et comprenant au moins un processeur configuré pour : - recevoir un message de sollicitation d’une assistance pour la gestion d’attaques en provenance d’un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n’est pas capable de traiter ledit message de sollicitation: - obtenir, au moyen d’un identifiant dudit domaine client obtenu par le premier serveur de mitigation, au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation. Un autre objet de l’invention concerne un nœud client hébergé par un domaine client comprenant au moins un processeur configuré pour : - transmettre un message de sollicitation d’une assistance pour la gestion d’attaques à destination d’un premier serveur de mitigation d’attaques ; - recevoir au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d’attaques étant associés à des services de mitigation distincts ; et - transmettre ledit message de sollicitation à destination dudit deuxième serveur de mitigation. L’invention concerne encore un signal destiné à être transmis par un nœud client hébergé par un domaine client à destination d’au moins un premier serveur de mitigation d’attaques, ledit signal comprenant un message de sollicitation d’une assistance pour la gestion d’attaques, ledit message de sollicitation comprenant au moins un identifiant dudit domaine client au moyen duquel au moins une information d’identification d’au moins un deuxième serveur de mitigation habilité à traiter ledit message de sollicitation peut être obtenue. L’invention concerne enfin des produits programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu’ils sont exécutés par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés selon l’invention tels que décrits ci-dessus. Un tel support 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 une clé USB ou un disque dur. D'autre part, un tel support 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 radio ou par d'autres moyens, de sorte que les programmes d’ordinateur qu’il contient sont exécutables à distance. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés objets de l’invention précités. Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : : cette figure représente différents équipements d’un réseau de communication mettant en œuvre un procédé d’identification d’au moins un serveur de mitigation selon un mode de réalisation de l’invention, : cette figure représente les principales étapes des procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique objet de la présente solution, : cette figure représente la structure simplifiée d’un nœud client selon l’un des modes de réalisation de la présente invention, : cette figure représente la structure simplifiée d’un serveur de mitigation selon l’un des modes de réalisation décrits ci-dessus. Description détaillée de modes de réalisation de l'invention Le principe général de l’invention repose sur la capacité d’un serveur de mitigation d’attaques à déterminer qu’il n’est pas capable de traiter un message de sollicitation d’une assistance dans la gestion d’attaques, comme une demande de mitigation d’une attaque émise par un nœud client d’un domaine client qui est la cible d’une attaque en cours ou une requête de filtrage à activer en cas d’attaque avérée, etc. Pour ce faire, le serveur de mitigation repose sur des informations locales (par ex. les habilitations préconfigurées par un administrateur) ou récupérées via des interfaces dédiées depuis des entités externes (par ex. vers un « mitigator » externe, une base de données). Ces interfaces sont par exemple similaires ou identiques à celles de la du document RFC 8811 édité par l’IETF et intitulé « DDos Open Threat Signaling (DOTS) Architecture », August 2020. Dans une implémentation de la présente solution, on envisage une architecture DOTS telle qu’introduite précédemment. Un tel message de sollicitation peut être, dans ce contexte, une requête DOTS. Une telle requête DOTS peut être par exemple : - un message de gestion d’alias, par exemple destiné à associer un identifiant avec une ou plusieurs ressources réseau située(s) dans le domaine du client , - un message de gestion de règles de filtrage tel que demander à un serveur DOTS d’installer une liste de contrôle d’accès ou ACL (pour « Access Control List » en anglais). - un message de signalisation pour solliciter la mitigation d’une attaque de déni de service auprès d’un serveur DOTS, le serveur de mitigation pouvant, sur réception d’un tel message, déclencher les actions nécessaires pour mettre fin à l’attaque (incluant la coordination avec une entité externe telle qu’un « mitigator »). - Un message de signalisation pour contrôler un filtre préinstallé tel que décrit dans la RFC9133. Si ledit serveur de mitigation est incapable de traiter le message de sollicitation reçu, il va alors chercher à identifier au moins un autre serveur de mitigation qui serait en mesure de traiter ce message de sollicitation plutôt que de rejeter la sollicitation en question. Ainsi, on s’assure que tout message de sollicitation émis par un nœud client d’un domaine client est traité. L’incapacité d’un serveur de mitigation à traiter un tel message de sollicitation peut avoir différentes origines. Dans l’implémentation particulière décrite en détail ici, on considère que le serveur de mitigation est dans l’incapacité de traiter un message de sollicitation émis par le nœud client (ex. un message de sollicitation d’attaque), car il ne dispose pas des autorisations (ou habilitations) nécessaires pour le faire. C’est le cas, par exemple, lorsque le serveur de mitigation n’est pas autorisé à appliquer certaines politiques relatives à des ressources du domaine client telles que des politiques de routage, de filtrage ou de redirection de trafic, etc. On dit alors que le serveur de mitigation n’est pas habilité à traiter le message de sollicitation émis par le nœud client. Dans une autre implémentation, un serveur de mitigation peut être dans l’incapacité de traiter un message de sollicitation émis par le nœud client (ex. une demande de mitigation d’attaque) car ledit serveur et/ou les entités à appliquer dans la mise en place d’actions de mitigation ne disposent pas des ressources structurelles (par ex. les capacités de calcul, les ressources réseau) et/ou fonctionnelles pour le faire. Un tel serveur de mitigation est alors désigné comme n’étant pas apte à traiter le message de sollicitation émis par le nœud client. Dans une autre implémentation encore, un serveur de mitigation peut être dans l’incapacité de traiter un message de sollicitation émis par le nœud client soit parce qu’il n’est pas habilité à le faire, soit parce qu’il n’est pas apte à le faire. A l’inverse, dans cette implémentation, un serveur de mitigation capable de traiter un message de sollicitation d’une assistance pour la gestion d’attaques au sens de l’invention est d’une part, habilité à le faire et d’autre part, dispose des ressources structurelles (ex. matérielles, logicielles, etc.) et fonctionnelles pour le faire. Conformément à l’invention, lorsqu’un premier serveur de mitigation détermine qu’il n’est pas capable de traiter un message de sollicitation, par exemple ici parce qu’il n’est pas habilité à le faire, il cherche à identifier un deuxième serveur de mitigation habilité à traiter le message de sollicitation qu’il a reçu. On présente, en relation avec la , différents équipements d’un réseau de communication mettant en œuvre un procédé d’identification d’au moins un serveur de mitigation selon un mode de réalisation de l’invention. On considère un premier domaine client 11 comprenant une ou plusieurs machines (dispositifs informatiques), encore appelées nœuds. On entend ici par « domaine » un ensemble de machines ou nœuds placés sous la responsabilité d’une même entité administrative. Le domaine client 11 comprend par exemple plusieurs nœuds clients C1, C2, C3 et Cm, m désignant un entier supérieur ou égal à 1, communiquant avec un premier serveur de mitigation S12. Le premier serveur de mitigation S12 appartient à un premier domaine serveur 12, tandis qu’ un deuxième serveur de mitigation S13 appartient à un deuxième domaine serveur 13 et un troisième serveur de mitigation S14 appartient à un troisième domaine serveur 14. Chacun de ces domaines serveurs 12, 13, 14 contribue à la mise en œuvre d’un service DPS permettant notamment de distinguer le trafic « légitime », i.e., les données consenties par l’utilisateur, du trafic « suspect ». Dans le mode de réalisation décrit ici, on considère que les domaines serveurs 12, 13 et 14 sont gérés par des entités administratives distinctes. Toutefois en variante, ils peuvent être gérés par une même entité administrative. Par ailleurs, par souci de simplification ici, on considère un seul serveur de mitigation associé à chaque service DPS et à chaque domaine serveur. Toutefois, il est possible en variante d’envisager plusieurs serveurs de mitigation par domaine serveur, ceux-ci pouvant être configurés pour protéger des ressources distinctes ou des ressources communes du domaine client 11. Un service DPS peut être hébergé au sein des infrastructures exploitées par les fournisseurs d’accès ou dans le « cloud » (en français « nuage »). Ainsi, un domaine client, tel que le domaine client 11 s’interface avec un ou plusieurs domaines serveurs 12, 13. Par abus de langage on dira qu’un domaine client tel que le domaine client 11 s’interface avec plusieurs services DPS. La détection d’une attaque, telle qu’une attaque DDoS, au sein d’un domaine client tel que le domaine client 11, peut être effectuée par un nœud client DOTS du domaine client concerné par l’attaque, tel que le nœud client C1, ou au moyen d’une fonction dédiée, appelée détecteur DDoS (DDoS Detector, en anglais), ou les deux. De manière générale, un ou plusieurs détecteurs DDoS peuvent être activés au sein d’un même domaine client DOTS. Dans la suite, aucune hypothèse n’est faite quant à l’architecture interne d’un domaine client ni aux mécanismes de détection DDoS mis en œuvre au sein du domaine. Enfin, la présente solution peut être mise en œuvre indépendamment de la nature des infrastructures réseau utilisées par les composantes (clients, serveurs) d’une architecture DOTS : ces réseaux peuvent être des réseaux IP, des réseaux mobiles (5G, B5G, 6G), etc. On décrit ci-après des exemples de mise en œuvre de l’invention dans une architecture de type DOTS, selon laquelle les nœuds clients C1, C2, C3 et Cm sont des clients DOTS et les serveurs de mitigation S12, S13, S14 sont des serveurs DOTS. Les nœuds clients C1, C2, C3, Cm et les serveurs S12, S13, S14 peuvent ainsi communiquer via des canaux de signalisation et/ou de données DOTS définis en relation avec l’art antérieur, pour informer les serveurs S12, S13, S14 au moyen de requêtes DOTS telles que décrites précédemment que des actions de protection sont requises, comme par exemple, la mitigation d’attaques ou la mise en place de règles de filtrage. Bien que décrite en relation avec une architecture DOTS, la présente solution peut être mise en œuvre dans le cadre d’autres types d’architectures, telles que par exemple des architectures propriétaires ou des architectures exploitant une signalisation reposant sur le protocole NETCONF. Elle s’applique par ailleurs à d’autres attaques que des attaques DDoS, comme par exemple à des attaques par intrusion. Un domaine DOTS peut accueillir un ou plusieurs clients DOTS. En d’autres termes, plusieurs nœuds client d’un domaine client peuvent disposer de fonctions DOTS. Les communications DOTS entre un domaine client et un serveur de mitigation peuvent être directes, ou établies via des passerelles DOTS (en anglais « DOTS gateways »). Ces passerelles peuvent être hébergées au sein du domaine client, du domaine du serveur de mitigation, ou des deux. En d’autres termes, un nœud client du domaine client peut communiquer directement avec le serveur de mitigation, ou transmettre une requête à une passerelle du domaine client qui communique directement avec le serveur de mitigation ou avec une passerelle du domaine du serveur de mitigation, ou transmettre une requête à une passerelle du domaine du serveur de mitigation qui communique avec le serveur de mitigation. Il convient de noter qu’une passerelle DOTS localisée dans un domaine client est considérée par un serveur DOTS comme un client DOTS. Une passerelle DOTS localisée dans un domaine serveur est considérée par un client DOTS comme un serveur DOTS. En cas de présence d’une passerelle DOTS dans le domaine du serveur de mitigation, l’authentification des clients DOTS peut être confiée à la passerelle DOTS du domaine du serveur de mitigation. Un serveur DOTS peut être configuré avec une liste des passerelles DOTS de confiance, actives au sein de son domaine et le serveur de mitigation peut déléguer certaines de ses fonctions à ces passerelles de confiance. En particulier, le serveur de mitigation peut utiliser en toute sécurité les informations fournies par une passerelle figurant dans une liste déclarée auprès du serveur de mitigation et maintenue par celui-ci, moyennant une procédure d’authentification ad hoc (par exemple, configuration explicite de la liste par l’administrateur habilité du serveur de mitigation, récupération de la liste auprès d’un serveur d’authentification tel qu’un serveur AAA (pour « Authentication, Authorization and Accounting »), etc.). Les modes de réalisation de la présente solution présentés ci-après peuvent être mis en œuvre quelle que soit la configuration de l’architecture DOTS (un ou plusieurs clients DOTS dans un domaine client, pas de passerelle DOTS, une ou plusieurs passerelles DOTS dans le domaine client ou dans le domaine du serveur de mitigation, domaine client distinct du domaine du serveur de mitigation, etc.). Dans la présente solution, on suppose que chaque domaine client DOTS, tel que le domaine client 11, dispose d’au moins un identifiant appelé par exemple ici « DOTS Administrative Domain Identifier » ou DADI, alloué de façon globalement unique au domaine client DOTS, et défini pour les besoins de l’invention. Cet identifiant DADI reflète le fait que le domaine client est protégé par au moins un service DPS et permet d’identifier ledit au moins un service DPS associé au domaine client. Un même domaine client 11 peut disposer d’un ou plusieurs identifiant(s) DADI DADI-11i. Un tel identifiant DADI fait donc le lien entre un domaine client, tel que le domaine client 11, et au moins un service DPS pouvant être mis en œuvre afin d’assister les nœuds clients du domaine client considéré en cas d’attaque. Un tel lien est utilisé par la suite pour identifier au moins un serveur de mitigation mettant en œuvre le service DPS en question, et capable de traiter le message de sollicitation. Comme mentionné précédemment, dans l’implémentation particulière décrite ici, un serveur de mitigation capable de traiter un message de sollicitation est un serveur habilité à le faire (autrement dit qui dispose des autorisations nécessaires pour traiter ce message de sollicitation). Dans une variante d’implémentation, un serveur de mitigation capable de traiter un message de sollicitation est non seulement habilité à le faire mais également dispose des ressources nécessaires pour traiter ce message ou pour s’interfacer avec une entité externe (ex. « mitigator ») apte à le traiter. Un même identifiant DADI peut être utilisé pour identifier plusieurs services DPS associés à un même domaine client. Un domaine client peut avoir des ressources (par ex. des préfixes IP sous la surveillance des nœuds clients) gérées (protégées) par un premier serveur de mitigation mettant en œuvre un premier service DPS et d’autres ressources gérées par un deuxième serveur de mitigation mettant en œuvre un deuxième service DPS. Un même identifiant DADI peut alors être utilisé pour les communications avec des serveurs de mitigation distincts. Le premier et le deuxième service DPS sont par exemple gérés par des entités administratives distinctes. Toutefois, en variante, ils peuvent être gérés par la même entité administrative. Il convient de noter qu’un identifiant DADI permet, contrairement à d’autres identifiants connus tels que les identifiants CUID et CDID, d’identifier un domaine client et non pas un nœud client. L’utilisation d’un identifiant de domaine client permet de s’assurer que quel que soit le nœud client (du domaine client) à l’origine de l’émission du message de sollicitation, celui-ci est émis à destination d’un serveur de mitigation qui, à défaut d’être capable de le traiter, mettra en œuvre la présente solution permettant d’identifier un serveur de mitigation habilité à traiter le message de sollicitation. Cela n’est pas le cas si l’on utilise un identifiant d’un nœud client. En effet, des nœuds clients appartenant à un même domaine client peuvent être gérés par des serveurs de mitigation différents. Si l’on se limite à l’utilisation d’un identifiant d’un nœud client, un autre serveur de mitigation ne pourra pas traiter le message de sollicitation car il n’est pas habilité à le faire et ainsi le message de sollicitation restera sans réponse. De plus, un tel identifiant CDID ne peut pas être utilisé pour identifier un autre serveur de mitigation habilité car cet identifiant CDID est généré sur la base d’un condensé (ou hash) d’un certificat du nœud client utilisé pour authentifier ce dernier auprès d’un serveur de mitigation donné. Ce condensé étant propre à cette association, il ne peut donc être réutilisé à d’autres fins. Un identifiant DADI peut être alloué à un domaine client par un fournisseur de services DPS. Dans un tel cas de figure, on s’assure que les espaces d’identification utilisés par différents fournisseurs de services DPS ne se recouvrent pas, par exemple en coordonnant l’attribution des identifiants DADI entre les fournisseurs de services DPS ou en utilisant un espace d’identification hiérarchique (par ex. l’identifiant DADI contient une partie qui est unique à chaque fournisseur de services DPS). De cette sorte, on s’assure que chaque identifiant DADI est globalement unique (c’est-à-dire sur l’ensemble des domaines clients considérés) En effet, pour les besoins de la présente solution, il est important qu’un identifiant DADI identifie de manière non-ambiguë un domaine client donné et permette ainsi d’établir un lien avec le ou les services DPS chargés de protéger ce domaine client. Dans un autre exemple, pour s’assurer de cette unicité globale, les identifiants DADI peuvent être alloués aux domaines clients par une entité indépendante, telle que l’IANA (ou « Internet Assigned Numbers Authority » en anglais). L’implication d’une telle autorité indépendante permet de s’assurer qu’il n’y a pas de recouvrement entre les différents identifiants DADI alloués aux domaines clients. Dans un exemple, un même identifiant DADI DADI-111 associé (c’est-à-dire alloué) au domaine client 11, peut être utilisé par plusieurs services DPS. Dans un autre exemple, un identifiant DADI DADI-112 associé au domaine client 11 est spécifique à un deuxième service DPS2 mis en œuvre, par exemple par le serveur de mitigation S13 et n’est, par conséquent, pas reconnu par un premier service DPS1 mis en œuvre, par exemple par le serveur de mitigation S12 ou encore par un troisième service DPS3 mis en œuvre, par exemple par le serveur de mitigation S14. Par un exemple, le domaine client 11 dispose d’un identifiant DADI DADI-113 spécifique au troisième service DPS3. Dans le mode de réalisation décrit ici, l’ensemble des identifiants DADI alloués à différents domaines clients DOTS sont maintenus dans un premier registre d’identifiants DADI accessible à une pluralité de services DPS (et aux serveurs de mitigation contribuant à la mise en œuvre de ces services DPS). Ce premier registre établit une correspondance entre des noms de domaines clients et les identifiants DADI alloués aux domaines clients associés à ces noms de domaines clients. Ainsi, une entrée d’un tel registre peut se présenter de la manière suivante : Noms de domaine client Identifiant DADI dots-client-domain11.example.com DADI-11 1 dots-client-domain11.example.com DADI-11 2 dots-client-domain11.example.com DADI-11 3 dots-client-domainij.example.com DADI-ij 1 dots-client-domainkl.example.com DADI-kl 1 où les entiers « ij » et « jk » font référence respectivement à des domaines clients « ij » et « jk ». Un tel premier registre d’identifiants DADI peut être par exemple stocké dans un registre DNS. De tels registres DNS étant, en général, déjà déployés dans un réseau, il est avantageux de les utiliser pour mémoriser les informations relatives à ces identifiants DADI. En effet, ces registres DNS étant connus des différents nœuds des domaines clients, leur interrogation par les nœuds clients est aisée. Bien entendu, d’autres types de registres peuvent être considérés pour stocker le premier registre d’identifiants DADI (par ex. base de données SQL (Structured Query Language) ou LDAP (Lightweight Directory Access Protocol)). En outre, le premier registre d’identifiants DADI peut être privé, c’est-à-dire que l’accès aux données qu’il maintient est restreint, ou public, c’est-à-dire que l’accès aux données qu’il maintient est libre. L’utilisation d’un registre d’identifiants DADI privé ou public relève d’un choix d’ingénierie. Il convient toutefois de noter que l’utilisation d’un registre d’identifiants DADI public peut donner accès à des informations sensibles, par exemple, l’absence d’une entrée dans le registre d’identifiants DADI pour un domaine client donné peut indiquer que ce domaine n’est pas protégé contre des attaques. Cette information peut être exploitée par les attaquants contre les domaines clients concernés. Lorsque le premier registre d’identifiants DADI est un registre DNS, des entrées de type DNS SVCB, telles que définies dans le document I-D.ietf-dnsop-svcb-https, peuvent être utilisées pour associer un nom de domaine client DOTS, tel que le domaine client 11, avec son/ses identifiants DADI, DADI-111, DADI-112, DADI-113. Le choix d’utiliser ce type d’entrée repose sur le fait que, les entrées DNS SVCB comprenant plusieurs paramètres de services, il est ainsi possible d’utiliser l’un de ces paramètres de services pour y mémoriser le ou les identifiants DADI d’un domaine client. Il n’est alors pas nécessaire de créer de nouveaux types d’entrées. De façon connue, les paramètres de service d’une entrée DNS SVCB sont appelés SvcParams (pour « Service Parameters » en anglais), et chacun de ces paramètres de service est caractérisé par une clé (SvcParamKey) et une valeur (Value). Dans le mode de réalisation décrit ici, il est donc proposé de définir un nouveau paramètre de service correspondant à une clé « SvcParamKey » que l’on appelle ici « dadi » à titre illustratif, et valorisé avec la liste des identifiants DADI associés au domaine client 11 à savoir DADA-111, DADI-112 et DADI-113. Un exemple d’une demande de création d’une entrée de type DNS SVCB dans le premier registre d’identifiants DADI associant le domaine client 11 « dots-client.example.com » à l’identifiant DADI-111 dont la valeur est « 4572sd174sf1 », se présente comme suit : _dots-client.example.com. 7200 IN SVCB 1 alpn=dots dadi=4572sd174sf1 simple.example. A réception d’une requête DNS de type SVCB émise par un serveur de mitigation afin d’obtenir le ou les identifiant(s) DADI associés au domaine client 11, le premier registre d’identifiants DADI retourne le ou les identifiants DADI associés au domaine client 11. Parallèlement, les différents fournisseurs de services DPS exploitant les serveurs de mitigation S12, S13, S14, selon la présente solution maintiennent un deuxième registre d’identifiants DADI, dit DPS_Active_DADI, dont chaque entrée associe un ou plusieurs identifiant(s) DADI associé(s) à un domaine client DOTS, tel que le domaine client 11, avec des données relatives à un ou plusieurs serveurs de mitigation mettant en œuvre un service DPS. Ce deuxième registre DPS_Active_DADI peut se présenter de la manière suivante : Identifiant DADI DPS_Contact_Point DADI-11 1 DPS_Contact_PointS12 (nom-domain12, @IP12, port 1) DADI-11 2 DPS_Contact_PointS13 (nom-domaine13, @IP13, port 2) DADI-11 3 DPS_Contact_PointS14(nom-domaine14, @IP14, port 3) Ce deuxième registre DPS_Active_DADI peut également être stocké dans un registre de type DNS. Bien entendu, d’autres types de registres peuvent être considérés comme, par exemple, un annuaire LDAP ou une base de données SQL tels que cités précédemment. Chaque fournisseur de services DPS procède, pour les services DPS qu’il fournit, à l’ajout ou la suppression d’entrées dans ce deuxième registre DPS_Active_DADI selon des accords passés avec les différents domaines clients DOTS pour lesquels ils sont habilités à mitiger des attaques et à protéger des ressources. Des API (pour « Application Programming Interface » en anglais) dédiées peuvent être utilisées à cet effet. Un exemple de création d’une entrée dans le registre DPS_Active_DADI est décrit ci-après. On appelle REGISTER(dadi) une primitive utilisée pour ajouter une entrée au registre DPS_Active_DADI. Une telle primitive indique qu’un ou plusieurs identifiant(s) DADI est associé avec un ou plusieurs serveur(s) de mitigation identifié(s) par un jeu de paramètres DPS_Contact_Point qui peut comprendre notamment ici, une information d’identification telle qu’un nom de domaine, des informations de localisation telles qu’une ou plusieurs adresses IP, un ou plusieurs numéros de port, ainsi que d’autres informations telles que par exemple une durée de validité de l’enregistrement, etc. De même, on appelle DELETE (dadi) une primitive utilisée pour supprimer une entrée dans ledit registre DPS_Active_DADI. Cette primitive est utilisée par exemple pour supprimer un enregistrement quand un domaine client n’utilise plus les services de mitigation d’un fournisseur de services DPS donné. Dans un exemple d’implémentation, les primitives REGISTER et DELETE sont authentifiées afin de s’assurer qu’un fournisseur de services DPS est habilité à procéder à une opération relative à un identifiant DADI dans le registre DPS_Active_DADI. La illustre les principales étapes des procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique objet de la présente solution. Ainsi, dans une étape E1, un nœud client C1 du domaine client 11 détecte une attaque ciblant tout ou partie des ressources du domaine client 11, de façon connue en soi et non décrite ici. Une telle attaque peut ne pas avoir encore touché le domaine client 11. Afin de mitiger cette attaque, le nœud client C1 émet, dans une étape E2, un message de sollicitation d’une assistance dans la gestion d’attaques à destination d’un premier serveur de mitigation DOTS, par exemple ici le serveur de mitigation S12, afin de signaler l’attaque dont il est la cible et demander l’exécution d’un service de mitigation « Request Mitigation » afin de traiter cette attaque. Un message de sollicitation est par exemple une requête DOTS. Le nœud client C1 insère un nouveau paramètre DOTS appelé ici « dadi » dans le message de sollicitation « Request Mitigation », et plus particulièrement dans un entête de ce message de sollicitation. Ce nouveau paramètre « dadi », inséré pour les besoins de la présente solution, comprend le ou les identifiant(s) DADI DADI-111, DADI-112 et DADI-113, associés au domaine client 11 auquel appartient le nœud client C1. Un exemple des entêtes d’un tel message de sollicitation modifié conformément à la présente solution est fourni ci-après, pour l’exemple illustratif de l’identifiant DADI-111 envisagé précédemment et ayant la valeur « 4572sd174sf1 » : Header: PUT (Code=0.03) Uri-Host: "www.example.com" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=mydotsclient" Uri-Path: "mid=57956" Uri-Path: "dadi=4572sd174sf1" Content-Format: "application/cbor" Lorsque le message de sollicitation comprend plusieurs identifiants DADI, ces derniers peuvent être séparés au moyen d’un séparateur comme par exemple « ; » entre les identifiants (par ex. dadi=DADI-111 ; DADI-112 ; DADI-113), ou l’argument est répété (par ex. Uri-Path: "dadi=DADI-111", Uri-Path:"dadi=DADI-112", Uri-Path:"dadi=DADI-113"). Cette dernière possibilité est moins intéressante car elle augmente la taille du message de sollicitation (et donc le risque de fragmentation du message). Les différents entêtes du message de sollicitation représentés ci-dessus sont définis dans le document RFC9132 publié par l’IETF (« Internet Engineering Task Force » en anglais). Ainsi, l’un des entêtes « Uri-Path », comprend, dans le cadre de la mise en œuvre de la présente solution, la valeur « 4572sd174sf1 » de l’identifiant DADI DADI-111 associé au domaine client 11. En variante, le ou les identifiant(s) DADI sont insérés dans le corps du message de sollicitation « Request Mitigation » (par ex., les messages PUT ou POST). Selon une autre variante de réalisation, qui peut être utilisée de façon alternative à ce qui vient d’être décrit ou de façon complémentaire, afin de s’assurer que les différents serveurs de mitigation recevant le message de sollicitation « Request Mitigation » puisse avoir accès à une valeur du paramètre DOTS « dadi » (par exemple, la requête « Request Mitigation » a été acheminée vers un serveur DOTS qui n’est pas en mesure de la déchiffrer), le nœud client C1 peut insérer une option UDP ou TCP, selon le protocole de transport utilisé message de sollicitation pour envoyer le message de sollicitation « Request Mitigation ». Un exemple de format d’une telle option conforme au format documenté dans la publication RFC793 de l’IETF, est le suivant : A réception du message de sollicitation « Request Mitigation », le serveur de mitigation S12 détermine, au cours d’une étape E3, s’il est capable de traiter ce message, c’est-à-dire dans l’implémentation particulière envisagée ici, s’il est habilité à le faire. Cette détermination peut être réalisée par des moyens connus de l’homme du métier et non décrits en détail ici. Si le serveur S12 est capable (i.e. habilité ici) de traiter le message de sollicitation, alors il informe le nœud client C1 qu’il peut répondre favorablement au message de sollicitation reçu, dans une étape E4. L’attaque impactant les ressources du domaine client 11 est alors mitigée de manière classique (soit directement par le serveur S12 soit en s’interfaçant avec une entité externe telle qu’un « mitigator »). Si au cours de l’étape E3, le serveur de mitigation S12 détermine qu’il n’est pas en mesure de traiter le message de sollicitation « Request Mitigation » car, dans l’implémentation particulière envisagée ici, il n’est pas habilité à gérer la ressource ciblée par l’attaque (identifiée par exemple par les champs « target-prefix », « target-uri », « target-fqdn », etc., du corps du message), alors, le serveur de mitigation S12 cherche à identifier un autre serveur de mitigation habilité à traiter le message de sollicitation. A cet effet, le serveur de mitigation S12 cherche à obtenir au moins un identifiant DADI associé au domaine client 11 auquel appartient le nœud client C1 émetteur du message de sollicitation au cours d’une étape E5. A ce stade, deux situations se présentent : une première situation dans laquelle le message de sollicitation « Request Mitigation » ne comprend aucun identifiant DADI associé au domaine client 11, et une deuxième situation (cas envisagé en exemple ici) dans laquelle le message de sollicitation « Request Mitigation » comprend au moins un identifiant DADI associé au domaine client 11 (dans son corps de message, dans l’un de ses champs d’entête, ou dans une option transport telle qu’une option UDP comme décrit précédemment). Dans la première situation, le serveur S12 détermine alors un nom de domaine associé au domaine client 11. A cet effet, il extrait par exemple, un nom de domaine associé au domaine client 11 compris, par exemple, dans le certificat utilisé pour créer l’association (D)TLS requise au préalable pour l’envoi du message de sollicitation « Request Mitigation ». Puis il interroge au moyen du nom de domaine ainsi obtenu, le premier registre d’identifiants DADI en lui envoyant lors d’une étape E6, une requête SVCB. Le premier registre d’identifiants DADI utilise alors ce nom de domaine pour obtenir au moins un identifiant DADI DADI-111, DADI-112 et/ou DADI-113, associé au domaine client 11. Une fois ces identifiants DADI DADI-111, DADI-112 et/ou DADI-113 obtenus, ils sont transmis au serveur de mitigation S12 par le premier registre d’identifiants DADI. Une fois en possession du ou des identifiant(s) DADI DADI-111, DADI-112, DADI-113 associé(s) au domaine client 11, le serveur S12, émet, dans une étape E7, une nouvelle requête, désignée par exemple ici par « QUERY_DPS_REGISTRY », et spécialement conçue pour les besoins de la présente solution, à destination du registre DPS_Active_DADI afin d’identifier au moins un serveur de mitigation, habilité à traiter le message de sollicitation « Request Mitigation » associé au(x) identifiant(s) obtenu(s). Comme indiqué en référence à la table 2, un tel registre DPS_Active_DADI est alimenté par les fournisseurs de services DPS dont les services DPS mettent en œuvre la présente solution. Dans la deuxième situation, le serveur S12 extrait, au cours d’une étape E8, le ou les identifiant(s) DADI présent(s) dans le message de sollicitation « Request Mitigation » et vérifie que cet (ces) identifiant(s) DADI est (sont) bien associé(s) au service DPS qu’il contribue à mettre en œuvre. Une telle information est par exemple configurée localement au niveau de chaque serveur de mitigation. Si le service DPS mis en œuvre par le serveur de mitigation S12 ne correspond pas à un service DPS associé à l’(aux) identifiant(s) DADI extrait(s) du message de sollicitation, cela signifie que le message de sollicitation « Request Mitigation » a été acheminé par erreur au serveur S12 car le service DPS qu’il met en œuvre n’est pas un service DPS retenu par l’entité gestionnaire du domaine client 11 pour mitiger les attaques contre les ressources de ce domaine client indiquées dans le message de signalisation. Dans ce cas, le serveur de mitigation S12 émet, dans une étape E9, une requête « QUERY_DPS_REGISTRY » à destination du registre DPS_Active_DADI afin d’identifier au moins un serveur de mitigation (S13 ou S14 dans l’exemple de la envisagé ici) habilité à traiter le message de sollicitation « Request Mitigation » et associé à l’identifiant extrait du message de sollicitation. Dans un autre exemple d’implémentation de l’invention, le serveur de mitigation S12 émet une requête « QUERY_DPS_REGISTRY » à destination du registre DPS_Active_DADI afin d’identifier au moins un serveur de mitigation (S13 ou S14 dans l’exemple de la envisagé ici) habilité et apte à traiter le message de sollicitation « Request Mitigation », et associé à l’identifiant extrait du message de sollicitation. Dans cet exemple, il est supposé une publication en temps réel des informations relatives aux différents serveurs de mitigation ou une interrogation des informations du serveur de mitigation afin de déterminer l’aptitude de ce dernier à traiter le message de sollicitation. Par exemple, le serveur de mitigation S12 met en œuvre le service de mitigation (DPS1 dans l’exemple envisagé ici) qui est associé à l’identifiant DADI DADI-111 alloué au domaine client 11. On suppose dans cet exemple que l’identifiant DADI extrait du message de sollicitation est l’identifiant DADI-113. En consultant le registre DPS_Active_DADI, le serveur de mitigation S12 constate que l’identifiant DADI DADI-113 ne correspond pas à l’identifiant DADI DADI-111 associé au service DPS1 de mitigation qu’il met en œuvre. Le serveur de mitigation S12 interroge alors le registre DPS_Active_DADI afin d’identifier, au moyen de l’identifiant DADI-113 extrait du message de sollicitation, un serveur de mitigation associé à l’identifiant DADI-113. Il obtient lors de cette étape les données relatives au serveur de mitigation en question (S14 dans l’exemple illustratif envisagé ici). Dans le cas de figure où l’identifiant DADI extrait par le serveur S12 au cours de l’étape E8 est bien associé au service DPS du serveur de mitigation S12 et que le serveur de mitigation S12 n’est pas habilité à traiter le message de sollicitation, cela veut dire, dans le mode de réalisation décrit ici, qu’un même identifiant DADI est utilisé par plusieurs services DPS (cas non représenté dans la table 2). En effet, dans cette situation, l’identifiant DADI extrait par le serveur S12 au cours de l’étape E8 identifie des services DPS chargés de protéger le domaine client 11 ; cependant le serveur S12 bien qu’habilité à protéger certaines ressources du domaine client 11 (par ex. 1.2.3.4/32), n’est pas habilité à protéger d’autres ressources (par ex. 11.12.13.14/32) à l’origine du message de sollicitation. Dans ce cas, dans le mode de réalisation décrit ici, le serveur de mitigation S12 utilise le nom de domaine du domaine client 11 se trouvant par exemple dans le certificat utilisé pour créer l’association (D)TLS requise au préalable pour l’envoi du message de sollicitation « Request Mitigation » comme décrit précédemment, afin d’émettre, dans une étape E10, une requête SVCB à destination du premier registre d’identifiants DADI pour obtenir le ou les identifiants DADI associé(s) au domaine client 11. A réception du ou des identifiant(s) DADI associé(s) au domaine client 11, le serveur S12, émet ensuite, dans une étape E11, une requête « QUERY_DPS_REGISTRY » à destination du registre DPS_Active_DADI afin d’identifier au moins un serveur de mitigation habilité à traiter le message de sollicitation « Request Mitigation ». Par exemple, le serveur de mitigation S12 contribue à mettre en œuvre un service de mitigation qui est associé à l’identifiant DADI DADI-111 associé au domaine client 11. L’identifiant DADI extrait du message de sollicitation est l’identifiant DADI-111. Le serveur de mitigation S12 constate que l’identifiant DADI extrait du message de sollicitation, DADI-111, correspond au service DPS qu’il met en œuvre bien qu’il n’est pas capable de traiter ce message de sollicitation. Le serveur de mitigation S12 interroge alors le premier registre d’identifiants DADI afin d’identifier le domaine client 11 associé à l’identifiant DADI-111 extrait du message de sollicitation reçu. Le serveur de mitigation obtient du premier registre d’identifiants DADI que l’identifiant DADI-111 est associé au domaine client 11. Le serveur de mitigation S12 obtient également l’information selon laquelle le domaine client 11 est associé en outre aux identifiants DADI-113 et DADI-112. Le serveur de mitigation S12 interroge ensuite le registre DPS_Active_DADI afin d’identifier, au moyen de l’identifiant DADI-111 extrait du message de sollicitation et le cas échéant, des identifiants DADI-113 et DADI-112 obtenus en interrogeant le registre d’identifiants DADI, un autre serveur de mitigation contribuant à mettre en œuvre ici un service DPS différent du service DPS mis en œuvre par le serveur de mitigation S12 mais qui est également associé à l’identifiant DADI-111 extrait du message de sollicitation, ou à un autre identifiant DADI-113 ou DADI-112 associé à un service de mitigation protégeant les ressources du domaine client 11. Dans une variante de réalisation, le serveur de mitigation S12 interroge le registre DPS_Active_DADI afin d’identifier, au moyen de l’identifiant DADI-111 extrait du message de sollicitation uniquement un autre serveur de mitigation contribuant à mettre en œuvre un service DPS différent du service DPS mis en œuvre par le serveur de mitigation S12 mais qui est également associé à l’identifiant DADI-111 extrait du message de sollicitation. La mise en œuvre de l’une ou l’autre des variantes peut dépendre d’accords éventuels passés entre le domaine client et les services de protection DPS, ou entre les services de protection DPS entre eux, etc. Plus particulièrement, le serveur de mitigation S12 peut obtenir les informations de localisation des serveurs de mitigation habilités et susceptibles de répondre à la demande de mitigation initiale. La transmission de tout ou partie des informations qui identifient le ou les fournisseurs de services DPS qui exploitent lesdits serveurs de mitigation au serveur de mitigation S12 est conditionnée par l’existence éventuelle d’accords passés entre les différents fournisseurs de services DPS. Ainsi, le serveur de mitigation S12 peut n’avoir accès qu’aux informations de contact des fournisseurs de services DPS partenaires, selon les identifiants DADI associés à leurs clients, et qui figurent dans le registre DPS_Active_DADI. En réponse à une requête « QUERY_DPS_REGISTRY », qu’elle ait été émise au cours de l’étape E7, E9 ou E11, le serveur de mitigation S12 reçoit, au cours d’une étape E12, un message en provenance du registre DPS_Active_DADI. Un tel message retourne un jeu de paramètres (c’est-à-dire des informations) DPS_Contact_Point associés à un ou plusieurs serveurs de mitigation a priori habilités à traiter le message de sollicitation. Comme précisé plus haut, un tel jeu de paramètres DPS_Contact_Point peut comprendre une information d’identification d’un serveur de mitigation tel qu’un nom de domaine, des informations de localisation de ce serveur de mitigation (par ex. une adresse IP, un numéro de port), et d’autres informations telles qu’une durée de validité de l’enregistrement, etc. relatives au service DPS qui lui est associé. Ainsi, le serveur de mitigation S12 contacte le registre DPS_Active_DADI pour récupérer le ou les points de contact (serveurs de mitigation) des services DPS habilités à traiter la requête de mitigation selon les valeurs des identifiants DADI. La réponse du registre peut consister en la transmission de tout ou partie des points de contact DPS, selon que des accords ont été passés entre les différents fournisseurs de services DPS ou pas Ainsi, à titre d’exemple, le serveur de mitigation S12 peut n’obtenir que les informations DPS_Contact_Point associées à des serveurs de mitigation mettant en œuvre le même service DPS, quelle que soit la localisation de ces serveurs de mitigation . Dans un autre exemple, le serveur de mitigation S12 peut n’obtenir que les informations DPS_Contact_Point associées à des serveurs de mitigation localisés dans le même domaine serveur que lui mais disposant de ressources différentes des siennes, etc. Suite à la réception de ce message comprenant les informations DPS_Contact_Point, le serveur de mitigation S12 peut entreprendre au moins deux actions. Un tel choix d’une action à entreprendre s’effectue par exemple sur la base de politiques de traitement du trafic d’attaque qui lui sont fournies par le fournisseur de services de mitigation qui l’exploite. Ainsi, une première action consiste à demander une redirection du message de sollicitation « Request Mitigation » vers un autre serveur de mitigation, identifié par un jeu de paramètres DPS_Contact_Point présent dans le message reçu au cours de l’étape E12. Pour cela, le serveur de mitigation S12 émet, dans une étape E13, un message de redirection à destination du nœud client C1, ce message de redirection comprend des informations permettant au nœud client C1 d’identifier (et le cas échéant de localiser) le serveur de mitigation à destination duquel il doit réémettre le message de sollicitation. Un exemple du corps d’un tel message de redirection est fourni ci-dessous : { "ietf-dots-signal-channel:redirected-signal": [ { "alt-server": "dps-contact-point1.name ", "alt-server-record": [ "2001:db8:6401::1", "2001:db8:6401::2" }, { "alt-server": "dps-contact-point2.name", "alt-server-record": [ "2001:db8:3000::1", "2001:db8:3000::2" } } Un tel message comprend une liste de serveurs de mitigation alternatifs à destination desquels le message de sollicitation peut être réémis, correspondant aux jeux de paramètres DPS_Contact_Point reçus par le serveur de mitigation S12. Ces serveurs de mitigations sont identifiés dans les attributs « alt-server » dudit message de redirection. Selon les politiques adoptées, ce message de redirection peut être transmis en parallèle à tous les serveurs de mitigation identifiés dans la liste ou selon un ordre prédéfini. A réception de ce message de redirection, le nœud client C1 réémet, dans une étape E14, le message de sollicitation « Request Mitigation » vers le ou les serveurs de mitigation identifiés dans le message de redirection, par exemple vers le serveur de mitigation S14. Si plusieurs serveurs de mitigation sont identifiés dans le message de redirection, le message de sollicitation peut être envoyé vers ces serveurs en parallèle ou en séquentiel. A réception du message de sollicitation émis par le nœud client C1 au cours de l’étape E14, le serveur de mitigation S14 met en œuvre, à son tour, les étapes E3 à E15 précédemment décrites. Il en sera ainsi jusqu’à ce qu’un serveur de mitigation capable de traiter le message de sollicitation soit identifié. Une deuxième action consiste, pour le serveur de mitigation S12, à relayer, dans une étape E15, le message de sollicitation « Request Mitigation » vers le ou les serveurs de mitigation identifiés au cours de l’étape E12. A réception du message de sollicitation relayé par le serveur de mitigation S12 au cours de l’étape E15, le serveur de mitigation identifié met en œuvre, à son tour, les étapes E3 à E15 précédemment décrites. Il en sera ainsi jusqu’à ce qu’un serveur de mitigation capable de traiter le message de sollicitation ainsi relayé de serveur de mitigation en serveur de mitigation soit identifié. Lorsqu’un serveur de mitigation en mesure de traiter le message de sollicitation est identifié, l’attaque impactant les ressources du domaine client 11 peut alors être mitigée de manière classique (directement par le serveur en question ou en s’interfaçant avec une entité externe telle qu’un « mitigator »). On note que dans l’exemple envisagé ici, le serveur de mitigation S12 a cherché à identifier, pour traiter le message de sollicitation, un serveur de mitigation mettant en œuvre un autre service DPS que lui. Toutefois, dans une variante de réalisation, on peut envisager qu’il identifie un autre serveur de mitigation habilité à traiter le message de sollicitation et mettant en œuvre le même service que lui. Dans cette variante, il est toutefois recommandé de mettre en place des mécanismes permettant d’éviter, lors d’une mise en œuvre récursive du procédé d’identification selon l’invention, qu’une boucle soit créée en sollicitant plusieurs fois un même serveur de mitigation incapable de traiter le message de sollicitation. Une telle boucle peut être évitée par exemple, en s’assurant que le serveur de mitigation ayant relayé le message de sollicitation est exclu de la liste des serveurs de mitigation vers lesquels le message de sollicitation peut être amené à être relayé. On présente, en relation avec la , la structure simplifiée d’un nœud client C1, C2, C3, Cm selon l’un des modes de réalisation décrits ci-dessus. Selon un mode de réalisation particulier, un nœud client C1, C2, C3, Cm comprend une mémoire 101C comprenant une mémoire tampon, une unité de traitement 102C, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 103C, mettant en œuvre des étapes des procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique selon un mode de réalisation de l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 103C sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 102C. Le processeur de l’unité de traitement 102C met en œuvre des étapes du procédé d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique décrit précédemment, selon les instructions du programme d’ordinateur 103C, pour : - transmettre un message de sollicitation d’une assistance pour la gestion d’attaques à destination d’un premier serveur de mitigation d’attaques ; - recevoir au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d’attaques étant par exemple associés à des services de mitigation distincts ; et - transmettre ledit message de sollicitation à destination dudit deuxième serveur de mitigation. On présente, en relation avec la , la structure simplifiée d’un serveur de mitigation S12, S13,S14 selon l’un des modes de réalisation décrits ci-dessus. Par exemple, un serveur de mitigation S12, S13,S14 comprend une mémoire 111S,C comprenant une mémoire tampon, une unité de traitement 112S,C, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 113S,C, mettant en œuvre des étapes des procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique selon un mode de réalisation de l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 113S ,C sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 112S. Le processeur de l’unité de traitement 112S,C met en œuvre des étapes des procédés décrit précédemment, selon les instructions du programme d’ordinateur 113S,C, pour : - recevoir un message de sollicitation d’une assistance pour la gestion d’attaques en provenance d’un nœud client du domaine client ; et lorsque ledit serveur de mitigation, dit premier serveur de mitigation, n’est pas capable de traiter ledit message de sollicitation: - obtenir, au moyen d’un identifiant dudit domaine client obtenu par le premier serveur de mitigation, au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation. Procédé d’identification d’au moins un serveur de mitigation d’attaques habilité à protéger un domaine client contre une attaque informatique, ledit procédé étant mis en œuvre par un premier serveur de mitigation d’attaques et comprenant : - la réception d’un message de sollicitation d’une assistance pour la gestion d’attaques en provenance d’un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n’est pas capable de traiter ledit message de sollicitation: - l’obtention, au moyen d’un au moins premier identifiant dudit domaine client obtenu par le premier serveur de mitigation, d’au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation. Procédé d’identification d’au moins un serveur de mitigation selon la revendication 1 dans lequel au moins un dit premier identifiant dudit domaine client est obtenu par interrogation d’une première base de données au moyen d’un nom de domaine associé audit domaine client. Procédé d’identification d’au moins un serveur de mitigation selon la revendication 1 dans lequel au moins un dit premier identifiant dudit domaine client obtenu est extrait dudit message de sollicitation. Procédé d’identification d’au moins un serveur de mitigation selon l’une quelconque des revendications 1 à 3 dans lequel au moins un dit premier identifiant dudit domaine client est obtenu au moyen d’un deuxième identifiant dudit domaine client extrait du message de sollicitation. Procédé d’identification d’au moins un serveur de mitigation selon la revendication 4 dans lequel ledit au moins un premier identifiant dudit domaine client est obtenu au moyen d’un nom de domaine dudit domaine client associé audit deuxième identifiant dudit domaine client. Procédé d’identification d’au moins un serveur de mitigation selon l’une quelconque des revendications 1 à 5 comprenant une étape d’obtention d’au moins une information de localisation dudit deuxième serveur de mitigation par interrogation d’une deuxième base de données au moyen dudit premier identifiant dudit domaine client. Procédé d’identification d’au moins un serveur de mitigation selon l’une quelconque des revendications 1 à 6 dans lequel ladite au moins une information d’identification dudit deuxième serveur de mitigation comprend au moins un nom de domaine d’un domaine associé audit deuxième serveur de mitigation. Procédé d’identification d’au moins un serveur de mitigation selon la revendication 6 dans lequel ladite au moins une information de localisation dudit deuxième serveur de mitigation comprend au moins une adresse réseau dudit deuxième serveur de mitigation et/ou au moins un numéro de port dudit deuxième serveur de mitigation. Procédé d’identification d’au moins un serveur de mitigation selon l’une quelconque des revendications 1 à 8 comprenant en outre la transmission, à destination dudit nœud client, desdites informations d’identification et/ou de localisation dudit deuxième serveur de mitigation. Procédé d’identification d’au moins un serveur de mitigation selon l’une quelconque des revendications 1 à 9 comprenant en outre la transmission, à destination dudit deuxième serveur de mitigation, dudit message de sollicitation. Procédé de protection d’un domaine client contre une attaque informatique, ledit procédé étant mis en œuvre par un nœud client hébergé par le domaine client et comprenant : - la transmission d’un message de sollicitation d’une assistance pour la gestion d’attaques à destination d’un premier serveur de mitigation d’attaques; et - la réception d’au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d’attaques étant associés à des services de mitigation distincts ; et - la transmission dudit message de sollicitation destination dudit deuxième serveur de mitigation. Procédé de protection d’un domaine client selon la revendication 11 dans lequel ledit message de sollicitation comprend au moins un identifiant dudit domaine client au moyen duquel ladite au moins une information d’identification dudit deuxième serveur de mitigation est obtenue par le premier serveur de mitigation. Serveur de mitigation d’attaques, dit premier serveur de mitigation, habilité à protéger un domaine client contre une attaque informatique, et comprenant au moins un processeur configuré pour : - recevoir un message de sollicitation d’une assistance pour la gestion d’attaques en provenance d’un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n’est pas capable de traiter ledit message de sollicitation: - obtenir, au moyen d’un identifiant dudit domaine client obtenu par le premier serveur de mitigation, au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation. Nœud client hébergé par un domaine client comprenant au moins un processeur configuré pour : - transmettre un message de sollicitation d’une assistance pour la gestion d’attaques à destination d’un premier serveur de mitigation d’attaques ; - recevoir au moins une information d’identification d’au moins un deuxième serveur de mitigation d’attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d’attaques étant associés à des services de mitigation distincts ; et - transmettre ledit message de sollicitation à destination dudit deuxième serveur de mitigation. Signal destiné à être transmis par un nœud client hébergé par un domaine client à destination d’au moins un premier serveur de mitigation d’attaques, ledit signal comprenant un message de sollicitation d’une assistance pour la gestion d’attaques, ledit message de sollicitation comprenant au moins un identifiant dudit domaine client au moyen duquel au moins une information d’identification d’au moins un deuxième serveur de mitigation habilité à traiter ledit message de sollicitation peut être obtenue.