Day 4: Addressing Security of Distributed Controller

As we have established in the previous post, we shall now be focusing on security threats that the controllers in an SDN architecture face. The most common type of attack the SDN controller is subject to, is malicious packets sent through the network. Among these, the most common attacks are DoS and DDoS attacks.

DoS and DDoS attacks generate unnecessary traffic on the network by creating illegitimate clients that access the server resources. Thus the consequence of these attacks involve reduced availability, scalability and hence low performance. Many research papers have tried to address these security issues in an SDN architecture keeping in mind only one controller. This is as good as saying "I want to secure my server, the only difference is that it contains information about the network". The only difference between DoS attack on a server and a controller is the type of data it stores. The technology used to address these issues could be same. 

The complexity of the problem comes into light only when we try to think of a larger SDN network. By larger SDN network, I mean to say that there is more than one controller, various data plane switches that may interact with one or more controller and a highly scalable network w.r.t additional switches and controllers. We need to start addressing the security concerns of these networks since they guarantee a more effective and scalable architecture. Securing these networks poses a challenge since we have to take care of various issues as sited below:
  • more than one controller and securing all of them together instead of each of them individually
  •  address single point failures and make sure that the network doesn't behave differently even when one controller stops working (this would involve distribution of tasks to other controllers)
  • manage controller to controller communication for handling attacks, mitigating them and ensuring overall efficient performance.
How to Secure Distributed Controllers then?

Now that we have had a look at the various issues we need to address in a distributed controller environment, let us look at few ways in which it has been achieved. I found this article extremely good for understanding the technologies used to address our problem statement.

Let us look briefly into what the article is all about. The various components they use in their distributed controller architecture is as follows:
  • A backup controller for every primary controller - this controller is the one that will take-over if the primary controller gets attacked. Thus back up controller keeps track of one or more controller through a mapping algorithm to keep track
  • Heart-beat messages - These are sent from the primary controller to their designated back up controller to state that they are functioning properly
  • Synchronization messages - These messages ensure that the flows and information about the network that is present in the primary controller is also shared with the back up controller.
  • Take-over mechanism - This is the place where the detection algorithm running on the network detects a potential malicious attack and activates the back up controller to take over once it is established that the primary controller is down.
  • Protective mode - This is the mode in which the back up controller now operates because the threat of the malicious attack still persists in the distributed network.
This is how the distributed SDN controller network looks.


A Distributed Controller Network

The above is the simplest example of the architecture of a distributed controller network. There are various other configurations that this could be done. Few configurations are costlier than few others. Following are just few examples of distributed SDN controller architecture that researchers have looked into thus far:

  • cluster based distributed openflow controller framework - this adopts a master slave configuration where the master and the slave vary dynamically
  • elastic controller that is not associated with a set of switches statically, instead it keeps changing based on the load taken on by each switch and controller pair
There are many variations to the kind of distributed SDN controller architecture we can see and thus how to increase security in each of them would be something we shall be looking in the upcoming posts.

Comments

  1. For disaster recovery purposes (may be applicable to security), the master and slave controllers would be in a different geographical location. How much bandwidth would be required to keep in sync and switch over issues and underlying network is going to remain the same.

    ReplyDelete

Post a Comment

Popular posts from this blog

Day 12: Master Slave SDN Controller Architecture

Day 1: Understanding Ransomware and how to detect them?

Day 50: Tcpreplay and tcpliveplay approach