1. Introduction

1.2. IoT Protocols

1

IEEE 802.15.4 Protocol

Both physical and MAC layers are ruled by IEEE 802.15.4 protocol which emerged in 2003. The physical layer provides some functionalities such as transferring data, detecting the energy of the channel, and indicating the link quality [11], whereas the MAC layer associates, disassociates, acknowledges frame arrival, and validates frame.

2

6LoWPAN protocol

Lower-Power Wireless Personal Area Network 6LoWPAN has emerged in 2007 due to the demand for low-energy IoT protocol [10]. It allows a direct connection to the internet and defines encapsulation and header compression mechanisms. 6LoWPAN is considered a replacement for IPv6. This protocol supports addresses with different lengths, low bandwidth, and costs.

3

Routing – RPL protocol

IETF proposed Routing Protocol Layer (RPL) for Low Power and Lossy Networks (LLNs) that provides IPv6 connectivity to the LLNs [12]. This protocol is used in multiple networking facilities such as automated homes, automated industry, and automated buildings.

4

CoAP Protocol

The Constrained Application Protocol (CoAP) is a proper web transfer protocol for lower resources devices and LLNs [13]. The nodes often have 8-bit microcontrollers and limited RAM and ROM. The protocol supports M2M applications like an automated smart home. Due to the demand for a proper design of a generic web protocol that fits constrained devices, CoAP has emerged.

1.2.1. CoAP Architecture

CoAP relies on the client/server model like HTTP with the usage of the request-response model for exchanging messages. The communication between two machines inspires a CoAP to interfere and acts as a client or as a server. A CoAP request is similar to an HTTP request which asks for a resource on a server. The resource is identified by URI. Thus, a response code from the server is sent back with the representation of the resource. So, CoAP architecture includes the message layer and the request-response layer as the main layers. The former is responsible for message delivery over UDP for two nodes and it supports optional reliability. As a result, it is in charge of the redundancy and consistency of any message. The latter avoids having outdated messages or having more copies of a message by holding the code of the requesting and responding.

Figure 3. Layers of the CoAP Protocol.

Figure 3. Layers of the CoAP Protocol.

1.2.2. Messaging Model

Messaging model of CoAP is based on sending and receiving messages over UDP for two nodes. CoAP has a 4-byte header, then it has options and payload. Each message has a message ID for duplication check and a reliable connection if desired. Four types of messages are supported by CoAP as follows:

1

Confirmable Message (CON): in this mode, all messages are marked as confirmable messages (reliable mode). The message is resent using a default timeout till receiving an Acknowledgement from the recipient with the same messageID as the sender. If the recipient failed to process the confirmable message, the recipient will send a reset message (RST) instead of (ACK) to reset the communication. Figure 4 shows the confirmable mode between the client and the server.

Figure 4. Confirmable message transmission.

Figure 4. Confirmable message transmission.

2

Non-Confirmable Message (NON): if reliable delivery is not desired, the message can be sent as a non-confirmable message (unreliable mode). For duplication check purposes, the message is not acknowledged but still has a messageID. Besides, the recipient could send a reset message if it failed to respond to the NON-message. Figure5 depicts the NON-message between the client and the server.

Figure 5. NON-Confirmable message transmission.

Figure 5. NON-Confirmable message transmission.

1.2.3. Request/Response Model

Request and response semantics which include method/response code is carried by the CoAP message. Some information about the request and response are considered optional such as the URI and payload media type. To check the identity of requests and responses, a token is used to connect responses with their opposite requests independently. Conceptually, Token differs from messageID. There are three types of messages in the request-response model as follows:

Piggybacked message: CON or NON-message carries a request and if instantly enforced, the response carried in a CON message is carried in the resulting ACK message. Figure 6 shows two examples of a basic GET request with a piggyback response, one for success and the other resulting in a 4.04 (Not Found) response. Hence, the code [0x00] is the message ID.

Empty Message: if the server is not able to respond immediately to a request carried on the CON message, an empty Acknowledgement.

