Overview of Software Defined Networks (SDN)
Discuss about the Security issues in Software Defined Networks.
Network technologies they have always been an important part for the success for the technologies such as the cloud computing (Ahmad, Namal, Ylianttila & Gurtov, 2015). Due to the slow developments in regards to scalable IT infrastructure, this might result in the problems with regards to competitiveness. SDN could hence counteract to these issues via providing new functions to the whole network topology. With the SDN, administrators have the functionality to abstract the under-lying network infrastructure for the programs as well as the network services (Ahmad, Namal , Ylianttila & Gurtov , 2015 ) . Within this research report it concentrate on the major outcomes of the systematic literature review on the security problems as well as the effects of the SDN. It highlights that most papers generally address on the implementation of the software described networks as an issue, including aspect for example vendor lock in and general risk to change on the traditional network architectures (Akhunzada, Ahmed, Gani, Khan, Imran & Guizani, 2015). Attention has been given on the security issues which arise from the SDN and the permanent substantial demand from the client coupled with the concern with transforming on the traditional networks (Dhawan, Poddar, Mahajan & Mann, 2015). The structure of the report would be defining on the overview of the SDN technology, relevant technologies and applications of those technologies, challenges/ problems in SDN as well as the research gaps in the literature. In the research gap it would address various aspects such as issues that have been addressed, issues not addressed, issues that are critical and the summary to the future research directed which is based on the identified gaps.
SDN is an rising computer network paradigm ( Jarraya , Madi & Debbabi , 2014 ) . The term has solely existed for a few years. SDN moves the focus to the software from the hardware via separating the control plane of present routers and configuration on the switches and moving this control plan to the centralized software (Ding, Crowcroft, Tarkoma & Flinck , 2014 ) . SDN nowadays enables the network administrators to manage together with operating the network via the abstraction of lower level functionality within the Open Systems Interconnection model.
SDN offer the dynamic technique when it comes to networking through decoupling the control plane and data forwarding plane of the coverage devices. The data plane is generally accountable for actual forwarding of the data packets through the network utilizing the paths that are chosen by the control plane (Ahmad, Namal, Ylianttila & Gurtov, 2015). The control plane is responsible to realize the intelligence of the network. When there have been implementations of the control plane to the hardware of the device which is the router the forwarding decisions are depending on the matching entries in routing table that is stored in the routers memory. On the section of the entries they may be depending on the routing table which is impacted by the information regarding the network topology ( Jarraya , Madi & Debbabi , 2014 ) . Routing might use static routes, where the network administrators explicitly program on the routers to use a particular approach to reach a particular destination within or perhaps outside the network which they execute.
Relevant technologies and application to those technologies
SDN offers new facts for the security applications in order to implement the security services. With the SDN decisions are usually made by centralized SDN controller which is responsible to decide on the best path and instruct the devices along the path on the actions they should undertake (Jarraya, Madi & Debbabi, 2014).
SDN applications are software programs which have been designed in order to perform on the task in the software defined networks environment (Dong, Lin, Tan, Iyer & Kalbarczyk, 2015). SDN applications could replace as well as expand upon the functions which are implemented via the firmware devices of conventional network (Dong, Lin, Tan, Iyer & Kalbarczyk, 2015). The architecture of SDN could take variety forms. An example of first tier in the SDN architecture is that of the physical infrastructure that comprise of the physical infrastructure that comprise of the hardware devices as well as cabling which is required to support on the network (Yan, Yu, Gong & Li, 2016). The network control is decoupled from hardware and it is then given to the software application (Dong, Lin, Tan, Iyer & Kalbarczyk, 2015). When it comes to the SDN controller, they usually initiate and terminate traffic.
The SDN challenges are grouped by the kind and with regards to SDN layer that is influenced by each of the attacks (Dong, Lin, Tan, Iyer & Kalbarczyk, 2015). The following are some of the challenges/ problems which are associated to SDN area of research.
Unauthorized Access: This type usually refers to the access of the control. One of the original features with regards to SDN is the fact that of the centralized control (Sezer, Scott-Hayward, Chouhan, Fraser, Lake, Finnegan & Rao, 2013). As a result of the evolution of the technology this is explained more correctly as the logically centralized control and which in several the kind of implementation is distributed. With regards to the functional architecture of the SDN, it is possible for multiple controllers to having access to the data plane of network. Furthermore, equivalent apps from multiple sources- for example those from the 3rd party, could link to the pool of the controllers (Scott-Hayward, Natarajan & Sezer, 2016). The controller usually offers an abstraction to the applications to ensure that the apps could read or write the state of the network which is an effective level to the control over the network. In case a hacker impersonate on the controller, they could have an access to the resources in the network as well as manipulate the operation of the network.
Challenges/problems in Software Defined Networks
Leakages of the data: There are numerous potential actions when describing the OpenFlow specification when it comes to the handling of the packet. These consist of forward, drop as well as send to the controller (Scott-Hayward, Natarajan & Sezer, 2016). It can be significantly practical for the attacker to ascertain on the activity that is used on the particular packet kinds via the method of processing of the packet that is transferred instantly from the input port to the output port that is shorter than the packet that is to be directed to controller for the processing. The hacker can hence discover on the proactive configuration of the switch (Shin, Porras , Yegneswaran , Fong , Gu & Tyson , 2013 ) . An additional challenge in the SDN architecture is the secure storage of the credentials for example the key and the certificates for the multiple logical networks when it comes to the programmable data plane (Hu, Hao & Bao, 2014). In the past, the cross virtual machine side channels attacks were demonstrated especially to the cloud environment. For the reason that kind of attack, a malicious VM could identify a vulnerable to the VM and extract secure data from the targeted resource (Hu, Hao & Bao , 2014 ) . Furthermore, there were comparable data leakages which were possible in SDN environment. For instance the OF-Config instantiates multiple OF-logical switches on the top of the OpenFlow capable switch.
Modification of the data: As highlighted earlier, the controller usually has the ability to program the network devices in order to control on the flow of the traffic in SDN. In case a hacker is able to hijack on the controller then he would have control of the whole system (Scott-Hayward, Natarajan & Sezer, 2016). From such privileged position, attacker might insert or even modify on the flow rules in network devices that might enable the packets to be steered via the network to the attacker advantages (Wang, Zheng, Lou & Hou, 2015). Additionally, if entities are introduced between information and control components for the provisioning to the virtual networks such as Flow Visor, open Virtex, FlowN, then the security mechanisms should be utilized between each interface, component as well as the communication channel (Hu, Hao & Bao, 2014). With regards to the communication channel, the OpenFlow specifications usually highlight on the usage of the TLS with the mutual authentication between the controller and their switches. Nevertheless, on the facet of the security feature is usually optional and version of the TLS is not specified (Hu, Hao & Bao, 2014). The deficiency of the TLS adaptation by the leading vendors could permit the man in the middle attacker to impersonate on the controller and release various attacks such as manipulate the control messages that has been sent by the controller or perhaps inject on the reset messages to be able to tear down the connection (Scott-Hayward , Natarajan & Sezer , 2016). Additionally, intermediate elements between the control and the data plane should be secure enough to prevent the introduction of additional security concerns (Mehdi , Khalid & Khayam, 2011). A man in the middle attack happens when the attacker has capacity to intercept on the messages between the two victims in order to monitor and alter or inject the messages into the communication channel. This might be possible particularly where there is absolutely no authentication of communication endpoints (Scott-Hayward, Natarajan & Sezer, 2016). The problems in relation to data modification are precise issues when it comes to the split-plane architecture of the SDN.
Denial of service: One of the core security weaknesses of the SDN architecture, combination of central controller and the separation of control and data planes (Mehdi, Khalid & Khayam, 2011). Due to the connection path between the controller and network devices , invader could overwhelm the controller with the packets which needs the flow rule decision and also render it out of reach for the legitimate customers ( Mehdi, Khalid & Khayam, 2011). Similar DoS attack could be taken on at infrastructure level with the flooding of flow table in which the limited memory resources are significantly accessible. Further to the potential for the DoS attacks which result in the fraudulent rule insertion and rule modification.
Configuration problems: The network policies as well as the standards have been in continual development as the networks vulnerabilities are identified. Most of these might apply to the layer as well as the interfaces of the SDN frame-work (Ding, Crowcroft, Tarkoma & Flinck, 2014). However, there has been little protection from these policies if they are not implemented or they are disabled without one grasping security implications in relation to the deployment scenario. When it comes to the SDN based network it might be crucial for the network operators to enforce on the implementation of the policies for example the TLS.
Areas/issues that you believe have been addressed in the current literature
While this research seeks to cast on a wide net over the current research opportunities for the researchers to advance further software defined network with the use of the current and emerging technologies, there are various issues which have been addressed in the current literature (Shin, & Gu, 2013). SDN is a broad subject; in this literature it has addressed security in the SDN that has been surveyed in this area of research. The challenges to secure the SDN from the persistent attackers have been highlighted and the holistic approach to the architecture of the security which is required for the SDN has been highlighted. In this research there has detailed explanation of the challenges which affects the Software Defined Networks especially on how the attacker exploits on the networks and how the architecture of the network could be compromised (Shin & Gu, 2013). The literature has also discussed on the overview of the SDN particular the components which make it and how they operate, this has been clearly defined through the diagram to explain the components of the system.
Highlighting areas/issues that have not been addressed or adequately addressed
In this area of research, SDN has not been neglected, it is a highly researched area within both academia as well as industry, and it has been adapted by various major IT organizations (Yeganeh, Tootoonchian & Ganjali, 2013). However there are areas which have not been addressed; one of the areas is that the research has not presented discussion on the SDN controllers and various threats vector that could enable for the exploitation of vulnerabilities of the SDN controllers (Nunes, Mendonca, Nguyen, Obraczka & Turletti, 2014).. Moreover, the research has not focused on designing a dependable controller platform which includes requirements for the secure, resilient as well as robust controller. Moreover, the research has not adequately addressed on how to secure the SDN controllers with any recommendations for the security improvements for the future SDN controllers (Nunes, Mendonca, Nguyen, Obraczka & Turletti, 2014). The literature has not addressed adequately on the multiple analysis in regards to the SDN of which some focus on the OpenFlow protocol. None of them has attempted to analyse on the security concerns in relation to the SDN architecture and offer a systematic techniques to instruct on the design of the SDN solutions which the required security strengths in order to tolerate on such threats. Moreover, there are no defined series of the security principles which offer a reference point onto the security work which has been developed independently.
Discussing your view(s) on the issue(s) that you see as being critical
The issues that are critical in this research have been on the security challenges in relation to the SDN (Kreutz, Ramos & Verissimo, 2013). This is the major concerns when it comes to the SDN and it needs to be addressed appropriately since the attackers are finding new ways to exploit on the systems (Dong, Lin, H., Tan, Iyer & Kalbarczyk, 2015). SDN has been research field within the academia and it has been adapted particular in the major IT organizations. For instances, according to the numerous reports as well as research articles, OpenDayLight controller alone has been seen over one hundred deployments with organization such as China Mobile, Telefonia and the Globe Telecom among others (Dotcenko, Vladyko & Letenko, 2014). Another critical area of research is on the evidence for the two sides of SDN security coin which is presented in the research. Therefore, it is possible to improve on the network security utilizing characteristics of the SDN architecture and SDN architecture which introduces on the security issues. It is also important to enhance on the network security through the SDN which is a critical subject to address.
The future direction in regards to the topic of SDN security issues could be focused on how new techniques to address on the security issues which are introduced to the SDN such as limit on the potential damage from malicious or compromised programs (Stojmenovic & Wen, 2014). The work on these issues could be developed through increasing on the security focus particularly in the industry sponsored standardization and the research groups. Additionally, having surveyed on this topic a number of topics for the future research can be identified (Wang, Xu & Gu, 2015). These kinds of powerful theme among the themes are on the projection of the possible security issues as well as automated response for the quick reaction to the threats in the networks.
By means of the implementing the proven security methods from the present from the current network deployments, solving on the security problems particularly in the SDN and further exploiting to the dynamic, programmable and open features of the SDN could help address on the issues which are related to the SDN security concern.
Conclusion
In this research report it has addressed on the topic on Security issues in Software Defined Networks (SDN). There has been overview of the SDN technology. There have been relevant technologies as well as applications in relation to the SDN. The research has also identified on the gaps in the literature.
References
Ahmad, I., Namal, S., Ylianttila, M., & Gurtov, A. (2015). Security in software defined networks: A survey. IEEE Communications Surveys & Tutorials, 17(4), 2317-2346.
Akhunzada, A., Ahmed, E., Gani, A., Khan, M. K., Imran, M., & Guizani, S. (2015). Securing software defined networks: taxonomy, requirements, and open issues. IEEE Communications Magazine, 53(4), 36-44.
Dhawan, M., Poddar, R., Mahajan, K., & Mann, V. (2015, February). SPHINX: Detecting Security Attacks in Software-Defined Networks. In NDSS.
Ding, A. Y., Crowcroft, J., Tarkoma, S., & Flinck, H. (2014). Software defined networking for security enhancement in wireless mobile networks. Computer Networks, 66, 94-101.
Dong, X., Lin, H., Tan, R., Iyer, R. K., & Kalbarczyk, Z. (2015, April). Software-defined networking for smart grid resilience: Opportunities and challenges. In Proceedings of the 1st ACM Workshop on Cyber-Physical System Security (pp. 61-68). ACM.
Dotcenko, S., Vladyko, A., & Letenko, I. (2014, February). A fuzzy logic-based information security management for software-defined networks. In Advanced Communication Technology (ICACT), 2014 16th International Conference on (pp. 167-171). IEEE.
Hu, F., Hao, Q., & Bao, K. (2014). A survey on software-defined network and openflow: From concept to implementation. IEEE Communications Surveys & Tutorials, 16(4), 2181- 2206.
Jarraya, Y., Madi, T., & Debbabi, M. (2014). A survey and a layered taxonomy of software- defined networking. IEEE Communications Surveys & Tutorials, 16(4), 1955-1980.
Kreutz, D., Ramos, F., & Verissimo, P. (2013, August). Towards secure and dependable software-defined networks. In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking (pp. 55-60). ACM.
Mehdi, S. A., Khalid, J., & Khayam, S. A. (2011, September). Revisiting traffic anomaly detection using software defined networking. In International workshop on recent advances in intrusion detection (pp. 161-180). Springer, Berlin, Heidelberg.
Nunes, B. A. A., Mendonca, M., Nguyen, X. N., Obraczka, K., & Turletti, T. (2014). A survey of software-defined networking: Past, present, and future of programmable networks. IEEE Communications Surveys & Tutorials, 16(3), 1617-1634.
Scott-Hayward, S., Natarajan, S., & Sezer, S. (2016). A survey of security in software defined networks. IEEE Communications Surveys & Tutorials, 18(1), 623-654.
Sezer, S., Scott-Hayward, S., Chouhan, P. K., Fraser, B., Lake, D., Finnegan, J., … & Rao, N. (2013). Are we ready for SDN? Implementation challenges for software-defined networks. IEEE Communications Magazine, 51(7), 36-43.
Shin, S., & Gu, G. (2013, August). Attacking software-defined networks: A first feasibility study. In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking (pp. 165-166). ACM.
Shin, S., Porras, P. A., Yegneswaran, V., Fong, M. W., Gu, G., & Tyson, M. (2013, February).FRESCO: Modular Composable Security Services for Software-Defined Networks. In NDSS.
Stojmenovic, I., & Wen, S. (2014, September). The fog computing paradigm: Scenarios and security issues. In Computer Science and Information Systems (FedCSIS), 2014 Federated Conference on (pp. 1-8). IEEE.
Wang, B., Zheng, Y., Lou, W., & Hou, Y. T. (2015). DDoS attack protection in the era of cloud computing and software-defined networking. Computer Networks, 81, 308-319.
Wang, H., Xu, L., & Gu, G. (2015, June). Floodguard: A dos attack prevention extension in software-defined networks. In Dependable Systems and Networks (DSN), 2015 45th Annual IEEE/IFIP International Conference on (pp. 239-250). IEEE.
Yan, Q., Yu, F. R., Gong, Q., & Li, J. (2016). Software-defined networking (SDN) and distributed denial of service (DDoS) attacks in cloud computing environments: A survey, some research issues, and challenges. IEEE Communications Surveys & Tutorials, 18(1), 602-622.
Yeganeh, S. H., Tootoonchian, A., & Ganjali, Y. (2013). On scalability of software-defined networking. IEEE Communications Magazine, 51(2), 136-141.