FR 3081574 A1 20191129 FR 1856024 A 20180629 Procédés de gestion du trafic associé à un domaine client, serveur, noeud client et programme d'ordinateur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des communications au sein d'un réseau de communication, par exemple un réseau IP, et notamment celui des services IP à valeur ajoutée. Plus précisément, l'invention offre une solution pour gérer le trafic associé à un domaine client, c'est-à-dire entrant dans un domaine client ou sortant d'un domaine client, en cas de détection d'un problème de communication entre le serveur et un noeud client du domaine client. En particulier, l'invention offre une solution permettant d'éviter le déclenchement systématique d'une procédure de mitigation en cas de perte de connexion entre un serveur et un noeud client. L'invention trouve notamment des applications dans le domaine de la mitigation d'attaques par déni de services distribuées (en anglais DDoS, pour « Distributed Denial of Service »), mettant par exemple en oeuvre, mais non exclusivement, une architecture de type DOTS (en anglais « DDoS Open Threat Signaling »), telle que normalisée par l'IETF. 2. Art antérieur 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 des attaques DDoS 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 un tel service n'est pas présent sur les chemins de routage (par défaut) permettant de joindre le réseau victime d'une attaque DDoS. Pour résoudre ce problème, il a été notamment proposé de mettre en place des tunnels pour forcer le trafic (entrant ou sortant) sur un site ou un réseau destiné à être inspecté par le service DPS. Toutefois, cette approche augmente considérablement la latence observée par les utilisateurs et impose des contraintes de dimensionnement du service DPS pour être en mesure 2 de traiter tout le trafic entrant ou sortant de tous les utilisateurs du réseau. 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 de routage du trafic entrant ou sortant d'un réseau, des difficultés peuvent survenir pour l'identification du trafic suspect. 5 Notamment, avec l'augmentation du trafic chiffré, transporté en particulier sur UDP (par exemple, le trafic QUIC, pour « Quick UDP Internet Connection » en anglais), il est difficile de distinguer le trafic légitime du trafic suspect. La difficulté d'accéder en clair aux messages de contrôle, tels que les messages « SYN/SYN-ACK/ACK » prévus dans le protocole TCP, peut en effet rendre complexe la vérification du consentement d'un noeud du réseau à recevoir du trafic. 10 Afin d'aider à l'identification du trafic suspect, une architecture spécifique a été normalisée par l'IETF. Une telle architecture, appelée DOTS, permet à un noeud client, dit client DOTS, d'informer un serveur, dit serveur DOTS, que son réseau est sujet à une attaque DDoS et que des actions appropriées sont requises. Ainsi, si un domaine client est la cible d'une attaque DDoS, un client DOTS attaché à ce 15 domaine client peut envoyer un message au 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 suspect, associé à 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. Cette solution utilise deux canaux de communication entre le client DOTS et le serveur 20 DOTS: - un canal de signalisation DOTS (en anglais « DOTS Signal Channel »), et - un canal de données DOTS (en anglais « DOTS Data Channel »). Le canal de signalisation DOTS est uniquement utilisé quand une attaque DDoS est en cours. Ainsi, un client DOTS peut utiliser ce canal pour demander de l'aide auprès du serveur 25 DOTS. Par exemple, un client DOTS utilise ce canal de signalisation pour envoyer une requête 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, noté par exemple CUID (« Client Unique Identifier »). Un serveur DOTS peut ainsi prendre les mesures adéquates pour mettre fin à une attaque 30 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 du même domaine client, ou avec une règle de filtrage installée préalablement sur le serveur par un autre client du domaine client, et d'autre part si le serveur est habilité à/configuré pour honorer la dernière requête reçue. En cas de conflit, le 3 serveur peut envoyer un message d'erreur, par exemple de type 4.09 (« Conflict »), pour informer le client. Un tel canal de signalisation est notamment décrit dans le document « Distributed Denialof-Service Open Threat Signaling (DOTS) Signal Channel Specification », draft-ietf-dots-signal- 5 channel, Reddy, T. et al., janvier 2018. Le canal de données DOTS est quant à lui utilisé lorsqu'aucune attaque DDoS n'est en cours. Par exemple, un client DOTS peut utiliser ce canal pour installer des règles de filtrage, telles que le filtrage du trafic reçu de certaines adresses ou celui destiné à un noeud donné. Par exemple, un client DOTS peut utiliser ce canal de données DOTS pour demander au serveur de 10 bloquer tout le trafic à destination du préfixe « 1.2.3.0/24 ». Le serveur DOTS peut procéder à l'installation de règles de filtrage en réponse à une demande envoyée par un client, si cette demande n'est pas en conflit avec d'autres demandes provenant d'autres clients du même domaine client ou avec une règle de filtrage existante. En cas de conflit avec d'autres règles maintenues par le serveur DOTS, le serveur peut envoyer un 15 message d'erreur, par exemple de type 409 (« Conflict »), pour informer le client. Un tel canal de données est notamment décrit dans le document « Distributed Denial-ofService Open Threat Signaling (DOTS) Data Channel », draft-ietf-dots-data-channel, Reddy, T. et al., décembre 2017. Selon la procédure décrite dans les deux documents précités, il existe un risque qu'un 20 serveur DOTS refuse de traiter une demande de mitigation d'attaque émise par un client DOTS alors que l'attaque est réelle, ou refuse des demandes de filtrage émise par un client DOTS (un objectif des demandes de filtrage étant d'anticiper des attaques DDoS). Un tel refus peut notamment survenir lorsque des clients du domaine client ont préalablement demandé au serveur d'installer des règles de filtrage, mais que ces règles ne sont désormais plus justifiées (en 25 anglais « stale »). Par ailleurs, l'architecture DOTS a été conçue pour supporter la mitigation automatique d'attaques de déni de service par un serveur en cas de perte de la session établie avec un client DOTS. La mise en oeuvre de cette procédure est dépendante de la valeur d'un paramètre de déclenchement de mitigation, noté « trigger-mitigation », associé à un client DOTS du domaine 30 client au cours d'une phase de négociation de configuration. En d'autres termes, si la valeur de ce paramètre de déclenchement de mitigation est valorisée par le client DOTS à « FAUX », ou « false » en anglais, le serveur DOTS déclenche automatiquement une procédure de mitigation s'il ne reçoit plus de messages depuis ce client 4 DOTS. Par exemple, tant que le serveur DOTS reçoit des messages réguliers de présence du client DOTS, par exemple de type « Heartbeat », le trafic entrant (c'est-à-dire destiné au domaine client) est acheminé normalement par les routeurs situés sur le chemin par défaut. Si le serveur 5 DOTS ne reçoit plus de messages provenant du client DOTS, il décide de déclencher la procédure de mitigation automatique. Le trafic entrant peut ainsi être redirigé vers un centre « d'épuration » du trafic (« DDoS scrubber » ou « DDoS scrubbing center », en anglais), qui se charge d'éliminer le trafic d'attaque DDoS. On note qu'un tel déclenchement automatique d'une procédure de mitigation peut être 10 problématique dans le cas où l'absence de message d'un client DOTS n'est pas due à une attaque DDoS, mais à un autre problème (problème logiciel, opération de maintenance en cours sans clôture convenable de la session DOTS, noeud intermédiaire indisponible, etc.). En particulier, la redirection du trafic entrant vers un centre d'épuration peut être dommageable pour le client car elle augmente le délai de transfert du trafic, voire empêche 15 l'acheminement du trafic, alors que l'absence de message d'un client DOTS n'est pas nécessairement due à une attaque DDoS. Par ailleurs, en cas d'inactivité d'un client DOTS ou lorsque celui-ci se déconnecte, un serveur DOTS peut procéder à la suppression de l'ensemble des filtres activés par ce client, ce qui peut nuire au bon acheminement du trafic vers le domaine client. 20 Il existe donc un besoin pour une nouvelle technique pour la gestion du trafic associé à un domaine client, permettant par exemple d'éviter le déclenchement automatique d'une procédure de mitigation lorsqu'une telle procédure n'est pas justifiée car qu'il n'y a pas d'attaque en cours. 3. Exposé de l'invention L'invention propose une solution nouvelle pour la gestion du trafic associé à un domaine 25 client, i.e., entrant dans le domaine client ou sortant du domaine client, mis en oeuvre dans un serveur, comprenant : - la détection d'un problème de communication entre le serveur et au moins un premier noeud client du domaine client, dit noeud défaillant, - l'identification d'au moins un deuxième noeud client appartenant au domaine client, 30 - la vérification si une session est active entre le serveur et le ou les deuxième(s) noeud(s) client(s), et o si aucune session n'est active : le déclenchement d'une procédure de mitigation sur au moins une ressource IP associée au domaine client, 5 o si au moins une session est active : l'utilisation du ou des deuxième(s) noeud(s) client(s) associé(s) à la ou aux session(s) active(s), dit noeud(s) actif(s), pour engager une action de gestion du trafic associé au domaine client. Ainsi, la solution proposée repose sur l'utilisation d'au moins un deuxième noeud client du 5 domaine client, en cas de défaillance du premier noeud client, pour déclencher une action de gestion du trafic entrant et/ou sortant du domaine client. La solution proposée repose donc sur une coopération entre les différents noeuds clients appartenant à un même domaine client. Par exemple, une telle action de gestion du trafic met en oeuvre la confirmation qu'une 10 attaque est en cours sur au moins une ressource IP associée au domaine client ou la redirection sur un deuxième noeud actif d'au moins une partie du trafic associée à au moins une ressource IP du domaine client. Selon au moins un mode de réalisation, la solution proposée permet d'améliorer la fiabilité des réponses aux attaques DDoS et la coordination entre les noeuds clients d'un même 15 domaine, notamment la coordination des actions de mitigation des attaques DDoS, en impliquant au moins un autre client du domaine pour vérifier la réalité d'une attaque. La solution proposée selon ce mode de réalisation permet ainsi d'éviter l'augmentation du délai de transfert des paquets entrants lorsqu'ils sont acheminés vers un centre d'épuration du trafic (« scrubber ») de manière injustifiée. 20 En particulier, selon au moins un mode de réalisation, la solution proposée permet de forcer le chemin emprunté par le trafic pour solliciter un ou plusieurs autres noeuds clients pendant une période donnée. Par conséquent, si une attaque DDoS est effective, ce ou ces noeuds clients pourront signaler cette attaque au serveur. Si le serveur ne reçoit pas de message signalant une attaque et requérant la mise en oeuvre d'une procédure de mitigation, le trafic peut être 25 redirigé sur le chemin nominal. Par ailleurs, selon au moins un mode de réalisation particulier, une telle coopération entre les clients DOTS d'un même domaine permet notamment de détecter et d'éliminer les entrées obsolètes (« stale ») des tables maintenues par le serveur, par exemple les règles de filtrage qui ne sont plus justifiées suite à l'expiration d'une session entre le client et le serveur. Ainsi, la 30 solution proposée selon ce mode de réalisation particulier permet d'assurer une cohérence de la configuration de plusieurs clients appartenant au même domaine. Notamment, la solution proposée permet à un noeud client du domaine client d'indiquer au serveur qu'il peut supprimer des entrées associées à des ressources IP gérées par un autre 6 noeud client du domaine client. On note également que le procédé de gestion proposé peut, selon au moins un mode de réalisation, s'appliquer au trafic sortant du domaine client. Par exemple, le serveur peut détecter une attaque dont l'origine est le domaine client. Il peut ainsi procéder à la notification du 5 domaine client et éventuellement filtrer le trafic sortant. D'autres modes de réalisation de l'invention concernent un serveur et un noeud client correspondants. Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé de gestion du trafic 10 associé à un domaine client selon au moins un mode de réalisation de l'invention, lorsque ce ou ces programmes est/sont exécuté(s) par un processeur. Dans encore un autre mode de réalisation, l'invention concerne un ou plusieurs supports d'informations, inamovibles, ou partiellement ou totalement amovibles, lisibles par un ordinateur, et comportant des instructions d'un ou plusieurs programmes d'ordinateur pour l'exécution des 15 étapes du procédé de gestion du trafic associé à un domaine client selon au moins un mode de réalisation de l'invention. Les procédés selon l'invention peuvent donc être mis en oeuvre de diverses manières, notamment sous forme câblée et/ou sous forme logicielle. 4. Liste des figures 20 D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre un exemple de réseau de communication mettant en oeuvre un procédé de gestion du trafic associé à un domaine client, selon un mode de réalisation de 25 l'invention ; la figure 2 présente les principales étapes du procédé de gestion du trafic associé à un domaine client, selon au moins un mode de réalisation de l'invention ; les figures 3 et 4 illustrent deux exemples d'application de l'invention ; la figure 5 présente les principales étapes mises en oeuvre par un serveur DOTS selon un 30 premier exemple d'application de l'invention ; la figure 6 illustre la suppression, dans des tables maintenues par le serveur, des ressources IP qui ne sont plus associées à un domaine client ; les figures 7A à 7D illustrent différentes variantes pour la mise en oeuvre d'une deuxième 7 phase de vérification, permettant de confirmer/infirmer si une attaque cible des ressources IP ; la figure 8 présente les principales étapes mises en oeuvre par un serveur DOTS selon un deuxième exemple d'application de l'invention ; 5 les figures 9 à 12 illustrent différents exemples de redirection de trafic selon le deuxième exemple d'application de l'invention ; les figures 13 et 14 illustrent la détection de conflit entre plusieurs clients d'un même domaine ; et la figure 15 présente la structure simplifiée d'un serveur et d'un noeud client selon un 10 mode de réalisation particulier. 5. Description d'un mode de réalisation de l'invention 5./ Principe général Le principe général de l'invention repose sur l'utilisation d'au moins un deuxième noeud client, appartenant à un domaine client, pour gérer le trafic entrant ou sortant du domaine client, 15 en cas de problème de communication entre le serveur et un premier noeud client. On présente, en relation avec la figure 1, différents équipements d'un réseau de communication mettant en oeuvre un procédé de gestion du trafic entrant ou sortant d'un domaine client selon un mode de réalisation de l'invention. On considère par exemple plusieurs noeuds clients Cl 111, C2 112, C3 113, Cm 114 20 appartenant à un domaine client 11, communiquant avec un serveur S 12. Par exemple, le domaine client 11 comprend une ou plusieurs machines, encore appelées noeuds. On entend ici par « domaine » un ensemble de machines ou noeuds placés sous la responsabilité d'une même entité. Selon l'exemple illustré, le serveur 12 n'appartient pas au domaine client 11. Selon un 25 autre exemple non illustré, le serveur 12 peut appartenir au domaine client 11. La figure 2 illustre les principales étapes mises en oeuvre pour la gestion du trafic associé au domaine client 11. Le serveur 12 détecte (21) un problème de communication avec un premier noeud du domaine client, dit noeud défaillant. Par exemple, un problème de communication est détecté si 30 une session entre le serveur 12 et le noeud défaillant est inactive pendant une durée supérieure ou égale à un seuil prédéterminé. En particulier, une session peut être considérée inactive si aucun message de présence (par exemple, de type « heartbeat »), destiné à vérifier qu'un pair distant est toujours actif, n'est reçu à l'issue d'une durée supérieure ou égale à un seuil 8 prédéterminé noté Th. Si un problème de communication est détecté entre le serveur 12 et, par exemple, le noeud Cl 111, le serveur identifie (22) au moins un deuxième noeud client appartenant au domaine client 11. 5 Le serveur vérifie (23) si au moins une session est active entre le serveur 12 et le ou les deuxième(s) noeud (s) client(s). Si aucune session n'est active (231), une procédure de mitigation 24 est déclenchée sur au moins une ressource IP associée au domaine client. Selon un mode de réalisation particulier, si aucune session n'est active, le déclenchement d'une procédure de mitigation est mis en oeuvre 10 sur toutes les ressources IP associées au domaine client. Si au moins une session est active (232), le deuxième noeud associé à la ou aux sessions actives, dit noeud actif, par exemple le noeud C2 112, est utilisé (25) pour engager une action de gestion du trafic du domaine client. Selon un mode de réalisation particulier, si le nombre de sessions inactives est supérieur 15 ou égal à un seuil prédéterminé, la procédure de mitigation 24 est déclenchée sur au moins une ressource IP associée au domaine client, et éventuellement sur toutes les ressources IP associées au domaine client. Par exemple, une telle procédure de mitigation est mise en oeuvre si plus de la moitié des sessions établies entre le serveur et les noeuds clients de ce domaine sont inactives. Les figures 3 et 4 illustrent deux exemples d'application de l'invention. Selon le premier 20 exemple d'application, l'action de gestion du trafic met en oeuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée au domaine client. Le premier exemple d'application permet donc de vérifier qu'une attaque DDoS est effective avant de déclencher une procédure de mitigation. Selon le deuxième exemple d'application, l'action de gestion du trafic met en oeuvre une redirection sur le noeud actif d'au moins une partie du trafic associé à au moins 25 une ressource IP du domaine client. La figure 3 illustre les principales étapes du procédé de gestion du trafic selon le premier exemple d'application. Selon ce premier exemple d'application, l'action de gestion du trafic met en oeuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée au domaine 30 client. En particulier, le trafic associé à une ressource IP peut être le trafic entrant à destination d'une adresse extraite de cette ressource IP ou le trafic sortant émis depuis cette ressource IP. Pour ce faire, le serveur 12 transmet (31s) au noeud client actif 112, et éventuellement à tous les noeuds clients actifs du domaine client, au moins un message de demande de 9 confirmation d'attaque portant sur au moins une ressource IP associée au domaine client. Par exemple, un tel message est noté MAcR, OU « ATTACK_CONFIRMATION_REQUEST(Resources) ». On note que les ressources IP concernées peuvent être indiquées explicitement dans le message, ou non. Par exemple, un tel message spécifie au moins une ressource IP, par exemple une 5 ressource IP associée au noeud client défaillant 111 ou au domaine client 11. L'absence de spécification d'une ressource IP dans un tel message peut être interprétée comme une requête de confirmation d'attaque portant sur l'ensemble des ressources IP associées au domaine client. En particulier, une telle ressource IP appartient au groupe comprenant : - une adresse IP (par exemple un préfixe IPv4 ou IPv6), par exemple les adresses IP des 10 différents noeuds du domaine client 11, - un préfixe IP (par exemple un préfixe IPv4 ou IPv6), par exemple un préfixe IP associé à un routeur de raccordement du domaine client 11, - un nom de domaine, par exemple un nom de domaine associé au domaine client 11, - etc. 15 Le noeud client actif 112 reçoit (32c2) donc au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au noeud client défaillant 111, ou plus généralement au domaine client 11, en provenance du serveur 12. Le noeud client actif 112 vérifie (33c2) que la ou les ressources IP identifiées dans le ou les message(s) de demande de confirmation d'attaque qu'il reçoit sont effectivement associées au 20 domaine client 11. Si au moins une ressource IP identifiée dans le ou les message(s) de demande de confirmation d'attaque n'est pas associée au domaine client, le noeud client actif 112 transmet (341c2) au serveur 12 au moins un message d'erreur. Par exemple, un tel message d'erreur est noté MERR, OU « ERROR(Unknown_Resources) ». En particulier, un tel message d'erreur peut 25 indiquer la ou les ressources IP qui n'appartiennent pas au domaine client 11. Le serveur 12 reçoit (342s) donc au moins un message d'erreur en provenance d'un noeud actif, indiquant qu'une ou plusieurs ressources IP identifiées dans le message de demande de confirmation d'attaque n'appartiennent pas au domaine client. Le serveur 12 peut alors supprimer (343s) la ou les ressources IP identifiées dans le ou les 30 message(s) de demande de confirmation d'attaque ou dans le message d'erreur, d'au moins une table qu'il maintient. Si au moins une ressource IP identifiée dans le ou les message(s) de demande de confirmation d'attaque est associée au domaine client, plusieurs variantes sont envisageables. 10 Selon une première variante, le noeud client actif 112 transmet (351c2) à au moins un noeud client du domaine client associé aux ressources IP identifiées dans le message de demande de confirmation d'attaque, au moins un premier message de vérification d'attaque. Par exemple, un tel premier message de vérification d'attaque est noté MvATT1, ou 5 « DOTS_PEER_PROBE(Request_Code) ». Un tel message est notamment envoyé au noeud client défaillant 111 pour lui demander de confirmer/infirmer l'attaque. Le noeud client recevant (352ci) ce message MvATTi, par exemple le noeud client défaillant 111, peut répondre au noeud actif, par exemple le noeud client actif 112, en transmettant (353ci) un premier message de statut indiquant si une attaque est en cours ou non. 10 Par exemple, un tel premier message de statut est noté MsTATi, ou « DOTS_PEER_PROBE(Reply_Code) ». Le noeud client actif 112 recevant (354c2) ce premier message de statut peut alors transmettre (355c2) au serveur 12 au moins un premier message de réponse informant le serveur de la réponse au premier message de vérification d'attaque. Par exemple, un tel premier message 15 de réponse est noté MREpi, ou « ATTACK_CONFIRMATION_REPLY(Resources, Status) » et indique le statut (attaque en cours ou non), et la ou les ressources IP concernées. Lorsque le serveur 12 reçoit ainsi (356s) au moins un premier message de réponse en provenance d'au moins un noeud actif, il peut déclencher (37s) une procédure de mitigation sur au moins une ressource IP associée au domaine client si au moins un premier message de réponse 20 confirme une attaque. Selon une deuxième variante, le noeud client actif 112 transmet (361c2), à au moins un noeud du domaine client mettant en oeuvre une fonction de détection d'attaque, au moins un deuxième message de vérification d'attaque portant sur au moins une ressource IP associée au domaine client. Par exemple, un tel deuxième message de vérification d'attaque est noté MvATT2, 25 ou « RESOURCE_PROBE(Rk) ». Le noeud N recevant (362N) ce message peut répondre au noeud actif, par exemple le noeud client actif 112, en transmettant (363N) un deuxième message de statut indiquant si une attaque est en cours ou non. Par exemple, un tel deuxième message de statut est noté MsTAT2, ou « RESOURCE_PROBE(code) ». 30 Le noeud client actif 112 recevant (364c2) ce deuxième message de statut peut alors transmettre (365c2) au serveur 12 au moins un deuxième message de réponse informant le serveur de la réponse au deuxième message de vérification d'attaque. Par exemple, un tel deuxième message de réponse est noté MREp2, ou « ATTACK_CONFIRMATION_REPLY(Resources, 11 Status) » et indique le statut (attaque en cours ou non), et la ou les ressources IP concernées. Lorsque le serveur 12 reçoit ainsi (366s) au moins un deuxième message de réponse en provenance d'au moins un noeud actif, il peut déclencher (37s) une procédure de mitigation sur au moins une ressource IP associée au domaine client si au moins un deuxième message de 5 réponse confirme une attaque. Selon une troisième variante, les première et deuxième variantes sont mises en oeuvre. Le noeud client actif 112 transmet donc au moins un premier message de vérification d'attaque à au moins un noeud client du domaine client (par exemple, au(x) noeud(s) client(s) associé(s) aux ressources IP identifiées dans le message de demande de confirmation d'attaque) 10 (351c2), et/ou au moins un deuxième message de vérification d'attaque à au moins un noeud du domaine client mettant en oeuvre une fonction de détection d'attaque (361c2), en tenant compte d'au moins un critère de sélection. Par exemple, le noeud client actif choisit à quel(s) noeud(s) (nceud(s) client(s) ou noeud(s) activant une fonction de détection d'attaque) il envoie des messages de vérification d'attaque. Le 15 critère de sélection est par exemple le volume du trafic transitant par les noeuds voisins du noeud actif. A nouveau, lorsque le serveur 12 reçoit au moins un message de réponse en provenance dudit au moins un noeud actif (premier et/ou deuxième message(s) de réponse), il peut déclencher (37s) une procédure de mitigation sur au moins une ressource IP associée au domaine 20 client si au moins un message de réponse confirme une attaque. Selon un mode de réalisation particulier, le serveur 12 déclenche (37s) une procédure de mitigation sur au moins une ressource IP associée au domaine client, si aucune réponse au message de demande de confirmation d'attaque n'est reçue pendant une durée prédéterminée. On présente désormais, en relation avec la figure 4, les principales étapes du procédé de 25 gestion du trafic selon le deuxième exemple d'application. Selon ce deuxième exemple d'application, l'action de gestion du trafic est une redirection, sur le noeud actif, d'au moins une partie du trafic associé à une ressource IP du domaine client. En particulier, une telle ressource IP peut être gérée par le noeud défaillant. Le serveur 12 peut mettre en oeuvre, au préalable, une sélection (41) de la partie du trafic 30 à rediriger. Par exemple, la sélection appartient au groupe comprenant : - une sélection aléatoire, - une sélection du trafic provenant d'un noeud source utilisant un nombre de ressources réseau supérieur ou égal à un nombre prédéterminé, par exemple la majorité des 12 ressources réseau ; - une sélection du trafic associé à une ressource IP du domaine client (i.e. du trafic entrant à destination d'une adresse extraite de cette ressource IP ou du trafic sortant émis depuis cette ressource IP) utilisant un nombre de ressources réseau supérieur ou égal à un 5 nombre prédéterminé, par exemple la majorité des ressources réseau. Comme déjà indiqué, le trafic à gérer peut être le trafic entrant à destination d'une adresse extraite d'une ressource IP ou le trafic sortant émis depuis cette ressource IP. On se place ci-après dans le contexte de la gestion du trafic entrant sur le domaine client. Le serveur dirige ensuite la partie du trafic sélectionné vers le noeud actif, par exemple le 10 noeud 112. Par exemple, la redirection est mise en oeuvre pendant une durée prédéterminée. Ainsi, sur détection d'un problème de communication entre le serveur et un noeud client, par exemple le noeud 111, le serveur 12 redirige une partie du trafic, acheminé initialement par un chemin passant par ce noeud client défaillant vers des chemins secondaires passant par un ou plusieurs noeuds clients du même domaine client présentant une session active avec le serveur. 15 Eventuellement, le ou les noeuds actifs peuvent déclencher une procédure de mitigation s'il(s) constate(nt) que le trafic sur ce noeud actif est du trafic illégitime, i.e., correspond à une attaque DDoS. Selon un autre mode de réalisation, qui peut être combiné avec l'un des exemples d'application présenté ci-dessus, le procédé de gestion du trafic associé à un domaine client 20 comprend la vérification du fait que tous les noeuds clients du domaine client ont préalablement accepté de mettre en oeuvre les étapes décrites ci-dessus qui les concernent, et notamment les étapes de détection d'un problème de communication entre le serveur et un premier noeud client du domaine client, d'identification d'au moins un deuxième noeud client du domaine client, et de vérification qu'au moins une session associée à ce deuxième noeud client est active. 25 En particulier, la vérification du fait que tous les noeuds clients du domaine client ont préalablement accepté la mise en oeuvre du procédé de gestion du trafic met en oeuvre le contrôle de la valeur d'un paramètre de déclenchement de mitigation, noté par exemple « trigger-mitigation », associé à chaque noeud client du domaine client au cours d'une phase de négociation de configuration. Par exemple, la valeur du paramètre de déclenchement de 30 mitigation « trigger-mitigation » doit être égale à « FAUX ». Par ailleurs, selon un autre mode de réalisation, qui peut être combiné avec l'un des exemples d'application présentés ci-dessus, l'action de gestion du trafic peut être interrompue si le serveur reçoit un message en provenance du noeud défaillant. En effet, la réception d'un tel 13 message en provenance du noeud défaillant signifie que la session entre le serveur et le noeud qui était défaillant est de nouveau active. Ce dernier peut éventuellement commander une action de mitigation en cas de besoin. 5.2 Exemples d'application dans le domaine des services de mitigation (DPS) 5 On décrit ci-après des exemples de mise en oeuvre de l'invention dans une architecture de type DOTS, selon laquelle les noeuds clients Cl 111, C2 112, C3 113 et Cm 114 sont des clients DOTS et le serveur S 12 est un serveur DOTS. Les noeuds clients Cl 111, C2 112, C3 113, Cm 114 et le serveur S 12 peuvent ainsi communiquer via les canaux de signalisation et de données DOTS définis en relation avec l'art antérieur, pour informer le serveur que le domaine client subit une 10 attaque DDoS et que des actions appropriées sont requises. 5.2.1 Rappels sur l'architecture DOTS Une 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, 15 - un message de signalisation pour solliciter la mitigation d'une attaque de déni de service auprès d'un serveur DOTS, le serveur pouvant, sur réception d'un tel message, déclencher les actions nécessaires pour mettre fin à l'attaque, ou - un message de gestion de règles de filtrage, tel que la sollicitation d'un serveur DOTS pour qu'il installe (ou fasse installer) une liste de contrôle d'accès (ACL pour « Access 20 Control List »). Une requête DOTS peut être envoyée d'un client DOTS, appartenant à un domaine client DOTS, à un serveur DOTS ou à une pluralité de serveurs DOTS. Un domaine DOTS peut accueillir un ou plusieurs clients DOTS. En d'autres termes, plusieurs noeuds client d'un domaine client peuvent disposer de fonctions DOTS. 25 Les communications DOTS entre un domaine client et un serveur 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, ou des deux. En d'autres termes, un noeud du domaine client peut communiquer directement avec le serveur, ou transmettre une requête à une passerelle du domaine client qui communique directement avec le serveur ou avec 30 une passerelle du domaine serveur, ou transmettre une requête à une passerelle du domaine serveur qui communique avec le serveur. Une passerelle DOTS localisée dans un domaine client est considérée par un serveur DOTS comme un client DOTS. 14 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 un domaine serveur, l'authentification des clients DOTS peut être confiée à la passerelle DOTS du domaine serveur. Un serveur DOTS peut être configuré avec la liste des passerelles DOTS actives au sein de son 5 domaine et le serveur peut déléguer certaines de ses fonctions à ces passerelles de confiance. En particulier, le serveur peut utiliser en toute sécurité les informations fournies par une passerelle figurant dans une liste déclarée auprès du serveur 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, récupération de la liste auprès d'un serveur 10 d'authentification tel qu'un serveur AAA (pour « Authentication, Authorization and Accounting »), etc.). Les modes de réalisation présentés ci-après peuvent être mis en oeuvre 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 15 serveur, domaine client distinct du domaine serveur, etc.). L'établissement d'une session DOTS sécurisée peut se dérouler conformément à la procédure décrite dans le document « Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification » précité. Par exemple, les sessions peuvent être établies en utilisant une procédure décrite dans l'un des documents suivants : 20 - « Datagram Transport Layer Security Version 1.2 », Rescorla E. et al., RFC 6347, DOI 10.17487/RFC6347, janvier 2012, - « The Data gram Transport Layer Security (DTLS) Protocol Version 1.3 », Rescorla E. et al., draft-ietf-tls-dtls13-22, novembre 2017, - « The Transport Layer Security (TLS) Protocol Version 1.2 », Dierks T. et al., RFC 5246, 25 DOI 10.17487/RFC5246, août 2008, - « The Transport Layer Security (TLS) Protocol Version 1.3 », Rescorla E., draft-ietf-tlstls13-23, janvier 2018. Dans la suite, on suppose que les agents DOTS (client(s), serveur(s)) s'authentifient mutuellement. Il existe donc un canal de communication sécurisé, par exemple de type (D)TLS, 30 entre un client DOTS et un serveur DOTS. Ainsi, les messages reçus d'un autre serveur usurpant l'identité du serveur légitime peuvent être rejetés par un client DOTS. De la même manière, les demandes des clients DOTS 15 non-autorisés à accéder au service de mitigation peuvent être ignorées par le serveur DOTS. On suppose dans la suite que cette procédure est mise en place par les agents DOTS. Les détails des échanges (D)TLS, et ceux concernant la gestion des clés de sécurité pour l'authentification mutuelle des agents DOTS, ne font pas l'objet de la présente invention et ne 5 sont pas détaillés ici. On présente ci-après les différentes étapes mises en oeuvre par un client DOTS et un serveur DOTS, en référence aux figures 1 à 4. On considère à titre d'exemple que les noeuds clients 111 à 114 de la figure 1 sont des clients DOTS et que le serveur 12 de la figure 1 est un serveur DOTS. Le domaine client est donc un domaine DOTS. 10 5.2.2 Premier exemple d'application : Procédure de mitigation automatique coopérative sur détection de perte du signal On présente ci-après plus en détail un premier exemple d'application de l'invention, selon lequel l'action de gestion du trafic met en oeuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée au domaine client. 15 Ce premier exemple d'application permet donc de vérifier qu'une attaque DDoS est effective avant de déclencher une procédure de mitigation, et offre donc une solution permettant d'éviter le déclenchement inutile d'opérations de mitigation. Comme décrit ci-après, la détection d'une attaque DDoS au sein d'un domaine client peut être effectuée par un client DOTS lui-même et/ou par une fonction dédiée, appelée détecteur 20 DDoS (« DDoS Detector » en anglais). Un ou plusieurs détecteurs DDoS peuvent être activés par domaine DOTS. Comme illustré en figure 5, au cours d'une étape de « monitoring » 51, le serveur DOTS surveille l'état des connexions avec les clients DOTS, ou plus généralement surveille les sessions DOTS, i.e., les connexions de canaux de signalisation établies entre le serveur DOTS et les clients 25 DOTS. Si un problème de communication avec un premier client DOTS est détecté au cours d'une étape 52, par exemple une perte de signal prolongé, le serveur DOTS ne déclenche pas automatiquement la procédure de mitigation mais déclenche une procédure permettant de confirmer qu'une attaque DDoS est effectivement en cours. Par exemple, un problème de 30 communication est détecté suite à la non réception par le serveur, pendant une période Th prédéterminée, de messages de présence en provenance du premier client DOTS, par exemple des messages de type « heartbeat ». Dans ce cas, l'état 521 associé à ce client DOTS défaillant, dans les tables à états du 16 serveur, peut être « ATTAQUE_A_VALIDER » (en anglais « ATTACK_TO_BE_VALIDATED »). Le serveur obtient, au cours d'une étape 53, une liste d'au moins une ressource IP associée au client DOTS défaillant, ou plus généralement au domaine client. Comme déjà indiqué, les ressources IP peuvent être des adresses IP, des préfixes IP ou des 5 noms de domaine. Les noms de domaine peuvent être résolus en des adresses IP. Les préfixes IP dénotent ci-après les préfixes IP directement communiqués par un client DOTS ou les adresses récupérées via un système de résolution de nom (par ex. DNS). Les préfixes peuvent être de la même famille d'adresses ou appartenir à des familles distinctes (IPv4, IPv6). L'état « ATTAQUE_A_VALIDER » indique ainsi que les ressources IP associées au client 10 DOTS défaillant, ou plus généralement au domaine client, subissent peut-être une attaque DDoS. Le serveur obtient également, au cours d'une étape 54, une liste d'au moins un deuxième client DOTS appartenant au même domaine que le client DOTS défaillant, et vérifie si ce ou ces deuxième(s) client(s) DOTS sont actifs, i.e., si une session DOTS est active entre le serveur et au moins un de ces deuxièmes clients DOTS. Le serveur peut également procéder à l'identification 15 des ressources IP associées aux clients DOTS actifs. Si toutes les sessions sont inactives (541), c'est-à-dire si aucun message de présence, par exemple de type « heartbeat », n'est reçu pendant une période Th pour tous les clients DOTS identifiés du domaine, le serveur DOTS peut lancer les opérations de mitigation 55 pour toutes les ressources IP associées à ce domaine. L'état du client défaillant tel que maintenu par le serveur 20 peut alors être passé à « MITIGATION_EN_COURS » (en anglais « MITIGATION_IN_PROGRESS )>). En variante, le serveur peut décider qu'une attaque est en cours si la plupart des sessions avec les clients DOTS du domaine client sont inactives. Un seuil de déclenchement est utilisé à cet effet par le serveur. Par exemple, ce seuil peut être à 50% ou 75% des sessions DOTS établies avec les clients de ce domaine. Ainsi, si plus de la moitié des sessions entre le serveur et les clients 25 DOTS du domaine sont inactives, le serveur peut décider de déclencher la procédure de mitigation. Bien entendu, d'autres valeurs peuvent être utilisées par le serveur. Si au moins une session DOTS est active (542) entre le serveur et un client DOTS, le serveur peut envoyer, au cours d'une étape 56, un message non-sollicité de demande de confirmation d'attaque (MAcR ou « ATTACK_CONFIRMATION_REQUEST(Resources) ») à au moins 30 un client DOTS actif du domaine. Un tel message comporte au moins une ressource IP associée au client DOTS défaillant, ou au domaine client auquel appartient le client DOTS défaillant. Par exemple, la valeur spéciale « ANY » peut être utilisée pour indiquer qu'il s'agit de n'importe quelle ressource IP associée au 17 domaine client. A l'envoi de ce message, l'état du client DOTS défaillant, tel que maintenu par le serveur, passe par exemple à « EN_ATTENTE_DE_CONFIRMATION » (en anglais « WAITING_FOR_CONFIRMATION »). 5 Lorsqu'un client DOTS actif du domaine client reçoit une telle requête de confirmation d'attaque en provenance du serveur, le client DOTS actif met en oeuvre une première phase de vérification au cours de laquelle il peut procéder aux vérifications de sécurité pour s'assurer de l'identité du serveur et il peut valider que les ressources IP associées au message de demande de confirmation d'attaque sont effectivement associées au domaine client. 10 La requête peut être ignorée par le client actif en cas d'échec des vérifications de sécurité, et le client actif peut ne pas envoyer de réponse au serveur à l'origine de la requête. Si aucune réponse au message de demande de confirmation d'attaque n'est reçue par le serveur après un temps prédéterminé Tc (57), l'état du client défaillant peut être passé à « TEMPS_DE_VALIDATION_ECOULE » (en anglais « VALIDATION_TIMEOUT ») dans la ou les tables 15 à états maintenues par le serveur. Le serveur DOTS peut alors procéder au lancement des opérations de mitigation 55 pour toutes les ressources IP associées à ce domaine client, et l'état du client défaillant tel que maintenu par le serveur peut être passé à « MITIGATION_EN_COURS » (en anglais « MITIGATION_IN_PROGRESS »). 20 Par ailleurs, si au moins une ressource IP indiquée dans le message de demande de confirmation d'attaque n'est pas associée au domaine client, le client actif peut envoyer un message d'erreur (MERR ou « ERROR(Unknown_Resources) ») au serveur pour l'informer. Un tel message liste notamment les ressources IP présentes dans le message de demande de confirmation d'attaque qui ne sont pas associées au domaine client. 25 Quand le message d'erreur est reçu par le serveur, ce dernier extrait les ressources IP renseignées dans le message d'erreur et procède à la suppression des états actifs associés à ces ressources. Par exemple, comme illustré en figure 6, la session entre le client Cl 111 et le serveur S 12 est inactive. En revanche, la session entre le client C2 112 et le serveur S 12 est active. Le serveur 30 peut donc envoyer un message de demande de confirmation d'attaque au client C2 112, comportant les adresses IP 1.2.3.4 et 11.2.3.4. Le client C2 112 vérifie que ces adresses appartiennent bien au domaine client 11, et envoie (341c2) un message d'erreur au serveur 12 pour l'informer que l'adresse IP 11.2.3.4 n'est pas associée au domaine client. Le serveur 12 peut 18 alors supprimer les règles de filtrage associées à l'adresse IP 11.2.3.4, ou plus généralement les règles de filtrage associées à des ressources n'appartenant pas au domaine client. Cette procédure permet d'éliminer les entrées obsolètes (« stale »). A l'issue de cette première phase de vérification, le client actif 112 peut procéder à une 5 deuxième phase de vérification pour confirmer/infirmer si une attaque cible la/les ressource(s) indiquée(s) dans le message de demande de confirmation d'attaque. En d'autres termes, en plus de la première phase de vérification locale permettant de vérifier si les ressources IP indiquées dans le message de demande de confirmation d'attaque sont associées au domaine client, et notamment gérées par le client actif, d'autres modalités de 10 vérification, qui ne sont pas mutuellement exclusives, peuvent être adoptées par le client actif pour conclure si une attaque est en cours ou pas. A l'issue de cette deuxième phase de vérification, détaillée ci-après en relation avec les figures 7A à 7D, le client actif 112 peut indiquer (58) au serveur si une attaque est en cours ou non sur une ou plusieurs ressources IP. Par exemple, le client actif 112 envoie au serveur un message 15 de réponse (ATTACK_CONFIRMATION_REPLY (Resources, Status)) comportant deux paramètres : - le paramètre « Resources», qui indique la ou les ressources IP concernées, et - le paramètre « Status», qui est positionné par exemple à « 1 » si une attaque est en cours ou à « 0 » sinon. Si le paramètre « Status» est valorisé à « 1 » (581), cela signifie qu'une attaque est en 20 cours sur au moins une ressource IP associée au message de demande de confirmation d'attaque, et le serveur procède au lancement des opérations de mitigation 55 pour les ressources IP concernées, ou à défaut pour l'ensemble des ressources IP associées au domaine client. L'état du client défaillant tel que maintenu par le serveur peut être passé à « ATTAQUE_VALIDEE » (en anglais « ATTACK_VALIDATED »), puis « MITIGATION_EN_COURS » 25 (« MITIGATION_IN_PROGRESS »). Si le serveur reçoit plusieurs messages de réponse provenant de différents clients du domaine, le serveur détermine par exemple qu'une attaque est en cours si au moins un de ces clients envoie un message de réponse portant le paramètre « Status» valorisé à « 1 ». Si le paramètre « Status» est valorisé à « 0 » (582) dans toutes les réponses reçues, cela 30 signifie qu'aucune attaque n'est en cours, et qu'il n'est pas nécessaire que le serveur active une procédure de mitigation. L'état du client défaillant tel que maintenu par le serveur peut être passé à « ATTAQUE_INVALIDEE » (en anglais « ATTACK_INVALIDATED »), puis « EN VEILLE » (en anglais 19 « IDLE ». On note par ailleurs que si le serveur DOTS reçoit un message du client défaillant, la procédure de vérification (selon la première ou la deuxième phase) est interrompue. L'état de ce client peut alors être passé à « EN VEILLE » (« IDLE »). 5 On présente ci-après trois variantes pour la mise en oeuvre de la deuxième phase de vérification, permettant de confirmer/infirmer si une attaque cible la/les ressource(s) indiquée(s) dans le message de demande de confirmation d'attaque, et identifiée(s) comme appartenant au domaine client. On suppose ici, à titre d'exemple, que les clients du domaine sont configurés au préalable 10 avec la liste des autres clients du domaine, ainsi que la liste des ressources IP associées à chaque client. Selon une première variante, illustrée en figure 7A, le client DOTS actif 112 contacte directement le client DOTS responsable de la gestion des ressources indiquées par le serveur, par exemple le client défaillant 111 si le message de demande de confirmation d'attaque comporte au 15 moins une ressource IP associée au client DOTS défaillant, ou une entité DOTS responsable de la gestion du domaine client si le message de demande de confirmation d'attaque porte la valeur spéciale « ANY » (utilisée pour indiquer qu'il s'agit de n'importe quelle ressource IP associée au domaine client). Par exemple, le client actif 112 envoie (351c2) au moins un premier message de 20 vérification d'attaque (MvArri ou « DOTS_PEER_PROBE(Request_Code) ») à au moins un noeud client du domaine client associé aux ressources IP identifiées dans le message de demande de confirmation d'attaque, par exemple le client défaillant 111. Ce premier message de vérification d'attaque est par exemple transmis du client actif 112 au client défaillant 111 pour lui demander de confirmer/infirmer l'attaque. 25 Le champ « Request_Code » du premier message de vérification peut être utilisé pour indiquer la nature de la requête, par exemple : - «O » : message de détection de vie du client défaillant 111, i.e., est-ce que ce client 111 est toujours actif dans le domaine ; - « 1 » : demande si le client défaillant 111 est au courant d'une attaque pour une 30 ressource donnée ; dans ce cas, le premier message de vérification peut comporter une liste de ressources pour lesquelles il faut vérifier si une attaque est en cours. Le client défaillant 111 peut éventuellement répondre (353ci) à ce premier message de vérification d'attaque avec un premier message de statut (MsTATi ou 20 « DOTS_PEER_PROBE(Reply_Code) ») indiquant si une attaque est en cours ou non. Le champ « Reply_Code » du premier message de statut peut être utilisé pour indiquer la nature de la réponse, par exemple : - «0 » : aucune attaque n'est en cours ; 5 - « 1 » : confirmation de l'attaque. Le client actif 112 peut ensuite envoyer au serveur un premier message de réponse (MREPI. ou « ATTACK_CONFIRMATION_REPLY(Resources, Status) ») indiquant le statut (le paramètre « Status » est positionné à « 1 » si une attaque est en cours ou à « 0 » sinon) et la ou les ressources IP concernées par l'attaque en cours. 10 Selon une deuxième variante, illustrée en figure 7B, le client DOTS actif 112 contacte une fonction de détection d'attaque DDoS utilisée au sein du domaine client. Une telle fonction est par exemple mise en oeuvre dans au moins un noeud N du domaine client 11, encore appelé détecteur DDoS. Par exemple, le client actif 112 envoie (361c2) au moins un deuxième message de 15 vérification d'attaque IM ,-VATT2 OU « RESOURCE_PROBE(Rk) ») au détecteur DDoS 115 pour demander de confirmer/infirmer une attaque ciblant au moins une ressource. Le champ « Rk » du deuxième message de vérification d'attaque peut être utilisé pour préciser la liste des ressources concernées : - « ANY » ou champ vide : s'il faut vérifier si une attaque est en cours sur toutes les 20 ressources IP du domaine client ; ou - une liste explicite des ressources IP pour lesquelles il faut vérifier si une attaque est en cours. La fonction de détection d'attaque DDoS, ou le noeud N 115 activant cette fonction, peut éventuellement répondre (363N) à ce deuxième message de vérification d'attaque avec un 25 deuxième message de statut (MsTAT2 ou « RESOURCE_PROBE(Code) ») indiquant si une attaque est en cours ou non. Le champ « Code » du deuxième message de statut peut être utilisé pour indiquer la nature de la réponse, par exemple : - «0 » : aucune attaque n'est en cours ; 30 - « 1 » : confirmation de l'attaque. Le client actif 112 peut ensuite répondre au serveur avec un deuxième message de réponse IM ,-REP2 OU « ATTACK_CONFIRMATION_REPLY(Resources, Status) ») indiquant le statut (le paramètre « Status » est positionné à « 1 » si une attaque est en cours ou à « 0 » sinon) et la ou 21 les ressources IP concernées. Selon une troisième variante, illustrée en figure 7C, combinant les première et deuxième variantes, le client DOTS actif 112 peut contacter une fonction de détection d'attaque DDoS utilisée au sein du domaine client et/ou un ou plusieurs clients DOTS, actifs ou non, et non 5 nécessairement responsable de la gestion des ressources indiquées par le serveur dans le message de demande de confirmation d'attaque. Les messages échangés entre le client DOTS actif 112 et un ou plusieurs clients DOTS sont similaires à ceux décrits en relation avec la première variante et ne sont pas décrits plus en détail. Les messages échangés entre le client DOTS actif 112 et la fonction de détection d'attaque DDoS 10 sont similaires à ceux décrits en relation avec la deuxième variante et ne sont pas décrits plus en détail. Eventuellement, le client actif 112 peut répartir les demandes de vérification d'attaque entre les clients et le détecteur DDoS selon des considérations d'activité des clients voisins, par exemple. 15 Le client actif 112 peut ensuite envoyer au serveur un message de réponse indiquant le statut (le paramètre « Status » est positionné à « 1 » si une attaque est en cours ou à « 0 » sinon) et la ou les ressources IP concernées. Selon cette troisième variante, le client actif 112 décide qu'une attaque est en cours s'il reçoit au moins une réponse confirmant l'attaque, et informe le serveur en conséquence. 20 Eventuellement, le client actif 112 peut envoyer plusieurs messages de réponse au serveur. Dans ce cas, le serveur décide qu'une attaque est en cours s'il reçoit au moins une réponse confirmant l'attaque. La figure 7D illustre trois exemples de messages échangés entre le client DOTS actif 112, le détecteur DDoS 115, et le client Cm 114. 25 Selon le premier exemple 71, le premier message de statut indique qu'aucune attaque n'est en cours (DOTS_PEER_PROBE(Reply_Code=0) et le deuxième message de statut indique qu'une attaque est en cours (RESOURCE_PROBE(Code=1)). Dans ce cas, le client DOTS actif 112 conclut qu'une attaque est en cours. Selon le deuxième exemple 72, le premier message de statut indique qu'une attaque est 30 en cours (DOTS_PEER_PROBE(Reply_Code=1) et le deuxième message de statut indique qu'aucune attaque n'est en cours (RESOURCE_PROBE(Code=0)). Dans ce cas, le client DOTS actif 112 conclut qu'une attaque est en cours. Selon le troisième exemple 73, le premier message de statut indique qu'aucune attaque 22 n'est en cours (DOTS_PEER_PROBE(Reply_Code=0) et le deuxième message de statut indique également qu'aucune attaque n'est en cours (RESOURCE_PROBE(Code=0)). Dans ce cas, le client DOTS actif 112 conclut qu'aucune attaque ne cible la ressource indiquée dans la requête. On note que les différents messages échangés entre le serveur DOTS et les clients DOTS 5 peuvent utiliser les canaux de signalisation et de données DOTS présentés en relation avec l'art antérieur. 5.2.3 Deuxième exemple d'application : solliciter d'autres clients DOTS du domaine On présente ci-après plus en détail un deuxième exemple d'application de l'invention, selon lequel l'action de gestion du trafic met en oeuvre une redirection sur le noeud actif d'au 10 moins une partie du trafic associé au domaine. La figure 8 illustre les principales étapes mises en oeuvre pour rediriger une partie du trafic sur un client actif. Les étapes de monitoring 51 des clients DOTS appartenant à un domaine client, de détection d'un problème de communication avec un premier client DOTS 52, d'obtention d'au 15 moins une ressource IP associée à ce client défaillant 53, d'obtention d'au moins un deuxième client appartenant à ce domaine client 54, et de mitigation 55 sont similaires à celles présentées en relation avec la figure 5 et ne sont pas décrites plus en détail. En particulier, si des clients DOTS appartenant au même domaine ont été identifiés par le serveur, celui-ci vérifie que des sessions DOTS sont actives avec au moins un de ces clients. 20 Si toutes les sessions DOTS sont inactives (541), par exemple aucun message de présence de type « heartbeat » n'est reçu pendant une période Th pour tous les clients du domaine, le serveur DOTS lance les opérations de mitigation 55 pour toutes les ressources associées à ce domaine. Si au moins une session DOTS avec un client du domaine client est active (542), le serveur 25 peut, suite à la détection d'un problème de communication avec un client DOTS (perte du signal par exemple) rediriger (86) une partie du trafic, acheminé initialement par le chemin impliquant le client DOTS défaillant, vers des chemins secondaires impliquant un ou plusieurs clients DOTS du même domaine dont la session DOTS est active. Selon un mode de réalisation particulier, la sélection du trafic à rediriger peut reposer sur 30 un ou plusieurs critères de sélection, appartenant au groupe comprenant : - sélection aléatoire, - sélection du trafic provenant d'une source donnée consommant la majorité des ressources réseau (L1), 23 - sélection du trafic à destination d'une machine donnée consommant la majorité des ressources réseau (L1), - etc. Si une partie du trafic est effectivement associé à une attaque DDoS, un ou plusieurs des 5 clients DOTS sollicités lors de la redirection du trafic peut ou peuvent envoyer un signal au serveur pour lui demander de lancer les opérations de mitigation. Par exemple, la redirection peut être programmée pour une durée prédéterminée REDIRECT_Tmax. Ainsi, le serveur DOTS surveille (87) la session inactive avec le client DOTS défaillant pendant une durée prédéterminée REDIRECT_Tmax. 10 Si, à l'issue de cette durée prédéterminée REDIRECT_Tmax, le serveur reçoit une demande de mitigation ou si la ou les sessions précédemment actives ne sont plus actives (871), le serveur DOTS peut lancer les opérations de mitigation 55 pour toutes les ressources associées à ce domaine client. Si, à l'issue de cette durée prédéterminée REDIRECT_Tmax, le serveur ne reçoit aucune 15 demande de mitigation (872), et si au moins une session avec un autre client DOTS est toujours active, cela signifie a priori que le problème de communication avec le client défaillant n'est pas dû à une attaque DDoS, et l'état associé au client DOTS défaillant peut être placé à « EN_VEILLE » (« IDLE ») dans la ou les tables à états maintenues par le serveur. Le serveur peut par ailleurs décider de rediriger une autre portion du trafic et de réitérer 20 la même procédure pour une autre durée REDIRECT_Tmax. Selon l'exemple illustré en figure 9, un problème de communication est détecté entre le serveur 12 et le client Cl 111. Une partie du trafic entrant 91 est redirigée, grâce à un routeur R 92 par exemple, vers le client C2 112 actif pendant une durée REDIRECT_Tmax égale à Ti. A l'issue de cette durée, une autre partie du trafic entrant 91 peut être redirigée vers le client Cm 114 actif 25 pendant une durée REDIRECT_Tmax égale à T2. Selon l'exemple illustré en figure 10, un problème de communication est détecté entre le serveur 12 et le client Cl 111. Une partie du trafic entrant est redirigée (100) vers un autre client actif. Une fois le trafic redirigé vers d'autres chemins, le serveur déclenche le « timer » REDIRECT_Tmax. Le client C2 112 peut intercepter le trafic redirigé (101), en particulier si le trafic 30 redirigé transite par le client C2 112, et détecter une attaque DDoS dans le trafic entrant avant l'expiration de la durée prédéterminée REDIRECT_Tmax. Le client C2 112 peut alors demander au serveur DOTS d'engager une procédure de mitigation (par exemple en utilisant le message PUT(mid=5986)). Le serveur peut alors déclencher les opérations de mitigation DDoS (102) et 24 informer le client C2 112 actif (2.01 (Created)). Selon l'exemple illustré en figure 11, un problème de communication est détecté entre le serveur 12 et le client Cl 111. Une partie du trafic entrant est redirigée (100) vers un autre client actif. Une fois le trafic redirigé vers d'autres chemins, le serveur déclenche le « timer » 5 REDIRECT_Tmax. Le client C2 112 peut intercepter le trafic redirigé (101), en particulier si le trafic redirigé transite par le client C2 112. Si aucune demande de mitigation n'est reçue par le serveur de la part du client C2 112, et que la session DOTS est toujours active avec ce client C2 112, le serveur conclut qu'aucune attaque n'est en cours. Le serveur peut alors décider de l'arrêt de la redirection du trafic (103). 10 Selon les exemples illustrés en figures 10 et 11, on suppose que, par construction du service DOTS, les clients DOTS sont activés sur des routeurs d'interconnexion. Il ne s'agit toutefois que d'un exemple de mise en oeuvre. La technique proposée peut également être mise en oeuvre quand les clients sont activés dans d'autres noeuds. Les clients DOTS ne sont donc pas nécessairement situés sur le chemin 15 emprunté par le trafic entrant et/ou sortant. Dans ce cas, comme illustré en figure 12, des détecteurs DDoS (D1 104, D2 105, ..., Dm 106) peuvent être activés pour surveiller le trafic écoulé via les différents liens d'interconnexion du domaine client. La détection d'attaques peut alors être mise en oeuvre par l'un de ces détecteurs, qui peut communiquer l'information au client DOTS associé. 20 Le serveur S 12 peut notamment communiquer avec les détecteurs DDoS via les canaux de signalisation et de données DOTS définis en relation avec l'art antérieur. 5.2.4 Détection de conflit entre plusieurs clients du même domaine Par ailleurs, selon au moins un mode de réalisation, le procédé de gestion du trafic associé à un domaine client comprend la vérification d'un paramètre commun aux noeuds client, 25 permettant notamment d'assurer la cohérence de la configuration des différents clients d'un même domaine quant à l'activation de la mitigation automatique sur perte du signal DOTS. Ainsi, selon ce mode de réalisation, un serveur peut n'activer la procédure décrite précédemment que si tous les clients d'un même domaine ont négocié la même valeur pour le paramètre de déclenchement de mitigation « trigger-mitigation » au cours de la négociation de 30 configuration des sessions DOTS. Le serveur doit donc vérifier la valeur de ce paramètre de déclenchement de mitigation. A titre d'exemple, on suppose que le client Cl 111 a indiqué la valeur « FAUX » pour le paramètre de déclenchement de mitigation dans sa demande de négociation de configuration 25 (« trigger-mitigation : false »). On suppose que le client C2 112 a indiqué la valeur « VRAI » pour le paramètre de déclenchement de mitigation dans sa demande de négociation de configuration (« trigger-mitigation: true »). Le serveur DOTS détecte un conflit entre ces deux demandes, et peut procéder à la désactivation de la mitigation automatique sur perte de signal pour tous les 5 clients de ce domaine. La figure 13 illustre le cas où le deuxième client C2 a établi une session DOTS (131) avec le serveur 12 au cours de laquelle il a indiqué que le paramètre de déclenchement de mitigation est valorisé à « VRAI » (« trigger-mitigation: true »). Si le premier client Cl cherche par la suite à établir une session DOTS (132) avec le serveur 12 en indiquant que le paramètre de 10 déclenchement de mitigation est valorisé à FAUX (« trigger-mitigation: false »), la nouvelle requête est en conflit avec celle déjà maintenue par le serveur. En particulier, si la requête maintenue par le serveur indique que la procédure de mitigation automatique sur perte de signal est désactivée (« trigger-mitigation: true »), alors le serveur DOTS peut rejeter la demande du premier client Cl, par exemple avec un message 4.09 15 de type « conflit » 133 (en anglais « Conflict »). En particulier, le message d'erreur peut indiquer la nature du conflit (« conflict-trigger-mitigation »). Le client Cl peut alors envoyer une nouvelle requête de négociation avec le paramètre de déclenchement de mitigation valorisé à « VRAI » (« trigger-mitigation: true »). La figure 14 illustre le cas où le premier client Cl a établi une session DOTS (141) avec le 20 serveur 12 au cours de laquelle il a indiqué que le paramètre de déclenchement de mitigation est valorisé à FAUX (« trigger-mitigation: false »). Si le deuxième client C2 cherche par la suite à établir une session DOTS (142) avec le serveur 12 en indiquant que le paramètre de déclenchement de mitigation est valorisé à « VRAI » (« trigger-mitigation: true »), la nouvelle requête est en conflit avec celle déjà maintenue par le serveur. 25 En particulier, si la requête maintenue par le serveur indique que la procédure de mitigation automatique sur perte de signal est activée (« trigger-mitigation: false »), alors le serveur DOTS peut mettre fin à la session TLS ou DTLS avec le client Cl ayant négocié le paramètre « trigger-mitigation: false ». Pour ce faire, le serveur DOTS envoie par exemple un message de type « alerte fatale » 143 (« Fatal Alert ») au client Cl, tel que décrit par exemple 30 dans le document RFC5246 précité. Le client Cl peut alors procéder à la réinitialisation 144 de la session avec le serveur et à la négociation 145 d'une nouvelle valeur du paramètre de déclenchement de mitigation valorisé à « VRAI » (« trigger-mitigation: true »). 26 5.3 Structures On présente finalement, en relation avec la figure 15, les structures simplifiées d'un serveur et d'un noeud client selon l'un des modes de réalisation décrits ci-dessus. Selon un mode de réalisation particulier, un serveur comprend une mémoire 151s 5 comprenant une mémoire tampon, une unité de traitement 152s, é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 153s, mettant en oeuvre des étapes du procédé de gestion du trafic associé à un domaine client selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 153s sont par 10 exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 152s. Le processeur de l'unité de traitement 152s met en oeuvre des étapes du procédé de gestion du trafic associé à un domaine client décrit précédemment, selon les instructions du programme d'ordinateur 153s, pour : 15 - détecter un problème de communication entre le serveur et au moins un premier noeud client du domaine client, dit noeud défaillant, - identifier au moins un deuxième noeud client appartenant au domaine client, - vérifier si une session est active entre le serveur et le ou les deuxième(s) noeud(s) client(s), 20 o si aucune session n'est active : déclencher une procédure de mitigation sur au moins une ressource IP associée au domaine client, o si au moins une session est active : utiliser le deuxième noeud client associé à ladite au moins une session active, dit noeud actif, pour engager une action de gestion du trafic associé au domaine client. 25 Selon un mode de réalisation particulier, un noeud client comprend une mémoire 151c comprenant une mémoire tampon, une unité de traitement 152c, é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 153c, mettant en oeuvre des étapes du procédé de gestion du trafic associé à un domaine client selon un mode de réalisation de l'invention 30 A l'initialisation, les instructions de code du programme d'ordinateur 153c sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 152c. Le processeur de l'unité de traitement 152c met en oeuvre des étapes du procédé de 27 gestion du trafic associé à un domaine client décrit précédemment, selon les instructions du programme d'ordinateur 1.53o pour recevoir au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client, REVENDICATIONS1. Procédé de gestion du trafic associé à un domaine client, mis en oeuvre dans un serveur, ledit procédé comprenant : - la détection (21) d'un problème de communication entre ledit serveur et au moins un premier noeud client dudit domaine client, dit noeud défaillant, - l'identification (22) d'au moins un deuxième noeud client appartenant audit domaine client, - la vérification (23) si une session est active entre ledit serveur et ledit au moins un deuxième noeud client, et o si aucune session n'est active : le déclenchement d'une procédure de mitigation sur au moins une ressource IP associée audit domaine client, o si au moins une session est active : l'utilisation du deuxième noeud client associé à ladite au moins une session active, dit noeud actif, pour engager une action de gestion du trafic associé audit domaine client. 2. Procédé selon la revendication 1, caractérisé en ce que ladite action de gestion du trafic met en oeuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée audit domaine client, ladite confirmation comprenant la transmission (31s), audit au moins un noeud actif, d'au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend la réception (342s) d'au moins un message d'erreur en provenance dudit noeud actif, indiquant qu'une ou plusieurs ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque n'appartiennent pas audit domaine client, et la suppression (343s) de ces ressources IP d'au moins une table maintenue par ledit serveur. 4. Procédé selon la revendication 2, caractérisé en ce qu'il comprend le déclenchement d'une procédure de mitigation (37s) sur au moins une ressource IP associée audit domaine client si aucune réponse au message de demande de confirmation d'attaque n'est reçue pendant une durée prédéterminée ou si au moins un message de réponse reçu (356s, 366s), en provenance dudit au moins un noeud actif, confirme une attaque. 5. Procédé selon la revendication 1, caractérisé en ce que ladite action de gestion du trafic est une redirection (42), sur ledit noeud actif, d'au moins une partie du trafic associé à au moins une ressource IP associée audit domaine client. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il 29 comprend la vérification du fait que tous les noeuds clients dudit domaine client ont préalablement accepté de mettre en oeuvre les étapes de la revendication 1 qui les concernent. 7. Procédé selon la revendication 6, caractérisé en ce que ladite vérification met en oeuvre le contrôle de la valeur d'un paramètre de déclenchement de mitigation associé à chaque noeud 5 client dudit domaine client au cours d'une phase de négociation de configuration. 8. Procédé de gestion du trafic associé à un domaine client, mis en oeuvre dans un noeud client associé à une session active avec un serveur, ledit procédé comprenant la réception (32c2) d'au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client, en provenance dudit serveur. 10 9. Procédé selon la revendication 8, caractérisé en ce qu'il comprend la vérification (33c2) que les ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque sont associées audit domaine client. 10. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce qu'il comprend : 15 - la transmission (351c2), à au moins un noeud client dudit domaine client associé aux ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque, d'au moins un premier message de vérification d'attaque, - la transmission (355c2) audit serveur, le cas échéant, d'au moins un premier message de réponse informant ledit serveur d'une réponse dudit noeud client associé aux ressources 20 IP identifiées dans ledit au moins un message de demande de confirmation d'attaque audit premier message de vérification d'attaque. 11. Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce qu'il comprend : - la transmission (361c2), à au moins un noeud dudit domaine client mettant en oeuvre une 25 fonction de détection d'attaque, d'au moins un deuxième message de vérification d'attaque portant sur au moins une ressource IP associée au domaine client ; - la transmission (365c2) audit serveur, le cas échéant, d'au moins un deuxième message de réponse informant ledit serveur d'une réponse dudit noeud mettant en oeuvre une fonction de détection d'attaque. 30 12. Procédé selon l'une quelconque des revendications 8 à 11, caractérisé en ce qu'il comprend la transmission d'au moins un premier message de vérification d'attaque audit au moins un noeud client associé aux ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque, et/ou au moins un deuxième message de vérification 30 d'attaque audit au moins un noeud dudit domaine client mettant en oeuvre une fonction de détection d'attaque, en tenant compte d'au moins un critère de sélection. 13. Serveur comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour gérer le trafic associé à un domaine client, mettant en oeuvre : 5 - la détection d'un problème de communication entre ledit serveur et au moins un premier noeud client dudit domaine client, dit noeud défaillant, - l'identification d'au moins un deuxième noeud client appartenant audit domaine client, - la vérification si une session est active entre ledit serveur et ledit au moins un deuxième noeud client, et 10 o si aucune session n'est active : le déclenchement d'une procédure de mitigation sur au moins une ressource IP associée audit domaine client, o si au moins une session est active : l'utilisation du deuxième noeud client associé à ladite au moins une session active, dit noeud actif, pour engager une action de gestion du trafic associé audit domaine client. 15 14. Noeud client comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour la gestion du trafic associé à un domaine client, mettant en oeuvre la réception d'au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client, en provenance d'un serveur avec lequel une session est active. 20 15. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 12 lorsque ce programme est exécuté par un processeur.