## 2 Background
### SDN Security Issues
#### 2.3.2 Control Plane Security  
The controller has a pivotal role in the SDN paradigm, since decisions are made on the control plane in a centralized way (e.g., an OpenFlow controller). This makes it highly targeted for malicious activities. In particular, the controller security can be seen from the point of view of its capability to properly authenticate and isolate applications [36]. Moreover, it is important to separate different applications before providing access to the network information and resources according to their security implications. Indeed, SDN applications have different functional requirements from the underlying controller and data path. For instance, a load balancer application might need network statistics, while an intrusion detection application might need to inspect packet header fields. Consequently, all applications (including both vendor and third-party applications) must have different privileges to access network information and resources. For instance, in [40], the authors presented the concept of participatory networking, which enables users and their applications to take part in SDN network configuration. These kinds of user applications must be analyzed properly before access to the network is provided, having comparatively fewer privileges than vendor applications. Therefore, a customized security  
\begin{table}
\begin{tabular}{l c c} \hline \hline \multicolumn{1}{c}{**SDN Layer**} & \multicolumn{2}{c}{**Security Issues**} \\ \hline \multirow{3}{*}{Application Plane} & - & Lack of authentication \\  & - & Fraudulent flow rule insertion \\  & - & Lack of access control \\ \hline \multirow{3}{*}{Control Plane} & - & DoS attack \\  & - & Unauthorized controller access \\  & - & Scalability and availability \\ \hline \multirow{3}{*}{Data Plane} & - & Fraudulent flow rules \\  & - & Flooding attacks \\ \cline{1-1}  & - & Controller compromising \\ \cline{1-1}  & - & TCP-level attacks \\ \cline{1-1}  & - & Man-in-the-middle attack \\ \hline \hline \end{tabular}
\end{table}
Table 1: Major SDN security issues for each SDN layer.  
enforcement mechanism for various types of applications is required in the northbound API of the controller.  
Another important open challenge for available SDN controller implementations is to avoid the controller being the single point of failure. To avoid this, the simplest way is to use a distributed SDN controller approach. Nonetheless, it has been shown that using a distributed SDN controller approach cannot effectively protect the network from a single point of failure [41]. The problem is that the load of a failed controller is processed by another controller until its capacity is not exceeded. This may cause cascading failures of controllers.  
Since DoS and distributed DoS attacks are capable of completely breaking an SDN network, from the end user's perspective, they are considered one of the most threatening security issues for the SDN controller. The authors in [42] demonstrated that a DoS attack can leverage the logical separation of the control plane and the data plane. Moreover, another work [43] demonstrated that a DoS attack may cause a breakdown of the SDN controller if an attacker continuously sends IP packets with random headers to the controller. To improve the control plane security, the authors suggested using a multiple controller approach, but nevertheless, each controller may suffer from DoS and DDoS attacks, and thus attack detection mechanisms are required to completely avoid a breakdown of the network. Finally, as described above [41], the distributed SDN controller approach is prone to cascading failure of multiple controllers and is not a complete solution for facing DoS and DDoS attacks.