Day 5 Part 1: Distributed controller architectures

From whatever we know of security through the past few posts, we can be sure of one thing - 'The security demands of each and every architecture is different'. Thus the kind of distributed controller architecture highly influences the kinds of security concerns we need to address in it. Since we are heading in the direction of securing distributed controller network, our first task would be to decide what architecture we would be looking at.

There are many distributed controller architectures that exist out there. Many are designed in a very efficient and optimized fashion that the security threat could be handled very easily. The purpose of this post would be go through various such architectures and devise an architecture that best suits our purpose. To restate our purpose - 'Building a controller network that has high availability, scalability and performance'.

In yesterday's post, I had mentioned few words 'cluster based architecture', 'elastic architecture' and so on. Today's post will describe these architectures and highlight the pros and cons of each.

Distributed Controller in Cloud running BFT Protocol

This article proposes an architecture that involves controller on cloud with BFT protocol running. The following are its properties;

• BFT provides a powerful state machine like approach for high reliability and consistency 
• each switch is connected to n controllers 
• the network can sustain upto f faulty controllers. here n and f are related through the following equations:
  n >= 3f + 1 (PBFT protocol running on controllers)
  n >= 2f + 1 (MinZyzzyva protocol)
• there is one primary controller for each switch. whenever the switch contacts the controller for flows, the primary controller forwards the request to all the other instances including faulty controllers. The switch waits for f+1 replies. The majority of the controllers would reply with correct flows. Thus the switch considers the majority as the correct flow. 

Why the architecture is not suitable for our problem statement

• too much redundancy
• deployed in a cloud environment and thus security is not a primary concern
• instances of the controller running and hence could be treated as a single controller and would not be a true reflection of a distributed controller architecture
• faulty controllers are let to operate and share their flows - possibility of contamination of other network components