The message is used to respond to the request so the client can stop retransmitting the request. If the response is ready, the server sends it in a new confirmable message as depicted in Figure 7.

Non-Confirmable Message: if a non-Confirmable mode is used to send a message, then either a new Non-Confirmable or a Confirmable message is used to send the response as illustrated in Figure 8.

1.2.4. Message Format

CoAP sends/receives messages and employs UDP for transportation. The encoding of CoAP messages is a simple binary format. A fixed-size 4-byte format appears in the header of the message, then it is followed by a Token value that is 0-8 bytes long. After the Token value, CoAP Options in Type-Length-Value (TLV) format appear, or a sequence of zeros for non-option is displayed. Finally, an optional payload appears that takes up the rest of the datagram. Figure 9 depicts the CoAP message format. The header fields can be elaborated as follows:

(1)

Version (V): unsigned integer (2-bit) that represents the CoAP version number. This field takes (01 binary), and other values are reserved for future versions. If the message comes with unknown version numbers, it must be ignored.

(2)

Type (T): unsigned integer (2-bit) that represents 0 for Confirmable, 1 for Non-Confirmable, 2 for Acknowledgement, or 3 for reset as illustrated in the previous section.

(3)

Token Length (TKL): unsigned integer (4-bit) with a length of 0 to 8 bytes. Lengths 9-15 are specialized for message format errors.

(4)

Code: unsigned integer (8-bit) that is divided into the most significant bits (3-bit) and the least significant bit (5-bit). It is represented as "c.dd" ("c" can be 0-7 as a digit for the 3-bit, and "dd" can be two digits in the range from 00 to 31 for the 5-bit). The most significant bits view 0 for a request, 2 for a successful response, 4 for a client error response, or 5 for a server error response. The other most significant bits are reserved. The code 0.00 represents an Empty message as a special case.

(5)

MessageID: unsigned integer (16-bit) used for duplicate vetting purposes. It is also used to match Acknowledgement/Reset messages to messages of type Confirmable or Non-Confirmable, respectively.

(6)

Token: maybe 0 to 8 bytes based on the length stated in the TKL field. It is used to correlate requests and responses.

(7)

Options: can be 0, by another option, or by the payload.

(8)

Payload: if exists, it is prefixed by a (0xFF) marker as a benchmark for payload start. To calculate the length of the payload, it is counted from the end of the marker until the UDP datagram end.

1.2.5. Method Definitions

Like HTTP, CoAP uses methods (GET, POST, PUT and DELETE) to take any action on a URI resource. CoAP message follows RESTful architecture that makes it fit for constrained devices as a lightweight protocol. A request that carries fault method code results in a 4.05 (Unallowed method) piggyback response. We will briefly elaborate on each method.

GET

The GET method retrieves the information's representation that belongs to the resource identified by the request URI. If the GET method succeeds, a 2.05 (Content) is presented, or a 2.03 (Valid) response code appears.

POST

The POST method functionality is to process the representation retrieved by the request. The origin server performs the main functionality of the POST method depending on the target resource. The result of this action is a creation of a new resource, or an updating process is performed on the target resource. In the case of the creation of a new resource, the response should have a 2.01 (Created) code with the corresponding URI of the created source. However, if POST is processed but the creation of a new source on the server fails, so a 2.04 (Changed) response code is generated. If POST is processed and results in a deletion of a resource, the response should have a 2.02 (Deleted) response code.

PUT

The PUT method functionality is confined to creating or updating the resource identified by the request URI. The enclosed representation format is specified by the media type and content coding provided in the Content-Format option (if it is given). In the case of existing resources at the request URI, the enclosed representation is a modification copy, and a 2.04 (Changed) response code is issued. Otherwise, a new resource should be created by the server and aligned to that URI, and then, a 2.01 (Created) response code is issued. In case of modifying or creating failure, then the error response code is returned.

DELETE

The DELETE method requests to drop the resource that the request URI identifies. If the deletion is a success, a 2.02 (Deleted) is issued. The same message is returned if the resource did not show up before the request.

1.2.6. CoAP URIs

