The Killer App For OpenFlow and SDN? Security.
I spent yesterday at the PacketPushers/TechFieldDay OpenFlow Symposium. The event provided a good overview of what OpenFlow [currently] means, how it fits into the overall context of software-defined networking (SDN) and where it might go from here.
I’d suggest reading Ethan Banks’ (@ecbanks) overview here.
Many of us left the event, however, still wondering about what the “killer app” for OpenFlow might be.
Chatting with Ivan Pepelnjak (@ioshints) and Derrick Winkworth (@CloudToad,) I reiterated that selfishly, I’m still thrilled about the potential that OpenFlow and SDN can bring to security. This was a topic only briefly skirted during the symposium as the ACL-like capabilities of OpenFlow were discussed, but there’s so much more here.
I wrote about this back in May (OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security):
… “security” needs to be as programmatic/programmable, agile, scaleable and flexible as the workloads (and stacks) it is designed to protect. “Security” in this context extends well beyond the network, but the network provides such a convenient way of defining templated containers against which we can construct and enforce policies across a wide variety of deployment and delivery models.
So as I watch OpenFlow (and Software Defined Networking) mature, I’m really, really excited to recognize the potential for a slew of innovative ways we can leverage and extend this approach to networking [monitoring and enforcement] in order to achieve greater visibility, scale, agility, performance, efficacy and reduced costs associated with security. The more programmatic and instrumented the network becomes, the more capable our security options will become also.
I had to chuckle at a serendipitous tweet from a former Cisco co-worker (Stefan Avgoustakis, @savgoust) because it’s really quite apropos for this topic:
…I think he’s oddly right!
Frankly, if you look at what OpenFlow and SDN (and network programmability in general) gives an operator — the visibility and effective graph of connectivity as well as the multiple-tupule flow action capabilities, there are numerous opportunities to leverage the separation of control/data plane across both virtual and physical networks to provide better security capabilities in response to threats and at a pace/scale/radius commensurate with said threat.
To be able to leverage telemetry and flow tables in the controllers “centrally” and then “dispatch” the necessary security response on an as-needed basis to the network location ONLY that needs it, really does start to sound a lot like the old “immune system” analogy that SDN (self defending networks) promised.
The ability to distribute security capabilities more intelligently as a service layer which can be effected when needed — without the heavy shotgunned footprint of physical in-line devices or the sprawl of virtualized appliances — is truly attractive. Automation for detection and ultimately prevention is FTW.
Bundling the capabilities delivered via programmatic interfaces and coupling that with ways of integrating the “network” and “applications” (of which security is one) produces some really neat opportunities.
Now, this isn’t just a classical “data center core” opportunity, either. How about the WAN/Edge? Campus, branch…? Anywhere you have the need to deliver security as a service.
For non-security examples, check out Dave Ward’s (my Juniper colleague) presentation “Programmable Networks are SFW” where he details interesting use cases such as “service engineered paths,” “service appliance pooling,” “service specific topology,” “content request routing,” and “bandwidth calendaring” for example.
…think of the security ramifications and opportunities linked to those capabilities!
I’ve mocked up a couple of very interesting security prototypes using OpenFlow and some open source security components; from IDP to Anti-malware and the potential is exciting because OpenFlow — in conjunction with other protocols and solutions in the security ecosystem — could provide some of the missing glue necessary to deliver a constant, but abstracted security command/control (nee API-like capability) across heterogenous infrastructure.
NOTE: I’m not suggesting that OpenFlow itself provide these security capabilities, but rather enable security solutions to take advantage of the control/data plane separation to provide for more agile and effective security.
If the potential exists for OpenFlow to effectively allow choice of packet forwarding engines and network virtualization across the spectrum of supporting vendors’ switches, it occurs to me that we could utilize it for firewalls, intrusion detection/prevention engines, WAFs, NAC, etc.
Thoughts?
Related articles
- What’s OpenFlow’s killer app? (infoworld.com)
- OpenFlow and SDN: Networking’s future? (networkworld.com)
- Can OpenFlow Unlock More of Virtualization’s Potential? (informationweek.com)
- OpenFlow Tutorial: Next-Gen Networking Has Much To Prove (informationweek.com)
- Network Virtualization is like a big virtual chassis (bradhedlund.com)
- A Contentious Question: The Value Proposition & Target Market Of Virtual Networking Solutions? (rationalsurvivability.com)
- VMware’s vShield – Why It’s Such A Pain In the Security Ecosystem’s *aaS… (rationalsurvivability.com)
- (Physical, Virtualized and Cloud) Security Automation – An API Example (rationalsurvivability.com)
- SecurityAutomata: A Reference For Security Automation… (rationalsurvivability.com)
At this point, the ability of SDN Controllers to manage ephemeral or transient flows is limited.
For a firewall function set, you need to create and delete significant volumes of entries in the state table. And, probably, also need to munge the MAC or IP header for such functions as NAT. The ability of the current switch/router silicon, and the controllers themselves, to program those flows is limited. The limitation occurs at many levels – controller performance, network performance, silicon performance and the heuristic limitations algorithmic control. Therefore, I’m not confident that a firewall function will occur on the next five years.
However, NAC is almost definitely an early use case that will be rapidly adopted. Consider a mobile service provider who wants to validate that a customer has a positive balance account. The first flow would be handled by a controller, validated against the central AAA engine, and then an OF command to permit flows at the edge. Extending this into corporate platforms, the controller might be the NAC Gateways that we have today. Scale could be achieved through a hierarchy of controllers or perhaps a distributed computing concept.
Perhaps the most significant security feature is the possibility of implementing a network where every single flow is matched against a set of policy. And because the controller implements a programmatic process, it could expose the policy in a way that is actually usable.
So, SDN/OpenFlow isn’t a security technology in any traditional sense, but it delivers security outcomes in a whole new way.
Is the security industry ready for that idea ?
Thanks Greg, for the comment.
To be clear (because perhaps I wasn’t) I’m not suggesting that OpenFlow itself provide these security capabilities, but rather enable security solutions to take advantage of the control/data plane separation to provide for more agile and effective security.
I agree that the NAC use-case makes total sense…as does lumpy ACL enforcement (on 5 tuple, for example without DPI)
As to your question “Is the security industry ready for that idea ?” << All I can suggest is that some *cough* of them are 🙂
The challenge is that most existing paradigms on how Security Infrastructure implements security policy will need to be radically rethought.
This isn’t something that the security industry does well. While not quite as slow as the storage industry is adopting new technology, resistance to change is strong.
Chris, Serge here… Isn't the basic problem w/ filtering using Openflow constructs is at best you'd get stateless ACL-like functionality? Certainly would work great for things like BPDU filtering or dropping LLC frames carrying CDP, but for IP/TCP/UDP/ICMP, wouldn't this fall short because of the lack of connection tracking mechanisms? Without this, a simple NMAP ack-scan would walk through any Openflow filter…
It’s finally the vision of NAI’s “Active Security” nearly 15 years later in a form that might actually work!
How soon after SDN goes mainstream in real production networks will we see it emerge as a new attack surface? Also, thinking about SDN in the context of “Dark Side of Automation” post http://www.rationalsurvivability.com/blog/?p=3234
Going through some of the WP’s on OpenFlow, I can’t help but think that the “rule” within an OpenFlow flow today is limited. It is still defined by any information up to L4 (MAC, IP, VLAN, etc..) where most of the security solutions today tend to look at information at L7.
How will OpenFLow “group” rules based on that information ?
E.g. how can OpenFlow direct traffic to a WAF if it can’t see the data info ? Based on IP info ok, but that’s not that interesting.
Thoughts ?
Cheers
Stefan
Using OpenFlow for distributed ACL dissemination and management will be a mistake. Today, the most common protocol for policy sharing in networks is BGP, and there is already a technology that is an IETF draft to do this called BGP FlowSpec:
http://tools.ietf.org/html/draft-ietf-idr-flow-spec-09
FlowSpec is already supported on JunOS, and it will be a better way to do this at perimeter / edge routers.