Patent ID: 12218955

5. DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE INVENTION

The general principle of the invention is based on the allocation of a unique identifier to a client node that is part of a client domain, but also on the recording of this identifier in association with an identifier of the client domain, and on the use of this unique identifier to enhance the efficiency and the reliability of the protection against denial of service attacks within the domain.

In relation toFIG.1, different equipment of a network in charge of protecting the network and the terminals connected to it against computing attacks, and implementing a method for allocating an identifier according to an embodiment of the invention is presented.

For example, the client domain11contains one or more machines, also called nodes. The term “domain” is used here to refer to a set of machines or nodes under the responsibility of the same entity. For example, several client nodes C1, C2, Cm belonging to the client domain11, communicating with a server S12, are considered.

According to the example shown, the server12does not belong to the client domain11. In another example not shown, the server12can belong to the client domain11.

In the remainder of the description, the case of a DOTS-type architecture according to which the client nodes C1, C2 and Cm 114 are DOTS clients and the server S is a DOTS server is considered. The client nodes C1, C2 and Cm and the server S can thus communicate via the DOTS signal and data channels defined in connection with the prior art to inform the server that a DDoS attack was detected and that appropriate actions are required.

5.1. Reminders of DOTS Architecture

A DOTS request can be, for example:an alias management message, for example to associate an identifier with one or more network resources located in the client domain,a signalling message to request the mitigation of a denial of service attack from a DOTS server, with the server being able, upon receipt of such a message, to initiate the actions necessary to stop the attack, ora traffic management rule management message, filtering for example, comprising requesting a DOTS server to install (or have installed), modify or delete an Access Control List (ACL) for mitigating an attack. In the following, “processing request” designates a request for installing one or more explicit filter rules, an access control list, and more generally any action that a DOTS client node may request from the server for mitigating 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 support one or more DOTS clients. In other words, several client nodes of a client domain can have DOTS functions.

DOTS communications between a client domain and a domain server can be direct, or established via DOTS gateways, not shown. These gateways can be hosted within the client domain, the server domain, or both. In other words, a client node of the client domain can communicate directly with the server, or transmit a request to a gateway of the client domain that communicates directly with the server or with a gateway of 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, the authentication of DOTS clients can be entrusted to the DOTS Gateway of the server domain. A DOTS server can be configured with the list of active DOTS gateways within its domain and the server can delegate some of its functions to these trusted gateways. In particular, the server can securely use the information provided by a gateway on a list declared to and maintained by the server by means of an ad hoc authentication procedure (for example, explicit configuration of the list by the authorised administrator of the server, retrieval of the list from an authentication server such as an AAA server (for “Authentication, Authorisation and Accounting”), etc.).

The embodiments presented below can be implemented regardless of the configuration of the DOTS architecture (one or more DOTS clients in a client domain, no DOTS gateway, one or more DOTS gateways of the client domain or in the server domain, client domain separate from the server domain, etc.).

The establishment of a secure DOTS session can be done in accordance with the procedure described in the above-mentioned document “Distributed Denial-of-Service Open Threat Signaling(DOTS)Signal Channel Specification”.

In the following, it is assumed that the DOTS agents (client(s), server(s)) authenticate each other. There is therefore a secure communication channel, of type DTLS/TLS ((Datagram) Transport Layer Security) for example, between a DOTS client and a DOTS server.

Thus, the messages received from another server spoofing the IP address of the legitimate server can be rejected by a DOTS client. Similarly, the requests from the DOTS clients not authorised to access the mitigation service are ignored by the DOTS server. It is assumed in what follows that this procedure is implemented by the DOTS agents.

The details of the DTLS/TLS exchanges, and those concerning the management of the security keys for the mutual authentication of the DOTS agents, are not the subject of the present invention and are not detailed here.

5.2 Application Examples in the Domain of Mitigation Services (DPS)