The CoAP uses "coap" and "coaps" URI schemes to identify and locate the resources. A CoAP server hierarchically organizes and governs these resources, and it waits to receive CoAP requests on a specified UDP port number. So, the CoAP methods discussed above are used to access the resources on the CoAP server. Therefore, the "coap" and "coaps" URI schemes are similar to that of "HTTP" and "HTTPS" used with the HTTP protocol.

2. Literature Review

2.3. CoAP Security Overview

This section introduces the DTLS binding for CoAP. Indeed, CoAP is equipped with the security demands such as keying materials and an access control list during the provisioning phase, or what so-called RawPublicKey mode. After RawPublicKey mode finishes, the IoT device should be in one of the following security modes:

A- NoSec Mode: No security protocol is engaged (DTLS disabled). Alternatively, assuming lower-layer protocol will implement the security mechanism; thus, messages are transferred with no security.

B- PresharedKey Mode: enabled DTLS. This mode has a list of pre-shared keys and there is a list of nodes that are assumed to engage in the communication for every key. For instance, in a significant scenario, every node has its key if it engages in CoAP communication. Contrarily, if a specific pre-shared key is shared with two entities or more, the entities are authenticated as a group by that key and would not be considered as specific peers anymore.

C- RawPublicKey Mode: enabled DTLS. This mode is adopted by the devices that required authentication, which uses the asymmetric key for each device to help to identify and communicate with these devices without a certificate.

D- Certificate Mode: DTLS is enabled. In this mode, an asymmetric key pair with X.509 certificate is reserved for a given device. The certificate is validated by what is called Certification Authority (CA).

2.3.1. Proposed defense mechanisms for Securing CoAP against DDoS Attacks

DTLS for CoAP Security

Some researchers proposed that DTLS be implemented in CoAP for security purposes. Maleh et al., (2016) mentioned that Datagram Transport Layer (DTLS) handshake suffers from spoofing IP address DDoS attacks [28]. To face this issue, the DTLS handshake is expanded with a cookie exchange technique. The capability and threshold for receiving packets must be declared with the IP address to the server, then, the server reserves resources for new communication. Because of the costly energy of this technique, they moved it to Proxy AC Server with no energy constraints. Their method reduces the resource occupancy DTLS ROM by 23% compared to standard DTLS. Haroon A. et al. (2017) proposed an enhancement to DTLS to make it resistant to DDoS attacks [29]. They claim that their method can reduce the overhead of handshaking time, packet size, and energy consumption compared to other works. The authors’ system named E-lithe relies on Trusted Third Party (TTP) to reduce the overhead on the server-side. Compared to Lithe and other works, E-lithe outperforms others in terms of running time and reduced packet size. Later, this work was enhanced by Shruti et al., (2018) who claimed that their work outperforms E-Lithe [30]. The authors’ work essentially focuses on the comparison between the payload of benign and malicious packets, defining a threshold, if the threshold is exceeded, then the source IP is blocked. They evaluate their work based on the malicious packet delivery ratio and legitimate packet drop ratio which outperforms the work done by Haroon et al.

SDN for CoAP Security

Alzahrani et al. (2020) implemented a software-defined networking scheme to authorize the messages over the CoAP protocol [31]. They argue that distributed approach in which IoT devices employ powerful gateways attached to them may be insufficient and making the access control decisions accomplished by the controller renders the security of CoAP messages more efficient and can help to avoid DDoS attacks.

Machine Learning for CoAP Security

Machine Learning is also proposed to detect and mitigate DDoS attacks against CoAP. Granjal et al., (2018) developed a framework that employs a threshold to mitigate DDoS attacks [32]. They define a limit for messages of CoAP, and after the limit is exceeded, extra messages will be dropped. The authors enhanced their work and proposed an anomaly-based detection system to protect the 6LoWPAN and CoAP protocol from DDoS attacks [33]. SVM is used as an ML-Classifier and gains an accuracy of 93%. However, the system generates a high false-positive rate of around 20%. Doshi et al., (2018) developed a machine learning pipeline that is employed on middleboxes such as routers or firewalls to detect IoT DDoS attacks [34]. They claim that IoT traffic is distinct from other traffics coming from other internet-connected devices because IoT traffic is repetitive and often communicates with a small finite of endpoints. After testing this method, it gains an accuracy of 99% using RF, KNN, and Neural Networks.

