ZHEJIANG SCI-TECH UNIVERSITY

SCHOOL OF INFORMATICS

INFORMATION COMMUNICATION ENGINEERING

MODERN COMPUTER NETWORK

HOMEWORK-4

PROFFESSOR HUANGLICAN

REVIEW ARTICLE ON SOFTWARE DEFINED NETWORKING

NGENDAHIMANA MOISE

L20192C060203

mailto:ngendahimana_moise@hotmail.com

ABSTRACT:We found that traditional network architecture is static. Users don’t have much controlling power and it is just trying to accommodate current networking needs of the user. Therefore which means window for innovation is too narrow with respect to network controlling, virtualization, automation, scalability, programmability and fault tolerance.as time goes on different research were carried on and Software-Defined Networking(SDN) has proved potential to replace traditional networking, as it brings promising opportunities for network management in terms of simplicity, programmability, and elasticity.While many efforts are currently being made to standardize this emerging paradigm, careful attention needs to be also paid to security at this early design stage.In this article we will review a brief introduction,background,importance and security threats with their countermeasures of Software Defined Networking.

KEYWORDS: Software Defined Networking, Data plane, Control plane, Network Function Virtualization

I. Introduction

How does a software-defined network work?

Software-defined networking (SDN) is designed to make a network flexible and agile. SDN lets you design, build, and manage networks, separating the control and forwarding planes. As a result, the control plane is directly programmable, and it abstracts the underlying infrastructure for applications and network services.Network intelligence is logically centralized through programmable SDN controllers. Implemented in software, these controllers maintain a coherent view of the network domain. To applications and policy engines, SDN looks like a single logical switch.

What does SDN consist of?

Software-defined networking (SDN) offers a centralized, programmable network that consists of an SDN controller, southbound APIs, and northbound APIs.

• SDN controllers are the brains of the network, offering a centralized view of the overall network.


• Southbound APIs relay information to the switches and routers in network.


• Northbound APIs communicate with the applications and deploy services.

What are the benefits of SDN?

• Fast and automated application deployment.


• On-demand app delivery and mobility at scale.


• Greater resource flexibility and utilization.


• Reduction of IT costs by enhancing the benefits of data center virtualization.

II. Background

In the traditional networks as shown in fig.1 both control plane and data plane are coupled inside the proprietary hardware. In a dedicated appliance network functionality is mainly implemented, ‘dedicated appliance’ refers to one or multiple switches, routers and/or application delivery controllers. Within this appliance Most of the functionality is implemented in dedicated hardware only and for this purpose, Application Specific Integrated Circuit (or: ASIC) is often used [2].

 

Figure 1 a) Traditional networks b) SDN approach is implemented

 

III. SDN Architecture

 

Figure 2 SDN Infrastructure

A software-defined network (SDN) architecture (or SDN architecture) defines how a networking and computing system can be built using a combination of open, software-based technologies and commodity networking hardware that separate the SDN control plane and the SDN data plane of the networking stack; SDN architecture separates the network into three distinguishable layers, connected through northbound and southbound APIs.A typical representation of SDN architecture comprises three layers: the application layer, the control layer and the infrastructure layer.

1. The application layer

The application layer contains the typical network applications or functions organizations use, which can include intrusion detection systems, load balancing or firewalls. Where a traditional network would use a specialized appliance, such as a firewall or load balancer, a software-defined network replaces the appliance with an application that uses the controller to manage data plane behavior.

2. The control layer

The control layer represents the centralized SDN controller software that acts as the brain of the software-defined network. This controller resides on a server and manages policies and the flow of traffic throughout the network.

3. The infrastructure layer

The infrastructure layer is made up of the physical switches in the network.

IV. Controllers in SDN

The SDN controller is a logical entity that receives instructions or requirements from the SDN application layer and relays them to the networking components. The controller also extracts information about the network from the hardware devices and communicates back to the SDN applications with an abstract view of the network, including statistics and events about what is happening.An SDN Controller platform typically contains a collection of “pluggable” modules that can perform different network tasks. Some of the basic tasks including inventorying what devices are within the network and the capabilities of each, gathering network statistics, etc. Extensions can be inserted that enhance the functionality and support more advanced capabilities, such as running algorithms to perform analytics and orchestrating new rules throughout the network.Two of the most well-known protocols used by SDN Controllers to communicate with the switches/routers is OpenFlow and OVSDB. Other protocols that could be used by an SDN Controller is YANG or NetConf. Other SDN Controller protocols are being developed, while more established networking protocols are finding ways to run in an SDN environment. For example, the Internet Engineering Task Force (IETF) working group – the Interface to the Routing System (i2rs) – developed an SDN standard that enables an SDN Controller to leverage proven, traditional protocols, such as OSPF, MPLS, BGP, and IS-IS.The type of protocols supported can influence the overall architecture of the network – for example, while OpenFlow attempts to completely centralize packet-forwarding decisions, i2rs splits the decision making by leveraging traditional routing protocols to execute distributed routing and allowing applications to modify routing decisions.