FIG.2illustrates the main steps of the method for allocating an identifier to a first client node C1 according to an embodiment of the invention. This method can be implemented by another client node of the client domain, benefiting from privileges on the server S, called a master client Cm, or by a dedicated software instance, called a CMI (“CUID Management Instance”), that interfaces with the master client node C1. In the following, it is assumed that the method for allocating an identifier is implemented by the master client Cm of the client domain11. However, the same method applies when this function is fulfilled by said dedicated CMI entity.

When the DOTS client C1 starts up, it contacts its master client Cm or the CMI instance to request in21the allocation of a DOTS client identifier or cuid. To do this, the DOTS client C1 sends an MREQID or GET( ) allocation request message to the master client Cm, as illustrated inFIG.4A. Upon receipt of the MREQID or GET( ) message by the DOTS master client Cm (or the CMI instance), the latter verifies that this client C1 is authorised to invoke the DOTS service. If necessary, the master client Cm obtains in22a list of identifiers currently used in the domain, for example by checking a table stored in memory, and chooses in23an identifier cuid_c1 that is not part of this list. In this way, the DOTS client Cm (or the CMI instance) ensures by default that two clients of the client domain do not use the same identifier ‘cuid’. It will be noted that this constraint can be released during the phases for securing or replacing a DOTS client with another one. Once the identifier cuid_c1 is chosen, the master client Cm stores in24the pair formed by the unique identifier allocated and the identifier of the client C1 in memory, for example a local memory. Then, and in order to improve the robustness of the DOTS service, the DOTS master client Cm contacts in25the server S in27Cm to record the new identifier activated within the DOTS client domain for the client C1. As illustrated inFIG.4B, it does this, for example, using an MREQREG( ) or REGISTER_REQ( ) recording request message. This message can include the DOTS identifier(s) cuid of the client C1 alone or of multiple clients. Upon receipt of an MREPREG( ) or REGISTER_ACK( ) confirmation message from the server S, it sends in26to the client C1 an MREPID or SET(cuid_c1) acknowledgement message comprising the identifier cuid_c1 it allocated to it, as illustrated inFIG.4A. Upon receipt of a rejection response from the server S, the client Cm can repeat the process in order to reallocate a new identifier to the client C1 and request again the recording of the new identifier cuid_c1 to the server S.

Optionally, upon detection of an event occurring in the client domain, such as the inactivity of the client node C1, or its disconnection, or a change in the security policy of the client domain in27, it modifies in28at least locally the record of the identifier cuid_c1.

In relation toFIG.3, the steps of a method for recording an identifier allocated to a client node, implemented by the server S according to an embodiment of the invention, are now described. Upon receipt in31of an MREQREG( ) or REGISTER_REQ recording request for an identifier cuid_c1 for the client C1 of the client domain11from the master client Cm, as illustrated inFIG.4B, the server S performs the security checks (not shown) already mentioned. In the case of success, it obtains in32an identifier ‘cdid’ (Client Domain IDentifier) of the client domain11to which the client C1 is attached. As an example, a DOTS server identifies the DOTS clients belonging to the same domain via the cdid attribute. Other mechanisms for identifying the client domain may be supported by the server. The domain identifier can be calculated locally by the server or communicated by another trusted entity (typically a DOTS relay of its server domain), or both. No assumptions are made about the structure of the cdid. It then checks in33whether an association between this client identifier cuid_c1 and this domain identifier ‘cdid’ is already stored in memory. If it finds one, it rejects the recording request in35by returning to the master client an MREPREQ(rej) response. If it does not find one, it processes the recording request in34by storing the (cuid, cdid) pair of the client C1 in memory M2. It then acknowledges the recording request with an MREPREG(ack) or REGISTER-ACK( ) message, as illustrated inFIG.4B.