Other Methods for CoAP Security

Other works propose different methods to cope with DDoS attacks against CoAP. Anirudh et al. (2017) propose a honeypot to lure the attacker and log his information for future verification or block purposes.

Table 2. Summary of IoT-CoAP defense mechanisms.

Table 2. Summary of IoT-CoAP defense mechanisms.

3. Materials and Methods

3.1. Dataset Collection

The CIDAD dataset is mainly targeting the CoAP with three different DDoS attacks: duplication, interception, and modification of the CoAP message with total malware samples of 288 only. Interception means intercepting stochastically sent packets before reaching the destination, whereas duplication is changing the content of the CoAP message, and modification is increasing the number of tokens. The rest of the ~10,000 packets are benign packets. This poses an imbalance in the dataset since only 0.02% of the dataset is malware. So, we extend the dataset to 100,000 samples, of which ~50% for benign and ~50% are for malware. We used to use Generative Adversarial Network (GAN) to extend the 288 malware samples to ~50,000 samples. The generated samples are compared with the original data to ensure the similarity between them by training each and calculating the RMSE. Our finding is surprising that the RMSE is ~0.005 for original data whereas the generated data is ~0.09. This indicates a coherent similarity between the original malware and the generated ones. On the other hand, for the benign samples, we do the same and find that RMSE for the original samples and the generated ones is ~0.03. Figure 10. Illustrate the general structure for GANs. Figure 11. Shows the distribution of the collected dataset.

Figure 10. GAN Architecture [40].

Figure 10. GAN Architecture [40].

Figure 12. The distribution of the collected dataset (0 for benign, 1 for malware).

Figure 12. The distribution of the collected dataset (0 for benign, 1 for malware).

3.2. Feature Extraction

CoAP has a total of 86 features that can be extracted from the pcap file. However, most of them have a huge number of missing values due to optionality in the communication and the GANs cannot generate fake data for empty values of the features. Only 10 features have decent values in the dataset. So, we only focus on these features as depicted in Figure 13. Then, we use the Pearson Correlation method formula (1) to get the relevant features to the label.

$${\mathit{r}}_{\mathit{x}\mathit{y}}={\displaystyle \sum _{\mathit{i}=1}^{\mathit{n}}}\frac{\left({\mathit{x}}_{\mathit{i}}-\overline{\mathit{x}}\right)\left({\mathit{y}}_{\mathit{i}}-\overline{\mathit{y}}\right)}{\sqrt{\sum _{\mathit{i}=1}^{\mathit{n}}{\left({\mathit{x}}_{\mathit{i}}-\overline{\mathit{x}}\right)}^2}\sqrt{\sum _{\mathit{i}=1}^{\mathit{n}}{\left({\mathit{y}}_{\mathit{i}}-\overline{\mathit{y}}\right)}^2}}$$

(1)

Where r_xy is the Pearson correlation between two features x and y, n represents the total number of samples, ${\mathit{x}}_{\mathit{i}}\mathit{a}\mathit{n}\mathit{d}{\mathit{y}}_{\mathit{i}}$ are the individual sample points indexed with i, $\overline{\mathit{x}}$ is the sample mean, and the same for $\overline{\mathit{y}}$.

We focus only on the features that have ±0.30 correlation to the label. Figure 13. shows the correlation between the features and the label.

The Pearson Correlation for all the features is less than the target value ±0.30. Therefore, we use other methods which represent the statistical methods: Lasso Regression and One-Way ANOVA test. Lasso Regression is a regression analysis that deepens the accuracy and interpretability by performing regularization alongside the variable selection as shown in formula (2). On the other hand, One-Way ANOVA checks the significant independence of two or more samples, where the P-value decides a rejection for the null hypothesis of samples equality if the score is less than 0.05 as shown in formula (3).