V. Security Threats in SDN

Most severe threats to SDN architecture can be performed in controllers because this is the most vital component in SDN architecture mainly because it defines the data flows that occur in the Data Plane (traffic flow manager). It is the “brain” of the network,It allows SDN users to gain a central look at the entire network, and empowers network administrators to instruct switches and routers how the forwarding plane should direct network traffic.Security analysis divide the threats and corresponding countermeasures into three categories based on SDN layers where each has its corresponding attack target, i.e., the forwarding layer, the control layer and the application layer.

 

Figure 3 Possible Attack points in SDN Architecture

Targeted level	Threats type	Caused by	Typical countermeasures
Data forwarding layer	Man-in-middle attack between switch and controller	• The communication channel is not secure without TLS support	• FlowChecker [8] • ForNOX [9] • VeriFlow [10] • Controller replication [11]
	DoS attack to saturate Flow Table and Flow Buffer	• Limited storage capacity of Flow Table and Flow Buffer • Enormous number of packets in a short time	• FlowVisor [12] • Virtual source Address Validation Edge (VAVE) [13] • Resonance [14]
Control layer	DoS/DDoS attack on the controller	• Attacking traffic can be mixed with normal traffic and is hard to distinguish • Limited computing and storage resources of the controller	• FloodGuard [15] • DDoS Blocking Application [16] • Content-Oriented Networking Architecture (CONA) [17]
	Threats based on distributed multi-controllers	• Distribution of access control • Incorporation difficult for multi-tenant controllers • Inconsistent configuration of multiple controllers	• DISCO [18] • McNettle [19] • HyperFlow [20]
	Threats from applications	• Open programmatic interface • Malicious Applications	• SE-Floodlight [21] • FRESCO [22]
Application layer	Illegal access	• Bypassing of the authentication mechanism • Software vulnerabilities of the controller	• PermOF [23] • NICE [24] • Verificare [25] • VeriCon [26]
	Security rules and configuration conflicts	• Variety for application software • Difference of access control and accountability for various application software	• Flover [27] • Anteater [28] • NetPlumber [29]

Table 1 Security threats and typical countermeasures in SDN architecture

CONCLUSION

In this article, we highlighted some of the characteristics and architecture of Software Defined Networking. We explained how SDN function and analyzed the basic threats to the SDN and discusses various solutions which have been suggested from three aspects or layers: the data forwarding layer, the control layer and the application layer.

References

[1] Sumit badotra,Japinder Singh,Department of computer Science and Engineering,Shaheed Bhagat Singh State Technical Campus,Ferozepur Punjab, India,"A Review Paper on Software Defined Networking",Volume 8, No. 2, March – April 2017.

[2] Wickboldt , Juliano Araujo, Wanderson Paim de Jesus, Pedro Heleno Isolani, Cristiano Bonato Both, Juergen Rochol, and Lisandro Zambenedetti Granville “Software-Defined Networking: Management Requirements and Challenges “, IEEE Communications Magazine,January 2015

[3] SDN OVERVIEW https://www.cisco.com/c/en/us/solutions/software-defined-networking/overview.html#~services

[4] SDN https://www.sdxcentral.com/networking/sdn

[5] SDN https://searchnetworking.techtarget.com/definition/software-defined-networking-SDN

[6] Saleh Asadollahi, Dr. Bhargavi Goswami, Dr. Atul M Gonsai,"Software Defined Network,Controller Comparison",Department of Computer Science, Saurashtra University, Rajkot, India,2017.

[7] Zhaogang Shu & Jiafu Wan & Di Li & Jiaxiang Lin & Athanasios V. Vasilakos & Muhammad Imran,"Security in Software-Defined Networking:Threats and Countermeasures",South China University of Technology,2016.