Optionally, upon receipt in36of an MREQT processing request for the implementation of a mitigation solution, such as the installation of a traffic management rule of type traffic filtering Rk, this request originating from a client identified by the identifier cuid_c1, the server checks in37that the identifier cuid_c1 is validly recorded in its memory in association with the identifier of the client domain from which the request originates. In the case of success, it processes the request in38, otherwise it rejects it. It is noted that the verification procedure according to the invention implemented by the DOTS server to process a DOTS request from a DOTS client enhances the reliability of the service even in case of security identity theft by a malicious entity. An example of an extract of a list of DOTS clients as maintained by a master DOTS client Cm is presented in relation to table 1. The table shows three active DOTS clients for this domain. The invention does not imply any particular structure for the tables maintained by the CMI instance/DOTS master client.

TABLE 1Client Identifier (cuid)Client Identitycuid_ex1Security Credentialscuid_ex2Security Credentialscuid_ex3Security Credentials

It will be noted that in the case where the method according to the invention is implemented by a software entity CMI, the information relating to the allocation of the DOTS client identifier is communicated by the CMI instance to the DOTS master client Cm.

An example of an extract of an MREPREG recording request transmitted by the master client Cm to the server S is presented below. In this example, the PUT request is relayed by a DOTS relay of the server domain. The relay client node inserts the “cdid=here.example” information to communicate to the server the identity of the domain of the DOTS client. This information is notably used by the server to enforce policies such as applying quotas or limiting the number of requests per domain.

Header: PUT (Code=0.03)Uri-Host: “www.example.com”Uri-Path: “.well-known”Uri-Path: “dots”Uri-Path: “v1”Uri-Path: “mitigate”Uri-Path: “cdid= here.example”Uri-Path: “cuid= cuid_ex1”Uri-Path: “mid=57956”

In relation to table 2, an example of an extract of a list of clients as maintained by the server S is also presented. The table shows 5 active DOTS clients, 3 of which belonging to the “here.example” domain of the master client Cm.

TABLE 2cuid/Client IdentifierClient IdentityClient Domain...cuid_ex1Security Credentialshere.example...cuid_ex2Security Credentialshere.example...cuid_ex3Security Credentialshere.example...cuid_exiSecurity Credentialsthere.example...cuid_exjSecurity Credentialsthere.example...

To illustrate the advantages of method for allocating a unique identifier according to the invention, the situation examples inFIGS.5A and5Bare considered.

In these two examples, the master client C1 first records to the server S the identifier cuid_c3 it allocated to the client C3. As previously described, the server S, upon receipt of the REGISTER_REQ(cuid_c3) request, checks that this identifier is unique in the client domain11identified by its unique identifier cdid=“here.example” and, if so, stores the (cuid_c3, cdid) association in memory.

In relation toFIG.5A, if a malicious DOTS client C4 belonging to another domain12contacts the server S, requesting the implementation of a management action on behalf of the client C3, i.e. using its identifier cuid_c3, the server detects that the (cuid_c3, cdid) association is incorrect and rejects the request.

In relation toFIG.5B, if a malicious DOTS client C2 belonging to the same domain11as the client C3 and the master client Cm, contacts the server S for an attack mitigation request, its request will be rejected by the server S, because this client C2 is not validly registered with it.

In relation toFIGS.6A to6C, the steps27for detecting a traffic management event associated with the client domain and28for modifying the association of identifiers recorded in the local memory of the master client or the CMI entity, according to a first embodiment of the invention, are now detailed.

It is assumed that the event detected in27is an event relating to a change in the activity of the client nodes recorded in the domain or in the security policy applied within the domain. According to the invention, a master client node Cm uses the unique identifiers to react to this event. It is for example:the inactivity of a client node for a predetermined period;the decision of the client domain administrator to reduce the number of DOTS clients activated within the domain;the suspicious behaviour of a DOTS client node;the explicit record deletion request from a DOTS client node of the client domain11.

Following this detection, the master client Cm may decide to delete the record of one or more client nodes with the server S.