(2)

Where M for the total number of samples, P for features, and w is the slope.

$$\mathit{F}=\frac{\mathit{M}\mathit{S}\mathit{B}}{\mathit{M}\mathit{S}\mathit{W}}$$

(3)

Where F represents the ANOVA coefficient, MSB: Mean sum of squares between the samples, and MSW: Mean sum of squares within samples.

We assume that any feature that is recommended by the two methods (ANOVA and Lasso) is correlated to the label and will be used for the training phase of the model. After calculating the Lasso and ANOVA methods, we find a total of six features that are recommended by both methods as depicted in Figure 14.

The recommended features are coap.mid, coap.opt.disc, coap.opt.location_query,coap.opt.uri_host, coap.retransmitted, and coap.token. Table 3. Shows the description for each feature. The features that are recommended by the ANOVA only are ignored.

4. Results

4.3. Decision Tree

This algorithm performs well with an accuracy of 98%. The number of false positives is 347 while the false negative rate is 302. The ROC curve infers the optimism of the decision tree algorithm.

Figure 20. Confusion matrix for DT algorithm.

Figure 20. Confusion matrix for DT algorithm.

Figure 21. ROC curve for DT.

Figure 21. ROC curve for DT.

5. Discussion

6. Conclusions

References

1. Vishwakarma, R.; Jain, A.K. ‘A survey of DDoS attacking techniques and defense mechanisms in the IoT network’. Telecommunication systems 2020, 73, 3–25. [Google Scholar] [CrossRef]
2. Syed, N.F. IoT-MQTT based denial of service attack modeling and detection. 2020. [Google Scholar]
3. Hussain, F.; Abbas, S.G.; Husnain, M.; Fayyaz, U.U.; Shahzad, F.; Shah, G.A. ‘IoT dos and DDoS attack detection using resnet’. arXiv 2020, arXiv:2012.01971. [Google Scholar]
4. Deng, L.; Li, D.; Yao, X.; Cox, D.; Wang, H. ‘Mobile network intrusion detection for IoT system based on transfer learning algorithm’. Cluster Computing 2019, 22, 9889–9904. [Google Scholar] [CrossRef]
5. Iglesias-Urkia, M.; Orive, A.; Urbieta, A.; Casado-Mansilla, D. Analysis of coap implementations for the industrial internet of things: a survey. Journal of Ambient Intelligence and Humanized Computing 2019, 10, 2505–2518. [Google Scholar] [CrossRef]
6. Alhaidari, F.A.; Alqahtani, E.J. Securing communication between fog computing and IoT using constrained application protocol (coap): A survey. Journal of Communications 2020, 15, 14–30. [Google Scholar] [CrossRef]
7. Bhardwaj, K.; Miranda, J.C.; Gavrilovska, A. Towards IoT-DDoS prevention using edge computing, in ‘{USENIX} Workshop on Hot Topics in Edge Computing (HotEdge 18)’. 2018. [Google Scholar]
8. Shafiq, M.; Tian, Z.; Sun, Y.; Du, X.; Guizani, M. Selection of effective machine learning algorithm and bot-IoT attacks traffic identification for the internet of things in the smart city. Future Generation Computer Systems 2020, 107, 433–442. [Google Scholar] [CrossRef]
9. Vishwakarma, R.; Jain, A.K. A honeypot with machine learning-based detection framework for defending IoT based botnet DDoS attacks. In Proceedings of the 2019 3rd International Conference on Trends in Electronics and Informatics (ICOEI); 2019; pp. 1019–1024. [Google Scholar]
10. Rahman, R.A.; Shah, B. Security analysis of IoT protocols: A focus in coap. In Proceedings of the 2016 3rd MEC international conference on big data and smart city (ICBDSC); 2016; pp. 1–7. [Google Scholar]
11. Mohamadi, M.; Djamaa, B.; Senouci, M.R. ‘Industrial internet of things over IEEE 802.15. 4 tsch networks: design and challenges’. International Journal of Internet Technology and Secured Transactions 2020, 10, 61–80. [Google Scholar] [CrossRef]
12. Musaddiq, A.; Zikria, Y.B.; Kim, S.W.; et al. ‘Routing protocol for low-power and lossy networks for heterogeneous traffic network’. EURASIP Journal on Wireless Communications and Networking 2020, 2020, 1–23. [Google Scholar] [CrossRef]
13. Shelby, Z.; Hartke, K.; Bormann, C. ‘The constrained application protocol (coap)’. 2014. [Google Scholar]
14. Munshi, A.; Alqarni, N.A.; Almalki, N.A. DDoS attack on IoT devices. In Proceedings of the 2020 3rd International Conference on Computer Applications & Information Security (ICCAIS); 2020; pp. 1–5. [Google Scholar]
15. Conti, M.; Kaliyar, P.; Lal, C. ‘Censor: Cloud-enabled secure IoT architecture over SDN paradigm’. Concurrency and Computation: Practice and Experience 2019, 31, e4978. [Google Scholar] [CrossRef]
16. Özçelik, M.; Chalabianloo, N.; Gür, G. Software-defined edge defense against IoT-based DDoS. In Proceedings of the 2017 IEEE International Conference on Computer and Information Technology (CIT); 2017; pp. 308–313. [Google Scholar]
17. Yin, D.; Zhang, L.; Yang, K. ‘A DDoS attack detection and mitigation with software-defined internet of things framework’. IEEE Access 2018, 6, 24694–24705. [Google Scholar] [CrossRef]
18. Galeano-Brajones, J.; Carmona-Murillo, J.; Valenzuela-Valdés, J.F.; Luna-Valero, F. ‘Detection and mitigation of dos and DDoS attacks in IoT-based stateful Sdn: An experimental approach’. Sensors 2020, 20, 816. [Google Scholar] [CrossRef] [PubMed]
19. Yang, Y.; Wang, J.; Zhai, B.; Liu, J. IoT-based DDoS attack detection and mitigation using the edge of sdn. In ‘International Symposium on Cyberspace Safety and Security; Springer, 2019; pp. 3–17. [Google Scholar]
20. Meidan, Y.; Bohadana, M.; Mathov, Y.; Mirsky, Y.; Shabtai, A.; Breitenbacher, D.; Elovici, Y. ‘N-baIoT—network-based detection of IoT botnet attacks using deep autoencoders’. IEEE Pervasive Computing 2018, 17, 12–22. [Google Scholar] [CrossRef]
21. Cvitić, I.; Peraković, D.; Periša, M.; Botica, M. ‘Novel approach for detection of IoT generated DDoS traffic’. Wireless Networks 2019, 1–14. [Google Scholar] [CrossRef]
22. Soe, Y.N.; Santosa, P.I.; Hartanto, R. DDoS attack detection based on simple ann with smote for IoT environment. In Proceedings of the 2019 Fourth International Conference on Informatics and Computing (ICIC); 2019; pp. 1–5. [Google Scholar]
23. Dao, N.-N.; Phan, T.V.; Kim, J.; Bauschert, T.; Cho, S.; et al. ‘Securing heterogeneous IoT with intelligent DDoS attack behavior learning’. arXiv 2017, arXiv:1711.06041. [Google Scholar] [CrossRef]
24. Jia, Y.; Zhong, F.; Alrawais, A.; Gong, B.; Cheng, X. ‘Flowguard: an intelligent edge defense mechanism against IoT DDoS attacks’. IEEE Internet of Things Journal 2020, 7, 9552–9562. [Google Scholar] [CrossRef]
25. Dai, W.; Wan, P.; Qiang, W.; Yang, L.T.; Zou, D.; Jin, H.; Xu, S.; Huang, Z. ‘Tnguard: Securing IoT oriented tenant networks based on sdn’. IEEE Internet of Things Journal 2018, 5, 1411–1423. [Google Scholar] [CrossRef]
26. Djouani, R.; Djouani, K.; Boutekkouk, F.; Sahbi, R. A security proposal for IoT integrated with sdn and cloud. In Proceedings of the 2018 6th International Conference on Wireless Networks and Mobile Communications (WINCOM); 2018; pp. 1–5. [Google Scholar]
27. Muthanna, A.; AAteya, A.; Khakimov, A.; Gudkova, I.; Abuarqoub, A.; Samouylov, K.; Koucheryavy, A. ‘Secure and reliable IoT networks using fog computing with software-defined networking and blockchain’. Journal of Sensor and Actuator Networks 2019, 8, 15. [Google Scholar] [CrossRef]
28. Maleh, Y.; Ezzati, A.; Belaissaoui, M. An enhanced dtls protocol for internet of things applications. In Proceedings of the 2016 International Conference on Wireless Networks and Mobile Communications (WINCOM); 2016; pp. 168–173. [Google Scholar]
29. Haroon, A.; Akram, S.; Shah, M.A.; Wahid, A. E-lithe: A lightweight secure dtls for IoT. In Proceedings of the 2017 IEEE 86th Vehicular Technology Conference (VTC-Fall); 2017; pp. 1–5. [Google Scholar]
30. Kajwadkar, S.; Jain, V.K. A novel algorithm for dos and DDoS attack detection in internet of things. In Proceedings of the 2018 Conference on Information and Communication Technology (CICT); 2018; pp. 1–4. [Google Scholar]
31. Alzahrani, B.; Fotiou, N. ‘Enhancing internet of things security using software-defined networking’. Journal of Systems Architecture 2020, 110, 101779. [Google Scholar] [CrossRef]
32. Granjal, J.; Pedroso, A. ‘An intrusion detection and prevention framework for internet-integrated coap wsn’. Security and Communication Networks 2018. 2018. [CrossRef]
33. Granjal, J.; Silva, J.M.; Lourenço, N. ‘Intrusion detection and prevention in coap wireless sensor networks using anomaly detection’. Sensors 2018, 18, 2445. [Google Scholar] [CrossRef]
34. Doshi, R.; Apthorpe, N.; Feamster, N. Machine learning ddos detection for consumer internet of things devices. In Proceedings of the 2018 IEEE Security and Privacy Workshops (SPW); 2018; p. 29. [Google Scholar]
35. Anirudh, M.; Thileeban, S.A.; Nallathambi, D.J. Use of honeypots for mitigating dos attacks targeted on IoT networks. In Proceedings of the 2017 International conference on computer, communication and signal processing (ICCCSP); 2017; pp. 1–4. [Google Scholar]
36. Mergendahl, S.; Sisodia, D.; Li, J.; Cam, H. Fr-ward: Fast retransmit as a wary but ample response to distributed denial-of-service attacks from the internet of things. In Proceedings of the 2018 27th International Conference on Computer Communication and Networks (ICCCN)’; 2018; pp. 1–9. [Google Scholar]
37. Arvind, S.; Narayanan, V.A. An overview of security in coap: Attack and analysis. In Proceedings of the 2019 5th International Conference on Advanced Computing & Communication Systems (ICACCS); 2019; pp. 655–660. [Google Scholar]
38. Vigoya, L.; Fernandez, D.; Carneiro, V.; Cacheda, F. (8135, 01 January). Cidad.pcap Dad-Repository/CIDAD@A109B87. Retrieved 14 April 2023, from https://github.com/dad-repository/cidad/commit/a109b8706174af5d6b1cb06f6afac5fe0ce2b28e.
39. Kahng, M.; Thorat, N.; Chau, D.H.; Viégas, F.B.; Wattenberg, M. Gan lab: Understanding complex deep generative models using interactive visual experimentation. IEEE transactions on visualization and computer graphics 2018, 25, 310–320. [Google Scholar] [CrossRef] [PubMed]
40. Vigoya, L.; Fernandez, D.; Carneiro, V.; Cacheda, F. Annotated dataset for anomaly detection in a data center with IoT sensors. Sensors 2020, 20, 3745. [Google Scholar] [CrossRef] [PubMed]