WO2022152377A1

WO2022152377A1 - MITIGATING DDoS ATTACKS

Info

Publication number: WO2022152377A1
Application number: PCT/EP2021/050662
Authority: WO
Inventors: Jaime JIMÉNEZ; Oscar Novo Diaz
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-01-14
Filing date: 2021-01-14
Publication date: 2022-07-21

Abstract

Methods and devices for mitigating Distributed Denial-of-Service (DDoS) attacks are provided. A first computing device operable to mitigate DDoS attacks includes processing circuitry configured to generate a DDoS Open Threat Signalling, DOTS, client identifier for the first computing device. The processing circuitry is further configured to initiate transmission of a request message to a second computing device, wherein the request message requests the registration of the first computing device and includes the DOTS client identifier for the first computing device. The processing circuitry is further configured to receive a response message from the second computing device, sent in response to the second computing device receiving the request message. Both the first computing device and second computing device are Constrained Application Protocol, CoAP, endpoints, and the request message and response message are transmitted via a DOTS signal channel.

Description

Mitigating DDoS attacks

Technical Field

The present disclosure relates to mitigation of Distributed Denial-of-Service (DDoS) attacks. In particular, the present disclosure relates to a first computing device operable to mitigate DDoS attacks, a method for mitigating DDoS attacks, a corresponding computer program, a corresponding carrier, and a corresponding computer program product.

Background

The term “Internet of Things” (loT) is used to refer to devices, which may include computing devices such as digital machines or mechanical devices, that are enabled for communication network connectivity. Communication network connectivity allows loT devices to be remotely managed, and data collected or required by the devices may be exchanged between individual devices and between devices and application servers. Examples of loT devices include sensors, actuators, smart appliances, and so on. Some loT devices are subject to limitations on processing power, storage capacity, energy supply, device complexity and/or network connectivity, imposed by their operating environment or situation, and may consequently be referred to as constrained loT devices (or simply constrained devices).

The constrained nature of many loT devices has prompted the design and implementation of new protocols and mechanisms. The Constrained Application Protocol (CoAP), as defined in RFC 7252 (produced by the Internet Engineering Task Force, IETF, available at https://tools.ietf.org/html/rfc7252 as of 4 January 4, 2021), is one example of a protocol designed for loT applications in constrained nodes and constrained networks. CoAP provides a request for information-response based RESTful communication architecture (using Representational State Transfer, REST, architecture) between constrained nodes or between constrained nodes and nodes on the Internet. CoAP can be integrated with the web and web services by translating CoAP messages to HTTP. CoAP is designed to be simple, and enables constrained devices to communicate in constrained networks with low bandwidth and low availability. CoAP employs a two- layer structure, where these two layers are the Message Layer and the Request/Response layer. The Request/Response layer supports methods including GET, PUT, POST and DELETE (as defined in RFC 7252), allowing for the access, modification, or deletion of resources. The Message Layer supports four types of messages: CON (confirmable), NON (non-confirmable), ACK (acknowledgement), and RST (reset), as defined in RFC 7252.

Confirmable messages are sent between a CoAP client and a CoAP server and require acknowledgement of reception by the recipient of the confirmable message. Non- confirmable messages do not require such acknowledgement. An Acknowledgement message is sent in response to a Confirmable message and acknowledges that a specific Confirmable message has been received. By itself, an Acknowledgement message does not indicate success or failure of any Request encapsulated in the Confirmable message, merely that the Confirmable message has been received. However, the Acknowledgement message may carry a Piggybacked Response. A Reset message indicates that a specific message was received, but some context that is required to process the message correctly is missing. This condition may be caused, for example, when a CoAP server has rebooted and deleted a state that is required to interpret the message.

The expansion in the use of loT devices has resulted in loT devices becoming targets of cyber-attacks. Instances of botnets (groups of devices under the control of a coordinating user, potentially without the knowledge of the owners of the devices) performing Distributed Denial-of-Service (DDoS) attacks that specifically target loT devices have increasingly interfered with the use of loT devices. DDoS attacks involve multiple devices flooding the resources of one or more targeted devices/systems, thereby interfering with the normal operation of the targeted devices/systems. The large volume and high vulnerability of loT devices make them particularly susceptible to this form of attack.

The impact of DDoS attacks has driven the creation of new solutions to mitigate such problems. An existing approach for detecting and handling DDoS attacks, as defined by the IETF, is referred to as DDoS Open Threat Signalling (DOTS). A schematic diagram of a DOTS architecture is shown in Figure 1. DOTS may be used to coordinate the response of a DDoS attack and redirect it. The attacked target node 11 hosts a DOTS client 12 that communicates with a DOTS server 13 using a DOTS signal channel and/or a DOTS data channel. When subjected to a DDoS attack, the targeted node 11 uses the DOTS client 12 to signal the DOTS server 13 requesting help in mitigating the attack. The DOTS server 13, in turn, invokes one or more mitigators 14 to suppress the DDoS attack. Typically, the mitigators 14 are nodes within a network, such as gateway devices or application servers, that are configured to perform mitigating actions. The mitigating actions may comprise traffic redirection or policy application, traffic might be rerouted towards the mitigation servers or other nodes, traffic may be dropped, new firewall policies might be applied, and so on.

Figure 2 is a schematic diagram of the interfaces between a DOTS client and DOTS server in an existing DOTS system. As shown in Figure 2, there are two interfaces between a DOTS server and a DOTS client: a DOTS signal channel and a DOTS data channel. The two interfaces use different protocols from one another.

The DOTS signal channel uses the CoAP referred to above; this is a lightweight protocol designed for constrained devices (such as constrained loT devices) and networks. The term “lightweight” in this context means that the protocol is less resource intensive than other similar protocols. DOTS clients and servers act as CoAP endpoints. The DOTS signal channel stack is depicted in Figure 3. As can be seen from Figure 3, the DOTS signal channel is built upon the CoAP, which in turn is built upon the Transport Layer Security (TLS) or the Datagram Transport Layer Security (DTLS), then the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP), and then the Internet Protocol (IP). The signal channel is used by DOTS clients to ask DOTS servers for help in mitigating an attack, and for DOTS servers to inform DOTS clients about the status of such mitigation. The DOTS signal channel uses a lightweight protocol as it is intended to remain operational even when confronted with signal degradation due to packet loss (as may occur during a DDoS attack).