To do this, as illustrated inFIG.6A, it sends an MREQUNREG or UNREGISTER_REQ( ) record deletion request message. The record deletion message can include one or more identifiers of DOTS clients of a client domain. Upon receipt of this message, the DOTS server S deletes the clients listed in its tables (after the usual security checks).

In relation toFIG.6B, the event detected by the master client Cm is the receipt of an explicit record deletion request from a client node C1 of the client domain. Upon receipt of the MREQSUP( ) or DELETE(cuid_c1) request, the master client Cm modifies the record of the identifier of the client C1.

Two options are considered:According to a first option, illustrated inFIG.6B, the master client C1 acknowledges the request of the client C1 with an MREPSUP(ack) response message and transmits an MREQUNREG( ) record deletion request from the client C1 to the server S. The latter deletes the (cuid_c1, cdid) association from its table and responds to the master client Cm with an acknowledgement message. The identifier cuid_c1 is thus released at the server S level, which will then delete the actions installed with this identifier.According to a variant illustrated inFIG.6C, before deleting the traffic management rules installed with the newly released identifier, the DOTS server S informs the other clients of the domain of the existence of these rules, so that they can reinstall them.In an embodiment, it is assumed that the DOTS agents (clients and servers) 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., September 2018”.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 C2 client, and then notifies the other client nodes of the same client domain, such as C1, of its intention to delete the traffic management rules associated with the client C2.Upon receipt of this notification, the client C1 may 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 to ask it to migrate to its name some rules of the client C2. The server S migrates these rules, and sends an acknowledgement message of type “204 created” to the client C1 (i.e., the identifier of the client node C1 will be maintained by the server as being responsible for the management of these rules).If no response is received from the other clients of the client domain, the deletion of the filters is confirmed by the server S.According to a second option, illustrated inFIG.6D, the master client Cm acknowledges the request of the client C1 with an MREPSUP(ack) response message. To avoid disrupting the operation of the DOTS domain11, it does not ask the server S to delete the record of the identifier cuid_c1 of the client C1, but it reallocates this identifier to another client C2 of the domain11. In this way, it replaces the client C1 with another client of the domain without affecting the state maintained by the server S.When the client C2 sends a processing request, such as the installation of a filter rule to the server S, by identifying itself with the identifier cuid_c1, the server can accept its request because the client C2 is validly identified.Thus, the allocation of a unique identifier to each client of a client domain performed by the method according to the invention enhances the reliability of the exchanges between the DOTS agents and makes the protection, by the master client Cm located in the client domain11, of the client domain against the attacks more robust, even in case of disconnection of certain client nodes of the same client domain.

In relation toFIG.7, the steps36to38for receiving and processing a request for modifying a traffic management rule implemented by the server S according to a second embodiment of the invention are now detailed.

The server S receives in36a processing request for a rule Rk from the client C1.

It checks in37that the identifier cuid_c1 is recorded in association with the identifier of the client domain cdid. If necessary, it searches in371for a record associating the identifier cuid_c1 with the rule Rk identified by the rk attribute. If this is the case, the client C1 is at the origin of the installation of the rule Rk it wants to modify. The server S performs the requested modification in38.

Otherwise, it performs in372an additional check, that consists in searching for a record associating with the rule Rk the “THIRD_PARTY_NONCE” delegation attribute of the client C1. If it finds it, the server S considers that client C1 benefits from a delegation from the client C2 to modify the rule Rk and performs the requested modification in38.

Concretely, this new “THIRD_PARTY_NONCE” attribute is specified by the DOTS client C2 when the rule Rk is created on the server S. This attribute includes a unique identifier, such as the identifier cuid_c1 of the client C1.

This delegation procedure allows a client node of the client domain to modify actions installed by another client of that client domain, such as traffic filtering rules that are stale or that conflict with the installation of other filter rules, for example, for implementing a mitigation solution against a DDoS attack.

