FR3081573A1 - Procedes de verification de la validite d'une ressource ip, serveur de controle d'acces, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants. - Google Patents

Procedes de verification de la validite d'une ressource ip, serveur de controle d'acces, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants. Download PDF

Info

Publication number
FR3081573A1
FR3081573A1 FR1856015A FR1856015A FR3081573A1 FR 3081573 A1 FR3081573 A1 FR 3081573A1 FR 1856015 A FR1856015 A FR 1856015A FR 1856015 A FR1856015 A FR 1856015A FR 3081573 A1 FR3081573 A1 FR 3081573A1
Authority
FR
France
Prior art keywords
client
resource
access control
domain
control server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1856015A
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1856015A priority Critical patent/FR3081573A1/fr
Priority to EP19750134.9A priority patent/EP3815335A1/fr
Priority to US17/256,386 priority patent/US20210273974A1/en
Priority to CN201980051584.6A priority patent/CN112514350B/zh
Priority to PCT/FR2019/051609 priority patent/WO2020002856A1/fr
Publication of FR3081573A1 publication Critical patent/FR3081573A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0245—Filtering by information in the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/695—Types of network addresses using masks or ranges of addresses

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en œuvre dans un serveur de contrôle d'accès, comprenant : - la réception (23S) d'une liste d'au moins une ressource IP associée audit domaine client, transmise d'un nœud client dudit domaine client audit serveur de contrôle d'accès ; - 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.

Description

