EP3857848A1 - 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 - Google Patents

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

Info

Publication number
EP3857848A1
EP3857848A1 EP19802235.2A EP19802235A EP3857848A1 EP 3857848 A1 EP3857848 A1 EP 3857848A1 EP 19802235 A EP19802235 A EP 19802235A EP 3857848 A1 EP3857848 A1 EP 3857848A1
Authority
EP
European Patent Office
Prior art keywords
client
identifier
client node
domain
request
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.)
Granted
Application number
EP19802235.2A
Other languages
German (de)
English (en)
Other versions
EP3857848B1 (fr
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
Publication of EP3857848A1 publication Critical patent/EP3857848A1/fr
Application granted granted Critical
Publication of EP3857848B1 publication Critical patent/EP3857848B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • Method for allocating an identifier to a client node Method for registering an identifier, device, client node, server and corresponding computer programs.
  • the field of the invention is that of communications within a communication network, for example an IP network, and in particular that of value-added IP services.
  • the invention offers a solution to protect the communication network and the terminals connected to this network against computer attacks.
  • the invention offers a solution allowing to allocate a unique identifier to a client node connected to the client domain and to register this identifier in association with an identifier of the client domain.
  • the invention notably finds applications in the field of mitigation of attacks by denial of distributed services (in English DDoS, for “Distributed Douai of Service”), for example implementing, but not exclusively, a DOTS type architecture (in English "DDoS Open Threat Signaling”), as standardized by the IETF.
  • denial of distributed services in English DDoS, for “Distributed Douai of Service”
  • DOTS type architecture in English "DDoS Open Threat Signaling”
  • a DDoS attack is an attempt to make resources, for example network or computing resources, unavailable to their users.
  • resources for example network or computing resources
  • Such attacks can be massively deployed by compromising a large number of hosts, and by using these hosts to amplify the attacks.
  • DDoS attacks In order to overcome these DDoS attacks, detection and mitigation services for DDoS attacks are offered by certain access or service providers to their customers.
  • Such mitigation services in English DPS for "DDoS Protection Services" can be hosted within the infrastructures operated by access providers or in the “cloud” (in French “cloud”). They make it possible in particular to distinguish “legitimate” traffic, i.e., data consented by the user, from “suspicious” traffic.
  • tunnels To solve this problem, it was notably proposed to set up tunnels to force traffic (incoming or outgoing) on a site or a network intended to be inspected by the DPS service.
  • this approach considerably increases the latency observed by the users and imposes constraints on the dimensioning of the DPS service to be able to handle all the traffic entering or leaving all the users of the network.
  • the tunnels are potential and proven attack vectors.
  • DOTS DOTS
  • a specific architecture has been standardized by the IETF.
  • DOTS allows a client node, said DOTS client, to inform a server, said DOTS server, that it has detected a DDoS attack and that appropriate actions are required to counter this attack.
  • a DOTS client in that client domain can send a message to a DOTS server asking for help.
  • the latter coordinates, with a mitigation entity (in English “mitigator”), the actions to be carried out so that the suspicious traffic, associated with the denial of service attack, is no longer routed to the client domain, while the traffic legitimate continues to be routed normally to the client domain.
  • the mitigation entity can be co-located with the DOTS server.
  • This solution uses two communication channels between a DOTS client and a server
  • DOTS Signaling channel in English "DOTS Signal Channel"
  • DOTS Data channel in English "DOTS Data Channel”
  • the DOTS signaling channel is used when a DDoS attack is in progress.
  • a DOTS client can use this channel to request help from a DOTS server.
  • a DOTS client uses this signaling channel to send a request to the server informing it that the prefix "1.2.3.0/24" is undergoing a DDoS attack, so that the server can take actions to end the attack .
  • Such a request is associated with a DOTS client identified by a unique identifier, noted for example CUID (“Unique Client I Dentifier”).
  • a DOTS server can thus take adequate measures to end a DDoS attack on the one hand if the request from the DOTS client does not conflict with other requests from other DOTS clients in the same client domain, or with a filtering rule installed beforehand on the server by another DOTS client in the client domain, and on the other hand if the server is empowered to / configured to honor the last request received.
  • the server can send an error message, for example of type 4.09 ("Conflict"), to inform the DOTS client.
  • Such a signaling channel is described in particular in the document “Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification”, draft-ietf-dots-signal-channel, Reddy, T. et al., January 2018.
  • DSS Distributed Denial-of-Service Open Threat Signaling
  • the DOTS data channel is used when no DDoS attack is in progress.
  • a DOTS client can use this channel to install filtering rules, such as filtering traffic received from certain addresses or traffic destined for a given node.
  • filtering rules such as filtering traffic received from certain addresses or traffic destined for a given node.
  • a DOTS client can use this DOTS data channel to request the server to block all traffic to the prefix "1.2.3.0/24", or all UDP traffic destined for port number 443.
  • the DOTS server can install filtering rules in response to a request sent by a DOTS client, if this request does not conflict with other requests from other DOTS clients in the same client domain or with an existing filter rule.
  • the server can send an error message, for example of type 409 ("Conflict"), to inform the DOTS client.
  • Such a data channel is described in particular in the document “Distributed Denial-of- Service Open Threat Signaling (DOTS) Data Channel”, draft-ietf-dots-data-channel, Boucadair M. et al., December 2017.
  • DSS Distributed Denial-of- Service Open Threat Signaling
  • a DOTS server refuses to process an attack mitigation request sent by a DOTS client while the attack is real, or refuses filtering requests sent by a DOTS client (an objective of filtering requests being to anticipate DDoS attacks). Such a refusal may in particular occur when these filtering requests are in conflict with filtering rules installed by other DOTS clients in the same client domain.
  • the invention relates to a method of allocating an identifier to a first client node of a client domain, said first client node being able to manage the traffic associated with the client domain for its purpose. protection against a computer attack, said method comprising:
  • the recording in a local memory of an association between the allocated identifier and the identification information of the first client node;
  • the invention thus provides a controlled management of identifiers used by client nodes in a client domain to communicate with each other and with a traffic management server associated with the client domain. According to this embodiment, it guarantees the uniqueness of the identifier allocated to the first node when it becomes active in the domain and therefore makes it possible to avoid identification conflicts between active nodes.
  • the method can be implemented by another client node, benefiting from privileges in the client domain, said master client, or by a dedicated software instance, called CMI (CUID Management Instance) which interfaces with the client node master.
  • CMI CMI Management Instance
  • the method comprises a modification of the association recorded in the local memory.
  • the management of the identifier allocated to the first client node is controlled during the entire period of connection of the node to the client domain.
  • the detected event belongs to a group comprising:
  • the event can concern either a change in the activity of the first client node, or in the security or administration policy of the client domain.
  • the modification comprises the deletion of the registration
  • the method comprises the emission of a request for cancellation of the registration of the allocated identifier intended for the server.
  • this first exemplary embodiment allows the repercussion at the server level of the deletion of the association (client, cuid).
  • the identifier allocated to the first client is thus released and can be assigned to another active client node.
  • the modification comprises replacing, in the recording of the local memory, the identification information of the first client with identification information of a second client in the domain.
  • this second embodiment makes it possible to facilitate the replacement of the first client node by a second, without modifying the mitigation actions installed by the first client node and, consequently, without disturbing the execution in progress of these mitigation actions.
  • the second client node will resume processing of the mitigation actions previously implemented by the first client node. It is not necessary, according to this example, to pass this modification on to the server, since it already stores the correct association between the unique identifier of the client node and the domain identifier.
  • the request received further comprising a request for allocation of a management delegation attribute, said attribute being intended to be specified by another client node in a request for processing a management rule traffic transmitted to the server to delegate the management of said traffic management rule to the first client node
  • the method comprises:
  • the response sent to the first client node includes the allocated delegation attribute.
  • the delegation attribute can be specified by the first client node during the installation of a rule (filtering, ACL, etc.) after the execution of a mitigation action to the server, so as to indicate that it grants a delegation on the mitigation action.
  • the delegation attribute is then stored by the server in association with the installed rule.
  • Knowledge of this delegation attribute allocated to the first client node can be transmitted to another client node in order to allow it to modify the rule installed by the first client node.
  • the second client node must insert the value of this delegation attribute in its request to modify the rule concerned and sent to the server.
  • the response further includes the delegation attribute allocated to at least one other client node.
  • the delegation attribute allocated to at least one other client node.
  • the master client node or the CMI entity wishes to deactivate the delegation procedure, for example because it induces an excessive load on certain client nodes in the domain.
  • the invention relates to a method of registering an identifier allocated to a client node capable of managing the traffic associated with a client domain for the purpose of its protection against a computer attack, implemented in a server, the method comprising:
  • the invention proposes to register at the server level an association between the unique identifier allocated to the client node and the identifier of the client domain, which makes it possible to secure exchanges between the client nodes and the server. to manage the traffic associated with the client domain and to guarantee the global uniqueness of the identifier consisting of the pair ⁇ CUID, CDID ⁇ .
  • the method comprises searching for said record in a memory and rejecting the request if said record was not found.
  • the method comprises:
  • This delegation procedure thus makes it possible to migrate the management of a mitigation action in the event of unavailability of the client node at the origin of its installation. It is particularly interesting, in the event of an attack, when a client node has previously issued a mitigation request to the server which has replied that there is a conflict between its request and at least one rule already installed by another client node following the execution of a mitigation action. With the invention, the client node which detects the attack can take advantage of the delegation procedure to request the server to modify the rule so that it no longer hinders the mitigation of the attack in progress. The reliability of the attack mitigation service is therefore increased.
  • the method comprises the deletion of said registration and the deletion of the traffic management rules installed by the first client node.
  • the method of registering an identifier comprises the notification of the other client nodes active in the client domain, prior to said removal of the traffic management rules installed by the first client node.
  • the invention relates to a device for allocating an identifier to a first client node capable of managing the traffic associated with a client domain for the purpose of its protection against a computer attack, said device comprising at least a programmable calculation machine or a dedicated calculation machine configured to implement:
  • the recording in a local memory of an association between the allocated identifier and the identification information of the first client node;
  • the invention relates to one or more computer programs comprising instructions for implementing a method according to at least one embodiment of the invention, when this or these programs is / are executed by a processor.
  • the invention relates to one or more non-removable or partially or completely removable information carriers, readable by a computer, and comprising instructions for one or more computer programs for execution of a method according to at least one embodiment of the invention.
  • the methods according to the invention can therefore be implemented in various ways, in particular in wired form and / or in software form.
  • FIG. 1 illustrates an example of a communication network implementing a method of allocating an identifier of a client node and a method of registering an identifier, according to an embodiment of the invention
  • FIG. 2 presents the main steps of the method for allocating an identifier according to an embodiment of the invention
  • FIG. 3 presents the main steps of the method of registering an identifier according to an embodiment of the invention
  • FIGS. 4A and 4B illustrate examples of messages exchanged between a first client node, a master client and a server for the allocation of an identifier to the first client of a client domain and its recording according to an embodiment of the invention
  • FIGS. 5A and 5B illustrate examples of application of the invention to make the exchanges between the client nodes and the server more reliable
  • FIGS. 6A to 6D illustrate examples of messages exchanged between the first client node, the master client and the server to delete the identifier allocated to the first client node according to an embodiment of the invention
  • FIG. 7 details the steps implemented by the server to process a modification request by a first client node of a management action installed by a second client node, according to an embodiment of the invention
  • FIGS. 8A to 8B illustrate the resolution of a conflict between traffic management actions according to an embodiment of the invention
  • FIGS. 9A to 9C illustrate examples of messages exchanged for the implementation of a delegation procedure between client nodes according to an embodiment of the invention.
  • FIG. 10 schematically illustrates the hardware structure of a client node and a server according to an embodiment of the invention.
  • the general principle of the invention is based on the allocation of a unique identifier to a client node forming part of a client domain, but also on the registration of this identifier in association with an identifier of the client domain, and on the use of this unique identifier to make protection against denial of service attacks within the domain more efficient and more reliable.
  • the client domain 11 includes one or more machines, also called nodes.
  • domain means a set of machines or nodes placed under the responsibility of the same entity. We consider for example several client nodes Cl, C2, Cm belonging to the client domain 11, communicating with a server S 12.
  • the server 12 does not belong to the client domain 11. According to another example not shown, the server 12 can belong to the client domain 11.
  • the client nodes C1, C2 and Cm 114 are DOTS clients and the server S is a DOTS server.
  • the client nodes Cl, C2 and Cm and the server S can thus communicate via the DOTS signaling and data channels defined in relation to the prior art, to inform the server that a DDoS attack has been detected and that appropriate actions are required.
  • a DOTS request can be, for example:
  • an alias management message for example intended to associate an identifier with one or more network resources located in the client domain
  • a signaling message to request mitigation of a denial of service attack with a DOTS server the server being able, on reception of such a message, to initiate the actions necessary to end the attack, or
  • a traffic management rules management message for example filtering, including a request to a DOTS server to install (or have installed), modify or delete an access control list (ACL for "Access Control List") for the mitigation of an attack.
  • ACL access control List
  • a “request for processing” will denote a request to install one or more explicit filtering rules, an access control list, and more generally any action. that a DOTS client node can request from the server for the mitigation of an attack and more generally, the application of a security policy targeting the domain that hosts the DOTS client.
  • a DOTS request can be sent from a DOTS client, belonging to a DOTS client domain, to a DOTS server or to a plurality of DOTS servers.
  • a DOTS domain can accommodate one or more DOTS clients. In other words, several client nodes in a client domain can have DOTS functions.
  • DOTS communications between a client domain and a server domain can be direct, or established via DOTS gateways (in English "DOTS gateways"), not shown. These gateways can be hosted within the client domain, the server domain, or both.
  • DOTS gateways in English "DOTS gateways"
  • a client node in the client domain can communicate directly with the server, or transmit a request to a gateway in the client domain which communicates directly with the server or with a gateway in the server domain, or transmit a request to a gateway of the server domain that communicates with the server.
  • a DOTS gateway located in a client domain is considered by a DOTS server as a DOTS client.
  • a DOTS gateway located in a server domain is considered by a DOTS client as a DOTS server. If there is a DOTS gateway in a server domain, authentication of DOTS clients can be entrusted to the DOTS gateway in the server domain.
  • a DOTS server can be configured with the list of DOTS gateways active within its domain and the server can delegate some of its functions to these trusted gateways. In particular, the server can safely use the information provided by a gateway appearing in a list declared to the server and maintained by the latter, by means of an ad hoc authentication procedure (for example, explicit configuration of the list by the 'authorized administrator of the server, retrieving the list from an authentication server such as an AAA server (for "Authentication, Authorization and Accounting”), etc.).
  • DOTS architecture one or more DOTS clients in a client domain, no DOTS gateway, one or more DOTS gateways in the client domain or in the server domain, client domain separate from the server domain, etc.
  • DOTS Distributed Denial-of-Service Open Threat Signaling
  • FIG. 2 illustrates the main steps of the method of allocating an identifier to a first client node C1 according to an embodiment of the invention.
  • This process can be implemented by another client node in the client domain, benefiting from privileges with the server S, called the master client Cm, or by a new dedicated software instance, called CMI (for “CUID Management Instance”, in English) which interfaces with a master client node CL
  • CMI for “CUID Management Instance”, in English
  • the DOTS Cl client When the DOTS Cl client starts up, it contacts its master client Cm or the CMI instance to request in 21 the allocation of a DOTS client identifier or cuid. To do this, the client DOTS Cl sends an allocation request message MREQID or GET () to the master client Cm, as illustrated in FIG. 4A. Upon receipt of the MREQID or GET () message by the master client Cm DOTS (or the CMI instance), the latter verifies that this client Cl is authorized to invoke the DOTS service. If necessary, the master client Cm obtains at 22 a list of identifiers currently used in the field, for example by consulting a table stored in memory, and chooses at 23 an identifier cuid_cl which is not part of this list.
  • the DOTS Cm client (or the CMI instance) ensures by default that two clients in the client domain do not use the same identifier 'cuid'. Note that this constraint can be relaxed during the securing or replacement phases of one DOTS client with another.
  • the master client Cm stores in 24 the pair formed by the allocated unique identifier and the identifier of the client Cl in memory, for example a local memory. Then, and in order to improve the robustness of the DOTS service, the DOTS Cm master client contacts at 25 the S server at 27Cm to register the new identifier activated within the DOTS client domain for the client Cl. As illustrated in FIG.
  • MREQREG Registration request message
  • REGISTER_REQ REGISTER_REQ
  • This message can include the DOTS cuid identifier (s) of the Cl client alone or of several clients.).
  • MREPREG MREPREG
  • REGISTER_ACK REGISTER_ACK
  • it sends in 26 to the client Cl an acknowledgment message MREPID or SET (cuid_cl) including the identifier cuid_cl which it allocated to it, as illustrated in Figure 4A.
  • the client Cm can repeat the process in order to reallocate a new identifier to the client Cl and request the registration of the new identifier cuid_cl from the server S.
  • the client domain upon detection of an event occurring in the client domain, such as the inactivity of the client node Cl, or its disconnection or even a change in the security policy of the client domain at 27, it modifies at least locally the 28 registration of the identifier cuid_cl.
  • an event occurring in the client domain such as the inactivity of the client node Cl, or its disconnection or even a change in the security policy of the client domain at 27, it modifies at least locally the 28 registration of the identifier cuid_cl.
  • the server S On reception at 31 of a request for registration MREQREG () or REGISTER_REQ of an identifier cuid_cl for the client Cl of the client domain 11 coming from the master client Cm, as illustrated in FIG. 4B, the server S performs the checks of security (not shown) already mentioned. If successful, it obtains in 32 an identifier 'cdid' (for "Client Domain I Dentifier", in English) of the client domain 11 to which the client Cl is attached. For example, a DOTS server identifies DOTS clients belonging to the same domain by the cdid attribute.
  • the domain identifier can be calculated locally by the server or communicated by another trusted entity (typically, a DOTS relay from its server domain), or both. No assumption is made as to the structure of the cdid. It then checks at 33 if an association between this client identifier cuid_cl and this domain identifier 'cdid' is already stored in memory. If it finds one, it rejects the registration request at 35 by sending the master client a rejection response MREPREQ (rej). If it does not find one, it processes the recording request at 34 by storing the pair (cuid, cdid) of client Cl in memory M2. It then acknowledges the registration request with an MREPREG (ack) or REGISTER-ACK () message, as shown in Figure 4B.
  • MREPREG ack
  • REGISTER-ACK REGISTER-ACK
  • a mitigation solution such as the installation of a traffic management rule of the type filtering of Rk traffic
  • this request coming from a client identified by the identifier cuid_cl
  • the server checks in 37 that the identifier cuid_cl is validly saved in its memory in association with the identifier of the client domain from which the request comes . If successful, it processes the request at 38, otherwise it rejects it.
  • the verification procedure according to the invention implemented by the DOTS server to process a DOTS request emanating from a DOTS client makes the service more reliable even in the event of the theft of security identities by a malicious entity.
  • Table 1 an example of an extract from a list of DOTS clients as maintained by a master DOTS client Cm is presented.
  • the table indicates three active DOTS clients for this domain.
  • the invention does not assume any particular structure for the tables maintained by the CMI / DOTS master client instance.
  • the information concerning the allocation of the identifier of the DOTS client is communicated by the CMI instance to the DOTS master client Cm.
  • the PUT request is relayed by a DOTS relay from the server domain.
  • Table 2 An example of extract from a list of clients as maintained by the server S.
  • the table indicates 5 active DOTS clients, 3 of which belong to the “here” domain. example ”of the master client Cm.
  • FIGS. 5A and 5B To illustrate the advantages of the method for allocating a unique identifier according to the invention, the examples of situations in FIGS. 5A and 5B are considered.
  • the master client C1 first registers with the server S the identifier cuid_c3 which he has allocated to the client C3.
  • a malicious DOTS client C4 belonging to another domain 12 contacts the server S, requesting the implementation of a management action on behalf of the client C3, that is to say in using its identifier cuid_c3, the server detects that the association (cuid_c3, cdid) is wrong and rejects the request.
  • the event detected at 27 is an event relating to a change in the activity of client nodes registered in the domain or in the security policy applied within the domain.
  • a master client node Cm uses the unique identifiers to react to this event. These include, for example:
  • the master client Cm can decide to delete the registration of one or more client nodes with the server S.
  • the record deletion message can include one or more DOTS client identifiers from a client domain.
  • the DOTS S server proceeds to delete the clients listed in its tables (after the usual security checks).
  • the event detected by the master client Cm is the receipt of an explicit request to delete the record from a client node C1 in the client domain.
  • the master client Cm proceeds to modify the registration of the identifier of the client Cl.
  • the master client C1 acknowledges the request from the client Cl with a response message MREPSUP (ack) and transmits a request for deleting the record MREQUNREG () from the client Cl to the server S.
  • Ce last removes the association (cuid_cl, cdid) from its table and responds to the master client Cm with an acknowledgment message.
  • the cuid_cl identifier is thus released at the level of the server S, which will then delete the actions installed with this identifier.
  • the DOTS server S informs the other clients of the domain of the existence of these rules, so that they can reinstall them.
  • the DOTS agents clients and servers
  • the DOTS agents support the “RESTCONF and HTTP Transport for Event Notifications” mechanism, as specified in the document “RESTCONF Transport for Event Notifications, draft-ietf-netconf- restconf -notif, E. Voit et al., Sep 2018 ”.
  • the client C2 When the client C2 disconnects or when the server detects an inactivity of the client C2 for a given period, it identifies the filters associated with this client C2, and then notifies the other client nodes of the same client domain such as Cl of its intention to remove the traffic management rules associated with the client C2.
  • the client C1 can decide to take responsibility for certain rules initially associated with the client C2. To do this, it transmits a POST type request to the server S asking it to migrate certain rules of the client C2 to its name. The server S migrates these rules, and sends an acknowledgment message of type “204 created” to the client Cl (ie, the identifier of the client node Cl will be maintained by the server as being responsible for managing these rules).
  • the master client Cm acknowledges the request from the client Cl by a response message MREPSUP (ack). To avoid disturbing the operation of the DOTS domain 11, it does not ask the server S to delete the registration of the identifier cuid_cl from the client Cl, but it reallocates this identifier to another client C2 in the domain 11. In this way, it replaces the Cl client with another client in the domain without affecting the state maintained by the S server.
  • MREPSUP response message
  • the server can accept its request because the client C2 is validly identified .
  • the server S receives at 36 a request for processing a rule Rk from the client Cl.
  • identifier cuid_cl It checks in 37 that the identifier cuid_cl is indeed registered in association with the identifier of the client domain cdid. If necessary, it searches in 371 for a record associating the identifier cuid_cl with the rule Rk identified by the attribute rk. If this is the case, the client Cl is at the origin of the installation of the rule Rk which he wishes to modify. The server S performs the modification requested at 38.
  • this new attribute "THIRD_PARTY_NONCE” is informed by the DOTS C2 client when the Rk rule is created with the server S.
  • This attribute includes a unique identifier, such as the identifier cuid_cl of the client Cl.
  • This delegation procedure allows a client node in the client domain to modify actions installed by another client in this client domain, such as, for example, traffic filter rules that are out of date or in conflict with the installation of other filter rules. , for example for the implementation of a mitigation solution against a DDoS attack.
  • the delegation is activated only by the client C1 for the benefit of the client C2.
  • Client C2 does not designate client Cl as beneficiary of a delegation;
  • the delegation is activated by the two clients: Cl delegates to C2 and vice versa.
  • THIRD_PARTY_NONCE o the same value of the THIRD_PARTY_NONCE attribute is used by the two customers o separate values are used by each of the customers.
  • my_acl for which the client node C2 identified by the identifier cuid_c2, specifies to the server that it supports the delegation by indicating the value "263afd79-835c-4ee7-9535- df245cf28d9a" for the attribute TFIIRD_PARTY_NONCE in its request.
  • the client node C1 requests the server S so that it implements a solution for mitigating this attack by sending in 81C1 the following message:
  • Client node C1 receives this error message at 87C1. Contrary to the state of the art, the client node Cl returns at 88C1 a request to modify the filtering rule Rk to the server SI to resolve the conflict. In this example, it is assumed that the client node Cl adds a new entry to the existing rule "my-acl" to block only the traffic intended for the address "1.2.3.1/32". For example, the request for modification of Rk which it addresses to the server SI takes the following form:
  • the value of the attribute "THIRD_PARTY_NONCE" is allocated by the CMI / master client Cm instance, at the same time as the identifier 'cuid'.
  • the value of the delegation attribute can be obtained by static or dynamic configuration, for example, using the DHCP protocol.
  • the client node C1 transmits an allocation request MREQID () or GET (cuid, THIRD_PARTY_NONCE) with an identifier 'cuid_cl' and a delegation attribute.
  • the CMI instance or the master client node Cm can deactivate this delegation procedure by not returning any delegation attribute value to the client Cl as shown in Figure 9B.
  • the absence of the THIRD_PARTY_NONCE attribute in the response received from the CMI is an explicit indication to inform the client node C1 that the DOTS delegation procedure is deactivated.
  • the delegation procedure can induce a computation overload for the client node which takes over from another client node for the management of its actions in progress. If the load of said relay node reaches a certain threshold, for example 80% of the central processing unit or CPU (for “Central Processing Unit”, in English), the delegation procedure could then be deactivated. The entity in charge of activating the delegation procedure can in particular be informed of a threshold being exceeded by conventional notification means such as an "SNMP trap".
  • the master client node indicates in its response to the client node C1, not only the value of the delegation attribute which it has allocated to it, but also that which it has allocated to other client nodes in the same client domain. It is understood that in this case, all the client nodes of the client domain share the same value of the delegation attribute.
  • the registration by the server S of an association between the unique identifier allocated to the client node by the master client node or the entity CMI, and the client domain identifier 11, not only makes exchanges between DOTS agents more reliable, but also facilitates and makes more robust the protection implemented by the S server against DDoS attacks.
  • a client node Cm comprises a memory 101cm comprising a buffer memory, a processing unit 102c m , equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P, and controlled by the computer program 103c m , implementing steps of the method of allocating an identifier to a first client node in charge of managing the traffic associated with a client domain according to an embodiment of the 'invention.
  • the code instructions of the computer program 103c m are for example loaded into a RAM memory before being executed by the processor of the processing unit 102c m ⁇
  • the processor of the processing unit 102c m implements process steps allocation of the identifier described above, according to the instructions of the computer program 103 Cm , for:
  • a server S comprises a memory 101 s comprising a buffer memory, a processing unit 102 $ , equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P, and controlled by the computer program 103 $ , implementing steps of the method of registering an identifier according to an embodiment of the invention.
  • the code instructions of the computer program 103 $ are for example loaded into a RAM memory before being executed by the processor of the processing unit 102s.
  • the processor of the processing unit 102 $ implements steps of the method for registering an identifier described above, according to the instructions of the computer program 103 $ , for:

Landscapes

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

Abstract

Procédé d'allocation d'un identifiant à un nœud client, procédé d'enregistrement d'un identifiant, dispositif, nœud client, serveur et programmes d'ordinateurs correspondants. L'invention concerne un procédé d'allocation d'un identifiant à un premier nœud client d'un domaine client, ledit premier nœud client étant apte à gérer le trafic associé audit domaine client en vue de sa protection contre une attaque informatique, ledit procédé comprenant : - la réception d'une requête d'allocation d'un identifiant de nœud client en provenance du premier nœud client, ladite requête comprenant au moins une information d'identification du nœud client; - l'obtention d'une liste d'identifiants de nœuds clients déjà alloués aux nœuds clients actifs au moins dans le domaine client; - l'allocation audit premier nœud client d'un identifiant de nœud client n'appartenant pas à la liste obtenue; - l'enregistrement dans une mémoire locale d'une association entre l'identifiant alloué et l'information d'identification du premier nœud client; - l'émission d'une réponse à destination du premier nœud client, comprenant l'identifiant alloué; et - l'émission d'une requête d'enregistrement de l'identifiant alloué au premier nœud client dans le domaine à au moins un serveur de gestion du trafic associé au domaine.

Description

Procédé d'allocation d'un identifiant à un nœud client, procédé d'enregistrement d'un identifiant, dispositif, nœud client, serveur et programmes d'ordinateurs 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 protéger le réseau de communication et les terminaux raccordés à ce réseau contre les attaques informatiques.
En particulier, l'invention offre une solution permettant d'allouer un identifiant unique à un nœud client connecté au domaine client et d'enregistrer cet identifiant en association avec un identifiant du domaine client.
L'invention trouve notamment des applications dans le domaine de la mitigation d'attaques par déni de services distribuées (en anglais DDoS, pour « Distributed Déniai of Service »), mettant par exemple en œuvre, mais non exclusivement, une architecture de type DOTS (en anglais « DDoS Open Threat Signaling »), telle que normalisée par l'IETF.
2. Art antérieur et ses inconvénients
Pour rappel, une attaque DDoS est une tentative de rendre des ressources, par exemple des ressources réseau ou de calcul, indisponibles pour leurs utilisateurs. De telles attaques peuvent être massivement déployées en compromettant un grand nombre d'hôtes, et en utilisant ces hôtes pour amplifier les attaques.
Afin de pallier à ces attaques DDoS, des services de détection et de mitigation des attaques DDoS sont proposés par certains fournisseurs d'accès ou de services à leurs clients. De tels services de mitigation (en anglais DPS pour « DDoS Protection Services ») peuvent être hébergés au sein des infrastructures exploitées par les fournisseurs d'accès ou dans le « cloud » (en français « nuage »). Ils permettent notamment de distinguer le trafic « légitime », i.e., les données consenties par l'utilisateur, du trafic « suspect ».
Lorsqu'un service de type DPS est hébergé dans le « cloud », il est difficile d'identifier une attaque DDoS de façon anticipée, car un tel service n'est pas présent sur les chemins de routage (par défaut) permettant de joindre le réseau victime d'une attaque DDoS.
Pour résoudre ce problème, il a été notamment proposé de mettre en place des tunnels pour forcer le trafic (entrant ou sortant) sur un site ou un réseau destiné à être inspecté par le service DPS. Toutefois, cette approche augmente considérablement la latence observée par les utilisateurs et impose des contraintes de dimensionnement du service DPS pour être en mesure de traiter tout le trafic entrant ou sortant de tous les utilisateurs du réseau. De plus, les tunnels constituent des vecteurs d'attaque potentiels et avérés.
Lorsqu'un service de type DPS est hébergé au sein d'une infrastructure exploitée par un fournisseur d'accès, même si le service DPS est présent sur le chemin de routage du trafic entrant ou sortant d'un réseau, des difficultés peuvent survenir pour l'identification du trafic suspect. 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 outre rendre complexe la vérification 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, permet à un nœud client, dit client DOTS, d'informer un serveur, dit serveur DOTS, qu'il a détecté une attaque DDoS et que des actions appropriées sont requises pour contrer cette attaque.
Ainsi, si un domaine client est la cible d'une attaque DDoS, un client DOTS faisant partie de ce domaine client peut envoyer un message à un serveur DOTS pour demander de l'aide. Ce dernier coordonne, avec une entité de mitigation (en anglais « mitigator »), les actions à effectuer pour que le trafic 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. L'entité de mitigation peut être co-localisée avec le serveur DOTS.
Cette solution utilise deux canaux de communication entre un client DOTS et un 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 utilisé quand une attaque DDoS est en cours. Ainsi, un client DOTS peut utiliser ce canal pour demander de l'aide auprès d'un serveur DOTS. Par exemple, un client DOTS utilise ce canal de signalisation pour envoyer une requête au serveur l'informant que le préfixe « 1.2.3.0/24 » subit une attaque DDoS, afin que le serveur puisse engager des actions pour mettre fin à l'attaque. Une telle requête est associée à un client DOTS identifié par un identifiant unique, noté par exemple CUID (« Client Unique I Dentifier »).
Un serveur DOTS peut ainsi prendre les mesures adéquates pour mettre fin à une attaque DDoS d'une part si la requête émanant du client DOTS n'est pas en conflit avec d'autres demandes émanant d'autres clients DOTS du même domaine client, ou avec une règle de filtrage installée préalablement sur le serveur par un autre client DOTS du domaine client, et d'autre part si le serveur est habilité à/configuré pour honorer la dernière requête reçue. En cas de conflit, le serveur peut envoyer un message d'erreur, par exemple de type 4.09 (« Conflict »), pour informer le client DOTS.
Un tel canal de signalisation est notamment décrit dans le document « Distributed Denial- of-Service Open Threat Signaling (DOTS) Signal Channel Spécification », draft-ietf-dots-signal- channel, Reddy, T. et al., janvier 2018.
Le canal de données DOTS est quant à lui utilisé lorsqu'aucune attaque DDoS n'est en cours. Par exemple, un client DOTS peut utiliser ce canal pour installer des règles de filtrage, telles que le filtrage du trafic reçu de certaines adresses ou celui destiné à un 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 », ou tout le trafic UDP destiné au numéro de port 443.
Le serveur DOTS peut procéder à l'installation de règles de filtrage en réponse à une demande envoyée par un client DOTS, si cette demande n'est pas en conflit avec d'autres demandes provenant d'autres clients DOTS du même domaine client ou avec une règle de filtrage existante. En cas de conflit avec d'autres règles maintenues par le serveur DOTS, le serveur peut envoyer un message d'erreur, par exemple de type 409 (« Conflict »), pour informer le client DOTS.
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, Boucadair M. et al., décembre 2017.
Selon la procédure décrite dans les deux documents précités, il existe un risque qu'un serveur DOTS refuse de traiter une demande de mitigation d'attaque émise par un client DOTS alors que l'attaque est réelle, ou refuse des demandes de filtrage émises par un client DOTS (un objectif des demandes de filtrage étant d'anticiper des attaques DDoS). Un tel refus peut notamment survenir lorsque ces demandes de filtrage sont en conflit avec des règles de filtrage installées par d'autres clients DOTS d'un même domaine client.
Or la suppression de ces règles par un autre nœud client du même domaine est impossible et le nœud client à l'origine de la demande de mitigation d'attaque ne dispose d'aucune information concernant l'identité du nœud client qui a installé ces règles.
Il se peut aussi que ces règles ne soient désormais plus justifiées, car périmées (en anglais « stale ») et que le client DOTS à l'origine de ces règles ne se soit pas préoccupé de les désinstaller.
Par ailleurs, des complications peuvent avoir lieu en cas de collision entre les identifiants utilisés pas les clients DOTS d'un même domaine. Par exemple, la mitigation d'une attaque DDoS peut prendre plus de temps si le serveur DOTS détecte que l'identifiant utilisé par le client DOTS à l'origine de la requête de mitigation est en conflit avec celui d'un autre client DOTS du même domaine client.
Il existe donc un besoin pour une nouvelle technique, permettant d'améliorer la fiabilité et la sécurité des échanges entre les clients et le serveur DOTS et ainsi de mettre en place une protection efficace contre les attaques informatiques, notamment les attaques par déni de service.
3. Exposé de l'invention
Selon au moins un mode de réalisation, l'invention concerne un procédé d'allocation d'un identifiant à un premier nœud client d'un domaine client, ledit premier nœud client étant apte à gérer le trafic associé au domaine client en vue de sa protection contre une attaque informatique, ledit procédé comprenant :
la réception d'une requête d'allocation d'un identifiant de nœud client en provenance du premier nœud client, ladite requête comprenant au moins une information d'identification du nœud client ;
l'obtention d'une liste d'identifiants de nœuds clients déjà alloués aux nœuds clients actifs au moins dans le domaine client ;
l'allocation audit premier nœud client d'un identifiant de nœud client n'appartenant pas à la liste obtenue ;
l'enregistrement dans une mémoire locale d'une association entre l'identifiant alloué et l'information d'identification du premier nœud client ;
l'émission d'une réponse à destination du premier nœud client, comprenant l'identifiant alloué ; et
l'émission d'une requête d'enregistrement de l'identifiant alloué au premier nœud client dans le domaine à au moins un serveur de gestion du trafic associé au domaine.
L'invention propose ainsi une gestion contrôlée des identifiants utilisés par les nœuds clients d'un domaine client pour communiquer entre eux et avec un serveur de gestion du trafic associé au domaine client. Selon ce mode de réalisation, elle garantit l'unicité de l'identifiant alloué au premier nœud lorsqu'il devient actif dans le domaine et de ce fait, permet d'éviter les conflits d'identification entre nœuds actifs.
On note que le procédé peut être mis en œuvre par un autre nœud client, bénéficiant de privilèges dans le domaine client, dit client maître, ou par une instance logicielle dédiée, dite CMI (CUID Management Instance) qui s'interface avec le nœud client maître. Il peut aussi y avoir un ou plusieurs serveurs impliqués dans la mitigation d'attaques informatiques, par exemple de déni de service, subies par un même domaine client. Selon un mode de réalisation particulier, sur détection d'un événement relatif à une activité du domaine client, le procédé comprend une modification de l'association enregistrée dans la mémoire locale.
Ainsi, selon ce mode de réalisation, la gestion de l'identifiant alloué au premier nœud client est contrôlée pendant l'intégralité de la période de connexion du nœud au domaine client.
En particulier, l'événement détecté appartient à un groupe comprenant :
l'inactivité du premier nœud client ;
un comportement suspect du premier nœud client ;
la réception d'une requête de suppression reçue du premier nœud client ; et
un nombre de nœuds clients activés dans le domaine trop élevé par rapport à un nombre maximal autorisé.
On note que l'événement peut concerner aussi bien un changement dans l'activité du premier nœud client, ou dans la politique de sécurité ou d'administration du domaine client.
Selon un premier exemple de réalisation, la modification comprend la suppression de l'enregistrement, et le procédé comprend l'émission d'une requête d'annulation de l'enregistrement de l'identifiant alloué à destination du serveur.
Ainsi, ce premier exemple de réalisation permet la répercussion au niveau du serveur de la suppression de l'association (client, cuid). L'identifiant alloué au premier client est ainsi relâché et pourra être affecté à un autre nœud client actif.
Selon un deuxième exemple de réalisation, la modification comprend un remplacement, dans l'enregistrement de la mémoire locale, de l'information d'identification du premier client par une information d'identification d'un deuxième client du domaine.
Ainsi, ce deuxième mode de réalisation permet de faciliter le remplacement du premier nœud client par un deuxième, sans modification des actions de mitigation installées par le premier nœud client et, par conséquent, sans perturber l'exécution en cours de ces actions de mitigation. Le deuxième nœud client va reprendre le traitement des actions de mitigation précédemment mises en œuvre par le premier nœud client. Il n'est pas nécessaire, selon cet exemple, de répercuter cette modification au serveur, puisqu'il stocke déjà l'association correcte entre identifiant unique de nœud client et identifiant de domaine.
Selon un mode de réalisation particulier, la requête reçue comprenant en outre une requête d'allocation d'un attribut de délégation de gestion, ledit attribut étant destiné à être spécifié par un autre nœud client dans une requête de traitement d'une règle de gestion de trafic transmise au serveur pour déléguer au premier nœud client la gestion de ladite règle de gestion de trafic, le procédé comprend :
l'allocation d'un attribut de délégation au premier nœud client,
le stockage de l'attribut alloué avec l'association dans l'enregistrement, et
la réponse émise à destination du premier nœud client comprend l'attribut de délégation alloué.
Selon ce mode de réalisation, l'attribut de délégation peut être spécifié par le premier nœud client lors de l'installation d'une règle (filtrage, ACL, etc.) à l'issue de l'exécution d'une action de mitigation auprès du serveur, de façon à indiquer qu'il accorde une délégation sur l'action de mitigation. L'attribut de délégation est alors stocké par le serveur en association avec la règle installée. La connaissance de cet attribut de délégation alloué au premier nœud client peut être transmise à un autre nœud client afin de lui permettre de modifier la règle installée par le premier nœud client. Pour ce faire, le deuxième nœud client devra insérer la valeur de cet attribut de délégation dans sa requête de modification de la règle concernée et adressée au serveur.
Par exemple, la réponse comprend en outre l'attribut de délégation alloué à au moins un autre nœud client. De la sorte, plusieurs nœuds clients du domaine partagent le même attribut de délégation, ce qui leur permet d'intervenir sur une règle installée par un autre nœud client lorsque c'est nécessaire. Un avantage de cette solution est d'être simple et d'optimiser le service de protection.
Au contraire, lorsque la réponse reçue du nœud client maître ou de l'entité CMI ne comprend pas d'attribut de délégation, cela signifie que le nœud client maître ou l'entité CMI souhaite désactiver la procédure de délégation, par exemple parce qu'elle induit une charge trop importante sur certains nœuds clients du domaine.
Dans un autre mode de réalisation, l'invention concerne un procédé d'enregistrement d'un identifiant alloué à un nœud client apte à gérer le trafic associé à un domaine client en vue de sa protection contre une attaque informatique, mis en œuvre dans un serveur, le procédé comprenant :
la réception d'une requête d'enregistrement d'un premier nœud client, ladite requête comprenant un identifiant du premier nœud client, ledit identifiant ayant été alloué au premier nœud client conformément au procédé d'allocation tel que décrit précédemment ; l'obtention d'un identifiant du domaine client auquel appartient le nœud client ; et l'enregistrement dans une mémoire de l'identifiant du premier nœud client associé à l'identifiant du domaine client obtenu. Selon ce mode de réalisation, l'invention propose d'enregistrer au niveau du serveur une association entre l'identifiant unique alloué au nœud client et l'identifiant du domaine client, ce qui permet de sécuriser les échanges entre les nœuds clients et le serveur pour gérer le trafic associé au domaine client et de garantir l'unicité globale de l'identifiant constitué de la paire {CUID, CDID}.
En particulier, sur réception d'une requête de traitement d'une règle de gestion de trafic émise par le nœud client, ladite requête comprenant l'identifiant du premier nœud client, le procédé comprend la recherche dudit enregistrement dans une mémoire et le rejet de la requête si ledit enregistrement n'a pas été trouvé.
La détection d'un nœud client malveillant appartenant par exemple à un autre domaine client est ainsi facilitée, et il est possible de rejeter la requête si le nœud est malveillant.
Selon un mode de réalisation particulier, lorsque la requête de traitement comprend une demande de modification d'une règle de gestion de trafic installée par un deuxième nœud client, le procédé comprend :
la vérification d'une délégation de gestion par comparaison d'un premier attribut de délégation de gestion spécifié dans la demande de modification de la règle de gestion de trafic et d'un deuxième attribut de délégation de gestion associé à la règle de gestion de trafic installée par le deuxième nœud client dans un enregistrement stocké en mémoire ; lorsque le premier et le deuxième attributs de délégation ont la même valeur, modification de la règle de gestion de trafic conformément à la demande.
Cette procédure de délégation permet ainsi de faire migrer la gestion d'une action de mitigation en cas d'indisponibilité du nœud client à l'origine de son installation. Elle est particulièrement intéressante, en cas d'attaque, lorsqu'un nœud client a préalablement émis une requête de mitigation au serveur qui lui a répondu qu'il existait un conflit entre sa requête et au moins une règle déjà installée par un autre nœud client suite à l'exécution d'une action de mitigation. Avec l'invention, le nœud client qui détecte l'attaque peut mettre à profit la procédure de délégation pour demander au serveur de modifier la règle de sorte qu'elle ne fasse plus obstacle à la mitigation de l'attaque en cours. La fiabilité du service de mitigation d'attaques est donc accrue.
En particulier, sur réception d'une demande de suppression d'enregistrement de l'identifiant du premier nœud client, le procédé comprend la suppression dudit enregistrement et la suppression des règles de gestion de trafic installées par le premier nœud client. Selon un mode de réalisation particulier, le procédé d'enregistrement d'un identifiant comprend la notification des autres noeuds clients actifs dans le domaine client, préalablement à ladite suppression des règles de gestion de trafic installées par le premier nœud client.
Il est ainsi possible d'informer les autres nœuds clients de la suppression imminente de règles installées par un client pour la mitigation d'une attaque, est de leur donner la possibilité de demander au serveur de les migrer à leur profit.
Selon un autre mode de réalisation, l'invention concerne un dispositif d'allocation d'un identifiant à un premier nœud client apte à gérer le trafic associé à un domaine client en vue de sa protection contre une attaque informatique, ledit dispositif comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée et configurée pour mettre en œuvre :
la réception d'une requête d'allocation d'un identifiant de nœud client en provenance du premier nœud client, ladite requête comprenant au moins une information d'identification du nœud client ;
l'obtention d'une liste d'identifiants de nœuds clients déjà alloués à des nœuds clients actifs au moins dans le domaine client ;
l'allocation au premier nœud client d'un identifiant de nœud client n'appartenant pas à la liste obtenue ;
l'enregistrement dans une mémoire locale d'une association entre l'identifiant alloué et l'information d'identification du premier nœud client ;
l'émission d'une réponse à destination du premier nœud client, comprenant l'identifiant alloué ; et
l'émission d'une requête d'enregistrement de l'identifiant alloué au premier nœud client dans le domaine à au moins un serveur de gestion du trafic associé au domaine.
D'autres modes de réalisation concernent un nœud client et un serveur 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é 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 d'un procédé selon au moins un mode de réalisation de l'invention. Les procédés selon l'invention peuvent donc être mis en oeuvre de diverses manières, notamment sous forme câblée et/ou sous forme logicielle.
4. Liste des figures
D’autres buts, caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
la figure 1 illustre un exemple de réseau de communication mettant en oeuvre un procédé d'allocation d'un identifiant d'un nœud client et un procédé d'enregistrement d'un identifiant, selon un mode de réalisation de l'invention ;
la figure 2 présente les principales étapes du procédé d'allocation d'un identifiant selon un mode de réalisation de l'invention ;
la figure 3 présente les principales étapes du procédé d'enregistrement d'un identifiant selon un mode de réalisation de l'invention ;
les figures 4A et 4B illustrent des exemples de messages échangés entre un premier nœud client, un client maître et un serveur pour l'allocation d'un identifiant au premier client d'un domaine client et son enregistrement selon un mode de réalisation de l'invention ;
les figures 5A et 5B illustrent des exemples d'application de l'invention pour fiabiliser les échanges entre les nœuds clients et le serveur ;
les figures 6A à 6D illustrent des exemples de messages échangés entre le premier nœud client, le client maître et le serveur pour supprimer l'identifiant alloué au premier nœud client selon un mode de réalisation de l'invention ;
La figure 7 détaille les étapes mises en œuvre par le serveur pour traiter une requête de modification par un premier nœud client d'une action de gestion installée par un deuxième nœud client, selon un mode de réalisation de l'invention ;
Les figures 8A à 8B illustrent la résolution d'un conflit entre actions de gestion de trafic selon un mode de réalisation de l'invention ;
Les figures 9A à 9C illustrent des exemples de messages échangés pour la mise en place d'une procédure de délégation entre nœuds clients selon un mode de réalisation de l'invention ; et
La figure 10 illustre de façon schématique la structure matérielle d'un nœud client et d'un serveur selon un mode de réalisation de l'invention.
5. Description détaillée de modes de réalisation de l’invention Le principe général de l'invention repose sur l'allocation d'un identifiant unique à un nœud client faisant partie d'un domaine client, mais également sur l'enregistrement de cet identifiant en association avec un identifiant du domaine client, et sur l'utilisation de cet identifiant unique pour rendre plus efficace et plus fiable la protection contre des attaques de déni de service au sein du domaine.
On présente, en relation avec la figure 1, différents équipements d'un réseau en charge de la protection du réseau et des terminaux qui y sont connectés contre des attaques informatiques, et mettant en œuvre un procédé d'allocation d'un identifiant selon un mode de réalisation de l'invention.
Par exemple, le domaine client 11 comprend une ou plusieurs machines, encore appelées nœuds. On entend ici par « domaine » un ensemble de machines ou nœuds placés sous la responsabilité d'une même entité. On considère par exemple plusieurs nœuds clients Cl, C2, Cm appartenant au domaine client 11, communiquant avec un serveur S 12.
Selon l'exemple illustré, le serveur 12 n'appartient pas au domaine client 11. Selon un autre exemple non illustré, le serveur 12 peut appartenir au domaine client 11.
Dans la suite de la description, on considère le cas d'une architecture de type DOTS, selon laquelle les nœuds clients Cl, C2 et Cm 114 sont des clients DOTS et le serveur S est un serveur DOTS. Les nœuds clients Cl, C2 et Cm et le serveur S peuvent ainsi communiquer via les canaux de signalisation et de données DOTS définis en relation avec l'art antérieur, pour informer le serveur qu'une attaque DDoS a été détectée et que des actions appropriées sont requises.
5.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 client,
un message de signalisation pour solliciter la mitigation d'une attaque de déni de service auprès d'un serveur DOTS, le serveur pouvant, sur réception d'un tel message, déclencher les actions nécessaires pour mettre fin à l'attaque, ou
un message de gestion de règles de gestion de trafic, par exemple de filtrage, comprenant une requête auprès d'un serveur DOTS pour qu'il installe (ou fasse installer), modifie ou encore supprime une liste de contrôle d'accès (ACL pour « Access Control List ») pour la mitigation d'une attaque. Dans la suite, on désignera par « requête de traitement» une demande d'installation d'une ou plusieurs règles de filtrage explicites, d'une liste de contrôle d'accès, et plus généralement de toute action qu'un nœud client DOTS peut solliciter du serveur pour la mitigation d'une attaque et plus généralement, l'application d'une politique de sécurité ciblant le domaine qui héberge le client DOTS.
Une requête DOTS peut être envoyée d'un client DOTS, appartenant à un domaine client DOTS, à un serveur DOTS ou à une pluralité de serveurs DOTS. Un domaine DOTS peut accueillir un ou plusieurs clients DOTS. En d'autres termes, plusieurs nœuds client d'un domaine client peuvent disposer de fonctions DOTS.
Les communications DOTS entre un domaine client et un domaine serveur peuvent être directes, ou établies via des passerelles DOTS (en anglais « DOTS gateways »), non représentées. Ces passerelles peuvent être hébergées au sein du domaine client, du domaine serveur, ou des deux. En d'autres termes, un nœud client du domaine client peut communiquer directement avec le serveur, ou transmettre une requête à une passerelle du domaine client qui communique directement avec le serveur ou avec une passerelle du domaine serveur, ou transmettre une requête à une passerelle du domaine serveur qui communique avec le serveur.
Une passerelle DOTS localisée dans un domaine client est considérée par un serveur DOTS comme un client DOTS.
Une passerelle DOTS localisée dans un domaine serveur est considérée par un client DOTS comme un serveur DOTS. En cas de présence d'une passerelle DOTS dans un domaine serveur, l'authentification des clients DOTS peut être confiée à la passerelle DOTS du domaine serveur. Un serveur DOTS peut être configuré avec la liste des passerelles DOTS actives au sein de son domaine et le serveur peut déléguer certaines de ses fonctions à ces passerelles de confiance. En particulier, le serveur peut utiliser en toute sécurité les informations fournies par une passerelle figurant dans une liste déclarée auprès du serveur et maintenue par celui-ci, moyennant une procédure d'authentification ad hoc (par exemple, configuration explicite de la liste par l'administrateur habilité du serveur, récupération de la liste auprès d'un serveur 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 Spécification » précité. Dans la suite, on suppose que les agents DOTS (client(s), serveur(s)) s'authentifient mutuellement. Il existe donc un canal de communication sécurisé, par exemple de type DTLS/TLS (pour « (Datagram) Transport Layer Security »), entre un client DOTS et un serveur DOTS.
Ainsi, les messages reçus d'un autre serveur usurpant l'adresse IP du serveur 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 sont ignorées par le serveur DOTS. On suppose dans la suite que cette procédure est mise en place par les agents DOTS.
Les détails des échanges DTLS/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.
5.2 Exemples d'application dans le domaine des services de mitigation (DPS)
La figure 2 illustre les principales étapes du procédé d'allocation d'un identifiant à un premier nœud client Cl selon un mode de réalisation de l'invention. Ce procédé peut être mis en œuvre par un autre nœud client du domaine client, bénéficiant de privilèges auprès du serveur S, dit client maître Cm, ou par une nouvelle instance logicielle dédiée, dite CMI (pour « CUID Management Instance », en anglais) qui s'interface avec un nœud client maître CL Dans la suite, on suppose que le procédé d'allocation d'un identifiant est mis en œuvre par le client maître Cm du domaine client 11. Cependant, le même procédé s'applique quand cette fonction est remplie par ladite entité dédiée CMI.
Au démarrage du client DOTS Cl, celui-ci contacte son client maître Cm ou l'instance CMI pour demander en 21 l'allocation d'un identifiant de client DOTS ou cuid. Pour ce faire, le client DOTS Cl émet un message de requête d'allocation MREQID ou GET() à destination du client maître Cm, comme illustré par la Figure 4A. Dès réception du message MREQID ou GET() par le client maître Cm DOTS (ou l'instance CMI), ce dernier vérifie que ce client Cl est autorisé à invoquer le service DOTS. Le cas échéant, le client maître Cm obtient en 22 une liste des identifiants actuellement utilisés dans le domaine, par exemple en consultant une table stockée en mémoire, et choisit en 23 un identifiant cuid_cl qui ne fait pas partie de cette liste. De la sorte, le client DOTS Cm (ou l'instance CMI) s'assure par défaut que deux clients du domaine client n'utilisent pas le même identifiant 'cuid'. On notera que cette contrainte peut être relâchée pendant les phases de sécurisation ou de remplacement d'un client DOTS par un autre. Une fois l'identifiant cuid_cl choisi, le client maître Cm enregistre en 24 la paire formée par l'identifiant unique alloué et l'identifiant du client Cl en mémoire, par exemple une mémoire locale. Ensuite, et afin d'améliorer la robustesse du service DOTS, le client maître DOTS Cm contacte en 25 le serveur S en 27Cm pour enregistrer le nouvel identifiant activé au sein du domaine client DOTS pour le client Cl. Comme illustré par la Figure 4B, il le fait par exemple à l'aide d'un message de requête d'enregistrement MREQREG() ou REGISTER_REQ(). Ce message peut inclure les identifiant(s) DOTS cuid du client Cl seul ou de plusieurs clients.). Sur réception d'un message de confirmation MREPREG() ou REGISTER_ACK() du serveur S, il envoie en 26 au client Cl un message d'acquittement MREPID ou SET(cuid_cl) comprenant l'identifiant cuid_cl qu'il lui a alloué, comme illustré par la Figure 4A. Sur réception d'une réponse de rejet de la part du serveur S, le client Cm peut réitérer le processus afin de réallouer un nouvel identifiant au client Cl et redemander l'enregistrement du nouvel identifiant cuid_cl au serveur S.
Optionnellement, sur détection d'un événement intervenant dans le domaine client, comme l'inactivité du nœud client Cl, ou sa déconnexion ou encore un changement dans la politique de sécurité du domaine client en 27, il modifie en 28 au moins localement l'enregistrement de l'identifiant cuid_cl.
En relation avec la figure 3, on décrit maintenant les étapes d'un procédé de d'enregistrement d'un identifiant alloué à un nœud client, mis en œuvre par le serveur S selon un mode de réalisation de l'invention. Sur réception en 31 d'une requête d'enregistrement MREQREG() ou REGISTER_REQ d'un identifiant cuid_cl pour le client Cl du domaine client 11 en provenance du client maître Cm, comme illustré par la Figure 4B, le serveur S procède aux vérifications de sécurité (non représentées) déjà évoquées. En cas de succès, il obtient en 32 un identifiant 'cdid' (pour « Client Domain I Dentifier », en anglais) du domaine client 11 auquel est rattaché le client Cl. A titre d'exemple, un serveur DOTS identifie les clients DOTS appartenant à un même domaine par l'attribut cdid. D'autres mécanismes pour l'identification du domaine client peuvent être supportés par le serveur. L'identifiant de domaine peut être calculé localement par le serveur ou communiqué par une autre entité de confiance (typiquement, un relais DOTS de son domaine serveur), ou les deux. Aucune hypothèse n'est faite quant à la structure du cdid. Il vérifie ensuite en 33 si une association entre cet identifiant de client cuid_cl et cet identifiant de domaine 'cdid' est déjà stockée en mémoire. S'il en trouve une, il rejette la requête d'enregistrement en 35 en renvoyant au client maître une réponse de rejet MREPREQ(rej). S'il n'en trouve pas, il traite la requête d'enregistrement en 34 en stockant la paire (cuid, cdid) du client Cl en mémoire M2. Il acquitte ensuite la requête d'enregistrement avec un message MREPREG(ack) ou REGISTER-ACK(), comme illustré par la Figure 4B.
Optionnellement, sur réception en 36 d'une requête de traitement MREQT pour la mise en œuvre d'une solution de mitigation, telle que l'installation d'une règle de gestion de trafic du type filtrage du trafic Rk, cette requête émanant d'un client identifié par l'identifiant cuid_cl, le serveur vérifie en 37 que l'identifiant cuid_cl est valablement enregistré dans sa mémoire en association avec l'identifiant du domaine client d'où provient la requête. En cas de succès, il traite la requête en 38, sinon il la rejette. On note que la procédure de vérification selon l'invention mise en oeuvre par le serveur DOTS pour traiter une requête DOTS émanant d'un client DOTS rend le service plus fiable même en cas de vol des identités de sécurité par une entité malveillante. On présente en relation avec la Table 1 un exemple d'extrait d'une liste de clients DOTS telle que maintenue par un client DOTS maître Cm. La table indique trois clients DOTS actifs pour ce domaine. L'invention ne suppose pas de structure particulière pour les tables maintenues par l'instance CMI/client maître DOTS.
Table 1
On notera que dans le cas où le procédé selon l'invention est mis en oeuvre par une entité logicielle CMI, les informations concernant l'allocation de l'identifiant du client DOTS sont communiquées par l'instance CMI au client maître DOTS Cm.
On présente ci-après un exemple d'extrait d'une requête d'enregistrement MREPREG transmise par le client maître Cm au serveur S. Dans cet exemple, la requête PUT est relayée par un relais DOTS du domaine serveur. Le nœud client relais insère l'information "cdid=here. example" pour communiquer au serveur l'identité du domaine du client DOTS. Cette information est notamment exploitée par le serveur pour l'application de politiques telles que l'application de quota ou la limitation du nombre de requêtes par domaine.
On présente aussi, en relation avec la Table 2, un exemple d'extrait d'une liste de clients telle que maintenue par le serveur S. La table indique 5 clients DOTS actifs dont 3 appartenant au domaine « here. example » du client maître Cm.
Table 2
Pour illustrer les avantages du procédé d'allocation d'identifiant unique selon l'invention, on considère les exemples de situation des Figures 5A et 5B.
Dans ces deux exemples, le client maître Cl procède d'abord à l'enregistrement auprès du serveur S de l'identifiant cuid_c3 qu'il a alloué au client C3. Comme précédemment décrit, le serveur S, sur réception de la requête REGISTER_REQ(cuid_c3), vérifie que cet identifiant est bien unique dans le domaine client 11 identifié par son identifiant unique cdid = « here. example » et, si c'est le cas, stocke en mémoire l'association (cuid_c3, cdid).
En relation avec la Figure 5A, si un client DOTS malveillant C4 appartenant à un autre domaine 12 contacte le serveur S, en demandant la mise en oeuvre d'une action de gestion au nom du client C3, c'est-à-dire en utilisant son identifiant cuid_c3, le serveur détecte que l'association (cuid_c3, cdid) est erronée et il rejette la requête.
En relation avec la Figure 5B, si un client DOTS malveillant C2 faisant partie du même domaine 11 que le client C3 et que le client maître Cm, contacte le serveur S pour une demande de mitigation d'une attaque, sa requête sera rejetée par le serveur S, parce que ce client C2 n'est pas enregistré valablement auprès de lui.
En relation avec les Figures 6A à 6C, on détaille maintenant les étapes 27 de détection d'un événement de gestion du trafic associé au domaine client et 28 de modification de l'association d'identifiants enregistrée dans la mémoire locale du client maître ou de l'entité CMI, selon un premier mode de réalisation de l'invention.
On suppose que l'événement détecté en 27 est un événement relatif à un changement dans l'activité des noeuds clients enregistrés dans le domaine ou dans la politique de sécurité appliquée au sein du domaine. Selon l'invention, un nœud client maître Cm exploite les identifiants uniques pour réagir à cet événement. Il s'agit par exemple de :
l'inactivité d'un nœud client pendant une période prédéterminée ;
la décision de l'administrateur du domaine client de réduire le nombre de clients DOTS activés au sein du domaine ;
le comportement suspect d'un nœud client DOTS ;
la demande explicite de suppression d'enregistrement en provenance d'un nœud client DOTS du domaine client 11.
Suite à cette détection, le client maître Cm peut décider de supprimer l'enregistrement d'un ou plusieurs nœuds clients auprès du serveur S.
Pour ce faire, comme illustré par la Figure 6A, il envoie un message de requête de suppression d'enregistrement MREQUNREG ou UNREGISTER_REQ(). Le message de suppression de l'enregistrement peut inclure un ou plusieurs identifiants de clients DOTS d'un domaine client. Dès réception de ce message, le serveur DOTS S procède à la suppression des clients listés dans ses tables (après les vérifications de sécurité d'usage).
En relation avec la Figure 6B, l'événement détecté par le client maître Cm est la réception d'une demande explicite de suppression d'enregistrement de la part d'un nœud client Cl du domaine client. Sur réception de la requête MREQSUP() ou DELETE(cuid_cl), le client maître Cm procède à la modification de l'enregistrement de l'identifiant du client Cl.
Deux options sont envisagées :
Selon une première option, illustrée par la Figure 6B, le client maître Cl acquitte la requête du client Cl par un message de réponse MREPSUP(ack) et transmet une requête de suppression d'enregistrement MREQUNREG() du client Cl au serveur S. Ce dernier supprime l'association (cuid_cl, cdid) de sa table et répond au client maître Cm par un message d'acquittement. L'identifiant cuid_cl est ainsi libéré au niveau du serveur S, lequel va ensuite supprimer les actions installées avec cet identifiant.
Selon une variante illustrée par la Figure 6C, avant de supprimer les règles de gestion de trafic installées avec l'identifiant qui vient d'être libéré, le serveur DOTS S informe les autres clients du domaine de l'existence de ces règles, de sorte qu'ils puissent les réinstaller. Dans un exemple de réalisation, on suppose que les agents DOTS (clients et serveurs) supportent le mécanisme « RESTCONF and HTTP Transport for Event Notifications », tel que spécifié dans le document «RESTCONF Transport for Event Notifications, draft-ietf-netconf- restconf-notif, E. Voit et al., sept. 2018 ».
Quand le client C2 se déconnecte ou quand le serveur détecte une inactivité du client C2 pendant une période donnée, celui-ci identifie les filtres associés à ce client C2, et notifie ensuite les autres noeuds clients du même domaine client tels que Cl de son intention de supprimer les règles de gestion de trafic associées au client C2.
Sur réception de cette notification, le client Cl peut décider de prendre la responsabilité de certaines règles initialement associées au client C2. Pour ce faire, il transmet une requête de type POST au serveur S pour lui demander de migrer vers son nom certaines règles du client C2. Le serveur S procède à la migration de ces règles, et envoie un message d'acquittement de type « 204 created » au client Cl (i.e., l'identifiant du nœud client Cl sera maintenu par le serveur comme étant responsable de la gestion de ces règles).
Si aucune réponse n'est reçue des autres clients du domaine client, la suppression des filtres est confirmée par le serveur S.
Selon une deuxième option, illustrée par la Figure 6D, le client maître Cm acquitte la requête du client Cl par un message de réponse MREPSUP(ack). Pour éviter de perturber le fonctionnement du domaine DOTS 11, il ne demande pas au serveur S de supprimer l'enregistrement de l'identifiant cuid_cl du client Cl, mais il réalloue cet identifiant à un autre client C2 du domaine 11. De la sorte, il remplace le client Cl par un autre client du domaine sans affecter l'état maintenu par le serveur S.
Lorsque le client C2 émet une requête de traitement, comme par exemple l'installation d'une règle de filtrage auprès du serveur S, en s'identifiant avec l'identifiant cuid_cl, le serveur peut accepter sa requête car le client C2 est valablement identifié.
Ainsi, l'allocation d'un identifiant unique à chaque client d'un domaine client réalisée par le procédé selon l'invention fiabilise les échanges entre les agents DOTS et rend plus robuste la protection, par le client maître Cm situé dans le domaine client 11, du domaine client contre les attaques, et cela même en cas de déconnexion de certains nœuds clients d'un même domaine client. En relation avec la Figure 7, on détaille maintenant les étapes 36 à 38 de réception et de traitement d'une requête de modification d'une règle de gestion de trafic mise en oeuvre par le serveur S selon un deuxième mode de réalisation de l'invention.
Le serveur S reçoit en 36 une requête de traitement d'une règle Rk en provenance du client Cl.
Il vérifie en 37 que l'identifiant cuid_cl est bien enregistré en association avec l'identifiant du domaine client cdid. Le cas échéant, il recherche en 371 un enregistrement associant l'identifiant cuid_cl à la règle Rk identifiée par l'attribut rk. Si c'est le cas, le client Cl est à l'origine de l'installation de la règle Rk qu'il souhaite modifier. Le serveur S procède à la modification demandée en 38.
Sinon, il réalise en 372 une vérification supplémentaire, qui consiste à chercher un enregistrement associant à la règle Rk l'attribut de délégation « THIRD_PARTY_NONCE » du client Cl. S'il le trouve, le serveur S considère que le client Cl bénéficie d'une délégation de la part du client C2 pour modifier la règle Rk et il procède à la modification demandée en 38.
Concrètement, ce nouvel attribut « THIRD_PARTY_NONCE » est renseigné par le client DOTS C2 lors de la création de la règle Rk auprès du serveur S. Cet attribut inclut un identifiant unique, tel que l'identifiant cuid_cl du client Cl.
Cette procédure de délégation permet à un nœud client du domaine client de modifier des actions installées par un autre client de ce domaine client, telles que par exemple des règles de filtrage de trafic périmées ou en conflit avec l'installation d'autres règles de filtrage, par exemple pour la mise en place d'une solution de mitigation contre une attaque DDoS.
On détaille maintenant la mise en place d'une procédure de délégation selon l'invention en considérant l'exemple des nœuds clients Cl et C2 du domaine client 11. On suppose que Cl et C2 activent la procédure de délégation des opérations DOTS pour fiabiliser le service en cas d'indisponibilité de l'un d'eux, en cas de conflit, etc. La procédure de délégation peut être activée de plusieurs manières :
selon une première option, la délégation est activée seulement par le client Cl au profit du client C2. Le client C2 ne désigne pas le client Cl comme bénéficiaire d'une délégation ; selon une deuxième option, la délégation est activée par les deux clients : Cl délègue à C2 et vice versa. Deux variantes sont envisagées :
o la même valeur de l'attribut THIRD_PARTY_NONCE est utilisée par les deux clients o des valeurs distinctes sont utilisées par chacun des clients. A des fins d'illustration, on présente ci-après un exemple de requête d'installation d'une action de gestion « my_acl », pour laquelle le nœud client C2 identifié par l'identifiant cuid_c2, précise au serveur qu'il supporte la délégation en indiquant la valeur « 263afd79-835c-4ee7-9535- df245cf28d9a » pour l'attribut TFIIRD_PARTY_NONCE dans sa requête.
On suppose maintenant que le nœud client Cl détecte que la machine dont l'adresse IP est
« 1.2.3.1/32 » subit une attaque, comme illustré par la Figure 8A.
En relation avec la Figure 8B, le nœud client Cl sollicite le serveur S pour qu'il mette en place une solution de mitigation de cette attaque en envoyant en 81C1 le message suivant :
Sur réception en 82S de cette requête, le serveur S procède en 83S aux vérifications de sécurité et d'enregistrement du nœud client Cl déjà décrites, puis décide en 84S d'une action à mettre en place. Il s'agit par exemple d'installer une nouvelle règle de filtrage Rk2. Lorsqu'il tente d'installer cette règle, il détecte en 85S un conflit avec la règle de filtrage Rk = « my_acl » déjà installée par le nœud client C2.
Il envoie en 86S un message d'erreur 4.09 (Conflict) au nœud client Cl pour l'informer de l'existence de ce conflit avec la règle de filtrage Rk = "my-acl".
Le nœud client Cl reçoit ce message d'erreur en 87C1. Contrairement à l'état de l'art, le nœud client Cl renvoie en 88C1 une requête de modification de la règle de filtrage Rk au serveur SI pour résoudre le conflit. Dans cet exemple, on suppose que le nœud client Cl ajoute une nouvelle entrée à la règle existante « my-acl » pour bloquer seulement le trafic destiné à l'adresse « 1.2.3.1/32 ». Par exemple, la requête de modification de Rk qu'il adresse au serveur SI prend la forme suivante :
On note qu'elle spécifie la valeur de l'attribut THIRD_PARTY_NONCE. Dès réception de ce message par le serveur DOTS S en 89S, ce dernier vérifie que la valeur de l'attribut "THIRD_PARTY_NONCE" (263afd79-835c-4ee7-9535-df245cf28d9a) est identique à celle indiquée par le client C2 lors de la création de la règle de filtrage Rk= "my-acl" et que les deux clients Cl et C2 appartiennent au même domaine client DOTS 11. Suite à cette vérification, le serveur DOTS S décide de modifier le filtre comme demandé par le nœud client Cl. Le trafic DDoS est alors bloqué comme illustré par la Figure 8C. L'invention permet ainsi de résoudre le conflit sans solliciter le nœud client C2.
Selon un troisième mode de réalisation de l'invention, la valeur de l'attribut "THIRD_PARTY_NONCE" est allouée par l'instance CMI/client maître Cm, en même temps que l'identifiant 'cuid'. La valeur de l'attribut de délégation peut être obtenue par configuration statique ou dynamique, par exemple, via le protocole DHCP.
En relation avec la Figure 9A, le nœud client Cl transmet une requête d'allocation MREQID() ou GET(cuid, THIRD_PARTY_NONCE) d'un identifiant 'cuid_cl' et d'un attribut de délégation.
Avantageusement, l'instance CMI ou le nœud client maître Cm peut désactiver cette procédure de délégation en ne retournant aucune valeur d'attribut de délégation au client Cl comme illustré par la Figure 9B. Concrètement, l'absence de l'attribut THIRD_PARTY_NONCE dans la réponse reçue du CMI est une indication explicite pour informer le nœud client Cl que la procédure de délégation DOTS est désactivée.
En effet, la procédure de délégation peut induire une surcharge de calcul pour le nœud client qui prend le relais d'un autre nœud client pour la gestion de ses actions en cours. Si la charge dudit nœud relais atteint un certain seuil, par exemple 80% de l'unité centrale de traitement ou CPU (pour « Central Processing Unit », en anglais), la procédure de délégation pourrait alors être désactivée. L'entité en charge de l'activation de la procédure de délégation peut notamment être informée d'un dépassement de seuil par des moyens de notification classiques tels qu'un « trap SNMP ».
Selon une variante de réalisation, illustrée par la Figure 9C, le nœud client maître indique dans sa réponse au nœud client Cl, non seulement la valeur de l'attribut de délégation qu'il lui a allouée, mais aussi celle qu'il a allouée aux autres nœuds clients du même domaine client. On comprend que dans ce cas, tous les nœuds clients du domaine client partagent la même valeur d'attribut de délégation.
Ainsi, comme illustré par les différents modes de réalisation de l'invention qui viennent d'être décrits, l'enregistrement par le serveur S d'une association entre l'identifiant unique alloué au nœud client par le nœud client maître ou l'entité CMI, et l'identifiant du domaine client 11, non seulement fiabilise les échanges entre les agents DOTS, mais facilite et rend plus robuste la protection mise en œuvre par le serveur S contre les attaques DDoS.
5.3 Structures
On présente finalement, en relation avec la figure 10, les structures simplifiées d'un nœud client et d'un serveur selon l'un des modes de réalisation décrits ci-dessus.
Selon un mode de réalisation particulier, un nœud client Cm comprend une mémoire 101cm comprenant une mémoire tampon, une unité de traitement 102cm, é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 103cm, mettant en œuvre des étapes du procédé d'allocation d'identifiant à un premier nœud client en charge de la gestion du trafic associé à un domaine client selon un mode de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur 103cm sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 102cm·
Le processeur de l'unité de traitement 102cm met en œuvre des étapes du procédé d'allocation d'identifiant décrit précédemment, selon les instructions du programme d'ordinateur 103Cm, pour :
recevoir une requête d'allocation d'un identifiant de nœud client en provenance du premier nœud client, ladite requête comprenant au moins une information d'identification du nœud client;
obtenir une liste d'identifiants de nœuds clients déjà alloués aux nœuds clients actifs au moins dans le domaine client ;
allouer audit premier nœud client d'un identifiant de nœud client n'appartenant pas à la liste obtenue ;
enregistrer dans une mémoire locale une association entre l'identifiant alloué et l'information d'identification du premier nœud client ;
émettre une réponse à destination du premier nœud client, comprenant l'identifiant alloué ; et
émettre une requête d'enregistrement de l'identifiant alloué au premier nœud client dans le domaine à au moins un serveur de gestion du trafic associé au domaine.
Selon un mode de réalisation particulier, un serveur S comprend une mémoire 101s comprenant une mémoire tampon, une unité de traitement 102$, é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 103$, mettant en œuvre des étapes du procédé d'enregistrement d'un identifiant selon un mode de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur 103$ sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 102s.
Le processeur de l'unité de traitement 102$ met en œuvre des étapes du procédé d'enregistrement d'un identifiant décrit précédemment, selon les instructions du programme d'ordinateur 103$, pour :
recevoir une requête d'enregistrement d'un premier nœud client, ladite requête comprenant un identifiant du premier nœud client, ledit identifiant ayant été alloué au premier nœud client par le nœud client Cm selon l'invention;
obtenir un identifiant du domaine client auquel appartient le nœud client ;
enregistrer dans une mémoire l'identifiant du premier nœud client associé à l'identifiant du domaine client obtenu.