The implementation of a delegation procedure according to the invention considering the example of the client nodes C1 and C2 of the client domain11is now detailed. It is assumed that C1 and C2 activate the delegation procedure for the DOTS operations to enhance the reliability of the service in case one of them is unavailable, in case of conflict, etc. The delegation procedure can be activated in several ways:according to a first option, the delegation is activated only by the client C1 to the benefit of the client C2. The client C2 does not designate the client C1 as the recipient of a delegation;according to a second option, the delegation is activated by both clients: C1 delegates to C2 and vice versa. Two variants are considered:the same value of the THIRD_PARTY_NONCE attribute is used by both clients.distinct values are used by each of the clients.

For illustration purposes, an example of a request for installing a management action “my_acl”, for which the client node C2 identified by the identifier cuid_c2 informs the server that it supports the delegation by indicating the value “263afd79-835c-4ee7-9535-df245cf28d9a” for the THIRD_PARTY_NONCE attribute in its request, is presented below.

POST /restconf/data/ietf-dots-data-channel:dots-data\/dots-client=cuid_c2 HTTP/1.1Host: {host}:{port}Content-Type: application/yang-data+json{“ietf-dots-data-channel:access-lists”: {“THIRD_PARTY_NONCE”: 263afd79-835c-4ee7-9535-df245cf28d9a,“acl”: [{“name”: “my-acl”,“type”: “ipv4-acl-type”,“aces”: {“ace”: [{“name”: “my-example”,“matches”: {“l3”: {“ipv4” {“destination-ipv4-network”: “1.2.3.0/24”}}},“actions”: {“forwarding”: “accept”}}]}}]}}

It is now assumed that the client node C1 detects that the machine with the IP address “1.2.3.1/32” is under an attack, as illustrated inFIG.8A.

In relation toFIG.8B, the client node C1 solicits the server S so that it implements a mitigation solution for this attack by sending in 81C1 the following message:

Header: PUT (Code=0.03)Uri-Host: “www.example.com”Uri-Path: “.well-known”Uri-Path: “dots”Uri-Path: “v1”Uri-Path: “mitigate”Uri-Path: “cuid=cuid_c1”Uri-Path: “mid=57956”Content-Format: “application/cbor”{“ietf-dots-signal-channel:mitigation-scope”: {“scope”: [{“target-prefix”: [“1.2.3.1/32”,],“target-port-range”: [{“lower-port”: 80}],“target-protocol”: [6]}]}}

Upon receipt in 82S of this request, the server S performs in 83S the security and recording checks of the client node C1 already described, then decides in 84S on an action to be implemented. This involves for example installing a new filter rule Rk2. When it tries to install this rule, it detects in 85S a conflict with the filter rule Rk=“my_acl” already installed by the client node C2.

It sends in 86S an error message 4.09 (Conflict) to the client node C1 to inform it of the existence of this conflict with the filter rule Rk=“my-acl”.

The client node C1 receives this error message in 87C1. Contrary to the state of the art, the client node C1 sends back in 88C1 a request for modifying the filter rule Rk to the server S1 to resolve the conflict. In this example, it is assumed that the client node C1 adds a new entry to the existing rule “my-acl” to block only the traffic destined for the address “1.2.3.1/32”. For example, the request for modifying Rk it sends to the server S1 takes the following form:

PUT /restconf/data/ietf-dots-data-channel:dots-data\/dots-client=cuid_c1 HTTP/1.1Host: {host}:{port}Content-Type: application/yang-data+json{“ietf-dots-data-channel:access-lists”: {“THIRD_PARTY_NONCE”: 263afd79-835c-4ee7-9535-df245cf28d9a,“acl”: [{“name”: “my-acl”,“type”: “ipv4-acl-type”,“aces”: {“ace”: [{“name”: “my-example_delegate”,“matches”: {“l3”: {“ipv4” {“destination-ipv4-network”: “1.2.3.1/32”}}},“actions”: {“forwarding”: “drop”}}]}}]}}