[8] Al-Shaer E, Al-Haj S (2010) FlowChecker: configuration analysis and verification of federated OpenFlow infrastructures. In:Proceedings of the 3rd ACM Workshop on Assurable and Usable Security Configuration, pp 37–44

[9] Porras P, Shin S, Yegneswaran V, Fong M, Tyson M, Gu G (2012) A security enforcement kernel for OpenFlow networks. In:Proceedings of the First Workshop on Hot Topics in Software Defined Networks, pp 121–126

[10] Khurshid A, Zhou W, Caesar M, Godfrey P (2012) Veriflow: verifying network-wide invariants in real time. ACM SIGCOMM Comput Commun Rev 42(4):467–472

[11] Fonseca P, Bennesby R, Mota E, Passito A (2012) A replication

component for resilient OpenFlow-based networking. In: IEEE Network Operations and Management Symposium (NOMS), pp933–939

[12] Sherwood R, Gibb G, Yap K K, Appenzeller G, Casado M,McKeown N, Parulkar G (2009) Flowvisor: a network virtualization layer. OpenFlow Switch Consortium, Tech. Rep

[13] Yao G, Bi J, Xiao P (2011) Source address validation solution with OpenFlow/NOX architecture. In: 19th IEEE International Conference on Network Protocols (ICNP), pp 7–12

[14] Braga R, Mota E, Passito A (2010) Lightweight DDoS flooding attack detection using NOX/OpenFlow. In: IEEE 35th Conference on Local Computer Networks (LCN), pp 408–415

[15] Wang H, Xu L, Gu G (2015) FloodGuard: a dos attack prevention extension in software-defined networks. In: 45th Annual IEEE/IFIP International Conference on Dependable Systems and Networks(DSN), pp 239–250

[16] Lim S, Ha J I, Kim H, Kim Y, Yang S (2014) A SDN-oriented DDoS blocking scheme for botnet-based attacks. In: IEEE Sixth International Conference on Ubiquitous and Future Networks (ICUFN), pp 63–68

[17] IETF Locator/ID Separation Protocol (LISP) [Online]. Available:http://datatracker.ietf.org/wg/lisp/

[18] Phemius K, Bouet M, Leguay J (2014) Disco: distributed multidomain sdn controllers. In: IEEE Network Operations and Management Symposium (NOMS), pp 1–4

[19] Voellmy A, Wang J (2012) Scalable software defined network controllers. In: Proceedings of the ACM SIGCOMM 2012 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, pp 289–290

[20] Tootoonchian A, Ganjali Y (2010) HyperFlow: a distributed control plane for OpenFlow. In: Proceedings of the 2010 Internet Network Management Conference on Research on Enterprise Networking.USENIX Association, pp 3–3

[21] Security-enhanced floodlight. [Online]. Available: http://www.sdncentral.com/education/toward-secure-sdn-controllayer/2013/10/

[22] Shin S, Porras P, Yegneswaran V, Fong M, Gu G, Tyson M (2013) FRESCO: Modular Composable Security Services for Software Defined Networks. In : Proceedings of Network and Distributed Security Symposium, pp 1-16

[23] Wen X, Chen Y, Hu C, Shi C, Wang Y (2013) Towards a secure controller platform for openflow applications. In: Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, pp 171–172

[24] Canini M, Venzano D, Peresini P, Kostic D, Rexford J (2012) A NICE way to test OpenFlow applications. In: Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation

[25] Skowyra R, Lapets A, Bestavros A, Kfoury A (2013) Verifiably safe software-defined networks for CPS. In: Proceedings of the 2nd ACM International Conference on High Confidence Networked Systems, pp. 101–110

[26] Ball T, Bjmer N, Gember A, Itzhaky S, Karbyshev A, Sagiv M,Valadarsky A (2014) Vericon: towards verifying controller programs in software-defined networks. ACM SIGPLAN Not 49(6):282–293

[27] Son S, Shin S, Yegneswaran V, Porras P, Gu G (2013) Model checking invariant security properties in OpenFlow. In: 2013 I.E.International Conference on Communications (ICC), pp 1974–1979

[28] Mai H, Khurshid A, Agarwal R, Caesar M, Godfrey P, King S(2011) Debugging the data plane with anteater. ACM SIGCOMM Comput Commun Rev 41(4):290–301

[29] Kazemian P, Chan M, Zeng H, Varghese G, McKeown N, Whyte S (2013) Real time network policy checking using header space analysis. In: USENIX Symposium on Networked Systems Design and Implementation, pp 99–111