Procédés de vérification de la validité d'une ressource IP, serveur de contrôle d'accès, serveur de validation, nœud client, nœud 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 œuvre 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 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.
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 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 nœud 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 »), permet à un nœud 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 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 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 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 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 nœud 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 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 la gestion de ce préfixe, par exemple le fournisseur d'accès). En particulier, les nœuds 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 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., 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 (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 (« 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 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.
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 ressource IP associée à un domaine client, Le., 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), 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 œuvre 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 d'un nœud 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 œuvre les étapes suivantes dans un nœud client 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 œuvre les étapes suivantes dans un nœud relais 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 nœud 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 contrôle d'accès, ladite requête comportant un message de contrôle ; et la transmission de la ou des requêtes au nœud 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 œuvre les étapes suivantes 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 nœud 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, 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 légitiment) associée à un domaine client.
En particulier, si un nœud 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 nœud identifié par une ressource IP, la solution proposée permet de vérifier si la ressource IP identifiant au moins un autre nœud est effectivement associée au domaine client, par exemple allouée à au moins un nœud 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 nœud client du domaine client, concerne réellement ce nœud client ou un autre nœud du domaine client, avant 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 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 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.
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 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 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 nœud client peut mettre à jour la liste des ressources IP associées au domaine client sans attendre l'expiration de la durée de validité.
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 nœuds du réseau sont fréquemment modifiés). Par exemple, dans le cadre d'une demande de mitigation, si un nœud 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 associé au domaine client à l'instant T0, le serveur de contrôle d'accès doit vérifier à l'instant Tl 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 préalablement définie.
D'autres modes de réalisation de l'invention concernent un serveur de contrôle d'accès, un nœud client, un nœud relais, et un serveur de validation correspondants.
Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en œuvre 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 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 œuvre de diverses manières, 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 :
la figure 1 illustre un exemple de réseau de communication mettant en œuvre 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 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 œuvre 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 ;
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 ;
la figure 10 illustre les communications autorisées ou non entre nœuds client et nœuds relais ;
les figures 11 à 15 présentent des exemples de mise en œuvre de la procédure de vérification selon un premier mode de réalisation dit « DOTS Probing » ;
la figure 16 présente un exemple de mise en œuvre 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, nœud client ou nœud relais selon un mode de réalisation particulier.
5. Description d'un mode de réalisation de l'invention
5.1 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, Le., la vérification que les ressources déclarées sont 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 œuvre un procédé de vérification de la validité d'une ressource IP associée à un domaine client.
On considère par exemple un nœud client Cl 111, appartenant à un domaine client 11, 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 nœuds. Notamment, le domaine client comprend au moins un nœud relais RI 112. On entend ici par « domaine » un ensemble de machines ou nœuds placés sous la responsabilité d'une même entité.
Un premier fournisseur d'accès 12 dispose d'équipements permettant aux clients du 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 VI 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 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 œuvre pour la vérification d'une ressource IP associée à un domaine client 11.
Un nœud du domaine client 11, par exemple le nœud 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 nœuds 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.
Le nœud client Cl 111, ou éventuellement un autre nœud 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 nœud 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 nœud client, mais les ressources IP à 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 ê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 (23$) donc la liste d'au moins une ressource IP associée au domaine client 11, transmise d'un nœud 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 (24$) au moins une ressource IP à valider parmi la liste.
Eventuellement, le serveur de contrôle d'accès 14 transmet (25$) au nœud client Cl 111 la ou les ressources IP sélectionnées. Le nœud 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 (27$) 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.
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 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 (27$) de la validité de la ou des ressources IP sélectionnées, mise en œuvre 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 nœud relais du domaine client associé à ladite au moins une ressource IP sélectionnée, par exemple le nœud relais RI 112. Eventuellement, le nœud relais RI 112 et le nœud client Cl 111 sont les mêmes. En variante, le nœud relais RI 112 et le nœud client Cl 111 sont deux nœuds distincts appartenant au même domaine. Similairement, le nœud client et le nœud relais peuvent être deux instances logicielles embarquées dans un même nœud 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 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 œuvre une procédure de résolution (par exemple, 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.
Le nœud relais RI 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 nœud relais si l'adresse de destination est allouée à la machine où réside le nœud relais.
Le nœud relais RI 112 transmet (33r) la ou les requêtes au nœud client Cl 111, Le., relaye la ou les requêtes en provenance du serveur de contrôle d'accès 14.
Le nœud 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 nœud 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.
En particulier, si le nœud relais RI 112 et le nœud client Cl 111 sont deux nœuds distincts appartenant au même domaine, les échanges entre le nœud relais RI 112 et le nœud client Cl 111 peuvent être mis en œuvre via une connexion sécurisée.
Si le nœud relais RI 112 et le nœud client Cl 111 sont un même nœud, le nœud client Cl
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 nœud 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.
Le serveur de contrôle d'accès 14 reçoit (36$) la réponse incluant l'information caractéristique du message de contrôle, en provenance du nœud 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 (37$) 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 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 fournisseur d'accès, par exemple le serveur de validation VI 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 (27$) de la validité de la ou des ressources IP sélectionnées, mise en œuvre 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. 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 œuvre l'identification (42s) d'au moins un serveur de validation associé à la ou aux ressources IP sélectionnées à l'étape 24s, Par exemple le serveur de validation VI 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 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 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 nœud client Cl 111 au serveur de contrôle d'accès S 14), reçoit (44y) 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 (45y) le domaine client.
Enfin, le serveur de validation V 121 peut vérifier (46v) l'association/appartenance de la 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 œuvre de la vérification (27$) 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 VI 121 peut mettre en œuvre la détermination (401v) d'une information représentative de l'identité du domaine client 11, directement ou sur requête d'un client du domaine client. Comme indiqué cidessus, 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 VI 121 transmet (402v) au domaine client 11, par exemple au nœud client Cl 111, l'information représentative de l'identité du domaine client.
Le nœud 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.
On note que ces étapes préalables de détermination 401v et de transmission 402y / réception 403c d'une information représentative de l'identité du domaine client 11 peuvent être mises en œuvre 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.
5.2 Exemples d'application dans le domaine des services de mitigation (DPS)
On décrit ci-après des exemples de mise en œuvre de l'invention dans une architecture de type DOTS, selon laquelle le nœud client Cl 111 est un client DOTS et le serveur de contrôle d'accès S 14 est un serveur de contrôle d'accès DOTS, permettant au nœud client Cl 111 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 nœud 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.
En particulier, au moins un mode de réalisation de l'invention peut être mis en œuvre 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 (Le., 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 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, 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 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.
Un domaine DOTS peut accueillir un ou plusieurs clients DOTS. En d'autres termes, plusieurs nœuds client d'un domaine client peuvent disposer de fonctions DOTS.
Les communications DOTS entre un domaine client et un serveur de 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 d'accès, ou des deux. En d'autres termes, un nœud 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 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.
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 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 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 œuvre quelle que soit la configuration de l'architecture DOTS (un ou plusieurs clients DOTS dans un domaine client, pas de passerelle DOTS, une ou plusieurs passerelles DOTS dans le domaine client ou dans le domaine 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 :
« 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-dtlsl3-22, novembre 2017, « The Transport Layer Security (TLS) Protocol Version 1.2 », Dierks T. et al., RFC 5246, DOI 10.17487/RFC5246, août 2008, et « The Transport Layer Security (TLS) Protocol Version 1.3 », Rescorla E., draft-ietf-tlstlsl3-23, janvier 2018.
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 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 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 œuvre par un client DOTS et un serveur DOTS, en référence à la figure 2. On considère à titre d'exemple que le nœud 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 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 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 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 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 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), indépendamment du fournisseur d'accès.
On décrit ci-après, en relation avec la figure 5, les principales étapes mises en œuvre par le client DOTS pour la déclaration de ressources IP associées à un domaine DOTS.
Au cours d'une étape d'initialisation 51c, 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.
Au cours d'une étape d'obtention 52c, similaire à l'étape 21c, Ie 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 53c, similaire à l'étape 22c, Ie client DOTS déclare la liste des ressources IP, en la transmettant à un ou plusieurs serveur(s) de contrôle d'accès DOTS.
Au cours d'une étape de mise à jour 54c, Ie 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 œuvre 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 œuvre 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.
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 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 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).
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é 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 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 ») :
POST /restconf/data/ietf-dots-data-channe1:dots-data\ /dots-client=mydotsclient HTTP/1.1
Host: {host}:{port}
Content-Type: application/yang-data-ι-j son {
ietf-dots-data-channel:prefixes : { prefix-list: [ {
name: my_first_prefix, prefix: 1.2.3.0/24, lifetime: 1504
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 à 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 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 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}
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 ressources IP à valider parmi la liste (étape 24$ 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).
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. II 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 œuvre la procédure de 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 :
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 œuvre la procédure de vérification de façon périodique pour demander aux clients DOTS de confirmer la 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 (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 œuvre la procédure de vérification sur détection de conflit entre les adresses de destination indiquées par 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 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 ».
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 œuvre une vérification de la validité de la ou des ressources sélectionnées (étape 27$ en référence à la figure 2).
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 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.
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 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 œuvre de la procédure de vérification, consistant à vérifier la validité de la ou des ressources sélectionnées (étape 27$ en 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/ISPs », dont les principales étapes sont illustrées en figure 4, permet de traiter les données maintenues par un 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 nœud du domaine client active une fonction « DOTS_CHECK_RELAY » permettant d'inspecter le trafic entrant et de le rediriger vers un nœud client. Un tel nœud est appelé « nœud relais » par la suite.
Plusieurs nœuds 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 nœuds le raccordant au réseau Internet.
Un client DOTS peut cohabiter avec la fonction « DOTS_CHECK_RELAY ». En d'autres termes, un nœud 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 nœud client est alors un nœud 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 nœuds 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 (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 nœud relais et des informations de sécurité (par exemple, jeton d'authentification destiné à vérifier que le client DOTS est habilité à communiquer avec un nœud relais), des informations supplémentaires peuvent être renseignées comme, par exemple, le numéro de port d'écoute du service ou la liste de ressources IP gérées par un nœud 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 ».
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 nœud 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 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 RI et Ri, alors que les messages provenant d'un client usurpateur « F_C » sont rejetés par les relais RI 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 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 grâce à la réutilisation des fonctions de capture de trafic. Ce mode est utilisé de préférence quand le nœud 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.
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 (24$), parmi la liste, une ou plusieurs ressources IP à valider. On note que le contenu de cette liste peut 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 25$ de la figure 2). Par 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.
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 serveur de contrôle d'accès peut mettre en œuvre 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 (i.e., une adresse extraite d'une ressource IP sélectionnée), et interceptées par le(s) nœud(s) relais identifié(s) (étape 31$ 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.
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 (25$).
L'envoi de tels messages aux nœuds 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ë.
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 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-adle-b4bb0f356189
3. 730d0839-0267-4216-8b62-66844bb30711
4. 61319aa3-555d-445c-8918-f2e9cfd67e06 calculer un ou plusieurs condensés qu'il insère dans le message « DOTS_PROBE_REQUEST », tels que des condensés SHA-256 :
1. bdl0ab3db20f6830feb53a8f295013e2934cdc674c32343341445082a73830f7
2. 00ba021fe38dcl2c0ceefd709be9a2d08c8ebea3f231c785f25d03623ee566c5
3. b9c8740f9a4f59c3311f2b027d055dfdd7ba3184754e7451ed649e05cc779385
4. b9e44dflb5f0dc788a068225f422b7cflb4858b62188a47b7504fe202c25e973 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 ;
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.
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 nœud relais identifié par la ressource IP sélectionnée) ;
le maintien d'un état caractéristique de la transmission desdits paquets avec des données aléatoires ;
l'envoi du message (31$) 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.
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.
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.
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) 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 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 (36$) du message DOTS_PROBE_ REPLY par le serveur de contrôle d'accès, le serveur de contrôle d'accès corréle (37$) la réponse (DOTS_PROBE_REPLY) avec la requête (DOTS_PROBE_REQUEST) pour vérifier l'authenticité et l'intégrité du message.
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 ;
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 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.
Les figures 11 à 15 présentent des exemples de mise en œuvre 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 (25$), par exemple les adresses PI à Pi. On 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 prêt. Ensuite, le serveur de contrôle d'accès peut envoyer (31$) 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 RI,...,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 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 PI à 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 DOTS_PROBE_REQUEST sont transmis (31$) à un même relai et sans notification préalable au client. L'état des adresses PI à Pi est également « validé ».
La figure 13 illustre un exemple de succès partiel de validation d'adresses. Seule l'adresse PI est validée alors que l'adresse Pi ne l'est pas. L'état de l'adresse PI est donc « validé » alors que l'état de l'adresse à Pi est « non-validé ».
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 de contrôle d'accès ne reçoit pas de réponses aux messages DOTS_PROBE_REQUEST. L'état des adresses PI 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 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 27$ en référence à la figure 2)·
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 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.
Les étapes de réception (23$), 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 (24$) d'au moins une ressource IP à valider parmi la liste, et optionnellement de transmission (25$) de la ou des ressources IP sélectionnées à valider aux clients DOTS, sont également mises en œuvre selon ce deuxième mode de réalisation, et sont similaires à celles mises en œuvre selon le premier mode de réalisation.
L'étape de vérification (27$) 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 (41$), selon ce deuxième mode de réalisation, 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 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).
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?search text=80.12.102.157#resultsSectlon
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.
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 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.
inetnum: 80.12.102.144 - 80.12.102.159 validation server (s): 80.12.102.15, 80.12.102.16
netname: VISION
des or : France Telecom NDC
country : FR
admin-c: FT09-RIPE
tech-c: FT09-RIPE
status : ASSIGNED PA
mnt-by : FT-BRX
created : 2014-11-20T10:56:45Z
last-modified: 2018-02-09T15: 00: HZ source: RIPE
On présente ci-après plus en détail les étapes mises en œuvre pour valider une ressource IP sélectionnée.
Le serveur de contrôle d'accès DOTS communique (25$) au client DOTS, de façon 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 (42$) également le propriétaire de la ressource et au moins un serveur de validation associé.
Une fois la liste reçue (26c) Par Ιθ 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 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.
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-0208T00:00:llZ » selon la nomenclature « subscriber_45979230632_timestamp_2018-0208T00:00:llZ » :
f4b542f76be38153ecc66b7c4aaa87a04c46def8116dl85cl32elc4alf515203
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.
Ce/ces condensé(s) sont ensuite transmis (404c) au serveur de contrôle d'accès DOTS par le client.
Sur réception (41$) du condensé, le serveur de contrôle d'accès DOTS envoie (43$) des messages de validation DOTS_PROBE_REQUEST vers les serveurs de validation RI,...,Ri. Ces messages comportent le condensé préalablement communiqué par le client, ainsi que la 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 (44y) 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é.
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 ».
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 (25$), par exemple les adresses RI à Ri. On rappelle que cette étape est optionnelle. Sur réception de cette liste, le client DOTS interroge les serveurs de validation VI d'un premier fournisseur d'accès 12 et Vi d'un i-ème fournisseur d'accès 16, associés aux ressources IP RI, ..., 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 (43$) des messages de validation DOTS_PROBE_REQUEST vers le ou les serveurs de validation, portant la ressource IP à valider et 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 l'information représentative de l'identité du domaine client. Si tel est le cas, l'état des adresses RI à 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.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 nœud client, d'un nœud 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 mémoire 171$ comprenant une mémoire tampon, une unité de traitement 172$, é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 173$, mettant en œuvre des étapes du 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 173$ sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 172sLe processeur de l'unité de traitement 172$ met en œuvre 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 173$, pour :
recevoir une liste d'au moins une ressource IP associée à un domaine client, transmise d'un nœud 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.
Selon un mode de réalisation particulier, un nœud client comprend une mémoire 171c comprenant une mémoire tampon, une unité de traitement 172c, é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 173c, mettant en œuvre des étapes du 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 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 172cLe processeur de l'unité de traitement 172c rnet en œuvre 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 173c, pour :
obtenir une liste d'au moins une ressource IP associée au domaine client auquel appartient le nœud client ;
transmettre la liste à un serveur de contrôle d'accès.
Selon un mode de réalisation particulier, un nœud 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 œuvre des étapes du 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 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 œuvre 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 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 nœud client du domaine client, ledit nœud 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 nœud client du domaine client au serveur de contrôle d'accès.
En particulier, un tel nœud relais peut activer la fonction « DOTS_CHECK_RELAY » définie 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 œuvre des étapes du 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 traitement 172\/.
Le processeur de l'unité de traitement 172y met en œuvre 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 :
- 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 compte de l'identité du domaine client.

