## 3 SDN Performance Challenges
### SDN Security Threat and Vulnerabilities  
The noble idea of placing the network control logic at the central controller provides flexibility, optimizes network management, and flow monitoring, which is very important in the practical usage of SDN. Considering the SDN flexibility, it is expected that the potentialities of SDN could mitigate some security threats and vulnerabilities that were inherited in the traditional network. Unfortunately, SDN introduces another security threat and vulnerabilities due to its novel architecture [41]. At least five threat vectors were identified with SDN [41; 42]. This includes attacks on vulnerabilities on SDN protocol [43], the central controller, underlying switches, forged legitimate traffic flows, and trust mechanism. Trust mechanism is very important in deploying application, overlooking it may easily cause malicious applications to be developed and deployed on the controller. It may further affect the detection of an event such as link failure in order to ensure fast recovery. In general, the most important threat vector is denial of service attack against the switch flowtable and central controller. For example, the central controller must have full control of the network state at a regular time interval to verify the network functionality and state [44]. In this case, the controller is required to receive an update from the switch more frequently. An attacker can leverage on the central entity to perform the DoS attack by forcing the switches to continuously update the controller with a fake update, which in turn consumed a lot of resources that the switch may use to process legitimate flows [44]. Similarly, because of the limited memory resources (TCAM), an attacker aggressively creates a large number of new traffic flows that might overwhelm the precious flowtable of the switches. In such a situation, the switches will be forced to continually add and delete flow entries, which may generate excessive packet-in message events to the controller. Consequently, the packet-in event will be stuck in the controller queue as there would be no more routing decision taking place for every new incoming flow. In this case, flow with no corresponding entries will be stuck in the switches [45]. Concerning the protocol vulnerability, the widely used OpenFlow suffers from unexpected shortcomings during its design and evolution [43]. Discarding the transport layer security during the message exchange between controller and switches at the feature's verification stage was the greatest flaw. Man-in-the-middle attacks may leverage on such an operation to compromise the network. Similarly, exchanges of messages between switches lack the authentication/encryption mechanism in the SDN data plane [44]. Toward addressing the aforementioned security challenges, efforts were made lately to address several SDN security attacks [46; 47; 48]. The works of [42; 43; 44; 45] proposed machine learning-based models to detect DoS attacks. Features were taken from SDN for data set under normal network state and DoS attack traffic. Afterwards, a new dataset was created using features selection methods on the existing dataset. This way, the model is trained both with and without the feature selection method under different classification models. The results have shown that machine learning and feature selection algorithms can detect DoS attack with high accuracy and less processing load on the controller. However, these solutions require keeping history as their performance can be acceptable when the flowtable space is quite enough. But in SDN where the flow table is a constraint with limited space, the methods may not give the desired performance. Other works, including [PERSON] et al. [49] and [PERSON] et al. [50], analyzed the effect of DoS attacks on the network performance and reported how these attacks could affect many QoS parameters such as the switch to controller bandwidth consumption, latency, and switch flow table, controller efficiency.