[Open] the gates and Security [Flow]s in ...

The momentum behind OpenFlow is significant, with major vendors announcing real products, a number of startups working on innovation and lots of interested organizations - basically every cloud or service provider, along with titans such as Google, Facebook and Yahoo - collaborating on how to bring this technology forward. Two key events just in the past month included the OpenNetSummit at Stanford and the PacketPushers/TechFieldDay OpenFlow Symposium just this week.

Ethan Banks (@ecbanks) provided a great summary of the Symposium here  and Chris Hoff (@beaker) expanded on the security aspects of this on his post today . My take on it is to explore the ramifications for security architecture a bit more, specifically within the context of enterprise security, primarily as it relates to access-layers.

Before delving into that, security *for* OpenFlow itself seems pretty straightforward: the switches talk to the controllers over a secure SSL channel and believe what the controller tells them. This means that if the controller is compromised, or if the switches can be misled to talk to a different controller, game over.

This highlights a key point: OpenFlow itself is just a protocol. As Ethan mentioned, the "Openflow magic" happens on the controller side "when we see vendors writing clever applications". There are several vendors working on OpenFlow controllers right now, from NEC to Nicira to Big Switch and others.

So, what can OpenFlow (and the broader topic of "Software-Defined Networking") bring to network security architecture?

• "Firewall" at the true edge. By implementing functionality that can dynamically instruct switches to pass, modify and drop packets, OpenFlow in essence, creates true "edge" firewalls with the benefit of centralized control and probably kills off NAC to boot. All that we tried to do with NAC and 802.1x - tying wired access to identity, responding to changes in endpoint security posture, ... - becomes viable with an Openflow-enabled switch. 
• As a side benefit, we get to implement the recommendation that packet filtering be done as close to the source as possible. 
• "Transparent" network changes. One of the more painful aspects for client-side user experience with NAC was having to switch VLANs after authenticating. Several applications - such as Windows RDP - would not handle that gracefully. An OpenFlow-enabled environment can just enforce rules itself (see above) or change VLAN parameters transparently. To make a long story short, the notion of making changes to flows *TRANSPARENTLY* means that security can 'blend in' that much better. 
• As a special case of these transparent changes, directing traffic to specialized security devices (WAFs, forensics, DLP, ...) can be made more elegantly and with more granularity.

• Realize the potential of IF-MAP. As vendors moved to implement IF-MAP to provide a framework for security orchestration, adoption has not been as wide as expected. Having an OpenFlow controller being able to subscribe to MAP events and alter the network based on that enhances the value of the technology as well, IMHO.
• We can now envision an architecture where higher-level security applications - maybe DLP, maybe WAF, maybe a client-side host-security suite - leverage IF-MAP to publish security events and can rely on a controller to boot sytems off the network or direct them to collection areas.

Well, this is all fine and dandy. What are some of the limitations?

• OpenFlow is still new, both in terms of protocol and ecosystem evolution. There will be lots of new things to discover, vendors to spring up and consolidate, etc... before we get into the... ahem... flow of things. 
• OpenFlow's centralized architecture will certainly have scalability and latency implications: the flow of traffic from the switch forwarding plane to the switch CPU to the OpenFlow controller will introduce delays making it impractical for environments such as low-latency trading, high-performance computing and the like. Also, as Ethan mentioned in his post, the notion of managing individual flows (also referrred to as microflows) will introduce challenges to controller scalability.
• Well, for all the power that OpenFlow offers, it can still only visualize flows in the context of L2-L4 attributes: what port is connected, what the IP address is, what protocol, etc... In the meantime, it comes as no surprise to anyone that the threat profile has long since changed to the application layers, exploiting Adobe PDF, Flash, SQL Injections, Cross-Site Scriptings, ... To me, what this will mean is that these higher-layer security controls - be they Web Application Firewalls (WAFs), Data Loss Prevention (DLP), Network Forensics, Host Security Agents ... - still need to intercept and inspect traffic. 

So, don't ditch your load balancers, WAFs, IPS, ... just yet. Quite the contrary: if the future is such that simple access control will be 'solved' with OF, these other control points will become more critical.

This is a truly exciting time to be in networking/security. Ultimately I think @beaker is right that security will be a killer app for OpenFlow, at least in the enterprise realm. Follow PacketPushers (packetpushers.net) and others for more discussion on new developments...

By all means let me know your thoughts or if I made any egregious mistakes above. This is new to me too...

To quote Brian Tracy - “Move out of your comfort zone. You can only grow if you are willing to feel awkward and uncomfortable when you try something new.”