Claims (15)

  1. REVENDICATIONS
    1. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en œuvre dans un serveur, dit serveur de contrôle d'accès (14), ledit procédé comprenant :
    la réception (23$) d'une liste d'au moins une ressource IP associée audit domaine client, transmise d'un nœud client (111) dudit domaine client audit serveur de contrôle d'accès (14);
    la sélection (24$) d'au moins une ressource IP à valider parmi ladite liste ; et la vérification (27$) de la validité de ladite au moins une ressource IP sélectionnée.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que ladite vérification (27$) comprend :
    la transmission (31$) 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 nœud 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 (36$) d'une réponse incluant une information caractéristique dudit message de contrôle, transmise par ledit nœud client (111) audit serveur de contrôle d'accès (14), ledit nœud relais (112) ayant préalablement relayé ladite requête audit nœud client (111); et la validation (37$) de ladite au moins une ressource IP sélectionnée par corrélation de ladite requête et de ladite réponse.
  3. 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. 4. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en œuvre dans un nœud 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. 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 d'accès (14), via au moins un nœud 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 information caractéristique dudit message de contrôle.
  6. 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 la transmission audit serveur de contrôle d'accès de ladite information représentative de l'identité dudit domaine client.
  7. 7. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en œuvre dans un nœud 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 associée au domaine client, préalablement transmise d'un nœud 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 la transmission (33r) de ladite au moins une requête audit nœud client.
  8. 8. Procédé de vérification de la validité d'une ressource IP associée à un domaine client, mis en œuvre 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 nœud client dudit domaine client audit serveur de contrôle 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 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. 9. Procédé selon la revendication 8, caractérisé en ce qu'il met en œuvre préalablement : la détermination de ladite information représentative de l'identité dudit domaine client (HASH) ; et la transmission, audit nœud client, de ladite information représentative de l'identité du domaine client.
  10. 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. 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 œuvre :
    la réception d'une liste d'au moins une ressource IP associée audit domaine client, transmise d'un nœud 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. 12. Nœud client 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 au domaine client auquel appartient ledit nœud client, mettant en œuvre :
    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. 13. Nœud relais 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 auquel appartient ledit nœud relais, mettant en œuvre :
    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 nœud client dudit domaine client, ledit nœud 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 nœud client dudit domaine client audit serveur de contrôle d'accès.
  14. 14. 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 à un domaine client, préalablement transmise d'un nœud 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 configurée pour vérifier la validité de ladite au moins une ressource IP sélectionnée, mettant en œuvre :
    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. 15. Programme d'ordinateur comportant des instructions pour la mise en œuvre d'un
    10 procédé selon l'une quelconque des revendications 1 à 10 lorsque ce programme est exécuté par un processeur.
