, , , ,

Originally this was going to be a post on how well the Spanning Tree Protocol has scaled for current technologies, but I got sidetracked during my research by something more interesting and relevant: Software Defined Networking (SDN).

The idea is simple: It involves separating the network into two layers of abstraction. The Data Plane is the packet routing/forwarding, and the Control Plane represents the firmware controlling the routers and network switches, the ACLs and routing/forwarding policies. I’ve just noticed that it all boils down to deciding whether packets are forwarded or not.

So, what’s the point of this, some might ask? Traditionally network administrators install, configure and manage each networking device individually, and use tools such as ping and traceroute to diagnose problems. It was relatively easy to do this with smaller networks, with perhaps just a perimeter router, and maybe a firewall and a couple of switches. Today’s enterprise networks tend to be dynamic, having to adapt to changes in topology as mobile devices come and go, stuff is increasingly virtualised, and more device types like firewalls, IDS, VPN gateways, etc. etc. are added.
What a network admin could end up with eventually is a network that’s nowhere near efficient for its current state of operation, and an architecture that looks rather different on paper to the actual one.

Engineers at UC Berkeley developed the model that separates the network infrastructure (and I really do mean ‘infrastructure‘ here) into the two layers of abstraction already mentioned, and proposed an interface for centrally managing all the networing hardware – essentially a controller or network operating system. On this, a network administrator could deploy software for monitoring the really low-level stuff in real time, for managing the network configuration and for changing the way packets are routed. Another software application could automate many of the configuration changes, making the infrastructure more adaptive.

Although the idea is pretty straightforward so far, not everything is strictly about forwarding packets: firewalls, IDS boxes, VPN gateways, QoS, etc. have to be considered. Scott Shenker at UC Berkeley has pointed out that most these additional non-routing functions tend to be implemented as software, and they tend to be deployed at the perimeter. He has suggested a more efficient model of SDN where the devices inside a network are limited to just hardware-layer packet forwarding while the SDN software manages the perimeter.

OpenFlow Protocol
Currently SDN is a (very interesting) concept rather than something discussed as a deployable technology. What still needs to be worked out is how networking devices receive and process instructions from elsewhere, their control interfaces and a standard method for the SDN server to communicate with them.

What we do have is the OpenFlow protocol specification, which is being developed by the Open Networking Foundation, that addresses most of the requirements. According to the Wikipedia entry, the main vendors, including IBM, Cisco, HP and Juniper, have announced they’ll be supporting it, so it does look as if OpenFlow will eventually become the standard for SDN.

OpenFlow defines three types of communication:
* Controller-to-Switch: Switch management and monitoring.
* Asynchronous: Current status updates sent from hardware.
* Symmetric: Other messages sent from controller or hardware.

To make OpenFlow reliable, the specification says that any implementation must guarantee that messages from an SDN server are delivered and fully processed by the switches in the network, unless the hardware has failed totally or is unreachable because of some unresolveable traffic congestion.

Security Implications
I haven’t seen the security issues of SDN addressed yet, except for a casual mention of OpenFlow message encryption, but maybe that’ll have to wait until when it’s deployed. SDN would potentially allow a malicious device or software application to becom the SDN server on a target network and perhaps take control of the infrastructure. What we should consider is how the server and devices would authenticate themselves, and how the authentication details would be protected against interception.

On the plus side, this idea of making everything at the perimeter software-based and under the control of SDN could improve network monitoring capabilities, and it might be possible to view malicious activity in real-time.