Claims

REVENDICATIONS
1. Procédé d'allocation d'un identifiant à un premier nœud client d'un domaine client, ledit premier nœud client étant apte à gérer le trafic associé audit domaine client en vue de sa protection contre une attaque informatique, ledit procédé comprenant :
la réception (21) d'une requête d'allocation d'un identifiant de nœud client en provenance du premier nœud client, ladite requête comprenant au moins une information d'identification du nœud client ;
l'obtention (22) d'une liste d'identifiants de nœuds clients déjà alloués aux nœuds clients actifs au moins dans le domaine client ;
l'allocation (23) audit premier nœud client d'un identifiant de nœud client n'appartenant pas à la liste obtenue ;
l'enregistrement (24) dans une mémoire locale d'une association entre l'identifiant alloué et l'information d'identification du premier nœud client ;
l'émission (26) d'une réponse à destination du premier nœud client, comprenant l'identifiant alloué ; et
l'émission (25) d'une requête d'enregistrement de l'identifiant alloué au premier nœud client dans le domaine à au moins un serveur de gestion du trafic associé au domaine.
2. Procédé d'allocation d'un identifiant selon la revendication 1, caractérisé en ce que, sur détection d'un événement relatif à une activité du domaine client, le procédé comprend une modification (28) de l'association enregistrée dans la mémoire locale.
3. Procédé d'allocation d'un identifiant selon la revendication 2, caractérisé en ce que l'événement détecté appartient à un groupe comprenant :
l'inactivité du premier nœud client ;
un comportement suspect du premier nœud client ;
la réception d'une requête de suppression reçue du premier nœud client ; et un nombre de nœuds clients activés dans le domaine trop élevé par rapport à un nombre maximal autorisé.
4. Procédé d'allocation d'un identifiant selon l'une des revendications 2 ou 3, caractérisé en ce que la modification comprend la suppression de l'enregistrement, et en ce que le procédé comprend l'émission d'une requête d'annulation de l'enregistrement de l'identifiant alloué à destination du serveur.
5. Procédé d'allocation d'un identifiant selon la revendication 2, caractérisé en ce que la modification comprend un remplacement, dans l'enregistrement de la mémoire locale, de l'information d'identification du premier client par une information d'identification d'un deuxième client du domaine.
6. Procédé d'allocation d'un identifiant selon l'une des revendications précédentes, caractérisé en ce que, la requête reçue comprenant en outre une requête d'allocation d'un attribut de délégation de gestion, ledit attribut étant destiné à être spécifié par un autre nœud client dans une requête de traitement d'une règle de gestion de trafic transmise au serveur pour déléguer au premier nœud client la gestion de ladite règle de gestion de trafic, le procédé comprend :
L'allocation d'un attribut de délégation au premier nœud client,
Le stockage de l'attribut alloué avec l'association dans l'enregistrement, et en ce que La réponse émise à destination du premier nœud client comprend l'attribut de délégation alloué.
7. Procédé d'enregistrement d'un identifiant alloué à un nœud client apte à gérer le trafic associé à un domaine client en vue de sa protection contre une attaque informatique, mis en œuvre dans un serveur, le procédé comprenant :
la réception d'une requête d'enregistrement d'un premier nœud client, ladite requête comprenant un identifiant du premier nœud client, ledit identifiant ayant été alloué au premier nœud client conformément au procédé d'allocation selon l'une des revendications 1 à 6 ;
l'obtention d'un identifiant du domaine client auquel appartient le nœud client ; et l'enregistrement dans une mémoire de l'identifiant du premier nœud client associé à l'identifiant du domaine client obtenu.
8. Procédé d'enregistrement d'un identifiant selon la revendication 7, caractérisé en ce que, sur réception d'une requête de traitement d'une règle de gestion de trafic émise par le nœud client, ladite requête comprenant l'identifiant du premier nœud client, le procédé comprend la recherche dudit enregistrement dans une mémoire et le rejet de la requête si ledit enregistrement n'a pas été trouvé.
9. Procédé d'enregistrement d'un identifiant selon la revendication 8, caractérisé en ce que, lorsque la requête de traitement comprend une demande de modification d'une règle de gestion de trafic installée par un deuxième nœud client, le procédé comprend :
la vérification d'une délégation de gestion par comparaison d'un premier attribut de délégation de gestion spécifié dans la demande de modification de la règle de gestion de trafic et d'un deuxième attribut de délégation de gestion associé à la règle de gestion de trafic installée par le deuxième nœud client dans un enregistrement stocké en mémoire ; lorsque le premier et le deuxième attributs de délégation ont la même valeur, modification de la règle de gestion de trafic conformément à la demande.
10. Procédé d'enregistrement d'un identifiant selon l'une des revendications 7 à 9, caractérisé en ce que, sur réception d'une demande de suppression d'enregistrement de l'identifiant du premier nœud client, il comprend la suppression dudit enregistrement et la suppression des règles de gestion de trafic installées par le premier nœud client.
11. Procédé d'enregistrement d'un identifiant selon la revendication 10, caractérisé en ce qu'il comprend la notification des autres nœuds clients actifs dans le domaine client, préalablement à ladite suppression des règles de gestion de trafic installées par le premier nœud client.
12. Dispositif d'allocation d'un identifiant à un premier nœud client apte à gérer le trafic associé à un domaine client en vue de sa protection contre une attaque informatique, ledit dispositif comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée et configurée pour mettre en œuvre :
la réception d'une requête d'allocation d'un identifiant de nœud client en provenance du premier nœud client, ladite requête comprenant au moins une information d'identification du nœud client ;
l'obtention d'une liste d'identifiants de nœuds clients déjà alloués à des nœuds clients actifs au moins dans le domaine client ;
l'allocation au premier nœud client d'un identifiant de nœud client n'appartenant pas à la liste obtenue ;
l'enregistrement dans une mémoire locale d'une association entre l'identifiant alloué et l'information d'identification du premier nœud client ;
l'émission d'une réponse à destination du premier nœud client, comprenant l'identifiant alloué ; et
l'émission d'une requête d'enregistrement de l'identifiant alloué au premier nœud client dans le domaine à au moins un serveur de gestion du trafic associé au domaine.
13. Nœud client comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour la gestion du trafic associé à un domaine client, caractérisé en ce qu'il comprend un dispositif d'allocation d'un identifiant à un premier nœud client selon la revendication 12.
14. Serveur comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour la gestion du trafic associé à un domaine client en vue de sa protection contre une attaque informatique, mettant en œuvre : la réception d'une requête d'enregistrement d'un premier nœud client, ladite requête comprenant un identifiant du premier nœud client ;
l'obtention d'un identifiant du domaine client auquel appartient le nœud client ;
l'enregistrement dans une mémoire de l'identifiant du premier nœud client associé à l'identifiant du domaine client obtenu.
15. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d'un procédé selon l’une quelconque des revendications 1 à 10, lorsqu'il est exécuté par un processeur.
EP19802235.2A 2018-09-28 2019-09-26 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 Active EP3857848B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1859044A FR3086776A1 (fr) 2018-09-28 2018-09-28 Procede d'allocation d'un identifiant a un nœud client, procede d'enregistrement d'un identifiant, dispositif, nœud client, serveur et programmes d'ordinateurs correspondants.
PCT/FR2019/052279 WO2020065232A1 (fr) 2018-09-28 2019-09-26 Procédé d'allocation d'un identifiant à un nœud client, procédé d'enregistrement d'un identifiant, dispositif, nœud client, serveur et programmes d'ordinateurs correspondants

