SDN: Is It A Solution For Network Security?

Ruslan L. Smelyanskiy
Сorresponding member,
Russian Academy of Sciences Professor,
Faculty of Computational Mathematics and Cybernetics, MSU, Russia

Software Defined Networking, or SDN, shows the programmable separation of control and forward elements of networking that enables software control of network forwarding that can be logially and/or physically separated from physical switches and routers. Software Defined Networking (SDN) is developed rapidly and used now by early adopters such as data centers. It offers immediate capital cost savings by replacing proprietary routers with commodity switches and controllers; using of computer science abstractions in network management offers operational cost savings, with performance and functionality improvements as well.

The following great question is considered in this paper: to what extent can SDN–based networks address network security management problems?

What is SDN?

Traditionally, networks are defined by their physical topology i.e. how servers, switches and routers are cabled together. That means that once you have built out your network, changes were costly and complex. Certainly, this type of networking is simply not compatible with the notion of a lights-out datacenter or a cloud environment that need flexibility to support varying workload demands.

Under Software Defined Networking approach software can dynamically configure the network, allowing it to adapt to changing needs. An SDN solution can accomplish several tasks:

1. Create virtual networks that run on the top of the physical network. In a multi-tenant cloud virtual network might represent a tenant’s network topology complete with the tenant’s own IP addresses, subnets, and even routing topology. Through SDN virtual networks can be created  dynamically, and can support VM mobility throughout the datacenter while preserving the logical network abstraction.

2. Control traffic flow within network. Some classes of traffic may need forwarding to a particular appliance (or VM) for security analysis or monitoring. You may need to create bandwidth guarantees or enforce bandwidth caps on particular workloads. Through SDN, you can create these policies and dynamically change them according to the needs of your workloads.

3. Create integrated policies that span the physical and virtual networks. Through SDN, you can ensure that your physical network and endpoints handle traffic similarly. For example, you may want to deploy common security profiles or you may want to share monitoring and metering infrastructure across both physical and virtual switches.

In summary, SDN is about being able to configure end hosts and physical network elements, dynamically adjust policies for how traffic flows through the network, and creating virtual network abstractions that support real-time VM instantiation and migration throughout the datacenter. SDN programmability includes not only configuration of physical network elements. It is much broader and includes programmability of end hosts, enabling end-to-end software control in the datacenter. All these features are important to facilitate automation and reliability in large-scale datacenters [1].

Figure1: Software defined network organization7

Security in traditional architecture networks

In network with traditional architecture there are many areas under threats: infrastructure, software, protocols etc. In those networks the compromising of one router can cause a serious damage to the network and its customers. We will conduct our further consideration with these case studies:

• Large  Transit  Service  Provider  kind  of  Tier-1  with  hundreds  Points  of Presence (PoP) in different countries.
• The  company  which  provides  some  services  to  the  branches  of  big International Company (Inc.) in different countries, e.g. VPN Services for Inc. offices in big cities.
• Network of Large Organization like International Airport where there are millions of passengers, airlines offices, state organization representatives (e.g. TSA, Immigration Service, etc.), and airport staff.

There should be Data Centers in this list. However, there are a lot of publications about DC architecture and SDN perspectives for DC. Along down the list of complexities  is the issue of physical controls over network infrastructure and how these controls itself decrease.

The number of geographically distributed locations with network equipment is growing in a large heterogeneous network. There are customers which are strongly engaged in competition with each other. So, there is a need not just to protect network from misbehavior of application and customers, but to protect customers from each other.

The term “protecting” is complex. It refers to the integrity and confidentiality of customer’s data, protecting from the fall down of network services (like DDoDs) etc.  Nowadays, under evolved networking technologies, enormous growth of Internet throughput and a shift from fixed client devices towards mobile networking (we have over 1 billion connected smartphones already in early 2013, and only about 200 million fixed devices) increases efficiency of existing access control solutions reduces. More expensive devices are required for every new version of Ethernet protocol providing the same level of network granularity as five or ten years ago. In terms of client devices mobility, network configurations are changing rapidly and the information on network topology changes could not be used directly for access control. So the problem of network access control based on the information on the expected behavior (flows) of network applications is becoming more and more important.