It is noted that it specifies the value of the THIRD_PARTY_NONCE attribute. Upon receipt of this message by the DOTS server S in 89S, the latter checks that the value of the “THIRD_PARTY_NONCE” attribute (263afd79-835c-4ee7-9535-df245cf28d9a) is identical to that indicated by the client C2 when creating the filter rule Rk=“my-acl” and that both clients C1 and C2 belong to the same DOTS client domain11. Following this check, the DOTS server S decides to modify the filter as requested by the client node C1. The DDoS traffic is then blocked as illustrated inFIG.8C. The invention thus resolves the conflict without soliciting the client node C2.

According to a third embodiment of the invention, the value of the “THIRD_PARTY_NONCE” attribute is allocated by the CMI instance/master client Cm, together with the identifier ‘cuid’. The value of the delegation attribute can be obtained by static or dynamic configuration, for example via the DHCP protocol.

In relation toFIG.9A, the client node C1 transmits an MREQID( ) or GET(cuid, THIRD_PARTY_NONCE) allocation request for an identifier ‘cuid_c1’ and a delegation attribute.

Advantageously, the CMI instance or the master client node Cm can disable this delegation procedure by not returning any delegation attribute value to the client C1 as illustrated inFIG.9B. Concretely, 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 disabled.

Indeed, the delegation procedure can induce a computing overload for the client node that takes over from another client node for managing its ongoing actions. If the load of said relay node reaches a certain threshold, for example 80% of the CPU (Central Processing Unit), then the delegation procedure could be disabled. The entity in charge of enabling the delegation procedure can notably be informed of a threshold overrun by conventional notification means such as an “SN MP trap”.

According to an embodiment variant, illustrated inFIG.9C, the master client node indicates in its response to the client node C1, not only the value of the delegation attribute it allocated to it, but also the one it allocated to the other client nodes of the same client domain. It is understood that in this case, all the client nodes of the client domain share the same delegation attribute value.

Thus, as illustrated by the different embodiments of the invention that have just been described, the recording by the server S of an association between the unique identifier allocated to the client node by the master client node or the CMI entity, and the identifier of the client domain11, not only enhances the reliability of the exchanges between the DOTS agents, but also makes the protection implemented by the server S against DDoS attacks easier and more robust.

5.3 Structures

Finally, a description is given, in relation toFIG.10, of the simplified structures of a client node and a server according to one of the embodiments described above.

According to one particular embodiment, a client node Cm comprises a memory101Cmcomprising a buffer memory, a processing unit102Cm, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program103Cm, implementing steps of the method for 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.

At initialisation, the code instructions of the computer program103Cmare for example loaded into a RAM memory before being executed by the processor of the processing unit102Cm.

The processor of the processing unit102Cmimplements steps of the identifier allocation method previously described, according to the instructions of the computer program103Cm, to:receive a request for allocating a client node identifier from the first client node, said request comprising at least one item of information for identifying the client node;obtain a list of client node identifiers already allocated to the client nodes active at least in the client domain;allocate to said first client node a client node identifier not belonging to the list obtained;record in a local memory an association between the allocated identifier and the item of information for identifying the first client node;send a response to the first client node, comprising the allocated identifier; andsend a request for recording the identifier allocated to the first client node in the domain to at least one traffic management server associated with the domain.

According to one particular embodiment, a server S comprises a memory101scomprising a buffer memory, a processing unit102s, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program103s, implementing steps of the method for recording an identifier according to an embodiment of the invention.

At initialisation, the code instructions of the computer program103sare for example loaded into a RAM memory before being executed by the processor of the processing unit102s.

The processor of the processing unit102simplements steps of the identifier recording method previously described, according to the instructions of the computer program103s, to:receive a recording request from a first client node, said request comprising an identifier of the first client node, said identifier having been allocated to the first client node by the client node Cm according to the invention;obtain an identifier of the client domain to which the client node belongs;record in a memory the identifier of the first client node associated with the identifier of the client domain obtained.