The proposed framework consists of an open-source IoT traffic generator tool which can generate the normal and attack traffic of IoT devices over a real-time network. We named it as IoT-Flock. Fig. 1 shows layer-wise core functionalities of the IoT-Flock. The IoT-Flock has following distinct features as compared to other commercially or publicly available traffic generator tools:
- IoT-Flock has two working modes, i.e., GUI mode and console mode which allows a user to create real-time IoT use cases add thousands of IoT devices into the use case.
- IoT-Flock provides XML support to import or export the designed use case. Thus, a user can create, share and run a use case through an XML file.
- IoT-Flock can also generate MQTT and CoAP related at- tacks. To our best knowledge, this feature is not supported yet by any other open-source IoT traffic generator tool. Thus, a user can easily create both normal and attacking devices in the same use case and generate their traffic.
A. IoT-Flock Architecture
We followed layered architecture in order to develop the IoT-Flock. IoT-Flock comprises of three layers, i.e., presen- tation layer, business logic layer and network layer. The following subsections describe these layers.
1. Presentation Layer: The presentation layer is respon- sible for viewing the interface to the end-user. It works in two modes, i.e., console mode and graphical user interface (GUI) mode. In console mode, a user will import the use case XML file through the console and run the tool for generating the IoT traffic as defined in the XML file. In GUI mode, a user will first create an IoT use case then add different IoT devices into it. A user can add MQTT and CoAP devices into the use case. While creating a device, a user has to give the information about the device name, device IP address, device type, number of devices and protocol type in order to emulate the device traffic over the real-time network using IoT-Flock. If a user selects MQTT protocol, then the MQTT GUI form will be enabled and the user has to give the further device information of MQTT device. In order to emulate an MQTT device, a user has to mention MQTT broker IP & port, username & password of the MQTT broker if exists and MQTT device type, i.e., subscriber or publisher.
If the device is a subscriber, then the user must mention the topic name which the device needs to be subscribed. For this purpose, a user can either select a topic from the topic list which the user has already saved or he/she may add a new topic if the topic name does not exist the topic list.
If the device is a publisher, then the user must mention the topic name along with the time profile and data profile in order to emulate the device behaviour.
- For the time profile, a user must tell in which frequency a device publishes the data, i.e., whether a device sends data after some specific interval (i.e., periodically, randomly, etc.) or after the occurrence of some event.
- For the data profile, a user must tell what type of data the device will is published by IoT device? It may be a numeric or binary or String data. Moreover, the user must define the data values or range of values that the device can publish in real-time in order to emulate the publishing device.
Both the time profile and data profile can be saved in the database so that they may be used later if some other device has the same time or data profile.
Likewise, if a user selects CoAP protocol from the main window, then the CoAP related GUI will be enabled and the user has to give information about CoAP server IP & port, CoAP method, time profile and data profile. The CoAP method includes four options, i.e., GET, POST, PUT and UPDATE which are briefly described in Table I.
2. Business Logic Layer: The business logic layer is responsible for implementing the user requirements that have been gathered from the presentation layer. We used four open- source APIs and database management system (DBMS) to implement the user required functionalities which include MQTT API [17], CoAP API [18] and libtins API [19]. The MQTT API [17] is used to create MQTT publisher and MQTT subscriber devices. An MQTT subscriber device will first send the subscribe request to the MQTT broker against some topic to establish the connection with MQTT broker and then will receive messages when some IoT device will publish a message to the MQTT broker against the subscribed topic. Similarly, an MQTT publisher device will first establish a connection with MQTT broker then will publish the message to the MQTT broker using MQTT API [17]. Likewise, the CoAP API [18] is used to send the user request to the CoAP server. The libtins API [19] is used to generate an attacking device. Finally, SQL DBMS is used to store the use case related information.
3. Network Layer: The network interface layer is respon- sible for assigning a unique virtual IP to each IoT device from a single physical system. Moreover, it is also responsible for sending and receiving the data to/from the network.
B. IoT-Flock Working
The flow diagram shown in Fig. 2(a) illustrates the working of IoT-Flock. It consists of four steps: create use case, add IoT devices to use case, save XML and run the use case & generate IoT traffic. Upon starting the IoT-Flock in GUI mode, a user will first create the desired use case by simply clicking at ‘+ new use case’ button. After entering the use case name, the user will click on ‘OK’ to create the use case and the use case window will appear. Now the user has to add IoT devices into the use case. Fig. 2(b) shows the device creation steps. A user can create both IoT normal and attack device with respect to use case. After adding the devices, the next step is to generate an XML file of the use case. In case, if a user needs to re-run the use case after some time, then a user can simply load and run the saved XML file of the use case instead of re-creating it. Moreover, the generated XML file can be shared with anyone to ease him/her in understanding the use case. Lastly, the user will click on the ‘Start’ button to initiate the emulation of the use case.
C. Attack Types in IoT-Flock
Currently, we included four recent IoT application layer vulnerability attacks in the IoT-Flock. However, one can add more types of attacks in IoT-Flock by extending the source code. These attacks are reported recently in a well-known vulnerability reporting platform, i.e., national vulnerability database (NVD) [20]. Below is the description of these attacks. MQTT Packet Crafting Attack - In this attack, MQTT packets are specially crafted to crash an application. The attacker first establishes a connection with MQTT broker at Transport layer and then sends the MQTT publish command right at the beginning instead of sending a connection request to MQTT broker [21].
MQTT Publish Flood - IoT devices follow a periodic or event-driven model for sending data using application layer protocols. In the periodic model, the device is set to send data after every x interval, e.g., temperature sensor sends temperature data after every five seconds to the server and in event-driven model device send data when some event occurs e.g motion sensor is configured to only send data to the server when it detects motion in the environment. According to [22], MQTT publishing message at a high rate can cause a denial of service (DoS) attack.
CoAP Segmentation Fault Attack - While communicating with the CoAP server, a valid Uri-Path is an essential part of the request and response packet. Recently, an attack is reported in which the attacker when sets the Uri-Path as null, then CoAP server mishandles such packets hence causes the segmentation fault [23]. Moreover, an attacker can generate the DoS attack by sending such packets in a large amount.
CoAP Memory Leak Attack - CoAP server sends or receives data based upon the CoAP methods as called by the clients. It is reported that when an attacker sends invalid options to the CoAP server, it causes the memory crash as the processing of packet with single invalid option wastes 24 bytes of memory [24].