FR1856015A 2018-06-29 2018-06-29 Procedes de verification de la validite d'une ressource ip, serveur de controle d'acces, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants. Withdrawn FR3081573A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1856015A FR3081573A1 (fr) 2018-06-29 2018-06-29 Procedes de verification de la validite d'une ressource ip, serveur de controle d'acces, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants.
EP19750134.9A EP3815335A1 (fr) 2018-06-29 2019-06-28 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
US17/256,386 US20210273974A1 (en) 2018-06-29 2019-06-28 Methods for verifying the validity of an ip resource, and associated access control server, validation server, client node, relay node and computer program
CN201980051584.6A CN112514350B (zh) 2018-06-29 2019-06-28 用于核实ip资源的有效性的方法以及相关联的访问控制服务器、验证服务器、客户端节点、中继节点和计算机程序
PCT/FR2019/051609 WO2020002856A1 (fr) 2018-06-29 2019-06-28 Procédés de vérification de la validité d'une ressource ip, serveur de contrôle d'accès, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1856015A FR3081573A1 (fr) 2018-06-29 2018-06-29 Procedes de verification de la validite d'une ressource ip, serveur de controle d'acces, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants.

Publications (1)

Publication Number Publication Date
FR3081573A1 true FR3081573A1 (fr) 2019-11-29