Publications (2)

Publication Number Publication Date
EP3857848A1 true EP3857848A1 (fr) 2021-08-04
EP3857848B1 EP3857848B1 (fr) 2022-08-31

Family

ID=65685535

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19802235.2A Active EP3857848B1 (fr) 2018-09-28 2019-09-26 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

Country Status (6)

Country Link
US (1) US12218955B2 (fr)
EP (1) EP3857848B1 (fr)
CN (1) CN112771833B (fr)
ES (1) ES2932499T3 (fr)
FR (1) FR3086776A1 (fr)
WO (1) WO2020065232A1 (fr)

Families Citing this family (3)

* 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.
US11637710B2 (en) * 2019-12-10 2023-04-25 Jpmorgan Chase Bank, N.A. Systems and methods for federated privacy management
WO2022152377A1 (fr) * 2021-01-14 2022-07-21 Telefonaktiebolaget Lm Ericsson (Publ) Atténuation d'attaques ddos

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1655928A1 (fr) * 2004-11-05 2006-05-10 Hitachi, Ltd. Procédé et dispositif pour assigner un identificateur unique à un noeud de réseau
US7653352B2 (en) * 2005-12-22 2010-01-26 Motorola, Inc. Method and apparatus for self-assigning addresses
US20080161008A1 (en) * 2006-12-27 2008-07-03 Enoch Porat Method and system for identification of a communication device in a wireless communication network
US9137135B2 (en) * 2011-11-14 2015-09-15 Jds Uniphase Corporation Selective IP address allocation for probes that do not have assigned IP addresses
US8935430B2 (en) * 2012-06-29 2015-01-13 Verisign, Inc. Secondary service updates into DNS system
CN103067385B (zh) * 2012-12-27 2015-09-09 深圳市深信服电子科技有限公司 防御会话劫持攻击的方法和防火墙
CN104618351A (zh) * 2015-01-15 2015-05-13 中国科学院信息工程研究所 一种识别dns欺骗攻击包及检测dns欺骗攻击的方法
CN105262722B (zh) * 2015-09-07 2018-09-21 深信服网络科技（深圳）有限公司 终端恶意流量规则更新方法、云端服务器和安全网关
CN105610852A (zh) 2016-01-15 2016-05-25 腾讯科技（深圳）有限公司 处理ack洪泛攻击的方法和装置
US20170345009A1 (en) 2016-05-25 2017-11-30 Mastercard International Incorporated Systems and Methods for Use in Facilitating Network Transactions
US10728280B2 (en) * 2016-06-29 2020-07-28 Cisco Technology, Inc. Automatic retraining of machine learning models to detect DDoS attacks
US10382480B2 (en) * 2016-10-13 2019-08-13 Cisco Technology, Inc. Distributed denial of service attack protection for internet of things devices
US10305931B2 (en) * 2016-10-19 2019-05-28 Cisco Technology, Inc. Inter-domain distributed denial of service threat signaling
US9756075B1 (en) * 2016-11-22 2017-09-05 Acalvio Technologies, Inc. Dynamic hiding of deception mechanism

