## 4 Characterising SDN-Based IoT Architecture
### The Architecture of SDN Based IoT Networks
\begin{table}
\begin{tabular}{c c c} \hline \hline
**IoT Application** & **Periodical Message** & **Event Trigger** \\ \hline Smart Home & ✗ & ✓ \\ \hline Wearables & ✗ & ✓ \\ \hline Connected Car & ✗ & ✓ \\ \hline Industrial IoT & ✗ & ✓ \\ \hline Smart City & ✓ & ✓ \\ \hline Agriculture & ✓ & ✓ \\ \hline Smart Retail & ✗ & ✓ \\ \hline Smart Grid & ✓ & ✓ \\ \hline Healthcare & ✓ & ✓ \\ \hline Farming & ✓ & ✓ \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Traffic nature of IoT applications. Flow entries in the SDN switches are generally provisioned in two modes, reactive and proactive, as explained below. * Reactive: Initially, there is no flow entry provisioned in the switch, except a default entry whose operation is to inquire the controller. Therefore, flow entries are generated according to the algorithm in the controller. It is fully flexible, yet the control plane is vulnerable in this scenario. As a mismatched customer packet can trigger a request to the controller, DDoS attacks could impact both the control and data plane. * Proactive: Flow entries are preconfigured in the switch, the role of controller varies according to the default operation given by the administrator. * _Drop when mismatch:_ No new flow entry is generated by the controller. Customer packets either follow the existing flow entries or be dropped. This kind of configuration sacrifices flexibility to higher security. As a host, the device is no longer capable of initialising a request to the controller. DDoS attacks from hosts can only take effect in the data plane. * _Ask controller when mismatch:_ This is similar to reactive flow entries. However, DDoS attacks triggering on the controller could be more sensitive due to the preconfigured flow entries. Because most of the popular routes must have been covered by the proactive flow entries, there should not be many requests to the controller within a short period. In order to explain the SDN-based IoT network under attack, Figure 1 depicts a basic scenario used for IoT applications under the SDN architecture:  
* Each end-user device behaves as an IoT-gateway or IoT-DAG that aggregates data from IoT-sensors (wired or wireless) and sends the IoT traffic to related IoT-DS or IoT-DPC. * The IoT attacker could be a compromised gateway or IoT sensor, which creates malicious traffic in the network. The traffic could be divided into two categories depending on the destination IP address: (i) varied IP address (targeted to the controller) and (ii) fixed IP address (targeted to the server). * The IoT-DS is an IoT server processing both TCP and UDP traffic sent by IoT-gateways. The IoT-Servers can be any computing platform providing services for IoT data collection or management. In the SDN network with multiple SDN switches (OpenFlow-based), a single attacker could not only impact the SDN-switch that is directly connected, but also other SDN switches under the same controller as well. This is because OpenFlow switches (OF-switch) forward these malicious packets to the controller by default. As the destination is unknown to the controller, it instructs the OF-switch to flood out all the ports except the incoming port (In-port in OpenFlow). When the next OF-switch receives this packet via switch-to-switch link, it repeats the same procedure as the first OF-switch. This operation spreads the vicious packets across the network. Figure 1: The basic topology of SDN-based IoT architecture under a DDoS attack.