Family

ID=63722563

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1856015A Withdrawn FR3081573A1 (fr) 2018-06-29 2018-06-29 Procedes de verification de la validite d'une ressource ip, serveur de controle d'acces, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants.

Country Status (5)

Country Link
US (1) US20210273974A1 (fr)
EP (1) EP3815335A1 (fr)
CN (1) CN112514350B (fr)
FR (1) FR3081573A1 (fr)
WO (1) WO2020002856A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3086821A1 (fr) * 2018-09-28 2020-04-03 Orange Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180041468A1 (en) * 2015-06-16 2018-02-08 Amazon Technologies, Inc. Managing dynamic ip address assignments

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100539501C (zh) * 2006-10-13 2009-09-09 清华大学 基于域名的统一身份标识和认证方法
US8769622B2 (en) * 2011-06-30 2014-07-01 International Business Machines Corporation Authentication and authorization methods for cloud computing security
US10033540B2 (en) * 2014-07-24 2018-07-24 The Hong Kong University Of Science And Technology Handoff free wireless network architecture
US20160173526A1 (en) * 2014-12-10 2016-06-16 NxLabs Limited Method and System for Protecting Against Distributed Denial of Service Attacks
US20180054438A1 (en) * 2015-03-02 2018-02-22 Microsoft Technology Licensing, Llc Proxy service for uploading data from a source to a destination
US20170149833A1 (en) * 2015-11-25 2017-05-25 Network Performance Research Group Llc Network security systems and methods
US10382480B2 (en) * 2016-10-13 2019-08-13 Cisco Technology, Inc. Distributed denial of service attack protection for internet of things devices
US20180159894A1 (en) * 2016-12-01 2018-06-07 Cisco Technology, Inc. Automatic threshold limit configuration for internet of things devices
US10542001B1 (en) * 2016-12-19 2020-01-21 Amazon Technologies, Inc. Content item instance access control
US10972455B2 (en) * 2018-04-24 2021-04-06 International Business Machines Corporation Secure authentication in TLS sessions

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180041468A1 (en) * 2015-06-16 2018-02-08 Amazon Technologies, Inc. Managing dynamic ip address assignments

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MORTENSEN ARBOR NETWORKS F ANDREASEN CISCO T REDDY MCAFEE A ET AL: "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture; draft-ietf-dots-architecture-05.txt", DISTRIBUTED-DENIAL-OF-SERVICE OPEN THREAT SIGNALING (DOTS) ARCHITECTURE; DRAFT-IETF-DOTS-ARCHITECTURE-05.TXT; INTERNET-DRAFT: DOTS, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENE, no. 5, 26 October 2017 (2017-10-26), pages 1 - 30, XP015122508 *
MORTENSEN ARBOR NETWORKS R MOSKOWITZ HUAWEI T REDDY MCAFEE A: "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements; draft-ietf-dots-requirements-14.txt", DISTRIBUTED DENIAL OF SERVICE (DDOS) OPEN THREAT SIGNALING REQUIREMENTS; DRAFT-IETF-DOTS-REQUIREMENTS-14.TXT; INTERNET-DRAFT: DOTS, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENE, no. 14, 8 February 2018 (2018-02-08), pages 1 - 20, XP015125616 *