The DOTS data channel uses the RESTCONF protocol (defined by RFC8040, produced by the IETF and available at https://tools.ietf.org/html/rfc8040 as of 4 January 2021). RESTCONF is an HTTP-based protocol that is used to access data defined using the Yet Another Next Generation (YANG) data modelling language (defined by RFC 6020, produced by the IETF and available at https://tools.ietf.org/html/rfc6020 as of 4 January 2021). RESTCONF is more resource intensive (less lightweight) than CoAP. The DOTS data channel stack is depicted in Figure 4. As can be seen from Figure 4, the DOTS data channel is built upon RESTCONF, which in turn is built upon the TLS, TCP and IP layers. The data channel provides additional capabilities and is used for infrequent bulk data exchange such as configuration or policy exchange information between the DOTS client and the DOTS server. Unlike the DOTS signal channel, the DOTS data channel is not expected to remain fully operational at all times, and the DOTS data channel may fail due to packet loss caused by a DDoS attack.

Although existing DOTS systems such as that shown schematically in Figure 2 may be useful in mitigating the impacts of DDoS attacks on some systems, existing DOTS systems may not be suitable for use with loT devices, particularly with constrained loT devices. When compared to typical loT devices, constrained loT devices may have limited computational and/or memory capabilities, limited power reserves (for example, constrained loT devices may rely on battery power), and so on. The limitations of constrained loT devices may make the requirements of existing DOTS systems difficult for the constrained loT devices to satisfy over extended periods of time, if the constrained devices are able to satisfy the requirements at all. According to existing DOTS systems, the DOTS signal channel requires persistent messaging, also known as heartbeat messaging every few seconds (typically of the order of every 30 seconds) to indicate device activity; this requirement could easily consume battery resources of constrained loT devices. The persistent messaging requirement may also be unrealistic for other loT devices (both constrained devices and typical devices) that are configured to be periodically asleep. DOTS signalling also requires a large amount of messaging capacity that some constrained devices might not have the memory and/or processing resources to provide.

Summary

It is an object of the present disclosure to provide DDoS mitigation solutions that are suitable for use in a broad range of devices, including resource constrained loT devices. According to an aspect of the present disclosure, there is provided a first computing device operable to mitigate Distributed Denial-of-Service (DDoS) attacks. The first computing device comprises processing circuitry configured to generate an DDoS Open Threat Signalling (DOTS) client identifier for the first computing device, and to initiate transmission of a request message to a second computing device requesting the registration of the first computing device. The request message comprises the DOTS client identifier. The processing circuitry is further configured to receive a response message from the second computing device, the response message being sent in response to the second computing device receiving the request message. The first computing device and the second computing device are Constrained Application Protocol (CoAP) endpoints. The request message and the response message are transmitted via a DOTS signal channel.

Advantageously, the first computing device may thereby communicate with, and request registration with, the second computing device using the DOTS signal channel, and the first computing device may thereby avoid the need to use more resource intensive communication methods.

If the response message is a confirmation of successful registration, the first computing device may receive a response identifier of the second computing device from the second computing device, and may use the received response identifier of the second computing device in further communications with the second computing device. In this way, the first computing device and second computing device may quickly and definitively identify one another.

The second computing device may host a DOTS server, or may be one of a plurality of computing devices forming a cloud of devices wherein the cloud of devices hosts a DOTS server, or the second computing device may be a CoAP proxy connected to a DOTS server. Different forms for the second computing device provide versatility such that DDoS attack mitigation may be provided for a range of different system configurations.

The first computing device may be an loT device, such as a resource constrained loT device. The resource conservation facilitated by embodiments may be particularly suitable for loT devices, such as resource constrained loT devices. According to a further aspect of the present disclosure, there is provided a method for mitigating DDoS attacks. The method comprises generating, at a first computing device a DOTS client identifier for the first computing device, and initiating transmission, by the first computing device, of a request message to a second computing device requesting the registration of the first computing device. The request message comprises the DOTS client identifier. The method further comprises receiving, at the first computing device, a response message from the second computing device, the response message being sent in response to the second computing device receiving the request message. The first computing device and the second computing device are CoAP endpoints. The request message and the response message are transmitted via a DOTS signal channel.

Embodiments of the method may provide similar advantages to those discussed in the context of the first and second computing devices hereinabove.

Brief Description of the Drawings

The disclosure is described, by way of example only, with reference to the figures, in which:

Figure 1 is a schematic diagram of an existing DOTS architecture;

Figure 2 is a a schematic diagram of the interfaces between a DOTS client and DOTS server in an existing DOTS system;

Figure 3 is a schematic diagram of the DOTS signal channel stack;

Figure 4 is a schematic diagram of the DOTS data channel stack;

Figure 5 is a flow chart illustrating a method performed by a first computing device in accordance with embodiments disclosed herein;

Figures 6A and 6B are schematic diagrams of first computing devices in accordance with embodiments disclosed herein; Figures 7A and 7B are schematic diagrams of second computing devices in accordance with embodiments disclosed herein;

Figure 8 is a flow chart illustrating a method performed by a second computing device in accordance with embodiments disclosed herein;

Figure 9 is a sequence diagram showing an example of a registration and a deregistration procedure for a DOTS thin client with a DOTS server in accordance with an embodiment disclosed herein;

Figure 10 is a sequence diagram showing an example of the response to an attack for a DOTS thin client with a DOTS server in accordance with an embodiment disclosed herein;

Figure 11 is a further sequence diagram showing an example of the response to an attack for a DOTS thin client with a DOTS server in accordance with an embodiment disclosed herein; and

Figure 12 is a still further sequence diagram showing an example of the response to an attack for a DOTS thin client with a DOTS server in accordance with an embodiment disclosed herein;

Detailed Description

For the purpose of explanation, details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed. It will be apparent, however, to those skilled in the art that the embodiments may be implemented without these specific details or with an equivalent arrangement

Embodiments of the present disclosure provide DOTS systems that can be implemented using only lightweight protocols (such as CoAP) without requiring the use of more resource intensive protocols (such as RESTCONF), and which are therefore suitable for use with a broad range of loT devices including constrained loT devices. As discussed above, existing DOTS systems support the use of CoAP for the DOTS signal channel and DOTS agents must support at least GET, PUT and DELETE CoAP methods. Embodiments disclosed herein provide DOTS systems that can be implemented using only the DOTS signal channel, without requiring support for a DOTS data channel. Accordingly, embodiments disclosed herein define a DOTS thin client, to supplement existing DOTS servers and DOTS clients. In the DOTS thin client, the DOTS data channel is not implemented, and the DOTS signal channel is implemented, while existing DOTS servers and DOTS clients implement both the DOTS signal channel and DOTS data channel.

In the following, embodiments are described with reference to three different identifiers which are associated with the DOTS signal channel: the DOTS client identifier, the resource identifier, and the message ID identifier. The DOTS client identifier may be used to uniquely identify the DOTS client in the DOTS server. The resource identifier may be used to identify the registration resource created for a particular DOTS client in the DOTS server. The message id identifier may be used to identify a specific mitigation request; a DOTS client may have multiple mitigation requests at the same time.

Figure 5 is a flowchart showing a method according to embodiments of a method for a first computing device operable to mitigate DDoS attacks. In particular, the method of Figure 5 allows a DOTS client (such as a DOTS thin client) hosted by the first computing device to perform a registration procedure and thereby register with a DOTS server, wherein a second computing device hosts the DOTS server, wherein the second computing device is one of a plurality of computing devices forming a cloud of devices and the cloud of devices hosts the DOTS server, or wherein the second computing device is a CoAP proxy (acting as a CoAP endpoint) connected to a DOTS server. Figure 6A and Figure 6B show first computing devices 60A, 60B in accordance with embodiments. The first computing devices 60A, 60B may perform the method of Figure 5. Further, Figure 7A and Figure 7B show second computing devices 70A, 70B in accordance with embodiments. The second computing device (which may be a device hosting a DOTS server, may be one of a plurality of computing devices forming a cloud of devices that hosts a DOTS server, or may be acting as a CoAP proxy for a DOTS server) 70A, 70B may perform methods such as the method according to embodiments that is shown in the flowchart of Figure 8. In order to allow the DOTS client (which may be a DOTS thin client) to register with the DOTS server, the DOTS client generates a DOTS client identifier. The DOTS client identifier should uniquely identify the DOTS client in the server, that is, any given DOTS server should not allow the same DOTS client identifier to be used by more than one DOTS client. According to some embodiments disclosed herein, a Client Unique Identifier (QUID) as defined in RFC8782 (produced by the IETF and available at https://tools.ietf.org/html/rfc8782 as of 5 January 2021) may be used to identify the DOTS client. In step S501 of the Fig. 5 method, the first computing device 60A, 60B generates the DOTS client identifier; which may be a QUID or any other suitable identifier. The generation of the DOTS client identifier may be performed, for example, by the processor 61 of first computing device 60A running a program stored on the memory 62, or may be performed by the generator 64 of first computing device 60B.

In step S502 the first computing device 60A, 60B initiates transmission of a request message to the second computing device 70A, 70B. The first computing device initiates transmission by either transmitting the request message to the second computing device itself, or by instructing the transmission of the request message to the second computing device. The request message requests the registration of the first computing device, and comprises the DOTS client identifier of the first computing device as generated in step S501. As discussed above, the request message is sent using CoAP, via a DOTS signal channel; the first computing device and second computing device are CoAP endpoints. The initiation of transmission may be performed, for example, by the processor 61 of first computing device 60A running a program stored on the memory 62 in conjunction with the interfaces 63, or may be performed by the transmitter 65 of first computing device 60B.

As shown in step S801 of Figure 8, the second computing device (which, as discussed above, may be a device hosting a DOTS server, may be one of a plurality of computing devices forming a cloud of devices that hosts a DOTS server, or may be acting as a CoAP proxy for a DOTS server) receives the request message via the DOTS signal channel, using CoAP. The receiving of the request message may be performed, for example, by the processor 71 of second computing device 70A running a program stored on the memory 72 in conjunction with the interfaces 73, or may be performed by the receiver 74 of second computing device 70B. The second computing device then determines at step S802 whether or not the DOTS client identifier included in the request message by the first computing device (for example, a CIIID) uniquely identifies the first computing device or is already in use by another DOTS client registered on the DOTS server, where the another DOTS client may be a normal DOTS client or a DOTS thin client. The determination of uniqueness may be performed, for example, by the processor 71 of second computing device 70A running a program stored on the memory 72 in conjunction with the interfaces 73, or may be performed by the determinator 75 of second computing device 70B.

The method then proceeds to the sending of a response message by the second computing device to the first computing device; the response message is also sent via the DOTS signal channel using CoAP. The method followed by the second computing device and consequential content of the response message is determined at least in part by the results of the uniqueness check on the DOTS client identifier included in the request message. If the DOTS client identifier is determined to be unique and the first computing device is successfully registered on the DOTS server, the response message may be a confirmation of successful registration (see step S803A); the registration of the first computing device is thereby completed. By contrast, if the DOTS client identifier is determined to not be unique the first computing device cannot successfully register on the DOTS server, and the response message may be an identifier conflict indication (see step S803B). The transmission of the response message may be initiated, for example, by the processor 71 of second computing device 70A running a program stored on the memory 72 in conjunction with the interfaces 73, or may be performed by the transmitter 76 of second computing device 70B. Following step S803A or S803B, as shown in step S503, the first computing device then receives the response message. The reception of the response message may be performed, for example, by the processor 61 of first computing device 60A running a program stored on the memory 62 in conjunction with the interfaces 63, or may be performed by the receiver 66 of first computing device 60B.

Where registration has been successful, the first computing device may then receive a resource identifier of the second computing device (different to the DOTS client identifier) from the second computing device identifying the registration resource created in the DOTS server; the resource identifier of the second computing device may be sent in the confirmation of successful registration, or separately from the confirmation of successful registration. The confirmation of registration is required in order to comply with CoAP protocol, in which registrations and deregistrations are confirmable operations. The resource identifier identifies the registration resource created in the second computing device and may be, for example, a full or partial Uniform Resource Locator (URL). Typically, the first computing device then uses the received resource identifier in further communications with the second computing device.

A URL is composed of various parts: scheme, authority, path, query and fragment. In the example URL “coap://sensor.iot.org:5683/lamp?rt=light-lux#rec=3”, which may relate to an loT connected lamp: the scheme is “coap”; authority is “sensor.iot.org:5683”; path is “/lamp”; query is “?rt=light-lux”; and fragment is “rec=3”. Some of the parts may be absent from some URLs. In the further example URL “coap://[2001 :db8:::1]:5683/temperature?ct=60”, which may relate to an loT temperature sensor: the scheme is “coap”; authority is “[2001 :db8:::1]:5683”; path is “/temperature”; and query is “?ct=60”; there is no fragment. In the further example URL “coap://coap.me:5683/.well-known/core”: the scheme is “coap”; authority is “coap.me:5683”; and path is “/.well-known/core”; there is no query or fragment. Where a URL is used as the identifier of the registration resource in the second computing device this URL may be a full URL including the scheme, authority and path, or may be a partial URL not including the scheme or authority (where the scheme and authority are known). The full or partial URL may or may not contain a query and a fragment.

Where the DOTS client identifier for the first computing device is determined to not be unique (so the DOTS client cannot successfully register on the DOTS server), the response message may be an identifier conflict indication. The identifier conflict indication informs the first computing device that the DOTS client identifier it generated and sent in the request message (at steps S501 and S502) is already being used by another DOTS client registered on the DOTS server. In response to receiving the identifier conflict indication, the first computing device then generates a further DOTS client identifier for the first computing device, and initiates transmission of a further request message to the second computing device comprising the further DOTS client identifier for the first computing device. Essentially, the first computing device repeats steps S501 and S502 using a different DOTS client identifier (for example, a different QUID). Upon receiving the further request message including the further identifier, the second computing device may perform the steps of the method in Figure 8 again; that is, the second computing device may determine whether the further DOTS client identifier is unique or not, and respond accordingly.

If the CoAP messages between the first and second computing devices require security, an option for securing UDP communications is through Datagram Transport Layer Security (DTLS), as discussed in RFC 6347 (produced by the Internet Engineering Task Force, IETF, available at https://tools.ietf.org/html/rfc6347 as of 4 January 4, 2021). A DOTS thin client can establish a DTLS session with the DOTS server during registration. After the registration, the DOTS thin client can resume the same DTLS session. If the DOTS thin client and DOTS server support DTLS 1.3, the resumption of the DTLS session can be done using the 0-RTT mode. In the 0-RTT mode, a DOTS client can authenticate itself and send DOTS messages in the first message, reducing delays due to handshake latency significantly.

As mentioned above, when the first computing device is successfully registered by the second computing device, the first computing device should use the resource identifier sent by the second computing device during the registration procedure in the subsequent messages. Examples of communications following registration include mitigation requests and deregistration messages.

In order to deregister from the DOTS server, the DOTS client (which may be a DOTS thin client) may send a deregistration message requesting the deregistration of the first computing device and comprising the DOTS client identifier (for example, QUID) for the first computing device used to register the first computing device with the second computing device (DOTS server). The DOTS client identifier for the first computing device should be included in the deregistration message in order to ensure the deregistration is correctly implemented. Following the deregistration of the first computing device, the second computing device may initiate the transmission of a confirmation of deregistration to the first computing device.

In addition to deregistering the first computing device following receipt of a deregistration request, the second computing device may also deregister the first computing devices for other reasons. The DOTS server may be configured to maintain the registration of the first device until a condition is satisfied; although a condition may be receipt of a deregistration request from the first computing device, additionally or alternatively a condition may be that a predetermined time period has elapsed without the DOTS server receiving a communication from the first computing device. Other conditions may also be implemented, depending on specific system requirements. If the first computing device attempts to communicate with the second communication device but receives an error message that indicates that the second computing device has deregistered the first computing device, the first computing device may then initiate a registration procedure as discussed above in order to register with the second computing device again.

Embodiments disclosed herein do not require DOTS thin clients to maintain persistent messaging (also defined as heartbeat messaging in RFC8782) in order to avoid a session being ended by a DOTS server, where ending the session would include the deregistration of the DOTS thin client. Accordingly, these embodiments allow DOTS thin clients to enter a sleep mode and remain registered. This can be of particular benefit where the DOTS thin client is hosted by a constrained loT device (for example, using a limited power source such as a battery) for which maintaining persistent messaging would cause unacceptable resource draining. In case that a DOTS thin client and a DOTS server have established a security session (for example, a DTLS security session), the identifier used to register with the DOTS server may be used once the DOTS thin client wakes from sleep to resume the session that commenced before the DOTS thin client entered a sleep state.

Figure 9 is a sequence diagram showing an example of a registration procedure for a DOTS thin client with a DOTS server in accordance with an embodiment. In step 1 , the DOTS thin client attempts registration (by sending a request message) with an existing identifier, specifically “jrOJGBpw”. The DOTS server receives the request message, checks the DOTS client identifier and determines that there is a conflict as the DOTS client identifier is already in use by another DOTS client registered on the DOTS server. The response message sent by the DOTS server at step 2 is therefore an identifier conflict indication, specifically a 4.09 (Conflict) error notifying the DOTS thin client that the identifier “jrOJGBpw” is already use by another DOTS client.

When the DOTS thin client receives the response message, a new identifier “5ed50113” is generated by the DOTS thin client and sent to the DOTS server (step 3). The DOTS server checks the new identifier and determines that it is unique on the DOTS server, therefore the second DOTS client identifier is accepted by the DOTS server. The DOTS server registers the DOTS thin client and returns a confirmation of registration (a 2.01 message) including an identifier of the resource in the DOTS server. Here, the identifier is a path 7sj4gsh” that the DOTS thin client should use for future DOTS operations (step 4).

At some point following registration, the DOTS thin client is caused to deregister from the DOTS signal channel and sends a deregistration message to the DOTS server (step 5). The deregistration message includes the DOTS client identifier used to successfully register the DOTS thin client with the DOTS server, that is, “5ed50113”. The DOTS server responds in this case with a confirmation of the deregistration of the DOTS thin client (step 6); specifically, the DOTS server response with a 2.05 message.

In the event of a first computing device that is registered detecting a DDoS attack, the first computing device may then initiate transmission, using CoAP, of a mitigation request to the second computing device. The mitigation request may request mitigation of the DDoS attack by the second computing device. In some embodiments, the mitigation request message may comprise the DOTS client identifier (for example, CIIID) for the first computing device used to register the first computing device with the second computing device, and may also comprise a message identifier. The message identifier may be used to identify a specific mitigation request; a single DOTS client (which may be a DOTS thin client) may have multiple mitigation requests ongoing at a point in time, so the ability to distinguish between the mitigation requests may be useful. The message identifier may be a MID, as defined in RFC8782. In some embodiments, the first computing device may act as a gateway device, providing network access for one or more connected loT devices. An example situation where a first computing device that acts as a gateway device may be used is in a household setting, where the first computing device may be a home router providing network access for loT devices in the household (such as smart lights or lightbulbs, smart appliances, and so on). A first computing device acting as a gateway device for connected loT devices may also itself be an loT device. Where a first computing acting as a gateway device sends a mitigation request to a second computing device, this mitigation request may include (additionally or alternatively to the DOTS client identifier for the first computing device and/or a message identifier) an indication of which of the one or more loT devices that the gateway device provides network access for are under DDoS attack.

Upon receiving a mitigation request, the DOTS server may begin operations to mitigate the DDoS attack, including sending any necessary communications to other components of the network. Any suitable mitigation techniques may be used, for example, traffic filters, dropping or rate-limiting some traffic, IP filtering some addresses, and so on. Where the first computing device is acting as a gateway device and the DDoS attack is against a device connected to the network using the gateway device (as discussed above), the mitigation techniques may include sending policies that the gateway device can implement to mitigate the attack.

Figure 10 is a sequence diagram showing an example of the response to an attack for a DOTS thin client with a DOTS server in accordance with an embodiment. In the embodiment shown in Figure 10, the DOTS thin client is hosted by a smart lightbulb, which connects to a network via a gateway device (a home router), and the second computing device is one of a plurality of computing devices forming a cloud of devices that hosts the DOTS server.

At step 1 of Figure 10, a registration procedure such as those discussed above with reference to Figures 5, 8 and 9, is executed. During the registration procedure, the DOTS thin client receives the resource identifier of the DOTS server, which in this case is the path 7sj4gsh”. The DOTS client identifier used to register with the DOTS server is, in this example, the QUID “825gh”. The DOTS thin client is registered and has an ongoing session with the DOTS server. Subsequently, the DOTS thin client detects a DDoS attack and sends a mitigation request to the DOTS server, as shown in step 2. As shown in Fig 10, the mitigation request message includes the DOTS server identifier (the path 7sj4gsh”), the QUID of the DOTS thin client “825gh” and the message identifier, which in this example is the MID “12”. In this case, the mitigation request message uses a PUT operation on a path “/mitigate/” followed by the QUID and the MID. In response to the mitigation request message, the DOTS server then sends the appropriate policies to the gateway device, which can be traffic filters, dropping or rate-limiting some traffic, IP filtering some addresses, and so on. The gateway device applies the policies (in step 3), thereby mitigating the DDoS attack. An example of a mitigation request message which may be sent in step 2 of Figure 10 is shown in pseudocode A. The message indicates that the device 2001:db8:6401::1 is receiving DDoS attacks on User Datagram Protocol (UDP) port numbers 5683 and 5684. The validity “lifetime” of the request is set to 3600 seconds; if mitigation is still required after this time period elapses, the DOTS thin client may send a further mitigation request.

Pseudocode A

{

"ietf-dots-signal-channel:mitigation-scope": {

"scope": [

{

"target-prefix": [

"2001:db8:6401 ::1/128"

"target-port-range": [

{"lower-port": 5683}, {"lower-port": 5684},

"target-protocol": [ 16

"lifetime": 3600

}

A further sequence diagram showing an example of the response to an attack for a DOTS thin client with a DOTS server in accordance with an embodiment disclosed herein is shown in Figure 11. The example shown in Figure 11 is similar to that shown in Figure 10, however in the Figure 11 example the DOTS thin client is hosted by the gateway device on behalf of the smart lightbulb, supporting the connected loT devices. Therefore, the gateway device itself registers with the DOTS server in step 1, rather than the loT devices connected to the gateway device individually registering (as is the case in the Figure 10 example). In step 2, the gateway device may indicate which of the connected loT devices are under attack. Example pseudocode showing how the gateway device may signal that three different connected loT devices (::1 , ::2, ::3) are under attack is shown below as pseudocode B; this code may be used to replace the "target-prefix": [ "2001:db8:6401 ::1/128"] code in pseudocode A. Pseudocode B

"target-prefix": [

"2001:db8:6401 ::1/128",

"2001:db8:6401 ::2/128",

"2001:db8:6401 ::3/128"

In the examples shown in Figure 10 and Figure 11 , the DOTS server is hosted by a second computing device (or cloud of devices comprising a second computing device) and is connected to the first computing device (the loT device in the Figure 10 example and the gateway device in the Figure 11 example) using CoAP; the first and second computing devices in both examples are CoAP endpoints.

A further example sequence diagram in accordance with an embodiment disclosed herein is shown in Figure 12. Whereas the scenarios in Figure 9, Figure 10, and Figure 11 represent non-cellular scenarios, the example in Figure 12 represents a cellular scenario. In the example shown in Figure 12, a Service Capability Exposure Function (SCEF) is used to securely expose the servers and capabilities provided by 3GPP network interfaces. It also may support CoAP for IP when SCEF implements a SCEF dispatcher, which is essentially a CoAP Proxy towards other components of the SCEF. SCEF provides interfaces for supporting non-IP data delivery (NIDD) and exposing external Application Programming Interfaces (API) to allow third party device access. Data between the SCEF and DOTS server may be exchanged, for example, using a interface such as the T8 interface (as defined in “T8 reference point for Northbound APIs” by 3GPP, TS 29.122 v17.0.0, available at htps://portal.3gpp. org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationld=3239 as of 12 January 2021). The T8 interface is an interface that provides low power data transfer of data between third-party application servers and loT devices.

In the example shown in Figure 12, the first and second computing devices are again CoAP endpoints, but the second computing device does not itself host the DOTS server (and also does not form part of a cloud of devices hosting the DOTS server). Instead, the second computing device is a CoAP proxy connected to a DOTS server. The first computing device in the Figure 12 example is the loT device (a smart light or lightbulb) hosting the DOTS thin client. The second computing device is the SCEF; the CoAP proxy connected to the DOTS server, and is also a gateway device. In step 1 the DOTS thin client registers with the DOTS Server and gets the 7sj4gsh” resource path. The DOTS Server is running on an Application Server outside the ISP boundaries, and the registration takes place via the CoAP proxy (gateway device). When an attack is detected, the DOTS thin client sends a mitigation request to the CoAP proxy in step 2, which then passes the request on to the DOTS server in step 3 using the T8 interface. In response to the mitigation request the DOTS server sends the mitigation policy through the T8 interface, and will then communicate to one or more components to take some action against the DDOS attack. The response could include the DOTS server communicating with the Home Subscriber Server (HSS) to see the subscribe information and send an alert to it, and/or the DOTS server could expose the attack information to other applications over HTTP to allow other applications to monitor information about the vulnerable endpoint.

Embodiments of the present disclosure provide support for the mitigation of DDoS attacks. In embodiments lightweight DOTS systems which are suitable for a broad range of devices, including resource-constrained loT devices are provided. Embodiments include a simple registration/deregistration procedure to avoid unnecessary messaging, as well as a DOTS thin client that operates using the signal channel of DOTS only (and does not use the DOTS data channel). Embodiments may provide relief from DDoS attacks for a broader range of devices than are supported by existing systems. Further, as CoAP are used extensive modifications to protocols used by devices are not required in order to implement embodiments.

It will be appreciated that examples of the present disclosure may be virtualised, such that the methods and processes described herein may be run in a cloud environment.

The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1. A first computing device (60A) operable to mitigate Distributed Denial-of Service, DDoS, attacks, the first computing device (60A) comprising processing circuitry (61) configured to: generate a DDoS Open Threat Signalling, DOTS, client identifier for the first computing device (60A); initiate transmission of a request message to a second computing device (70A) requesting the registration of the first computing device (60A), the request message comprising the DOTS client identifier; and receive a response message from the second computing device (70A), the response message being sent in response to the second computing device (70A) receiving the request message; wherein the first computing device (60A) and second computing device (70A) are Constrained Application Protocol, CoAP, endpoints, and wherein the request message and response message are transmitted via a DOTS signal channel.

2. The first computing device (60A) of claim 1 configured such that, if the response message is a confirmation of successful registration, the first computing device (60A) is configured to receive a response identifier of the second computing device (70A) from the second computing device (70A), and to use the received response identifier in further communications with the second computing device (70A).

3. The first computing device (60A) of any preceding claim configured such that, if the response message is an identifier conflict indication, the first computing device (60A) is configured to generate a further DOTS client identifier for the first computing device (60A), and initiate transmission of a further request message to the second computing device (70A) comprising the further DOTS client identifier.

4. The first computing device (60A) of any preceding claim configured such that, if the first computing device (60A) has received confirmation of successful registration from the second computing device (70A) and subsequently determines to deregister, the first computing device (60A) initiates transmission of a deregistration message to the second computing device (70A), the deregistration message requesting the deregistration of the first computing device (60A) and comprising the DOTS client identifier used to register the first computing device (60A) with the second computing device (70A).

5. The first computing device (60A) of any preceding claim configured such that, if the first computing device (60A) detects a DDoS attack, the first computing device (60A) initiates transmission of a mitigation request message to the second computing device (70A), the mitigation request message requesting mitigation of the DDoS attack.

6. The first computing device (60A) of claim 5, wherein the mitigation request message comprises the DOTS client identifier used to register the first computing device (60A) with the second computing device (70A), and further comprises a message identifier.

7. The first computing device (60A) of any of claims 5 and 6, wherein the first computing device (60A) is a gateway device configured to provide network access for one or more Internet of Things, loT, devices, and wherein the mitigation request message comprises an indication of which of the one or more loT devices that the gateway device provides network access for are under DDoS attack.

8. The first computing device (60A) of any of claims 1 to 6, wherein the first computing device (60A) is an Internet of Things, loT, device.

9. The first computing device (60A) of claim 8, wherein the loT device is a resource constrained loT device.

10. The first computing device (60A) of any preceding claim, wherein the first computing device (60A) hosts a DOTS thin client.

11. A system comprising the first computing device (60A) of any of claims 1 to 10, further comprising the second computing device (70A).

12. The system of claim 11 , wherein the second computing device (70A) hosts a DDoS Open Threat Signalling, DOTS, server, or wherein the second computing device (70A) is one of a plurality of computing devices forming a cloud of devices and the cloud of devices hosts a DOTS server.

13. The system of claim 11 , wherein the second computing device (70A) is a CoAP proxy connected to a DOTS server.

14. The system of any of claims 11 to 13, wherein the DOTS server is configured to maintain the registration of the first device (60A) until a condition is satisfied.

15. The system of claim 14, wherein the condition is the receipt of a deregistration message from the first computing device (60A) requesting the deregistration of the first computing device (60A).

16. The system of claim 14, wherein the condition is that a predetermined time period elapses without the DOTS server receiving a communication from the first computing device (60A).

17. The system of any of claims 11 to 16 wherein, if the second computing device (70A) receives a mitigation request from the first computing device (60A), the second computing device (70A) is configured to provide a mitigation response to the first computing device (60A).

18. A method for mitigating Distributed Denial-of-Service, DDoS, attacks, the method comprising: generating, at a first computing device (60A, 60B) a DDoS Open Threat Signalling, DOTS, client identifier for the first computing device (60A, 60B); initiating transmission, by the first computing device (60A, 60B), of a request message to a second computing device (70A, 70B) requesting the registration of the first computing device (60A, 60B), the request message comprising the DOTS client identifier; and receiving, at the first computing device (60A, 60B), a response message from the second computing device (70A, 70B), the response message being sent in response to the second computing device (70A, 70B) receiving the request message; wherein the first computing device (60A, 60B) and second computing device (70A, 70B) are Constrained Application Protocol, CoAP, endpoints, and wherein the request message and response message are transmitted via a DOTS signal channel.

19. The method of claim 18, wherein, if the response message is a confirmation of successful registration, the first computing device (60A, 60B) receives a response identifier of the second computing device (70A, 70B) from the second computing device (70A, 70B), and uses the received response identifier in further communications with the second computing device (70A, 70B).

20. The method of any of claims 18 and 19 wherein, if the response message is an identifier conflict indication, the first computing device (60A, 60B) generates a further DOTS client identifier for the first computing device (60A, 60B), and initiates transmission of a further request message to the second computing device (70A, 70B) comprising the further DOTS client identifier.

21. The method of any of claims 18 to 20 wherein, if the first computing device (60A, 60B) has received confirmation of successful registration from the second computing device (70A, 70B) and subsequently determines to deregister, the first computing device (60A, 60B) initiates transmission of a deregistration message to the second computing device (70A, 70B), the deregistration message requesting the deregistration of the first computing device (60A, 60B) and comprising the DOTS client identifier used to register the first computing device (60A, 60B) with the second computing device (70A, 70B).

22. The method of any of claims 18 to 21 wherein, if the first computing device (60A, 60B) detects a DDoS attack, the first computing device (70A, 70B) initiates transmission of a mitigation request message to the second computing device (60A, 60B), the mitigation request message requesting mitigation of the DDoS attack.

23. The method of claim 22, wherein the mitigation request message comprises the DOTS client identifier used to register the first computing device (60A, 60B) with the second computing device (70A, 70B), and further comprises a message identifier.

24. The method of any of claims 22 and 23, wherein the first computing device (60A, 60B) is a gateway device configured to provide network access for one or more Internet of Things, loT, devices, and wherein the mitigation request message comprises an indication of which of the one or more loT devices that the gateway device provides network access for are under DDoS attack.

25. The method of any of claims 18 to 23, wherein the first computing device (60A, 60B) is an Internet of Things, loT, device.

26. The method of claim 25, wherein the loT device is a resource constrained loT device.

27. The method of any of claims 18 to 26, wherein the first computing device (60A, 60B) hosts a DOTS thin client.

28. The method of any of claims 18 to 27, wherein the second computing device (70A, 70B) hosts a DDoS Open Threat Signalling, DOTS, server, or wherein the second computing device (70A, 70B) is one of a plurality of computing devices forming a cloud of devices and the cloud of devices hosts a DOTS server.

29. The method of claim 28, wherein the second computing device (70A, 70B) is a CoAP proxy connected to a DOTS server.

30. The method of any of claims 28 and 29, wherein the DOTS server maintains the registration of the first device (60A, 60B) until a condition is satisfied.

31. The method of claim 30, wherein the condition is the receipt of a deregistration message from the first computing device (60A, 60B) requesting the deregistration of the first computing device (60A, 60B).

32. The method of claim 30, wherein the condition is that a predetermined time period elapses without the DOTS server receiving a communication from the first computing device (60A, 60B).

33. The method of any of claims 18 to 32 wherein, if the second computing device (70A, 70B) receives a mitigation request from the first computing device (60A, 60B), the second computing device (70A, 70B) provides a mitigation response to the first computing device (60A, 60B).

34. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of claims 18 to 33.

35. A carrier containing a computer program as claimed in claim 34, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

36. A computer program product comprising non transitory computer readable media having stored thereon a computer program as claimed in claim 34.