FR 3081573 A1 20191129 FR 1856015 A 20180629 Procédés de vérification de la validité d'une ressource IP, serveur de contrôle d'accès, serveur de validation, noeud client, noeud relais 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 vérifier la validité d'une ressource IP associée à un domaine, i.e., vérifier qu'une adresse IP, un préfixe IP (ensemble d'adresses IP), un nom de domaine, etc., est effectivement associé à ce domaine. L'invention trouve notamment, mais non exclusivement, 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 »), en particulier pour faciliter la coordination des actions de mitigation. Elle peut notamment être mise en oeuvre avant ou pendant une procédure de mitigation. 2. Art antérieur On s'attache plus particulièrement dans la suite de ce document à décrire une problématique existante dans le domaine de la mitigation des attaques par déni de services distribuées. L'invention ne se limite bien sûr pas à ce domaine particulier d'applications, mais, plus généralement, l'invention présente un intérêt pour toute technique dans laquelle la validité d'une ressource IP doit être vérifiée avant d'engager une quelconque action relative à ladite ressource. 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 2 pour forcer l'invocation du service DPS pour tout le trafic (entrant ou sortant) d'un réseau. 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 de traiter tout le trafic de tous les utilisateurs du réseau. 5 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 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 (par exemple, le trafic QUIC, pour « Quick UDP Internet Connection » en anglais), il est difficile de distinguer le trafic 10 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 détermination du consentement d'un noeud du réseau à recevoir du trafic. 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 (« DDoS Open Threat Signaling »), 15 permet à un noeud client, dit client DOTS, d'informer un serveur, dit serveur DOTS, que son réseau fait l'objet d'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 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 20 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 DOTS: - un canal de signalisation DOTS (en anglais « DOTS Signal Channel »), et 25 - 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 DOTS. Par exemple, un client DOTS utilise ce canal de signalisation pour envoyer une requête à son serveur l'informant que le préfixe « 1.2.3.0/24 » subit une attaque DDoS, afin que le serveur 30 puisse engager des actions pour mettre fin à l'attaque. Un tel canal de signalisation est notamment décrit dans le document « Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification », draft-ietf-dots-signal-channel, Reddy, T. et al., janvier 2018. Le canal de données DOTS est quant à lui utilisé quand aucune attaque DDoS n'est en 3 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 bloquer tout le trafic à destination du préfixe « 1.2.3.0/24 ». Un tel canal de données est 5 notamment décrit dans le document « Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel », draft-ietf-dots-data-channel, Reddy, T. et al., décembre 2017. Il est à noter que si le serveur ne dispose pas de mécanisme permettant de vérifier que le préfixe « 1.2.3.0/24 » est effectivement associé au domaine du client DOTS, des perturbations de service peuvent être observées par le propriétaire légitime de ce préfixe (i.e., l'entité en charge de 10 la gestion de ce préfixe, par exemple le fournisseur d'accès). En particulier, les noeuds auxquels une adresse extraite de ce préfixe est allouée peuvent ne plus recevoir de trafic en cas de mise en place de mesures de contournement du trafic associé à ce préfixe ou de filtrage sur tout le trafic ayant une adresse de destination relevant de ce préfixe. De plus, le service de mitigation DDoS peut être facturé aux propriétaires légitimes, alors 15 qu'ils n'ont pas été à l'origine de la demande de mitigation. Par ailleurs, pour résoudre le problème d'usurpation d'adresses IP, l'IETF recommande l'activation du BCP 38 (« Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing », P. Ferguson et al., mai 2000), et de la fonction uRPF (« unicast Reverse Path Forwarding », RFC2504 : « Users' Security Handbook » E. Guttman et al., 20 février 1999). Cependant, ces mécanismes ne s'appliquent que pour la validation de l'adresse source d'un paquet IP. Des solutions dites « SAVI » (« Source Address Validation Improvements ») ont également été proposées, mais ces solutions ne permettent pas de valider les adresses/préfixes IP indiqués dans le contenu (« payload » ou charge utile) des protocoles utilisant des références (par ex. SDP 25 (Session Description Protocol), SIP (Session Initiation Protocol), ou DOTS). Ainsi, les techniques de l'art antérieur présentent au moins un des inconvénients suivants : - la validation des adresses se fait sur la base de l'adresse source d'un paquet, - les bases de données disponibles, par exemple une base de données gérée par un RIR 30 (« Regional Internet Registry »), sont renseignées par les propriétaires des ressources IP (à savoir, généralement, les opérateurs) ou ne fournissent que l'identité des propriétaires des ressources IP, - il n'existe pas de solution de validation de ressources IP déployée uniformément dans 4 l'Internet par les différents acteurs - fournisseurs de contenus, de services et opérateurs de réseau, - des attaques destinées à fragiliser la sécurité des communications ou des terminaux connectés à Internet sont toujours possibles. 5 Il existe donc un besoin pour une nouvelle technique permettant de vérifier la validité d'un préfixe IP, ou plus généralement d'une ressource IP, en particulier lorsque le service DPS est hébergé dans le « cloud ». 3. Exposé de l'invention L'invention propose une solution nouvelle pour la vérification de la validité d'une 10 ressource IP associée à un domaine client, i.e., pour la vérification de l'appartenance d'une ressource IP à un domaine client. Par exemple, une telle ressource IP appartient au groupe comprenant : - une adresse IP (par exemple une adresse IPv4 ou IPv6), - un préfixe IP (par exemple un préfixe IPv4 ou IPv6), 15 - un nom de domaine. Selon au moins un mode de réalisation, un procédé de vérification de la validité d'une ressource IP associée à un domaine client met en oeuvre les étapes suivantes dans un serveur, dit serveur de contrôle d'accès : - la réception d'une liste d'au moins une ressource IP associée au domaine client, transmise 20 d'un noeud client du domaine client au serveur de contrôle d'accès ; - la sélection d'au moins une ressource IP à valider parmi la liste ; et - la vérification de la validité de la ou des ressources IP sélectionnées. Selon au moins un mode de réalisation, le procédé de vérification de la validité d'une ressource IP associée à un domaine client met en oeuvre les étapes suivantes dans un noeud client 25 du domaine client : - l'obtention d'une liste d'au moins une ressource IP associée au domaine client ; et - la transmission de la liste à un serveur de contrôle d'accès. Selon au moins un mode de réalisation, le procédé de vérification de la validité d'une ressource IP associée à un domaine client met en oeuvre les étapes suivantes dans un noeud relais 30 du domaine client, associé à au moins une ressource IP sélectionnée par un serveur de contrôle d'accès parmi une liste d'au moins une ressource IP associée au domaine client, préalablement transmise d'un noeud client du domaine client au serveur de contrôle d'accès : - la réception ou l'interception d'au moins une requête en provenance du serveur de 5 contrôle d'accès, ladite requête comportant un message de contrôle ; et - la transmission de la ou des requêtes au noeud client. Selon au moins un mode de réalisation, le procédé de vérification de la validité d'une ressource IP associée à un domaine client met en oeuvre les étapes suivantes dans un serveur de 5 validation associé à au moins une ressource IP sélectionnée par un serveur de contrôle d'accès parmi une liste d'au moins une ressource IP associée au domaine client, préalablement transmise d'un noeud client du domaine client au serveur de contrôle d'accès : - la réception d'au moins une requête comportant une information représentative de l'identité d'un domaine client et de la ou des ressources IP sélectionnées, 10 - l'identification du domaine client à partir de l'information représentative de l'identité du domaine client, et - la vérification de l'association de la ou des ressources IP sélectionnées avec le domaine client en tenant compte de l'identité du domaine client. La solution proposée permet ainsi de vérifier qu'une ressource IP est effectivement (et 15 légitiment) associée à un domaine client. En particulier, si un noeud client du domaine client émet une requête demandant au serveur de contrôle d'accès d'effectuer une action sur au moins un autre noeud identifié par une ressource IP, la solution proposée permet de vérifier si la ressource IP identifiant au moins un autre noeud est effectivement associée au domaine client, par exemple allouée à au moins un 20 noeud du domaine client, ou si le trafic à destination de cette ressource IP est légitiment acheminé vers ce domaine client. Ainsi, dans le contexte d'une attaque DDoS par exemple, le serveur de contrôle d'accès peut vérifier si une demande de mitigation ou de filtrage transmise par un noeud client du domaine client, concerne réellement ce noeud client ou un autre noeud du domaine client, avant 25 d'engager des actions pour que le trafic suspect ne soit plus acheminé vers le domaine client. Par ailleurs, selon au moins un mode de réalisation, la solution proposée ne nécessite pas d'utiliser les infrastructures du fournisseur d'accès. Ainsi, la solution proposée permet de vérifier la validité d'une ressource IP associée à un domaine client, que le service de mitigation DPS soit hébergé au sein de l'infrastructure exploitée par le fournisseur d'accès, dans le « cloud », ou 30 ailleurs. Selon au moins un mode de réalisation, la solution proposée permet d'améliorer la fiabilité, la robustesse et/ou l'efficacité des réponses aux attaques DDoS. En particulier, contrairement aux solutions actuelles qui reposent sur la consultation 6 statique de bases de données, le procédé de vérification de la validité d'une ressource IP selon au moins un mode de réalisation de l'invention permet de vérifier en temps réel les informations concernant l'allocation de ressources IP aux clients, sans pour autant divulguer leur identité, y compris dans un contexte d'allocation dynamique de ressources IP. 5 Selon au moins un mode de réalisation, la liste est mise à jour périodiquement et/ou en cas d'ajout, suppression ou modification d'une ressource IP associée au domaine client. Ainsi, la solution proposée permet de valider une ressource IP régulièrement, et/ou en cas d'ajout, suppression ou modification d'une ressource IP associée au domaine client. De cette façon, dans le contexte d'une architecture DOTS par exemple, il n'est pas 10 nécessaire d'attendre la réception d'une demande d'installation de filtre (une telle mise en place pouvant par exemple correspondre à la réponse à une attaque), ce qui permet d'optimiser les délais de traitement des requêtes DOTS. Par ailleurs, selon au moins un mode de réalisation, il est possible d'associer une durée de validité à la liste d'au moins une ressource IP associée au domaine client, à chacune des 15 ressources IP voire plusieurs ressources IP. Dans ce cas, le serveur de contrôle d'accès peut supprimer automatiquement la ou les ressources IP concernées de ses tables à l'expiration de la durée de validité. En particulier, un noeud client peut mettre à jour la liste des ressources IP associées au domaine client sans attendre l'expiration de la durée de validité. 20 De cette façon, il est possible de détecter qu'une validation de ressource est obsolète, ce qui présente notamment un intérêt dans le cas de réseaux avec renumérotation fréquente (c'est-à-dire, les adresses ou préfixes IP alloués aux noeuds du réseau sont fréquemment modifiés). Par exemple, dans le cadre d'une demande de mitigation, si un noeud d'un domaine client demande au serveur de contrôle d'accès de filtrer le trafic (entrant) à destination du préfixe 1.2.3.0/24 25 associé au domaine client à l'instant TO, le serveur de contrôle d'accès doit vérifier à l'instant Ti que le préfixe 1.2.3.0/24 est toujours associé au même domaine client pour décider s'il doit filtrer ou acheminer le trafic vers ce préfixe 1.2.3.0/24. Selon une caractéristique particulière de l'invention, le procédé de vérification de la validité d'une ressource IP tient également compte d'au moins une règle de filtrage des données 30 préalablement définie. D'autres modes de réalisation de l'invention concernent un serveur de contrôle d'accès, un noeud client, un noeud relais, et un serveur de validation correspondants. Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes 7 d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé de vérification de la validité d'une ressource IP associée à 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 5 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 étapes du procédé de vérification de la validité d'une ressource IP associée à 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, 10 notamment sous forme câblée et/ou sous forme logicielle. 4. Liste des figures 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 : 15 - la figure 1 illustre un exemple de réseau de communication mettant en oeuvre un procédé de vérification de la validité d'une ressource IP associée à un domaine client, selon un mode de réalisation de l'invention ; la figure 2 présente les principales étapes du procédé de vérification de la validité d'une ressource IP associée à un domaine client, selon au moins un mode de réalisation de 20 l'invention ; les figures 3 et 4 illustrent deux modes de réalisation de l'invention ; la figure 5 présente les principales étapes mises en oeuvre par un client DOTS pour la déclaration de ressources IP associées à un domaine DOTS, selon un mode de réalisation ; les figures 6A et 6B illustrent deux exemples de déclaration des ressources IP; 25 - la figure 7 illustre une détection de conflit d'adresses entre plusieurs domaines ; la figure 8 illustre la suppression des ressources IP ne faisant pas partie de la liste déclarée par un client DOTS; la figure 9 illustre le refus d'une demande de mitigation sur une adresse ne faisant pas partie de la liste déclarée par un client DOTS; 30 - la figure 10 illustre les communications autorisées ou non entre noeuds client et noeuds relais ; les figures 11 à 15 présentent des exemples de mise en oeuvre de la procédure de vérification selon un premier mode de réalisation dit « DOTS Probing » ; 8 la figure 16 présente un exemple de mise en oeuvre de la procédure de vérification selon un deuxième mode de réalisation dit « Cooperating DOTS/ISPs »; et la figure 17 présente la structure simplifiée d'un serveur de contrôle d'accès, serveur de validation, noeud client ou noeud relais selon un mode de réalisation particulier. 5 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 une déclaration auprès d'un serveur, dit serveur de contrôle d'accès, des ressources IP associées à un domaine client, et sur une vérification de la validité de ces ressources IP, i.e., la vérification que les ressources déclarées sont 10 effectivement associées au domaine 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 vérification de la validité d'une ressource IP associée à un domaine client. On considère par exemple un noeud client Cl 111, appartenant à un domaine client 11, 15 communiquant avec un serveur de contrôle d'accès S 14. Par exemple, le domaine client 11 comprend une ou plusieurs machines, encore appelées noeuds. Notamment, le domaine client comprend au moins un noeud relais R1 112. On entend ici par « domaine » un ensemble de machines ou noeuds placés sous la responsabilité d'une même entité. Un premier fournisseur d'accès 12 dispose d'équipements permettant aux clients du 20 domaine client 11 d'accéder au réseau Internet 13 auquel est connecté le serveur de contrôle d'accès 14. Selon au moins un mode de réalisation, le premier fournisseur d'accès 12 comprend au moins un serveur de validation V1 121. Selon l'exemple illustré, le serveur de contrôle d'accès 14 n'appartient pas au domaine client 11, et peut donc être connecté au réseau Internet 13 par l'intermédiaire d'un deuxième 25 fournisseur d'accès. Selon un autre exemple non illustré, le serveur de contrôle d'accès 14 peut appartenir au domaine client, ou bien à un autre domaine connecté au réseau Internet 13 par l'intermédiaire du premier fournisseur d'accès 12. La figure 2 illustre les principales étapes mises en oeuvre pour la vérification d'une ressource IP associée à un domaine client 11. 30 Un noeud du domaine client 11, par exemple le noeud client Cl 111, obtient (21c) une liste d'au moins une ressource IP associée au domaine client 11. Par exemple, une telle liste comprend les adresses IP des différents noeuds du domaine client 11, un préfixe IP associé à un routeur de raccordement du domaine client 11, un nom de domaine associé au domaine client 11, etc. 9 Le noeud client Cl 111, ou éventuellement un autre noeud du domaine client 11, transmet (22c) cette liste à un serveur, par exemple le serveur de contrôle d'accès 14. En d'autres termes, le noeud client Cl 111 déclare au serveur de contrôle d'accès 14 les ressources IP associées au domaine client 11. L'adresse source est donc l'adresse du noeud client, mais les ressources IP à 5 valider sont celles transmises au serveur de contrôle d'accès, dans le contenu du message. La déclaration des ressources IP peut être explicite (à l'aide d'un message dédié) ou être implicite (faisant partie d'une requête de signalisation ou de demande de filtrage). Selon un premier exemple, la liste d'au moins une ressource IP associée au domaine client est transmise dans un seul message. Dans ce cas, une unique requête, dire requête agrégée, peut 10 être émise à destination du serveur de contrôle d'accès. Selon un deuxième exemple, la liste d'au moins une ressource IP associée au domaine client est répartie dans une pluralité de messages. Dans ce cas, plusieurs requêtes séparées peuvent être émises à destination du serveur de contrôle d'accès. Le serveur de contrôle d'accès 14 reçoit (23s) donc la liste d'au moins une ressource IP 15 associée au domaine client 11, transmise d'un noeud client du domaine client 11 au serveur de contrôle d'accès 14. Le serveur de contrôle d'accès 14 sélectionne (24s) au moins une ressource IP à valider parmi la liste. Eventuellement, le serveur de contrôle d'accès 14 transmet (25s) au noeud client Cl 111 la 20 ou les ressources IP sélectionnées. Le noeud client Cl 111 reçoit donc (26c) la ou les ressources IP sélectionnées par le serveur de contrôle d'accès 14. Le serveur de contrôle d'accès 14 vérifie (27s) ensuite la validité de ladite au moins une ressource IP sélectionnée. En d'autres termes, le serveur de contrôle d'accès vérifie si la ressource IP sélectionnée est effectivement associée au domaine client 11. 25 Les figures 3 et 4 illustrent deux modes de réalisation de l'invention. Le premier mode de réalisation permet de s'affranchir du fournisseur d'accès gérant le domaine client pour la validation des ressources IP associées à ce domaine client. Le deuxième mode de réalisation permet d'utiliser les équipements du fournisseur d'accès pour la validation des ressources IP associées à un domaine client, tout en préservant la confidentialité de l'identité du domaine 30 client. La figure 3 illustre les principales étapes du procédé de vérification de la validité de ressource IP selon le premier mode de réalisation. Selon ce mode de réalisation, la vérification (27s) de la validité de la ou des ressources IP 10 sélectionnées, mise en oeuvre par le serveur de contrôle d'accès 14, repose sur la transmission (31s) d'au moins une requête à destination de ladite ressource IP à valider, reçue ou interceptée par au moins un noeud relais du domaine client associé à ladite au moins une ressource IP sélectionnée, par exemple le noeud relais R1 112. Eventuellement, le noeud relais R1 112 et le 5 noeud client Cl 111 sont les mêmes. En variante, le noeud relais R1 112 et le noeud client Cl 111 sont deux noeuds distincts appartenant au même domaine. Similairement, le noeud client et le noeud relais peuvent être deux instances logicielles embarquées dans un même noeud physique. Plus précisément, la ressource IP sélectionnée peut être une adresse IP. Dans ce cas, le serveur de contrôle d'accès transmet la requête à destination de l'adresse IP. La ressource 10 sélectionnée peut également être un préfixe IP. Dans ce cas, le serveur de contrôle d'accès transmet la requête à destination d'une ou plusieurs adresses extraites de ce préfixe ; ces requêtes seront typiquement interceptées par le(s) routeur(s) de raccordement du domaine client à Internet. La ressource sélectionnée peut également être un nom de domaine. Dans ce cas, le serveur de contrôle d'accès peut mettre en oeuvre une procédure de résolution (par exemple, 15 DNS), pour obtenir l'adresse IP de l'entité gestionnaire du domaine associé (fournisseur d'accès). Une telle requête comporte un message ou des données de contrôle. En particulier, un tel message de contrôle peut être associé à toute information permettant d'identifier la requête de façon non-ambiguë. Notamment, ce message de contrôle ne doit pas être trivial pour éviter son usurpation. Par exemple, un tel message de contrôle est généré aléatoirement. 20 Le noeud relais R1 112 intercepte (32R) donc au moins une requête en provenance du serveur de contrôle d'accès 14, et comportant le message de contrôle. La requête peut être destinée directement au noeud relais si l'adresse de destination est allouée à la machine où réside le noeud relais. Le noeud relais R1 112 transmet (33R) la ou les requêtes au noeud client Cl 111, i.e., relaye 25 la ou les requêtes en provenance du serveur de contrôle d'accès 14. Le noeud client Cl 111 reçoit (34c) donc au moins une requête en provenance du serveur de contrôle d'accès, et comportant le message ou des données de contrôle, via au moins un noeud relais du domaine client associé à au moins une ressource IP, sélectionnée par le serveur de contrôle d'accès parmi la liste. 30 En particulier, si le noeud relais R1 112 et le noeud client Cl 111 sont deux noeuds distincts appartenant au même domaine, les échanges entre le noeud relais R1 112 et le noeud client Cl 111 peuvent être mis en oeuvre via une connexion sécurisée. Si le noeud relais R1 112 et le noeud client Cl 111 sont un même noeud, le noeud client Cl 11 111 reçoit directement la requête en provenance du serveur de contrôle d'accès 14, ou la requête est relayée en interne. Le noeud client Cl 111 répond en transmettant (35c) au serveur de contrôle d'accès 14 une réponse incluant une information caractéristique du message ou des données de contrôle. 5 Le serveur de contrôle d'accès 14 reçoit (36s) la réponse incluant l'information caractéristique du message de contrôle, en provenance du noeud client Cl 111. L'information caractéristique du message de contrôle peut être identique ou différente du message du contrôle. Le serveur de contrôle d'accès 14 effectue une corrélation (37s) de la requête et de la réponse, ou plus particulièrement des données de contrôle véhiculées dans la requête et de 10 l'information caractéristique des données de contrôle véhiculée dans la réponse, et valide ou non l'appartenance de la ressource IP sélectionnée au domaine client. On présente désormais, en relation avec la figure 4, les principales étapes du procédé de vérification de la validité de la ressource IP selon le deuxième mode de réalisation. Ce deuxième mode de réalisation fait intervenir un serveur de validation associé au 15 fournisseur d'accès, par exemple le serveur de validation V1 121 associé au premier fournisseur d'accès 12 du domaine client 11. Plus précisément, selon ce deuxième mode de réalisation, la vérification (27s) de la validité de la ou des ressources IP sélectionnées, mise en oeuvre par le serveur de contrôle d'accès 14, repose sur la réception (41s) d'une information représentative de l'identité du domaine client. 20 Par exemple, une telle information est représentative de l'identité du domaine client ou de l'entité qui gère le domaine client, comme un abonné à un service de connectivité. En particulier, une telle information est un condensé, ou « hash », de l'identité du domaine client 11 ou de l'entité qui gère le domaine client. Le serveur de contrôle d'accès S 14 met également en oeuvre l'identification (42s) d'au 25 moins un serveur de validation associé à la ou aux ressources IP sélectionnées à l'étape 24s, par exemple le serveur de validation V1 121. Enfin, le serveur de contrôle d'accès S 14 transmet (43s) au(x) serveur(s) de validation identifié(s) au moins une requête comportant d'une part l'information représentative de l'identité du domaine client et d'autre part la ou les ressources IP sélectionnées. Selon ce deuxième mode 30 de réalisation, la requête n'est donc pas envoyée à une adresse de destination extraite d'un préfixe IP ou d'une liste d'adresses IP à valider, mais à un serveur de validation. Eventuellement, une telle requête comporte un message de contrôle associé à toute information permettant d'identifier la requête de façon non-ambiguë. Comme pour le premier 12 mode de réalisation, un tel message de contrôle peut être généré aléatoirement. Le serveur de validation V 121, associé à au moins une ressource IP sélectionnée par le serveur de contrôle d'accès 14 parmi la liste d'au moins une ressource IP associée au domaine client (liste préalablement envoyée par le noeud client Cl 111 au serveur de contrôle d'accès S 5 14), reçoit (44v) la ou les requêtes comportant d'une part une information représentative de l'identité du domaine client, et d'autre part la ou les ressources IP sélectionnées. A partir de l'information représentative de l'identité du domaine client, le serveur de validation V 121 peut identifier (45v) le domaine client. Enfin, le serveur de validation V 121 peut vérifier (46v) l'association/appartenance de la 10 ou des ressources IP sélectionnées avec le domaine client, en tenant compte de l'identité du domaine client. Préalablement à la mise en oeuvre de la vérification (27s) de la validité de la ou des ressources IP sélectionnées par le serveur de contrôle d'accès 14, le serveur de validation V1 121 peut mettre en oeuvre la détermination (401v) d'une information représentative de l'identité du 15 domaine client 11, directement ou sur requête d'un client du domaine client. Comme indiqué ci- dessus, une telle information est représentative de l'identité du domaine client ou de l'entité qui gère le domaine client, et peut prendre par exemple la forme d'un condensé de l'identité du domaine client 11. Le serveur de validation V1 121 transmet (402v) au domaine client 11, par exemple au 20 noeud client Cl 111, l'information représentative de l'identité du domaine client. Le noeud client Cl 111 reçoit (403c) donc l'information représentative de l'identité du domaine client de la part du serveur de validation attaché au domaine client 11, et peut la transmettre (404c) au serveur de contrôle d'accès 14, directement ou sur requête du serveur de contrôle d'accès 14. 25 On note que ces étapes préalables de détermination 401v et de transmission 402v / réception 403c d'une information représentative de l'identité du domaine client 11 peuvent être mises en oeuvre lors d'une phase d'initialisation, ou lorsqu'un domaine client 11 est raccordé à un réseau activant un serveur de validation, ou lorsqu'une procédure de mitigation est déclenchée, etc. 30 5.2 Exemples d'application dans le domaine des services de mitigation (DPS) On décrit ci-après des exemples de mise en oeuvre de l'invention dans une architecture de type DOTS, selon laquelle le noeud client Cl 111 est un client DOTS et le serveur de contrôle d'accès 5 14 est un serveur de contrôle d'accès DOTS, permettant au noeud client Cl 111 13 d'informer le serveur de contrôle d'accès S 14 que le domaine client subit une attaque DDoS et que des actions appropriées sont requises. Le noeud client Cl 111 et le serveur de contrôle d'accès S 14 peuvent ainsi communiquer via les canaux de signalisation et de données DOTS définis en relation avec l'art antérieur. 5 En particulier, au moins un mode de réalisation de l'invention peut être mis en oeuvre pour vérifier la validité des ressources IP associées à un domaine client lorsque les services de mitigation DPS ne sont pas hébergés au sein des infrastructures exploitées par le fournisseur d'accès raccordé au domaine client (i.e., si le serveur de contrôle d'accès DOTS n'est pas exploité par le fournisseur d'accès raccordé au domaine client), mais dans les infrastructures exploitées 10 par un autre fournisseur d'accès ou dans le « cloud ». 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 de contrôle d'accès DOTS, le serveur de contrôle d'accès 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 de 20 contrôle d'accès DOTS pour qu'il installe (ou fasse installer) une liste de contrôle d'accès (ACL pour « Access Control List »). Une requête DOTS peut être envoyée d'un client DOTS, appartenant à un domaine client DOTS, à un serveur de contrôle d'accès DOTS ou une pluralité de serveurs de contrôle d'accès DOTS. 25 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. Les communications DOTS entre un domaine client et un serveur de contrôle d'accès 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 contrôle 30 d'accès, ou des deux. En d'autres termes, un noeud du domaine client peut communiquer directement avec le serveur de contrôle d'accès, ou transmettre une requête à une passerelle du domaine client qui communique directement avec le serveur de contrôle d'accès ou avec une 14 passerelle du domaine serveur, ou transmettre une requête à une passerelle du domaine serveur qui communique avec le serveur de contrôle d'accès. Une passerelle DOTS localisée dans un domaine client est considérée par un serveur de contrôle d'accès DOTS comme un client DOTS. 5 Une passerelle DOTS localisée dans un domaine serveur est considérée par un client DOTS comme un serveur de contrôle d'accès 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 de contrôle d'accès DOTS peut être configuré avec la liste des passerelles DOTS actives au sein de son domaine et le serveur de contrôle d'accès peut déléguer 10 certaines de ses fonctions à ces passerelles de confiance. En particulier, le serveur de contrôle d'accès peut utiliser en toute sécurité les informations fournies par une passerelle figurant dans une liste déclarée auprès du serveur de contrôle d'accès 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 contrôle d'accès, récupération de la liste auprès d'un 15 serveur 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 20 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 : 25 - « Datagram Transport Layer Security Version 1.2 », Rescorla E. et al., RFC 6347, DOI 10.17487/RFC6347, janvier 2012, - « The Datagram 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, 30 DOI 10.17487/RFC5246, août 2008, et - « The Transport Layer Security (TLS) Protocol Version 1.3 », Rescorla E., draft-ietf-tlstls13-23, janvier 2018. 15 Dans la suite, on suppose que les agents DOTS (client(s), serveur(s) de contrôle d'accès) s'authentifient mutuellement. Il existe donc un canal de communication sécurisé, par exemple de type (D)TLS, entre un client DOTS et un serveur de contrôle d'accès DOTS. Ainsi, les messages reçus d'un autre serveur usurpant l'identité du serveur de contrôle 5 d'accès légitime peuvent être rejetés par un client DOTS. De la même manière, les demandes des clients DOTS non-autorisés à accéder au service de mitigation peuvent être ignorées par le serveur de contrôle d'accès 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 10 l'authentification mutuelle des agents DOTS, ne font pas l'objet de la présente invention et ne 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 à la figure 2. On considère à titre d'exemple que le noeud client 111 de la figure 1 est un client DOTS et que le serveur de contrôle d'accès 14 de la figure 1 est un 15 serveur DOTS. Le domaine client est donc un domaine DOTS. 5.2.2 Déclaration de la liste des ressources IP associées à un domaine client En référence à la figure 2, le client DOTS obtient (21c) une liste d'au moins une ressource IP associée au domaine DOTS, puis la transmet (22c) à un ou plusieurs serveur(s) de contrôle d'accès DOTS, par exemple en utilisant les canaux de communication DOTS de données ou de 20 signalisation. Un client DOTS peut donc déclarer au serveur de contrôle d'accès DOTS les ressources IP qu'il gère, ou plus généralement les ressources IP qui sont associées au domaine client DOTS. Un avantage d'une telle déclaration de ressources IP est qu'elle permet de déclencher la vérification de la validité des ressources IP associées sans attendre la réception d'une requête 25 DOTS et donc sans attendre qu'une attaque soit en cours. De ce fait, les messages de signalisation transmis du client DOTS vers le serveur de contrôle d'accès DOTS pour solliciter la mitigation d'une attaque de déni de service peuvent être traités rapidement. Comme déjà indiqué, les ressources IP peuvent être des adresses IP, des préfixes IP ou des noms de domaine. Les noms de domaine peuvent être résolus en des adresses IP. Les préfixes IP 30 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). Les préfixes IP ne sont pas obligatoirement contigus, ni gérés par un même fournisseur d'accès. De plus, ces 16 préfixes peuvent être des préfixes de type PA (en anglais « Provider Assigned »), c'est-à-dire des préfixes détenus par le fournisseur de service, ou des préfixes de type PI (en anglais « Provider Independent »), c'est-à-dire des préfixes alloués à la demande d'un client, par exemple par un organisme de type registre régional Internet (« Regional Internet Registry », ou RIR en anglais), 5 indépendamment du fournisseur d'accès. On décrit ci-après, en relation avec la figure 5, les principales étapes mises en oeuvre par le client DOTS pour la déclaration de ressources IP associées à un domaine DOTS. Au cours d'une étape d'initialisation 510 des canaux de communication sécurisée entre le client DOTS et un ou plusieurs serveur(s) de contrôle d'accès DOTS sont établis. 10 Au cours d'une étape d'obtention 52c, similaire à l'étape 210 le client DOTS obtient la liste des ressources IP qu'il gère, ou plus généralement, la liste des ressources IP associées à son domaine (client) DOTS. Au cours d'une étape de transmission 53e, similaire à l'étape 22c, le client DOTS déclare la liste des ressources IP, en la transmettant à un ou plusieurs serveur(s) de contrôle d'accès DOTS. 15 Au cours d'une étape de mise à jour 54c, le client DOTS vérifie la validité des entrées de la liste ou découvre de nouvelles ressources. Cette étape de mise à jour peut être mise en oeuvre périodiquement, et/ou à chaque ajout, modification, suppression d'une ressource IP associée au domaine. Une fois la liste mise à jour, la liste est de nouveau transmise au serveur de contrôle d'accès DOTS selon l'étape de transmission 53c. Cette transmission peut être mise en oeuvre 20 périodiquement ou dès qu'une mise à jour de la liste est effectuée. Lors de la transmission de la liste de ressources IP au(x) serveur(s) de contrôle d'accès, le client DOTS peut indiquer la durée de validité associée à cette liste, ou à certaines ressources IP de cette liste, par exemple dans un champ « Lifetime ». Une telle durée de validité s'exprime par exemple en minutes. 25 Si le client ne renouvelle pas sa déclaration/liste avant l'expiration de la durée de validité définie dans la requête de déclaration initiale, le serveur de contrôle d'accès DOTS peut procéder automatiquement au retrait de la ou des ressource(s) IP associée(s) de ses tables de préfixes/ressources actifs pour ce client/domaine client. Par exemple, le champ « Lifetime » peut indiquer la valeur « -1 » pour signaler une durée 30 de validité indéfinie. Comme illustré en figure 6A, des requêtes distinctes peuvent être émises par le client DOTS pour déclarer au(x) serveur(s) de contrôle d'accès chacune des ressources IP associées au domaine DOTS du client DOTS (une première requête pour déclarer l'adresse « 1.2.3.4 » et une 17 deuxième requête pour déclarer l'adresse « 11.22.33.44 » par exemple). Optionnellement, comme illustré en figure 6B, une unique requête peut être émise pour déclarer toutes les ressources IP associées au domaine DOTS du client DOTS (une unique requête pour déclarer l'adresse « 1.2.3.4 » et l'adresse « 11.22.33.44 » par exemple). 5 Si plusieurs clients DOTS sont déployés dans un même domaine, la déclaration de ressources IP peut être effectuée par un seul ou plusieurs clients. En d'autres termes, les déclarations sont, par défaut, associées au domaine et non pas à un client DOTS. Un serveur de contrôle d'accès DOTS est capable d'identifier les clients DOTS d'un même domaine. Pour ce faire, le serveur de contrôle d'accès DOTS s'appuie sur les clés de sécurité 10 utilisées pour l'authentification, telles que par exemple les informations de clé publique SPKI (« Subject Public Key Information ») d'un certificat associé au client DOTS (par exemple le certificat X.509, tel que défini dans le document RFC 5280 intitulé « Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile », D. Cooper et al., Mai 2008 ), ou les identifiants de clé partagée PSK (« PSK Identity ») utilisés par les clients lors de la 15 procédure d'authentification (« TLS ClientKeyExchange »). On présente ci-après un exemple de programme pour la déclaration du préfixe « 1.2.3.0/24 » d'un client DOTS à son serveur de contrôle d'accès DOTS. Le message « POST» est utilisé à des fins d'illustration, mais d'autres messages peuvent bien sûr être utilisés (par exemple « HTTP PUT ») : 20 POST /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=mydotsclient HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:prefixes ": { "prefix-list": [ { "name": "my first prefix", "prefix": "1.2.3.0/24", "lifetime": 1504 25 30 18 Comme indiqué ci-dessus, la liste de ressources IP associées au domaine client peut être mise à jour régulièrement et/ou à chaque ajout/modification/suppression d'une ressource IP associée au domaine client. Selon un premier exemple, des opérations d'acquisition peuvent donner lieu à 5 l'attribution et à l'utilisation de nouvelles ressources IP, par exemple de nouveaux préfixes qui sont gérés par un client DOTS actif. Le client DOTS peut déclarer de tels nouveaux préfixes. Pour ce faire, le client DOTS peut par exemple envoyer un message POST. Selon un deuxième exemple, un client DOTS peut également mettre à jour la liste des ressources IP en retirant celles qui ne sont plus valides (par exemple, un préfixe qui n'est plus 10 délégué par le réseau d'accès, ou dont la durée de validité a expiré). Dans ce cas, le client DOTS peut supprimer la ou les ressources IP qui ne sont plus valides sans attendre l'expiration de la date de validité indiquée lors de la déclaration. On présente ci-après un exemple de programme pour la suppression du préfixe « my_first_prefix » par un client DOTS. A nouveau, le message « POST» est utilisé à des fins 15 d'illustration, mais d'autres messages peuvent bien sûr être utilisés (par exemple « HTTP PUT ») : DELETE /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=mydotsclient /prefixes/prefix-list=my first prefix HTTP/1.1 Host: {host}:{port} 20 5.2.3 Sélection des ressources IP à valider par un serveur de contrôle d'accès DOTS Une fois les ressources IP associées à un domaine déclarées par le client DOTS auprès d'un serveur de contrôle d'accès DOTS, le serveur de contrôle d'accès DOTS peut vérifier que les ressources déclarées sont effectivement associées au domaine client déclarant. Pour ce faire, le serveur de contrôle d'accès DOTS peut sélectionner une ou plusieurs 25 ressources IP à valider parmi la liste (étape 24s en référence à la figure 2), puis appliquer une procédure de vérification à chacune des ressources IP sélectionnées. Eventuellement, la procédure de vérification s'applique à d'autres entrées maintenues par le serveur de contrôle d'accès (par exemple, des entrées de filtrage, ou des entrées d'autres clients appartenant au même domaine). 30 En particulier, généraliser la procédure de vérification aux autres types d'entrées maintenues par un serveur de contrôle d'accès est intéressante pour les clients ne supportant pas la procédure de déclaration de ressources IP. Il est en effet possible de vérifier ainsi la validité des ressources IP gérées par un client qui n'est pas apte à mettre en oeuvre la procédure de 19 déclaration de ressources IP, si un autre client du domaine a préalablement déclaré l'ensemble des ressources IP associées à ce domaine. On présente ci-après différents exemples de sélection des ressources IP à valider par un serveur de contrôle d'accès DOTS : 5 - le serveur de contrôle d'accès DOTS peut exécuter systématiquement la procédure de vérification dès la réception d'une déclaration d'un client, ou durant la durée de validité des règles de filtrage ou de signalisation, ou les deux ; - le serveur de contrôle d'accès DOTS peut mettre en oeuvre la procédure de vérification de façon périodique pour demander aux clients DOTS de confirmer la 10 validité des règles de filtrage, particulièrement les adresses de destination renseignées dans les règles de filtrage ; - le serveur de contrôle d'accès peut sélectionner tout ou partie des entrées à valider ; pour ce faire, le serveur de contrôle d'accès exécute une procédure de sélection, telle que mode aléatoire, sélection des entrées ayant dépassé une certaine durée de vie 15 (tout en restant théoriquement valides en vertu de la valeur du paramètre « Lifetime » allouée par le serveur de contrôle d'accès lors de la création de l'entrée), etc.; - le serveur de contrôle d'accès DOTS peut mettre en oeuvre la procédure de vérification sur détection de conflit entre les adresses de destination indiquées par 20 des clients appartenant à des domaines DOTS distincts. Selon ce dernier exemple, illustré en figure 7, un serveur de contrôle d'accès DOTS peut détecter un conflit d'adresses entres plusieurs domaines en comparant le ou les préfixes de destination indiqués dans les requêtes DOTS. Par exemple, un premier client Cl, appartenant à un premier domaine 71, indique l'adresse de destination « 1.2.3.4/32 » dans une requête DOTS, alors 25 que cette adresse est couverte par la demande d'un deuxième client C2, appartenant à un deuxième domaine 72, pour le préfixe « 1.2.3.0/24 ». Comme les deux clients Cl et C2 n'appartiennent pas au même domaine, le serveur de contrôle d'accès S peut détecter un conflit entre les adresses de destination et ne sélectionner aucune adresse de destination comme « ressource IP à valider ». 30 5.2.4 Validation des ressources IP sélectionnées Une fois les ressources IP à valider sélectionnées par le serveur de contrôle d'accès DOTS, le serveur de contrôle d'accès DOTS met en oeuvre une vérification de la validité de la ou des ressources sélectionnées (étape 27s en référence à la figure 2). 20 Selon au moins un mode de réalisation, le serveur de contrôle d'accès DOTS peut au préalable, ou simultanément à la procédure de vérification, supprimer les entrées DOTS indiquant des ressources IP ne faisant pas partie de la liste déclarée par un client DOTS. Ainsi, comme illustré en figure 8, si le client Cl déclare l'adresse « 1.2.3.4 » au serveur de contrôle d'accès S, et 5 que les entrées DOTS contiennent les adresses « 1.2.3.4 » et « 11.2.3.4 », le serveur de contrôle d'accès détecte une anomalie dans les règles de filtrage associées au client Cl et peut procéder à la suppression des entrées correspondantes de ses tables. Optionnellement, le serveur de contrôle d'accès peut envoyer une notification au client pour rendre compte de l'opération de nettoyage. 10 De la même façon, les requêtes DOTS indiquant une ressource IP ne faisant pas partie des ressources IP déclarées peuvent être rejetées par le serveur de contrôle d'accès, préalablement ou simultanément à la procédure de vérification. Ainsi, comme illustré en figure 9, si le client Cl déclare l'adresse 1.2.3.4 auprès du serveur de contrôle d'accès S, et que le serveur de contrôle d'accès reçoit une demande de signalisation/mitigation sur l'adresse « 15.45.45.78 », le serveur 15 de contrôle d'accès peut refuser la demande de signalisation car l'adresse indiquée comme cible de l'attaque dans la demande ne figure pas dans la liste des ressources IP déclarées par le client Cl ou les clients appartenant au même domaine client. On présente ci-après deux modes de réalisation pour la mise en oeuvre de la procédure de vérification, consistant à vérifier la validité de la ou des ressources sélectionnées (étape 27s en 20 référence à la figure 2). Le premier mode de réalisation, dit « DOTS probing », dont les principales étapes sont illustrées en figure 3, permet de s'affranchir du fournisseur d'accès pour la validation des ressources IP. Le deuxième mode de réalisation, dit « Cooperating DOTS/1SPs », dont les principales étapes sont illustrées en figure 4, permet de traiter les données maintenues par un 25 fournisseur d'accès sans porter atteinte à la vie privée des clients. On décrit ci-après plus en détail le premier mode de réalisation (« DOTS probing »). Selon ce premier mode de réalisation, au moins un noeud du domaine client active une fonction « DOTS_CHECK_RELAY » permettant d'inspecter le trafic entrant et de le rediriger vers un noeud client. Un tel noeud est appelé « noeud relais » par la suite. 30 Plusieurs noeuds du domaine client disposant de la fonction « DOTS_CHECK_RELAY » peuvent être sollicités. Par exemple, un domaine client raccordé au réseau Internet via plusieurs liens (contexte de « Multi-homing ») peut activer la fonction « DOTS_CHECK_RELAY » sur tous les noeuds le raccordant au réseau Internet. 21 Un client DOTS peut cohabiter avec la fonction « DOTS_CHECK_RELAY ». En d'autres termes, un noeud client peut activer la fonction « DOTS_CHECK_RELAY », par exemple lorsque le client DOTS est embarqué dans un routeur de raccordement au réseau tel qu'une passerelle résidentielle (« Customer Premises Equipment », ou CPE en anglais). Le noeud client est alors un 5 noeud relais. Dans ce cas, le client DOTS est avantageusement situé sur le chemin de tout le trafic destiné au domaine client. On suppose dans la suite qu'un client DOTS dispose de la liste des noeuds relais activant la fonction « DOTS_CHECK_RELAY ». Cette liste de relais peut contenir un ou plusieurs relais, et peut être déclarée explicitement au client (configuration statique) ou fournie de manière dynamique 10 (par exemple, en utilisant les ressources d'une option DHCP). Il n'est en revanche pas nécessaire de communiquer une telle liste de relais au serveur de contrôle d'accès. En plus d'une ou plusieurs adresse(s) pour joindre un noeud relais et des informations de sécurité (par exemple, jeton d'authentification destiné à vérifier que le client DOTS est habilité à communiquer avec un noeud relais), des informations supplémentaires peuvent être renseignées comme, par exemple, 15 le numéro de port d'écoute du service ou la liste de ressources IP gérées par un noeud relais. Si aucune précision concernant les ressources IP n'est fournie pour un relais de la liste de relais, alors un client DOTS peut utiliser ce relais pour toutes les ressources IP associées au domaine. On décrit ci-après plus en détail la fonction « DOTS_CHECK_RELAY ». 20 La fonction « DOTS_CHECK_RELAY » peut être : un module logiciel dédié au service DOTS, une fonction de capture de trafic activée sur un noeud du domaine client, par exemple un des routeurs de raccordement du domaine client au réseau Internet. Selon un mode de réalisation particulier, la communication entre les relais activant la 25 fonction « DOTS_CHECK_RELAY » et les clients DOTS du domaine peut être sécurisée. Par exemple, un relais activant la fonction « DOTS_CHECK_RELAY » peut communiquer des informations ou recevoir de demandes vers/les clients de confiance dûment habilités. Ainsi, comme illustré en figure 10, les messages provenant des clients Cl et Cm du domaine client 11 sont autorisés par les relais R1 et Ri, alors que les messages provenant d'un 30 client usurpateur « F_C » sont rejetés par les relais R1 et Ri. Selon un mode de réalisation particulier, la fonction « DOTS_CHECK_RELAY » peut être activée à la demande. Selon ce mode, l'activation de cette fonction est contrôlée par au moins un client DOTS du domaine. La fonction est activée pendant une durée limitée ; elle est ensuite 22 désactivée. Ce mode est utilisé de préférence pour associer une adresse ou un préfixe temporaire au relais activant cette fonction. Selon un autre mode de réalisation, la fonction « DOTS_CHECK_RELAY » peut être activée de façon permanente. Selon ce mode, la fonction « DOTS_CHECK_RELAY » peut être réalisée 5 grâce à la réutilisation des fonctions de capture de trafic. Ce mode est utilisé de préférence quand le noeud relais activant la fonction « DOTS_CHECK_RELAY » est situé sur un chemin qui permet d'acheminer tout ou partie du trafic destiné au domaine client (par exemple un routeur de raccordement au réseau Internet, tel qu'un CPE). L'utilisation d'adresses/préfixes temporaires n'est pas nécessaire pour ce mode. 10 On décrit ci-après la procédure de vérification selon le premier mode de réalisation (« DOTS probing »). Comme indiqué précédemment en relation avec la figure 2, le serveur de contrôle d'accès reçoit (23s) une liste d'au moins une ressource IP associée au domaine client, et sélectionne (24s), parmi la liste, une ou plusieurs ressources IP à valider. On note que le contenu de cette liste peut 15 varier au cours du temps, puisque la liste peut être mise à jour (étape 54c de la figure 5). Par exemple, sur identification d'une entrée DOTS à valider par le serveur de contrôle d'accès, ce dernier extrait des préfixes de destination associés. Optionnellement, le serveur de contrôle d'accès communique la liste des ressources IP (ou les préfixes/adresses IP associées) ainsi sélectionnées au client (étape 25s de la figure 2). Par 20 exemple, une telle liste peut être communiquée au client dans le cas du déploiement d'un module logiciel dédié au service DOTS qui exploite, par exemple, les techniques de virtualisation pour instancier dynamiquement des fonctions service (mode « à la demande » ci-dessus). En particulier, ces fonctions service peuvent être configurées pour intercepter le trafic destiné à au moins une des adresses communiquées par le serveur de contrôle d'accès DOTS. 25 Selon un mode de réalisation particulier, le client peut configurer la ou les fonctions « DOTS_CHECK_RELAY » conformément aux instructions du serveur de contrôle d'accès. Eventuellement, le client peut informer le serveur de contrôle d'accès que le domaine client est prêt pour traiter les messages de validation des ressources IP. Une fois les ressources IP à valider sélectionnées par le serveur de contrôle d'accès, le 30 serveur de contrôle d'accès peut mettre en oeuvre la vérification (27s) de la validité de la ou des ressources IP sélectionnées, ou des adresses/préfixes associés. Pour ce faire, selon ce premier mode de réalisation (« DOTS Probing »), le serveur de contrôle d'accès envoie des requêtes ayant comme adresse de destination ladite adresse à valider 23 (i.e., une adresse extraite d'une ressource IP sélectionnée), et interceptées par le(s) noeud(s) relais identifié(s) (étape 31s de la figure 3). Par exemple, des messages de validation « DOTS_PROBE_REQUEST » sont transmis à chacune des adresses de la liste des ressources IP sélectionnées. 5 Le serveur de contrôle d'accès peut procéder à l'envoi des messages de validation « DOTS_PROBE_REQUEST » dès que les ressources IP à valider sont sélectionnées, ou après un certain délai, ou à réception d'un message du client, par exemple un message de confirmation de réception lorsque le serveur de contrôle d'accès communique la liste des ressources IP sélectionnées au client (25s). 10 L'envoi de tels messages aux noeuds identifié(s) par la ou les ressources IP sélectionnées peut être effectué successivement ou simultanément. En particulier, on note que de tels messages de validation comportent un message de contrôle associé à toute information permettant d'identifier le message de validation de façon non-ambiguë. 15 Par exemple, le serveur de contrôle d'accès DOTS génère des messages « DOTS_PROBE_REQUEST » avec des charges utiles aléatoires pour éviter que les clients suspects ne devinent facilement les messages et n'envoient des réponses usurpées. Ainsi, à titre d'exemples, le serveur de contrôle d'accès peut : insérer un ou plusieurs identifiants uniques, tels que des identifiants de type UUID - 20 Universally Unique Identifier - version 4 (tels que décrits dans le document RFC 4122 «A Universally Unique IDentifier (UUID) URN Namespace » P. Leach, juillet 2005), générés d'une manière aléatoire : 1. 263afd79-835c-4ee7-9535-df245cf28d9a 2. 246813cd-2bf3-46a9-ad1e-b4bb0f356189 25 3. 730d0839-0267-4216-8b62-66844bb30711 4. 61319aa3-555d-445c-891842e9cfd67e06 calculer un ou plusieurs condensés qu'il insère dans le message « DOTS_PROBE_REQUEST », tels que des condensés SHA-256 : 1. bd10ab3db20f6830feb53a8f295013e2934cdc674c32343341445082a73830f7 30 2. 00ba021fe38dc12cOceefd709be9a2d08c8ebea3f231c785f25d03623ee566c5 3. b9c8740f9a4f59c3311f2b027d055dfdd7ba3184754e7451ed649e05cc779385 4. b9e44df1b5f0dc788a068225f422b7cf1b4858b62188a47b7504fe202c25e973 24 - utiliser une technique pour assurer l'intégrité et l'authenticité du message de contrôle, par exemple de type AEAD « Authenticated Encryption with Associated Data », tel que décrit dans le document RFC5116 : «An Interface and Algorithms for Authenticated Encryption », D. McGrew, janvier 2008; 5 - utiliser toute autre procédure de génération aléatoire, telle que celles spécifiées dans le document RFC4086 intitulé « Randomness Requirements for Security », D. Eastlake, janvier 2005; - utiliser un fichier aléatoire (par exemple une image) ; - etc. 10 Par exemple, la génération d'un message de validation « DOTS_PROBE_REQUEST » par le serveur de contrôle d'accès DOTS comprend : - la génération de paquets avec des données aléatoires (données de contrôle) ; - la définition de l'adresse de destination (adresse du noeud relais identifié par la ressource IP sélectionnée) ; 15 - le maintien d'un état caractéristique de la transmission desdits paquets avec des données aléatoires ; - l'envoi du message (31s) au relais identifié par la ressource IP sélectionnée. Un même message peut être transmis plusieurs fois, notamment dans le cas où l'un des messages a été détruit lors de son acheminement vers sa destination. 20 Si l'adresse de destination extraite de la ressource IP sélectionnée n'est pas associée au domaine client, deux cas sont à considérer par le serveur de contrôle d'accès : - soit le serveur de contrôle d'accès reçoit un message d'erreur (via le protocole ICMP, par exemple) ; - soit le serveur de contrôle d'accès ne reçoit aucune réponse. 25 Dans les deux cas, le serveur de contrôle d'accès peut conclure que l'adresse associée au message DOTS_PROBE_REQUEST n'est pas légitiment associée au client DOTS. Le serveur de contrôle d'accès peut ainsi procéder à l'invalidation des entrées correspondantes dans ses tables. D'autres actions peuvent être entreprises, par exemple, bloquer le client DOTS ayant indiqué cette adresse/préfixe. 30 Si l'adresse de destination est effectivement associée au domaine client, alors au moins un relais du domaine peut intercepter le ou les messages DOTS_PROBE_REQUEST (étape 32R de la figure 3). Ces messages peuvent être explicitement destinés au relais (mode à la demande) ou aux relais ayant une adresse du domaine. Dans les deux cas, ces messages doivent être relayés (33R) 25 vers le client DOTS. De préférence, le contenu du message DOTS_PROBE_REQUEST n'est pas modifié par le relais. A réception (34c) du message DOTS_PROBE_REQUEST par le client, le client DOTS envoie (35c) une réponse DOTS_PROBE_REPLY vers le serveur de contrôle d'accès. De préférence, le 5 contenu du message n'est pas modifié par le client. En particulier, la réponse comporte une information caractéristique du message de contrôle. A réception (36s) du message DOTS_PROBE_ REPLY par le serveur de contrôle d'accès, le serveur de contrôle d'accès corrèle (37s) la réponse (DOTS_PROBE_REPLY) avec la requête (DOTS_PROBE_REQUEST) pour vérifier l'authenticité et l'intégrité du message. 10 Si la corrélation s'est déroulée avec succès, la ressource IP associée est validée. Par exemple, le traitement d'un message de réponse « DOTS_PROBE_REPLY » par le serveur de contrôle d'accès DOTS comprend : - la vérification que l'émetteur du message est un client DOTS légitime : si ce n'est pas le cas, la ressource IP correspondante est écartée ; 15 - l'extraction du contenu du message de réponse (message de contrôle ou information caractéristique du message de contrôle) ; - le contrôle de l'intégrité du contenu du message : si le contenu du message n'est pas corrélé avec le message de contrôle, la ressource IP correspondante est écartée ; - la vérification du contenu des tables : si la ressource IP ne correspond à aucune des 20 entrées de la table maintenue par le serveur de contrôle d'accès, alors cette ressource IP correspondante est écartée ; - la validation de la ressource IP correspondante. De telles étapes peuvent être réitérées pour toutes les adresses sélectionnées et qui doivent être validées. 25 Les figures 11 à 15 présentent des exemples de mise en oeuvre de la procédure de vérification selon ce premier mode de réalisation (« DOTS Probing »). La figure 11 illustre un exemple de validation réussie de toutes les ressources IP associées à un client DOTS. On suppose dans cet exemple que le serveur de contrôle d'accès 14 informe le client de la liste des adresses sélectionnées à valider (25s), par exemple les adresses P1 à Pi. On 30 rappelle que cette étape est optionnelle. Sur réception (26c) de cette liste, le client DOTS procède à la configuration (« Setup ») des relais nécessaires pour qu'ils se tiennent prêts à recevoir les messages de validation DOTS_PROBE_REQUEST. Un message de confirmation « ACK » peut être envoyé par le client DOTS au serveur de contrôle d'accès pour indiquer que le domaine client est 26 prêt. Ensuite, le serveur de contrôle d'accès peut envoyer (31s) des messages de validation DOTS_PROBE_REQUEST vers le ou les relais pour chacune des adresses à valider. Ces messages sont relayés (33R) avec succès par les relais R1,... ,Ri vers le client DOTS. Ce dernier transmet (35c) alors les messages DOTS_PROBE_REPLY vers le serveur de contrôle d'accès DOTS. Ce dernier 5 vérifie l'intégrité du contenu du message et, après consultation de ses tables, valide les adresses. Ces adresses sont associées à ce domaine pour une période configurable sur le serveur de contrôle d'accès. L'état des adresses P1 à Pi est donc « validé ». La figure 12 illustre un autre exemple de validation réussie de toutes les ressources IP associées à un client DOTS. Selon ce deuxième exemple, les messages de validation 10 DOTS_PROBE_REQUEST sont transmis (31s) à un même relai et sans notification préalable au client. L'état des adresses P1 à Pi est également « validé ». La figure 13 illustre un exemple de succès partiel de validation d'adresses. Seule l'adresse P1 est validée alors que l'adresse Pi ne l'est pas. L'état de l'adresse P1 est donc « validé » alors que l'état de l'adresse à Pi est « non-validé ». 15 En particulier, on note que si aucune réponse n'est reçue de la part du client, ou si la réponse reçue n'a pas été validée, le serveur de contrôle d'accès conclut que cette ressource IP n'est pas associée à ce domaine client DOTS. Il procède ainsi à la suppression de ladite adresse dans ses tables. La figure 14 illustre un exemple d'échec de validation d'adresses, dans le cas où le serveur 20 de contrôle d'accès ne reçoit pas de réponses aux messages DOTS_PROBE_REQUEST. L'état des adresses P1 et Pi est donc « non-validé ». La figure 15 illustre un autre exemple selon lequel un client génère des messages de réponse DOTS_PROBE_REPLY pour simuler que des relais de son domaine ont effectivement reçu les messages de validation DOTS_PROBE_REQUEST. Ces messages DOTS_PROBE_REPLY ne sont 25 pas validés par le serveur de contrôle d'accès, car les charges utiles des messages DOTS_PROBE_REQUEST et DOTS_PROBE_REPLY ne sont pas corrélées. On décrit désormais le deuxième mode de réalisation (« Cooperating DOTS/ISPs ») pour la vérification de la validité de la ou des ressources sélectionnées (étape 27s en référence à la figure 2). 30 Ce deuxième mode de réalisation consiste à solliciter les fournisseurs d'accès pour vérifier qu'une adresse ou un préfixe déclaré par un client DOTS est effectivement alloué par ce fournisseur à ce client. Ce mode suppose que les fournisseurs d'accès exposent une interface de programmation (API) pour proposer à des tiers des services à valeur ajoutée telle que la validation 27 de ressources IP. Aussi, et afin de préserver la confidentialité des données des clients, certaines informations ne sont pas divulguées à ces tiers, ou alors seulement sur accord explicite des clients. De plus, et afin d'éviter l'usurpation des données, les informations des clients ne sont pas transmises aux tiers. 5 Les étapes de réception (23s), par le serveur de contrôle d'accès, d'une liste d'au moins une ressource IP associée au domaine client, de sélection (24s) d'au moins une ressource IP à valider parmi la liste, et optionnellement de transmission (25s) de la ou des ressources IP sélectionnées à valider aux clients DOTS, sont également mises en oeuvre selon ce deuxième mode de réalisation, et sont similaires à celles mises en oeuvre selon le premier mode de 10 réalisation. L'étape de vérification (27s) de la validité de la ou des ressources IP sélectionnées fait quant à elle intervenir un ou plusieurs serveurs de validation. Plus précisément, comme illustré en figure 4, le serveur de contrôle d'accès reçoit (41s), selon ce deuxième mode de réalisation, une information représentative de l'identité du domaine 15 client ou de l'entité qui gère le domaine client. Par exemple, le serveur de contrôle d'accès DOTS récupère l'identité du ou des fournisseur(s) propriétaire(s) de la ressource IP. De telles informations peuvent en effet être disponibles publiquement. Pour ce faire, le serveur de contrôle d'accès interroge par exemple la base des Réseaux IP Européens (RIPE). 20 Un exemple de requête utilisant les ressources de la base RIPE pour récupérer l'identité du domaine client ou de l'entité qui gère la ressource IP « 80.12.102.157 » du domaine client est donné ci-après : https://apps.db.ripe.net/db-web-ui \ /#/query?searchtext=80 . 12 .102 .157#resultsSection 25 Comme indiqué ci-dessus, ce deuxième mode de réalisation suppose que les fournisseurs d'accès exposent une interface de programmation (API) pour la validation de ressources IP, par exemple dans un ou plusieurs serveurs de validation hébergés par ces fournisseurs d'accès. Les adresses des serveurs de validation sont aussi accessibles/disponibles pour les clients de ces fournisseurs d'accès. 30 Si les fournisseurs d'accès exposent ladite API pour la validation de ressources IP, et si la base RIPE est modifiée pour renseigner le/les serveur(s) de validation, la réponse à cette requête indique que la ressource IP « 80.12.102.157 » est allouée, selon cet exemple, au fournisseur 28 d'accès « Orange S.A. », et que le ou les serveur(s) de validation pour cette ressource IP sont localisés par les adresses « 80.12.102.15 » et « 80.12.102.16 ». Un exemple de réponse à la requête est donné ci-après : Responsible organisation: Orange S.A. 5 inetnum: 80.12.102.144 - 80.12.102.159 validation server (s) : 80.12.102.15, 80.12.102.16 netname: VISION descr: France Telecom NDC country: FR 10 admin-c: FT09-RIPE tech-c: FT09-RIPE status: ASSIGNED PA mnt-by: FT-BRX created: 2014-11-20T10:56:45Z 15 last-modified: 2018-02-09T15: 00:11Z source: RIPE On présente ci-après plus en détail les étapes mises en oeuvre pour valider une ressource IP sélectionnée. Le serveur de contrôle d'accès DOTS communique (25s) au client DOTS, de façon 20 optionnelle, la ressource IP sélectionnée, ou la liste des ressources IP sélectionnées. Le serveur de contrôle d'accès DOTS identifie (42s) également le propriétaire de la ressource et au moins un serveur de validation associé. Une fois la liste reçue (26c) par le client DOTS, ce dernier établit une communication sécurisée avec un serveur de validation géré par le fournisseur d'accès du client pour récupérer 25 une information représentative de l'identité du domaine client ou de l'entité qui gère le domaine client. Par exemple, le serveur de validation détermine (401v) un condensé unique de l'identité du domaine client. Une durée de validité peut être affectée au condensé. Un tel condensé permet d'identifier d'une manière simple et non ambiguë un domaine client sans pour autant divulguer d'autres informations confidentielles concernant le client. 30 Par exemple, le serveur de validation peut générer un condensé correspondant à l'entité qui gère le domaine client dont l'identifiant est « 45979230632 » avec un horodatage « 2018-02- 08T00:00:11Z » selon la nomenclature « subscriber_45979230632_timestamp_2018-02- 08T00:00:11Z » : 29 f4b542f76be38153ecc66b7c4aaa87a04c46def8116d185c132e1c4a1f515203 Le client DOTS peut obtenir (403c) le condensé s'il est client du fournisseur d'accès hébergeant le serveur de validation. Si aucun condensé n'est reçu, la ressource IP n'est pas validée. 5 Ce/ces condensé(s) sont ensuite transmis (404c) au serveur de contrôle d'accès DOTS par le client. Sur réception (41s) du condensé, le serveur de contrôle d'accès DOTS envoie (43s) des messages de validation DOTS_PROBE_REQUEST vers les serveurs de validation R1,...,Ri. Ces messages comportent le condensé préalablement communiqué par le client, ainsi que la 10 ressource IP à valider. En l'absence de condensé, le serveur de contrôle d'accès ne peut pas identifier le client concerné, et la ressource IP n'est pas validée. Sur réception (44v) d'un message de validation par un serveur de validation Ri, ce dernier vérifie si la ressource IP à valider (adresse/préfixe) est effectivement allouée au client identifié par ledit condensé. 15 Si oui, la ressource IP est validée, sinon la ressource IP n'est pas validée. Un message de confirmation (DOTS_PROBE_REPLY) ou un message d'erreur peut être transmis au serveur de contrôle d'accès. La suite des opérations est similaire à celle du premier mode de réalisation « DOTS Probing ». 20 La figure 16 illustre un exemple de validation réussie de toutes les ressources IP associées à un client DOTS. On suppose dans cet exemple que le serveur de contrôle d'accès 14 informe le client de la liste des adresses sélectionnées à valider (25s), par exemple les adresses R1 à Ri. On rappelle que cette étape est optionnelle. Sur réception de cette liste, le client DOTS interroge les serveurs de validation V1 d'un premier fournisseur d'accès 12 et Vi d'un i-ème fournisseur d'accès 25 16, associés aux ressources IP R1, ..., Ri à valider, pour obtenir (403c) une information représentative de l'identité du domaine client, puis transmet (404c) cette information au serveur de contrôle d'accès. Ensuite, le serveur de contrôle d'accès peut envoyer (43s) des messages de validation DOTS_PROBE_REQUEST vers le ou les serveurs de validation, portant la ressource IP à valider et 30 l'information représentative de l'identité du domaine client. Le ou les serveurs de validation vérifient que la ressource IP portée par le message de validation DOTS_PROBE_REQUEST est effectivement associée au domaine identifié par 30 l'information représentative de l'identité du domaine client. Si tel est le cas, l'état des adresses R1 à Ri est donc « validé ». Eventuellement, le ou les serveurs de validation envoient une réponse DOTS_PROBE_REPLY vers le serveur de contrôle d'accès DOTS. 5 5.3 Structures On présente finalement, en relation avec la figure 17, les structures simplifiées d'un serveur de contrôle d'accès, d'un noeud client, d'un noeud relais et d'un serveur de validation selon l'un des modes de réalisation décrits ci-dessus. Selon un mode de réalisation particulier, un serveur de contrôle d'accès comprend une 10 mémoire 171s comprenant une mémoire tampon, une unité de traitement 172s, é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 173s, mettant en oeuvre des étapes du procédé de vérification de la validité d'une ressource IP selon un mode de réalisation de l'invention. 15 A l'initialisation, les instructions de code du programme d'ordinateur 173s sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 172s. Le processeur de l'unité de traitement 172s met en oeuvre des étapes du procédé de vérification de la validité d'une ressource IP décrit précédemment, selon les instructions du 20 programme d'ordinateur 173s, pour : - recevoir une liste d'au moins une ressource IP associée à un domaine client, transmise d'un noeud client du domaine client au serveur de contrôle d'accès ; - sélectionner au moins une ressource IP à valider parmi la liste ; - vérifier la validité de la ou des ressources IP sélectionnées. 25 Selon un mode de réalisation particulier, un noeud client comprend une mémoire 171c comprenant une mémoire tampon, une unité de traitement 172o é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 173o mettant en oeuvre des étapes du procédé de vérification de la validité d'une ressource IP selon un mode de réalisation de l'invention. 30 A l'initialisation, les instructions de code du programme d'ordinateur 173c sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 172c. Le processeur de l'unité de traitement 172c met en oeuvre des étapes du procédé de 31 vérification de la validité d'une ressource IP décrit précédemment, selon les instructions du programme d'ordinateur 173o pour : - obtenir une liste d'au moins une ressource IP associée au domaine client auquel appartient le noeud client ; 5 - transmettre la liste à un serveur de contrôle d'accès. Selon un mode de réalisation particulier, un noeud relais comprend une mémoire 171R comprenant une mémoire tampon, une unité de traitement 172R, é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 173R, mettant en oeuvre des étapes du procédé de 10 vérification de la validité d'une ressource IP selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 173R sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 172R. Le processeur de l'unité de traitement 172R met en oeuvre des étapes du procédé de 15 vérification de la validité d'une ressource IP décrit précédemment, selon les instructions du programme d'ordinateur 173R, pour : - recevoir au moins une requête comportant un message de contrôle, en provenance d'un serveur de contrôle d'accès, - transmettre la ou les requêtes à un noeud client du domaine client, 20 ledit noeud relais étant associé à au moins une ressource IP sélectionnée par le serveur de contrôle d'accès parmi une liste d'au moins une ressource IP associée au domaine client, la liste étant préalablement transmise d'un noeud client du domaine client au serveur de contrôle d'accès. En particulier, un tel noeud relais peut activer la fonction « DOTS_CHECK_RELAY » définie 25 précédemment. Selon un mode de réalisation particulier, un serveur de validation comprend une mémoire 171v comprenant une mémoire tampon, une unité de traitement 172v, é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 173v, mettant en oeuvre des étapes du 30 procédé de vérification de la validité d'une ressource IP selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 173v sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de 32 traitement 172v. Le processeur de l'unité de traitement 172v met en oeuvre des étapes du procédé de vérification de la validité d'une ressource IP décrit précédemment, selon les instructions du programme d'ordinateur 173v, pour : 5 - recevoir ou intercepter au moins une requête comportant une information représentative de l'identité d'un domaine client et d'au moins une ressource IP sélectionnée, - identifier le domaine client à partir de l'information représentative de l'identité du domaine client, - vérifier l'association de la ressource IP sélectionnée avec le domaine client en tenant 10 compte de l'identité REVENDICATIONS1. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en oeuvre dans un serveur, dit serveur de contrôle d'accès (14), ledit procédé comprenant : - la réception (23s) d'une liste d'au moins une ressource IP associée audit domaine client, transmise d'un noeud client (111) dudit domaine client audit serveur de contrôle d'accès (14) ; - la sélection (24s) d'au moins une ressource IP à valider parmi ladite liste ; et - la vérification (27s) de la validité de ladite au moins une ressource IP sélectionnée. 2. Procédé selon la revendication 1, caractérisé en ce que ladite vérification (27s) comprend : - la transmission (31s) d'au moins une requête à au moins une ressource IP sélectionnée, destinée à être reçue ou interceptée par au moins un noeud relais (112) dudit domaine client associé à ladite au moins une ressource IP sélectionnée, ladite requête comportant un message de contrôle ; - la réception (36s) d'une réponse incluant une information caractéristique dudit message de contrôle, transmise par ledit noeud client (111) audit serveur de contrôle d'accès (14), ledit noeud relais (112) ayant préalablement relayé ladite requête audit noeud client (111) ; et - la validation (37s) de ladite au moins une ressource IP sélectionnée par corrélation de ladite requête et de ladite réponse. 3. Procédé selon la revendication 1, caractérisé en ce que ladite vérification comprend : - l'obtention d'une information représentative de l'identité dudit domaine client ; - l'identification d'au moins un serveur de validation associé à ladite au moins une ressource IP sélectionnée ; et - la transmission audit au moins un serveur de validation d'au moins une requête comportant ladite information représentative de l'identité dudit domaine client et ladite au moins une ressource IP sélectionnée. 4. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en oeuvre dans un noeud client (111) dudit domaine client, ledit procédé comprenant : - l'obtention (21c) d'une liste d'au moins une ressource IP associée au domaine client ; et - la transmission (22c) de ladite liste à un serveur de contrôle d'accès (14). 5. Procédé selon la revendication 4, caractérisé en ce qu'il comprend également : - la réception (34c) d'au moins une requête en provenance dudit serveur de contrôle 34 d'accès (14), via au moins un noeud relais (112) dudit domaine client associé à au moins une ressource IP sélectionnée parmi ladite liste par ledit serveur de contrôle d'accès, ladite requête comportant un message de contrôle ; et - la transmission (35c) audit serveur de contrôle d'accès (14) d'une réponse incluant une 5 information caractéristique dudit message de contrôle. 6. Procédé selon la revendication 4, caractérisé en ce qu'il comprend également : - la réception d'une information représentative de l'identité dudit domaine client, générée par un serveur de validation associé à au moins une ressource IP sélectionnée parmi ladite liste par ledit serveur de contrôle d'accès ; et 10 - la transmission audit serveur de contrôle d'accès de ladite information représentative de l'identité dudit domaine client. 7. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en oeuvre dans un noeud relais (112) dudit domaine client associé à au moins une ressource IP sélectionnée par un serveur de contrôle d'accès (14) parmi une liste d'au moins une ressource IP 15 associée au domaine client, préalablement transmise d'un noeud client (111) dudit domaine client audit serveur de contrôle d'accès, ledit procédé comprenant : - la réception ou l'interception (32R) d'au moins une requête en provenance dudit serveur de contrôle d'accès, ladite requête comportant un message de contrôle ; et 20 - la transmission (33R) de ladite au moins une requête audit noeud client. 8. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en oeuvre dans un serveur de validation associé à au moins une ressource IP sélectionnée par un serveur de contrôle d'accès parmi une liste d'au moins une ressource IP associée au domaine client, préalablement transmise d'un noeud client dudit domaine client audit serveur de contrôle 25 d'accès, ledit procédé comprenant : - la réception d'au moins une requête comportant une information représentative de l'identité d'un domaine client et de ladite au moins une ressource IP sélectionnée ; - l'identification dudit domaine client à partir de ladite information représentative de 30 l'identité du domaine client ; et - la vérification de l'association de ladite au moins une ressource IP sélectionnée avec le domaine client en tenant compte de l'identité du domaine client. 9. Procédé selon la revendication 8, caractérisé en ce qu'il met en oeuvre préalablement : - la détermination de ladite information représentative de l'identité dudit domaine client (HASH) ; et - la transmission, audit noeud client, de ladite information représentative de l'identité du domaine client. 5 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'une durée de validité est associée à ladite liste d'au moins une ressource IP associée au domaine client. 11. Serveur de contrôle d'accès comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour vérifier la validité d'une ressource IP associée à un domaine client, mettant en oeuvre : 10 - la réception d'une liste d'au moins une ressource IP associée audit domaine client, transmise d'un noeud client dudit domaine client audit serveur de contrôle d'accès ; - la sélection d'au moins une ressource IP à valider parmi ladite liste ; et - la vérification de la validité de ladite au moins une ressource IP sélectionnée. 12. Noeud client comprenant au moins une machine de calcul programmable ou une machine 15 de calcul dédiée configurée pour vérifier la validité d'une ressource IP associée au domaine client auquel appartient ledit noeud client, mettant en oeuvre : - l'obtention d'une liste d'au moins une ressource IP associée au domaine client ; et - la transmission de ladite liste à un serveur de contrôle d'accès. 13. Noeud relais comprenant au moins une machine de calcul programmable ou une machine 20 de calcul dédiée configurée pour vérifier la validité d'une ressource IP associée à un domaine client auquel appartient ledit noeud relais, mettant en oeuvre : - la réception ou l'interception d'au moins une requête en provenance d'un serveur de contrôle d'accès, ladite requête comportant un message de contrôle ; et - la transmission de ladite au moins une requête à un noeud client dudit domaine client, 25 ledit noeud relais étant associé à au moins une ressource IP sélectionnée par ledit serveur de contrôle d'accès parmi une liste d'au moins une ressource IP associée audit domaine client, préalablement transmise d'un noeud client dudit domaine client audit serveur de contrôle d'accès. 14. Serveur de validation associé à au moins une ressource IP sélectionnée par un serveur de 30 contrôle d'accès parmi une liste d'au moins une ressource IP associée à un domaine client, préalablement transmise d'un noeud client dudit domaine client audit serveur de contrôle d'accès, comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée 36 configurée pour vérifier la validité de ladite au moins une ressource IP sélectionnée, mettant en oeuvre : - la réception d'au moins une requête comportant une information représentative de l'identité d'un domaine client et de ladite au moins une ressource IP sélectionnée ; 5 - l'identification dudit domaine client à partir de ladite information représentative de l'identité du domaine client ; et - la vérification de l'association de ladite au moins une ressource IP sélectionnée avec le domaine client en tenant compte de l'identité du domaine client. 15. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un 10 procédé selon l'une quelconque des revendications 1 à 10 lorsque ce programme est exécuté par un processeur.