Also Published As

Publication number Publication date
US20210273974A1 (en) 2021-09-02
CN112514350B (zh) 2023-10-20
WO2020002856A1 (fr) 2020-01-02
CN112514350A (zh) 2021-03-16
EP3815335A1 (fr) 2021-05-05

Similar Documents

Publication Publication Date Title
EP3857848B1 (fr) Procédé d'allocation d'un identifiant à un noeud client, procédé d'enregistrement d'un identifiant, dispositif, noeud client, serveur et programmes d'ordinateurs correspondants
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
FR3072238A1 (fr) Dispositif et procede de transmission de donnees
EP3972218A1 (fr) Procédé d'accès sécurisé à des ressources via un réseau de télécommunication et système de contrôle associé
EP3815335A1 (fr) 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
WO2018115647A1 (fr) Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
EP3087719B1 (fr) Procédé de ralentissement d'une communication dans un réseau
EP3857849A1 (fr) Procédés de protection d'un domaine client, noeud client, serveur et programmes d'ordinateur correspondants
EP3788762A1 (fr) Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip
WO2015197978A1 (fr) Procede de protection d'un routeur contre des attaques
EP3815336A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, noeud client et programme d'ordinateur correspondants
FR3131023A1 (fr) Procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique, dispositifs, signal et dispositifs correspondants
FR3136075A1 (fr) Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés.
FR3086821A1 (fr) Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.
Alarco et al. Multidomain network based on programmable networks: security architecture
EP4268426A1 (fr) Procedes pour la redirection de trafic, terminal, controleur, serveur d'autorisation, serveurs de resolution de noms, et programme d'ordinateur correspondants
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20191129

ST Notification of lapse

Effective date: 20210206