Also Published As

Publication number Publication date
CN112771833B (zh) 2023-06-06
EP3857848B1 (fr) 2022-08-31
FR3086776A1 (fr) 2020-04-03
US12218955B2 (en) 2025-02-04
CN112771833A (zh) 2021-05-07
US20220038473A1 (en) 2022-02-03
WO2020065232A1 (fr) 2020-04-02
ES2932499T3 (es) 2023-01-20

Similar Documents

Publication Publication Date Title
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
FR3041493A1 (fr) Equipement pour offrir des services de resolution de noms de domaine
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
EP3939232B1 (fr) Mitigation d'attaques informatiques
FR2962621A1 (fr) Acces confidentiel ou protege a un reseau de noeuds repartis sur une architecture de communication a l'aide d'un serveur de topologie
CH718976A2 (fr) Gestion des pares-feux d'entreprise et isolement du réseau.
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
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é
EP3788762B1 (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
EP3857849B1 (fr) Procédés de protection d'un domaine client, noeud client, serveur et programmes d'ordinateur correspondants
WO2020002853A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants
FR3136075A1 (fr) Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés.
FR3087603A1 (fr) Technique de collecte d'informations relatives a un flux achemine dans un reseau
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
WO2020065233A1 (fr) Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants
FR3145253A1 (fr) Procédé de révocation d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
WO2021105617A1 (fr) Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes
FR3157769A1 (fr) Procédé d’accès à un service par un dispositif de communication via au moins un réseau de communication

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210311

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602019019067

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0009400000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20220120

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 9/40 20220101AFI20220110BHEP

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTC Intention to grant announced (deleted)
INTG Intention to grant announced

Effective date: 20220330

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1516113

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220915

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602019019067

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20220831

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2932499

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20230120

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221130

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1516113

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221231

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221201

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230102

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20220930

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602019019067

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220926

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220930

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220926

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220930

26N No opposition filed

Effective date: 20230601

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220930

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20190926

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220831

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20250820

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20250820

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20250820

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20250821

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20251001

Year of fee payment: 7