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/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
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/14—Session management
  • H04L67/148—Migration or transfer of sessions
• • 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/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

Definitions

• 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 provides a solution for managing the traffic associated with a client domain, that is to say entering a client domain or leaving a client domain, in the event of a communication problem between the server and a client node in the client domain.
• the invention offers a solution making it possible to avoid the systematic triggering of a mitigation procedure in the event of loss of connection between a server and a client node.
• 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 attacks.
• DDoS Protection Services In order to overcome these DDoS attacks, services for detecting and mitigating 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 allow in particular to distinguish “legitimate” traffic, i.e., data consented by the user, from “suspicious” traffic.
• DOTS DOTS
• client client node
• DOTS server server
• a DOTS client attached to that client domain can send a message to the 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.
• a mitigation entity in English “mitigator”
• This solution uses two communication channels between the DOTS client and the server
• DOTS Signal Channel a DOTS signaling channel
• DOTS Data channel in English "DOTS Data Channel”
• the DOTS signaling channel is only used when a DDoS attack is in progress.
• a DOTS client can use this channel to request assistance from the 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 ("Client Unique Identifier").
• a DOTS server can thus take the appropriate 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 clients in the same client domain, or with a filtering rule previously installed on the server by another client in the client domain, and on the other hand if the server is authorized to / configured to honor the last request received.
• the server can send an error message, for example type 4.09 ("Conflict"), to inform the 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".
• the DOTS server can install filtering rules in response to a request sent by a client, if this request does not conflict with other requests from other clients in the same client domain or with a rule existing filtering. In the event of a conflict with other rules maintained by the DOTS server, the server can send an error message, for example of type 409 ("Conflict"), to inform the client.
• Conflict type 409
• 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, Reddy, T. 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 the filtering requests being to anticipate DDoS attacks).
• Such a refusal can notably occur when clients in the client domain have previously asked the server to install filtering rules, but these rules are no longer justified (in English "stale").
• the DOTS architecture was designed to support automatic mitigation of denial of service attacks by a server in the event of loss of the session established with a DOTS client.
• the implementation of this procedure is dependent on the value of a mitigation trigger parameter, denoted "trigger-mitigation", associated with a DOTS client in the client domain during a configuration negotiation phase.
• this mitigation trigger parameter is set by the DOTS client to “FALSE”, or “false” in English, the DOTS server automatically triggers a mitigation procedure if it no longer receives messages from this client DOTS.
• incoming traffic that is to say intended for the client domain
• the DOTS server decides to trigger the automatic mitigation procedure. Incoming traffic can thus be redirected to a traffic “purification” center (“DDoS scrubber” or “DDoS scrubbing center”, which is responsible for eliminating DDoS attack traffic.
• a traffic “purification” center (“DDoS scrubber” or “DDoS scrubbing center”, which is responsible for eliminating DDoS attack traffic.
• redirecting incoming traffic to a treatment center can be harmful to the customer because it increases the delay in transferring traffic, or even prevents the routing of traffic, while the absence of a message from a DOTS client is not necessarily due to a DDoS attack.
• a DOTS server can delete all the filters activated by this client, which can adversely affect the proper routing of traffic to the client area.
• the invention provides a new solution for managing traffic associated with a client domain, i.e., entering the client domain or leaving the client domain, implemented in a server, comprising:
• o if no session is active the triggering of a mitigation procedure on at least one IP resource associated with the client domain
• o if at least one session is active the use of the second client node (s) associated with the active session (s), known as the active node (s) (s), to initiate an action to manage the traffic associated with the client domain.
• the proposed solution is based on the use of at least a second client node of the client domain, in the event of failure of the first client node, to trigger an action for managing traffic entering and / or leaving the client domain.
• the proposed solution is therefore based on cooperation between the different client nodes belonging to the same client domain.
• such a traffic management action implements the confirmation that an attack is in progress on at least one IP resource associated with the client domain or the redirection to a second active node of at least part of the traffic associated with at least one IP resource from the client domain.
• the proposed solution makes it possible to improve the reliability of the responses to DDoS attacks and the coordination between the client nodes of the same domain, in particular the coordination of the mitigation actions of the DDoS attacks, by involving at least another domain client to verify the reality of an attack.
• the solution proposed according to this embodiment thus makes it possible to avoid the increase in the delay in transferring incoming packets when they are unjustifiably routed to a traffic purification center (“scrubber”).
• the proposed solution makes it possible to force the path taken by the traffic to request one or more other client nodes during a given period. Consequently, if a DDoS attack is effective, this or these client nodes will be able to report this attack to the server. If the server does not receive a message signaling an attack and requesting the implementation of a mitigation procedure, traffic can be redirected on the nominal path.
• such cooperation between DOTS clients in the same domain makes it possible in particular to detect and eliminate obsolete entries ("stale") from the tables maintained by the server, for example the filtering rules that are no longer justified following the expiration of a session between the client and the server.
• stale obsolete entries
• the solution proposed according to this particular embodiment makes it possible to ensure consistency in the configuration of several clients belonging to the same domain.
• the proposed solution allows a client node in the client domain to indicate to the server that it can delete entries associated with IP resources managed by another client node of the client domain.
• the proposed management method can, according to at least one embodiment, apply to traffic leaving the client domain.
• the server can detect an attack whose origin is the client domain. It can thus proceed to the notification of the client domain and possibly filter outgoing traffic.
• the invention relates to one or more computer programs comprising instructions for implementing a traffic management method associated with a client domain 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 steps of the traffic management method associated with a client domain 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 traffic management associated with a client domain, according to an embodiment of the invention
• FIG. 2 presents the main steps of the traffic management method associated with a client domain, according to at least one embodiment of the invention
• FIGS 3 and 4 illustrate two examples of application of the invention
• FIG. 5 presents the main steps implemented by a DOTS server according to a first example of application of the invention
• FIG. 6 illustrates the deletion, in tables maintained by the server, of IP resources which are no longer associated with a client domain
• Figures 7A to 7D illustrate different variants for the implementation of a second verification phase, allowing confirmation / invalidation if an attack targets IP resources;
• FIG. 8 presents the main steps implemented by a DOTS server according to a second example of application of the invention.
• FIG. 9 to 12 illustrate different examples of traffic redirection according to the second example of application of the invention.
• FIGS 13 and 14 illustrate the detection of conflicts between several clients in the same domain
• FIG. 15 shows the simplified structure of a server and a client node according to a particular embodiment.
• the general principle of the invention is based on the use of at least a second client node, belonging to a client domain, to manage traffic entering or leaving the client domain, in the event of a communication problem between the server and a first client node.
• client domain 11 comprises one or more machines, also called nodes.
• domain is understood here to mean a set of machines or nodes placed under the responsibility of the same entity.
• 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.
• FIG. 2 illustrates the main steps implemented for managing the traffic associated with the client domain 11.
• the server 12 detects (21) a communication problem with a first node in the client domain, known as the failed node. For example, a communication problem is detected if a session between the server 12 and the faulty node is inactive for a duration greater than or equal to a predetermined threshold.
• a session can be considered inactive if no presence message (for example, of the “heartbeat” type), intended to verify that a remote peer is still active, is received after a longer period or equal to a threshold predetermined noted Th.
• the server 12 If a communication problem is detected between the server 12 and, for example, the node Cl 111, the server identifies (22) at least one second client node belonging to the client domain 11.
• the server checks (23) if at least one session is active between the server 12 and the second client node (s).
• a mitigation procedure 24 is triggered on at least one IP resource associated with the client domain. According to a particular embodiment, if no session is active, the triggering of a mitigation procedure is implemented on all the IP resources associated with the client domain.
• the second node associated with the active session or sessions is used (25) to initiate an action for managing traffic in the client domain.
• the mitigation procedure 24 is triggered on at least one IP resource associated with the client domain, and possibly on all IP resources associated with the domain customer. For example, such a mitigation procedure is implemented if more than half of the sessions established between the server and the client nodes in this domain are inactive.
• Figures 3 and 4 illustrate two examples of application of the invention.
• the traffic management action implements confirmation that an attack is in progress on at least one IP resource associated with the client domain.
• the first example of application therefore makes it possible to verify that a DDoS attack is effective before triggering a mitigation procedure.
• the traffic management action implements a redirection on the active node of at least part of the traffic associated with at least one IP resource from the client domain.
• FIG. 3 illustrates the main steps of the traffic management method according to the first example of application.
• the traffic management action implements confirmation that an attack is in progress on at least one IP resource associated with the client domain.
• the traffic associated with an IP resource can be incoming traffic to an address extracted from this IP resource or outgoing traffic sent from this IP resource.
• the server 12 transmits ( $ 31) to the active client node 112, and possibly to all the active client nodes in the client domain, at least one request message for confirmation of an attack on at least one IP resource associated with the client domain.
• a message is noted MACR, OR "ATTACK_CONFIRMATION_REQUEST (Resources)".
• the IP resources concerned can be explicitly indicated in the message, or not.
• such a message specifies at least one IP resource, for example an IP resource associated with the failed client node 111 or with the client domain 11. The absence of specification of an IP resource in such a message can be interpreted as a request. confirmation of attack on all IP resources associated with the client domain.
• IP resource belongs to the group comprising:
• IP address for example an IPv4 or IPv6 prefix
• IPv4 or IPv6 prefix for example the IP addresses of the different nodes of the client domain 11
• IP prefix for example an IPv4 or IPv6 prefix
• IP prefix for example an IP prefix associated with a connection router of the client domain 11
• a domain name for example a domain name associated with client domain 11, etc.
• the active client node 112 receives (32V 2 ) therefore at least one attack confirmation request message relating to at least one IP resource associated with the failed client node 111, or more generally to the client domain 11, coming from the server 12.
• the active client node 112 checks (33c2) that the IP resource or resources identified in the attack confirmation request message (s) that it receives are effectively associated with the client domain 11.
• the active client node 112 transmits (341V 2 ) to the server 12 at least one message of fault.
• an error message is noted MERR, OR "ERROR (Unknown_Resources)".
• such an error message can indicate the IP resource or resources which do not belong to the client domain 11.
• Server 12 receives ( $ 342) therefore at least one error message from an active node, indicating that one or more IP resources identified in the attack confirmation request message do not belong to the client domain .
• the server 12 can then delete ( $ 343) the IP resource or resources identified in the attack confirmation request message (s) or in the error message, from at least one table that it maintains.
• the active client node 112 transmits (351V 2 ) to at least one client node of the client domain associated with the IP resources identified in the attack confirmation request message, at least one first attack verification message .
• a first attack verification message is noted MVATTI ; OR
• the client node receiving (352ci) this MVATTI message can respond to the active node, for example the active client node 112, by transmitting (353ci) a first status message indicating whether an attack is in progress or not.
• a first status message is noted MSTATI, OR
• the active client node 112 receiving (354V 2 ) this first status message can then transmit (355V 2 ) to the server 12 at least one first response message informing the server of the response to the first attack verification message.
• a first response message is noted MREPI, OR “ATTACK_CONFIRMATION_REPLY (Resources, Status)” and indicates the status (attack in progress or not), and the IP resource or resources concerned.
• the server 12 When the server 12 thus receives ( $ 356) at least a first response message from at least one active node, it can trigger ( $ 37) a mitigation procedure on at least one IP resource associated with the client domain if at minus a first response message confirms an attack.
• the active client node 112 transmits (361V 2 ), to at least one node in the client domain implementing an attack detection function, at least one second attack verification message relating to at least one IP resource associated with the client domain.
• a second attack verification message is noted MVATT2 ⁇ or "RESOURCE_PROBE (Rk)".
• the node N receiving (362N) this message can respond to the active node, for example the active client node 112, by transmitting (363 ⁇ ) a second status message indicating whether an attack is in progress or not.
• a second status message is noted M $ TAT2 / OR "RESOU RCE_PROBE (code)".
• the active client node 112 receiving (364V 2 ) this second status message can then transmit (365V 2 ) to the server 12 at least one second response message informing the server of the response to the second attack verification message.
• a second response message is noted MREP 2 , OR "ATTACK_CONFIRMATION_REPLY (Resources, Status) ”and indicates the status (attack in progress or not), and the IP resource (s) concerned.
• the server 12 When the server 12 thus receives ( $ 366) at least one second response message from at least one active node, it can trigger ( $ 37) a mitigation procedure on at least one IP resource associated with the client domain if at minus a second response message confirms an attack.
• the first and second variants are implemented.
• the active client node 112 therefore transmits at least a first attack verification message to at least one client node of the client domain (for example, to the client node (s) associated with the identified IP resources. in the attack confirmation request message) (351C2), and / or at least a second attack verification message to at least one node of the client domain implementing an attack detection function (361V 2 ) , taking into account at least one selection criterion.
• the active client node chooses to which node (s) (client node (s) or node (s) activating an attack detection function) it sends attack verification messages.
• the selection criterion is for example the volume of traffic passing through the neighboring nodes of the active node.
• the server 12 when it receives at least one response message from said at least one active node (first and / or second response message (s)), it can trigger (37 $ ) a mitigation procedure on at least an IP resource associated with the client domain if at least one response message confirms an attack.
• the server 12 triggers ( $ 37) a mitigation procedure on at least one IP resource associated with the client domain, if no response to the attack confirmation request message is received for a predetermined duration .
• the traffic management action is a redirection, on the active node, of at least part of the traffic associated with an IP resource of the client domain.
• an IP resource can be managed by the failing node.
• the server 12 can implement, beforehand, a selection (41) of the part of the traffic to be redirected.
• the selection belongs to the group comprising:
• a selection of the traffic associated with an IP resource in the client domain ie incoming traffic to an address extracted from this IP resource or outgoing traffic sent from this IP resource
• a number of network resources greater than or equal to a number predetermined, for example the majority of network resources.
• the traffic to be managed can be incoming traffic destined for an address extracted from an IP resource or outgoing traffic sent from this IP resource.
• the server then directs the portion of the selected traffic to the active node, for example node 112.
• the redirection is implemented for a predetermined duration.
• the server 12 redirects part of the traffic, initially routed by a path passing through this faulty client node to secondary paths passing through one or more client nodes in the same client domain having an active session with the server.
• the active node (s) can trigger a mitigation procedure if it (s) finds (s) that the traffic on this active node is illegitimate traffic, i.e., corresponds to a DDoS attack.
• the method of managing traffic associated with a client domain comprises checking that all the client nodes in the client domain have previously agreed to implement the steps described above which concern them, and in particular the steps of detecting a communication problem between the server and a first client node of the client domain, of identification of at least a second node client of the client domain, and checking that at least one session associated with this second client node is active.
• the verification of the fact that all the client nodes in the client domain have previously accepted the implementation of the traffic management method implements the control of the value of a mitigation trigger parameter, noted for example “trigger -mitigation ”, associated with each client node in the client domain during a configuration negotiation phase.
• a mitigation trigger parameter noted for example “trigger -mitigation ”
• the value of the trigger-mitigation parameter must be equal to "FALSE".
• the traffic management action can be interrupted if the server receives a message from the faulty node. Indeed, the receipt of such message from the failed node means that the session between the server and the failed node is active again. The latter can optionally order a mitigation action if necessary.
• Examples of implementation of the invention are described below in a DOTS-type architecture, according to which the client nodes Cl 111, C2 112, C3 113 and Cm 114 are DOTS clients and the server S 12 is a server.
• DOTS DOTS.
• the client nodes C1 111, C2 112, C3 113, Cm 114 and the server S 12 can thus communicate via the DOTS signaling and data channels defined in relation to the prior art, to inform the server that the client domain is undergoing a DDoS attack 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's domain
• a signaling message to request the mitigation of a denial of service attack with a DOTS server, the server being able, on reception of such a message, to trigger the actions necessary to end the attack,
• a message for managing filtering rules such as requesting a DOTS server to install (or have installed) an access control list (ACL).
• ACL access control list
• 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.
• several client nodes in a client domain can have DOTS functions.
• DOTS communications between a client domain and a server can be direct, or established via DOTS gateways (in English "DOTS gateways"). These gateways can be hosted within the client domain, the server domain, or both.
• DOTS gateways in English "DOTS gateways"
• a 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 in 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.
• 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.).
• 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
• DOTS agents clients (s), server (s)
• DOTS server authenticate each other.
• a secure communication channel for example of the (D) TLS type, between a DOTS client and a DOTS server.
• the different steps implemented by a DOTS client and a DOTS server are presented below, with reference to FIGS. 1 to 4.
• the client nodes 111 to 114 of FIG. 1 are DOTS clients and that the server 12 in FIG. 1 is a DOTS server.
• the client domain is therefore a DOTS domain.
• a first example of application of the invention is presented below in more detail, according to which the traffic management action implements confirmation that an attack is in progress on at least one IP resource associated with the client domain. .
• This first example of application therefore makes it possible to verify that a DDoS attack is effective before triggering a mitigation procedure, and therefore offers a solution making it possible to avoid unnecessary triggering of mitigation operations.
• DDoS detector DDoS Detector
• One or more DDoS detectors can be activated per DOTS domain.
• the DOTS server monitors the state of the connections with the DOTS clients, or more generally monitors the DOTS sessions, ie, the connections of signaling channels established between the DOTS server and DOTS clients.
• the DOTS server does not automatically initiate the mitigation procedure but initiates a procedure making it possible to confirm that an attack DDoS is indeed in progress.
• a communication problem is detected following the non reception by the server, for a predetermined period Th, of presence messages originating from the first DOTS client, for example messages of the “heartbeat” type.
• the state 521 associated with this faulty DOTS client in the state tables of the server, can be "ATTAQUE_A_VALIDER” (in English “ATTACK_TO_BE_VALIDATED”).
• the server obtains, during a step 53, a list of at least one IP resource associated with the faulty DOTS client, or more generally with the client domain.
• IP resources can be IP addresses, IP prefixes or domain names. Domain names can be resolved to IP addresses.
• IP prefixes denote the IP prefixes directly communicated by a DOTS client or the addresses retrieved via a name resolution system (eg DNS).
• DNS name resolution system
• the prefixes can be from the same address family or belong to different families (IPv4, IPv6).
• the “ATTAQUE_A_VALIDER” state thus indicates that the IP resources associated with the failing DOTS client, or more generally with the client domain, may be subject to a DDoS attack.
• the server also obtains, during a step 54, a list of at least a second DOTS client belonging to the same domain as the faulty DOTS client, and checks whether this or these second DOTS client (s) are active. , ie, if a DOTS session is active between the server and at least one of these second DOTS clients.
• the server can also identify IP resources associated with active DOTS clients.
• the server DOTS can initiate mitigation 55 operations for all IP resources associated with this domain.
• the state of the faulty client as maintained by the server can then be changed to "MITIGATION_EN_COURS" (in English “MITIGATION_IN_PROGRESS").
• the server may decide that an attack is in progress if most of the sessions with DOTS clients in the client domain are inactive.
• a trigger threshold is used for this purpose by the server.
• this threshold can be 50% or 75% of DOTS sessions established with clients in this domain.
• the server can decide to trigger the mitigation procedure.
• other values can be used by the server.
• the server can send, during a step 56, an unsolicited message for an attack confirmation request (MACR OR "ATTACK_CONFIRMATION_REQUEST ( Resources) ”) to at least one active DOTS client in the domain.
• an unsolicited message for an attack confirmation request (MACR OR "ATTACK_CONFIRMATION_REQUEST ( Resources) ”) to at least one active DOTS client in the domain.
• Such a message comprises at least one IP resource associated with the faulty DOTS client, or with the client domain to which the faulty DOTS client belongs.
• the special value "ANY" can be used to indicate that it is any IP resource associated with the client area.
• the active DOTS client When an active DOTS client in the client domain receives such an attack confirmation request from the server, the active DOTS client implements a first verification phase during which it can carry out security verifications to ensure server identity and it can validate that the IP resources associated with the attack confirmation request message are effectively associated with the client domain.
• the request can be ignored by the active client if security checks fail, and the active client may not send a response to the server making the request.
• the status of the faulty client can be changed to "TEMPS_DE_VALIDATION_ECOULE" (in English “VALIDATION_TIMEOUT”) in the or the state tables maintained by the server.
• the DOTS server can then launch the mitigation operations 55 for all the IP resources associated with this client domain, and the state of the failing client as maintained by the server can be changed to "MITIGATION_EN_COURS" (in English “MITIGATION_IN_PROGRESS” ).
• the active client can send an error message (MERR OR "ERROR (Unknown_Resources)" to server to inform him.
• MRR OR Error (Unknown_Resources)
• Such a message notably lists the IP resources present in the attack confirmation request message which are not associated with the client domain.
• the latter When the error message is received by the server, the latter extracts the IP resources indicated in the error message and proceeds to delete the active states associated with these resources.
• the session between the client C1 111 and the server S 12 is inactive.
• the session between the client C2 112 and the server S 12 is active.
• the server can therefore send an attack confirmation request message to the C2 112 client, comprising the IP addresses 1.2.3.4 and 11.2.3.4.
• the client C2 112 verifies that these addresses belong to the client domain 11, and sends (341 c 2 ) an error message to the server 12 to inform it that the IP address 11.2.3.4 is not associated with the client domain .
• Server 12 can then delete the filtering rules associated with the IP address 11.2.3.4, or more generally the filtering rules associated with resources not belonging to the client domain. This procedure eliminates obsolete entries ("stale").
• the active client 112 can proceed to a second verification phase to confirm / invalidate if an attack targets the resource (s) indicated in the confirmation request message d 'attack.
• the active client 112 can indicate (58) to the server whether or not an attack is in progress on one or more IP resources. For example, the active client 112 sends the server a response message (ATTACK_CONFIRMATION_REPLY (Resources, Status)) with two parameters:
• the "Resources” parameter which indicates the IP resource or resources concerned
• the "Status” parameter which is set for example to “1” if an attack is in progress or to "0" otherwise.
• the state of the failed client as maintained by the server can be changed to
• the server determines for example that an attack is in progress if at least one of these clients sends a response message carrying the parameter "Status" set to "1" .
• the state of the failed client as maintained by the server can be changed to
• DOTS server receives a message from the faulty client, the verification procedure (according to the first or second phase) is interrupted. The status of this client can then be changed to "ON STANDBY" ("IDLE").
• the clients in the domain are configured beforehand with the list of other clients in the domain, as well as the list of IP resources associated with each client.
• the active DOTS client 112 directly contacts the DOTS client responsible for managing the resources indicated by the server, for example the faulty client 111 if the attack confirmation request message comprises at least an IP resource associated with the failing DOTS client, or a DOTS entity responsible for managing the client domain if the attack confirmation request message has the special value "ANY" (used to indicate that it is n ' any IP resource associated with the client domain).
• the active client 112 sends (351V 2 ) at least one first attack verification message (MVATTI OR “DOTS_PEER_PROBE (Request_Code)”) to at least one client node of the client domain associated with the IP resources identified in the message of request for confirmation of attack, for example the defaulting customer 111.
• MVATTI OR “DOTS_PEER_PROBE (Request_Code) at least one first attack verification message
• This first attack verification message is for example transmitted from the active client 112 to the failed client 111 to ask him to confirm / deny the attack.
• the "Request_Code" field of the first verification message can be used to indicate the nature of the request, for example:
• the first verification message may include a list of resources for which it is necessary to verify whether an attack is in progress.
• the faulty client 111 can possibly reply (353ci) to this first attack verification message with a first status message (MSJATI OR "DOTS_PEER_PROBE (Reply_Code)") indicating whether an attack is in progress or not.
• a first status message MSJATI OR "DOTS_PEER_PROBE (Reply_Code)
• the "Reply_Code" field of the first status message can be used to indicate the nature of the reply, for example:
• the active client 112 can then send the server a first response message (MREPI OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)”) indicating the status (the "Status” parameter is set to "1” if an attack is in progress or to " 0 ”otherwise) and the IP resource (s) concerned by the attack in progress.
• MREPI MREPI OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)
• the active DOTS client 112 contacts a DDoS attack detection function used within the client domain.
• a DDoS attack detection function used within the client domain.
• Such a function is for example implemented in at least one node N of the client domain 11, also called a DDoS detector.
• the active client 112 sends (361c2) at least one second attack verification message (MVAT ⁇ 2 OR “RESOURCE_PROBE (Rk)”) to the DDoS detector 115 to ask to confirm / deny an attack targeting at least one resource.
• the "Rk" field of the second attack verification message can be used to specify the list of resources concerned:
• the DDoS attack detection function or the node N 115 activating this function, can possibly respond (363N) to this second attack verification message with a second status message (MSJAT2 OR "RESOURCE_PROBE (Code)" indicating whether or not an attack is in progress.
• a second status message MSJAT2 OR "RESOURCE_PROBE (Code)"
• the "Code” field of the second status message can be used to indicate the nature of the response, for example:
• the active client 112 can then respond to the server with a second response message (MREP 2 OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)”) indicating the status (the "Status” parameter is set to "1" if an attack is in progress or otherwise "0") and the or the IP resources concerned.
• MREP 2 OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)"
• the status the "Status” parameter is set to "1" if an attack is in progress or otherwise "0" and the or the IP resources concerned.
• the active DOTS client 112 can contact a DDoS attack detection function used within the client domain and / or one or more DOTS clients, active or not. , and not necessarily responsible for managing the resources indicated by the server in the attack confirmation request message.
• the messages exchanged between the active DOTS client 112 and one or more DOTS clients are similar to those described in connection with the first variant and are not described in more detail.
• the messages exchanged between the active DOTS client 112 and the DDoS attack detection function are similar to those described in connection with the second variant and are not described in more detail.
• the active client 112 can distribute the attack verification requests between the clients and the DDoS detector according to considerations of activity from neighboring clients, for example.
• the active client 112 can then send the server a response message indicating the status (the "Status” parameter is set to "1" if an attack is in progress or to "0" otherwise) and the IP resource or resources concerned. According to this third variant, the active client 112 decides that an attack is in progress if it receives at least one response confirming the attack, and informs the server accordingly.
• the active client 112 can send several response messages to the server.
• the server decides that an attack is in progress if it receives at least one response confirming the attack.
• FIG. 7D illustrates three examples of messages exchanged between the active DOTS client 112, the DDoS detector 115, and the client Cm 114.
• the active DOTS client 112 concludes that an attack is in progress.
• the active DOTS client 112 concludes that an attack is in progress.
• the active DOTS client 112 concludes that no attack targets the resource indicated in the request.
• a second example of application of the invention is presented below in more detail, according to which the traffic management action implements a redirection on the active node of at least part of the traffic associated with the domain.
• Figure 8 illustrates the main steps implemented to redirect part of the traffic to an active client.
• the steps of monitoring 51 of DOTS clients belonging to a client domain, of detecting a communication problem with a first DOTS client 52, of obtaining at least one IP resource associated with this faulty client 53, of obtaining 'at least a second client belonging to this client 54 and mitigation domain 55 are similar to those presented in relation to FIG. 5 and are not described in more detail.
• DOTS clients belonging to the same domain have been identified by the server, the latter verifies that DOTS sessions are active with at least one of these clients.
• the DOTS server launches the mitigation operations 55 for all the resources associated with this area.
• the server can, following the detection of a communication problem with a DOTS client (loss of signal for example) redirect (86) part of the traffic, initially routed by the path involving the failing DOTS client, to secondary paths involving one or more DOTS clients in the same domain whose DOTS session is active.
• a communication problem with a DOTS client loss of signal for example
• the selection of the traffic to be redirected can be based on one or more selection criteria, belonging to the group comprising:
• one or more of the DOTS clients called upon during traffic redirection may or may send a signal to the server asking it to launch mitigation operations.
• the redirection can be programmed for a predetermined duration REDIRECT_Tmax.
• the DOTS server monitors (87) the inactive session with the failing DOTS client for a predetermined duration REDIRECT_Tmax.
• the DOTS server can launch mitigation operations 55 for all associated resources to this client area.
• the server does not receive any request for mitigation (872), and if at least one session with another DOTS client is still active, this means a priori that the problem of communication with the Failed client is not due to a DDoS attack, and the status associated with the failed DOTS client can be set to "EN_VEILLE" ("IDLE”) in the state table or tables maintained by the server.
• the server can also decide to redirect another portion of the traffic and to repeat the same procedure for another REDIRECT_Tmax duration.
• a communication problem is detected between the server 12 and the client Cl 111.
• Part of the incoming traffic 91 is redirected, by means of a router R 92 for example, to the client C2 112 active during a REDIRECT_Tmax duration equal to T1.
• a router R 92 for example, to the client C2 112 active during a REDIRECT_Tmax duration equal to T1.
• another part of the incoming traffic 91 can be redirected to the active client Cm 114 for a REDIRECT_Tmax duration equal to T2.
• a communication problem is detected between the server 12 and the client C1111.
• Part of the incoming traffic is redirected (100) to another active client.
• the server triggers the REDIRECT_Tmax timer.
• the C2 112 client can intercept the redirected traffic (101), in particular if the redirected traffic passes through the C2 112 client, and detect a DDoS attack in the incoming traffic before the expiration of the predetermined duration REDIRECT_Tmax.
• the server can then trigger DDoS mitigation operations (102) and inform the active C2 112 customer (2.01 (Created)).
• a communication problem is detected between the server 12 and the client C1 111.
• Part of the incoming traffic is redirected (100) to another active client.
• the server triggers the REDIRECT_Tmax timer.
• the client C2 112 can intercept the redirected traffic (101), in particular if the redirected traffic passes through the client C2 112. If no request for mitigation is received by the server from the client C2 112, and the session DOTS is still active with this C2 112 client, the server concludes that no attack is in progress. The server can then decide to stop traffic redirection (103).
• DOTS clients are therefore not necessarily located on the path taken by incoming and / or outgoing traffic.
• DDoS detectors DI 104, D2 105, ..., Dm 106
• the detection of attacks can then be implemented by one of these detectors, which can communicate the information to the associated DOTS client.
• the server S 12 can in particular communicate with the DDoS detectors via the DOTS signaling and data channels defined in relation to the prior art.
• the traffic management method associated with a client domain comprises the verification of a parameter common to the client nodes, making it possible in particular to ensure the consistency of the configuration of the different clients of a same area as for the activation of automatic mitigation on loss of the DOTS signal.
• a server can activate the procedure described above only if all the clients of the same domain have negotiated the same value for the triggering parameter of mitigation "trigger-mitigation" during the negotiation configuration of DOTS sessions. The server must therefore check the value of this mitigation trigger parameter.
• the client Cl 111 indicated the value “FALSE” for the triggering mitigation parameter in its configuration negotiation request. (“Trigger-mitigation: false”). It is assumed that the C2 112 client indicated the value “TRUE” for the mitigation trigger parameter in its configuration negotiation request (“trigger-mitigation: true”).
• the DOTS server detects a conflict between these two requests, and can deactivate automatic mitigation on loss of signal for all clients in this domain.
• FIG. 13 illustrates the case where the second client C2 has established a DOTS session (131) with the server 12 during which he has indicated that the mitigation trigger parameter is set to "TRUE" ("trigger-mitigation: true "). If the first client C1 subsequently seeks to establish a DOTS session (132) with the server 12 by indicating that the mitigation trigger parameter is set to FALSE ("trigger-mitigation: false"), the new request is in conflict with the one already maintained by the server.
• the DOTS server can reject the request of the first Cl client, for example with a message 4.09 of type “conflict” 133 (in English “Conflict”).
• the error message can indicate the nature of the conflict (“conflict-trigger-mitigation”).
• Client C1 can then send a new negotiation request with the mitigation trigger parameter set to "TRUE" ("trigger-mitigation: true").
• FIG. 14 illustrates the case where the first client C1 has established a DOTS session (141) with the server 12 during which he has indicated that the mitigation trigger parameter is set to FALSE ("trigger-mitigation: false") . If the second client C2 subsequently seeks to establish a DOTS session (142) with the server 12 by indicating that the mitigation trigger parameter is set to "TRUE" (“trigger-mitigation: true”), the new request is in conflict with that already maintained by the server.
• the DOTS server can end the TLS or DTLS session with the client Cl having negotiated the "trigger-mitigation: false" parameter. To do this, the DOTS server sends, for example, a “fatal alert” type message 143 (“Fatal Alert”) to the client C1, as described for example in the aforementioned document RFC5246.
• a “fatal alert” type message 143 (“Fatal Alert”)
• the client C1 can then reset the session 144 with the server and negotiate 145 a new value of the mitigation trigger parameter set to "TRUE"("trigger-mitigation:true”).
• a server comprises a memory $ 151 comprising a buffer memory, a processing unit $ 152, 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 $ 153, implementing steps of the traffic management method associated with a client domain according to an embodiment of the invention.
• the code instructions of the computer program 153 $ are for example loaded into a RAM memory before being executed by the processor of the processing unit 152s.
• the processor of the processing unit 152 $ implements steps of the traffic management method associated with a client domain described above, according to the instructions of the computer program 153 $ , for:
• o if at least one session is active use the second node associated with said at least one active session, known as the active node, to initiate an action for managing the traffic associated with the client domain.
• a client node comprises a memory 151c comprising a buffer memory, a processing unit 152 Q 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 153 Q implementing steps of the traffic management method associated with a client domain according to an embodiment of the invention.
• the code instructions of the computer program 153c are for example loaded into a RAM memory before being executed by the processor of the processing unit 152 Q.
• the processor 152c of the processing unit implements the steps of the associated traffic management method for a customer area described above according to the instructions of to 153o F or receive computer program at least one attack confirmation request message on at least one IP resource associated with the customer area from the server.

Landscapes

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

Applications Claiming Priority (2)

Publications (1)

Family

ID=63834171

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (9)

• 2018
  • 2018-06-29 FR FR1856024A patent/FR3081574A1/fr active Pending
• 2019
  • 2019-06-28 US US17/256,377 patent/US11563816B2/en active Active
  • 2019-06-28 EP EP19752541.3A patent/EP3815336A1/de active Pending
  • 2019-06-28 WO PCT/FR2019/051605 patent/WO2020002853A1/fr active Application Filing

Also Published As

Similar Documents

Legal Events