Day 59: What next!

The features built into the architecture so far:
  • high sustainability of controllers when DoS attack occurs - due to switchover mechanism (high availability)
  • avoiding single point of failures in load balancer and master controller
  • dynamic learning of new flows
  • scalability 
  • synchronized controllers
Thus in case any DoS attack happens from switch to controller, the distributed controller architecture can sustain this attack for a very long time. This was the purpose of the architecture from when we conceived the idea of building it. What other features should we be implement?

  • an ML server - detection and decision regarding malicious packets (  watch out for Swati's blogs regarding this)
  • this ML server must receive packets from load balancer using any pub-sub model like kafka and zookeeper architecture
What other features can make our already existing architecture better?

As a further enhancement to the architectural design, I have intended to add a component to detect and mitigate DDoS attacks on the SDN network side. As we know, only when DDoS attack occurs from a malicious host to a victim host is when the FX switch also floods the controller with large amounts of packets. This is what causes DoS attack on the controller side.

Given the fact that the controller always knows about the hosts and switches connected to it, it has all information required to detect and mitigate any DDoS attack on SDN network. Thus we can build an Ryu program that identifies if any DoS attack is likely to occur on the controller. To mitigate the same, we can come up with strategies.

I am referring to this github repo to know more about detection and mitigation of DDoS attacks from controllers.

Refer to previous and next posts here.

Author: Shravanya
Co-author: Swati

Comments

Popular posts from this blog

Day 12: Master Slave SDN Controller Architecture

Day 50: Tcpreplay and tcpliveplay approach

Day 10: Mininet Simulation of a basic distributed SDN controller architeture