Infrastructure

One of the main threats in this area is a physical access to network devices. In a big airport. it`s impossible to guarantee physical inaccessibility to the network devices. Once trespasser gain the physical access to the device, he/she can modify, replace internals of that device. A trespasser can gain access to the network cabling as well. This is another example of the threat in this area. It is impossible prevent such an access. For example, if the Provider needs to exchange some network equipment in its network, nobody can guarantee that the equipment on its way from a factory to the Provider location would not be modified.

There is absolutely different situation in SDN network. All intelligence got away from the routers and switches and places into SDN network controllers (see figure 1) The server with controller easily could move into well protect environment. Programmable controllers can support the set of so called applications (c-application or control program on figure 1) which will supply as ordinary, traditional network services like routing, congestion avoidance, QoS management etc. as a new one such as virtualization, filtering (as ordinary firewalls), malware detection etc. In this context, virtualization services mean separation.

Software

Software in the SDN network is concentrated in controllers. So, one of the key questions is where SDN controllers should be placed [2]. As it is seen today there is a hierarchy of controllers with different sets of applications.
This hierarchy should have at least two levels. On the top level should be a controller for infrastructure management. Controllers on this level issue the approval for resources allocation under user request. They play a role of infrastructure resources managers. For example, at the airport, new airlines or new companies will issue the request for resources. In this request it describes what kind of recourses are needed, amounts for each kind of recourses and required QoS. The mapping of virtual recourses on physical ones is implemented by the controllers on the next low level. They issue the set of proper rules for the corresponding switches.

Each controller should implement the following functions:
• Controllers on the same level should have the same set of c-applications;
• C-applications should be reusable by different controllers placed near-by each other;
• Different controller instances should be able to share the same instance of an n-application;
• Controller should be trusted environment;
• Controller should be scalable; it means that if workload is growing beyond the current computational power of the controller then it should be able to get more computational power, for example, by splitting its activity with another controller instance, placed on another physical resource;
• If some controller instance is shut down, then some other controllers placed nearby should be able to catch up those part of network switches that were managed by controller instances which are shut down.

A secure n-application is another problem. Here we are faced with the same problem like people had with applications for iPhone, Android etc. A good solution for such a problem could be the description of c-application behavior [3]. It seems this approach will be more effective, not resource consuming like formal verification e.g. and Model checking [4].

Monitoring is another crucial function for SDN network security. There should be different kind of monitoring activities. с-application behavior monitoring is one of the activities. Another one is packet monitoring and inspection. It is important as for sampling of a data flows as for get sure that virtualizing has separated data flows properly, e.g. the data flows of competitors never crossing. Monitoring is an important function for reaction system. Once a trespasser is detected such system should react properly up to restore the controller operation. It doesn’t matter of what form a trespasser has, e.g. unauthorized software, misbehavior n-application etc.

Protocols
Talking about protocol security, we will split the consideration on the following parts:
• Switch-controller protocol security;
• c-Application Protocol security;
• Controller-controller protocol security.

Switch — controller security: In a typical SDN network segment between switch and controller SSL secure connection is used. SSL provides the basic security level and that in real-network SDN deployment may not be enough (for example, advanced cryptographic protocols: Internet Key Exchange, IPsec, Kerberos and etc.). These inscription technics could be enough for Data Centers but hardly would be appropriate for WAN networks or even for Autonomous Systems. Here all problems related to key management, appeare with increase cost and delays for encryption [5,6].

c-Application protocol security: One of the problems is whether the existing solutions enough and are there any different for SDN n-applications? One such point is how keys could be bootstrapped into a device in a secure way? Another example could be such as a native place for traffic analysis is an n-application over controller. But controller applications focus only on network packet header analysis. That’s why it is not recommended to put deep-packet inspection functions on controller, because it requires forwarding packet payload to controller. A payload must never be executed on a controller side.

Controller — controller protocol security: Most likely that in near future SDN controllers will run in a local distributed computer environment. In such cases SSL/TLS protocols could be used. The major component of distributed controller is protocol among several controllers in a local environment. Supposedly, such protocols can operate in two ways: out-band, and in-band. In case of out-band a separate control network among controllers is building and there is no necessity to network protection. In case of in-band it is important to provide secure channel to forward data among controllers. In the case of WAN or MAN for controllers communications will have two cases. Either the protocol runs in a data plane or it will require new sophisticated security technics. If there will be a separated control plane which is inaccessible through data plane, much easier security technics would be used. And every time we have to remember that simplicity is a power.

Considering SDN security in the case of WAN, we have to understand that a controller would be an extremely desirable target for trespassers. In this way we come to the fingerprinting problem. Another word: how to distinguish is the network segments controlled by SDN controller or have traditional network communication mixture of data plane and control plane? In that case the most probable approach is to use timeout deviations while the connection process to concrete segment.

There is one area was not considered so far here is network Application Protocol security. In this area we still have unanswered question: Does network application should have any communication with c-application?

From informational security principals the answer should be No. However the practice show that for the many reason it could be useful to let them communicate. One such example could be the quality of Service management.

Conclusion

>Software  Defined  Networking  (SDN)  has been developed rapidly and is now used by early adopters such as data centres. It offers immediate capital cost savings by replacing proprietary routers with commodity switches and controllers; computer  science abstractions in  network management  offer operational cost savings, with performance and functionality improvements too.

SDN network has a lot of advantages for network security, especially in physical security of network equipment. Splitting data plane and control plane bring a lot of new advantages. However, there is a lot researching has to be done — especially in the SDN software area. The example of one of such area could be security protocol in switch- controller and controller-to-controller communication.

The major opportunity of SDN approach is convenient and flexible configuration of packet forwarding policy. Using functionality of OpenFlow protocol, we could not only configure forwarding of concrete traffic types to go through special network points, but also verify that all the network packets come thought these specific points. This feature sounds like it can provide a lot of opportunities for network security, but still requires further research.

Footnotes

[1] http://blogs.technet.com/b/windowsserver/archive/2012/08/22/ software-efined-networking-enabled-in-windows-server-2012-and-system- center-2012-sp1-virtual-machine-manager.aspx

[2] Heller, R. Sherwood, and N. McKeown, “The controller placement problem,” in Proceedings of the first workshop on Hot topics in software defined networks, ser. HotSDN ’12. ACM, 2012, pp. 7–12.

[3] R.L.Smeliansky, D.Gamaynov “The model of network applications behavior.”, Moscow, Programmirovanie, 2007, № 4, pp.1-12 (Programming and Computer Software, ISSN 0361-7688, 2007, Vol. 33, No. 6, pp. 308–316. ©Pleiades Publishing, Inc., 2007.)

[4] Edmund M. Clarke, Jr., Orna Grumberg and Doron A. Peled, Model Checking, MIT Press, 1999, ISBN 0-262-03270-8.

[5] M.Lepinski (Ed.) “BGPSEC Protocol Specification,” Internet Engineering Task Force, Feb. 2013. [Online]. Available: http://www.ietf.org/id/draft-ietf-sidr-bgpsec-protocol-07.txt

[6] Domain Name System Security Extensions. RFC 2535

[7] Nick McKeown Moscow talk 2012.

 

 

This article is based on a presentation delivered at the 7th Scientific conference of the International Research Consortium on Information Security, as part of the International Forum on «Partnership of state authorities, civil society and business community in ensuring international information security», held on 22-25 April 2013 in Garmisch-Partenkirchen, Germany. It is published on Digital.Report with an explicit permission from the conference organizers.