OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security
As facetious as the introductory premise of my Commode Computing presentation is, the main message — the automation of security capabilities up and down the stack — really is something I’m passionate about.
Ultimately, I made the point that “security” needs to be as programmatic/programmable, agile, scaleable and flexible as the workloads (and stacks) it is designed to protect. “Security” in this contexts 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’m busy reading many of the research activities associated with OpenFlow security and digesting where vendors are in terms of their approach to leveraging this technology in terms of security. It may be just my perspective, but it’s a little sparse today — not disappointingly so — with a huge greenfield opportunity for really innovative stuff when paired with advancements we’re seeing in virtualization and cloud computing.
I’ll relate more of my thoughts and discoveries as time goes on. If you’ve got some cool ideas/concepts/products in this area (I don’t care who you work for,) post ’em here in the comments, please!
In the meantime, check out: www.openflow.org to get your feet wet.
/Hoff
Reminders to self to perform more research on (I think I’m going to do my next presentation series on this):
- AAA for messages between OpenFlow Switch and Controllers
- Flood protection for controllers
- Spoofing/MITM between switch/controllers (specifically SSL/TLS)
- Flow-through (ha!)/support of OpenFlow in virtual switches (see 1000v and Open vSwitch)
- (per above) Integration with VN-Tag (like) flow-VM (workload) tagging
- Integration of Netflow data from OpenFlow flow tables
- State/flow-table convergence for security decisions with/without cut-through given traffic steering
- Service insertion overlays for security control planes
- Integration with 802.1x (and protocol extensions such as TrustSec)
- Telemetry integration with NAC and vNAC
- Anti-DDoS implications
Related articles
- Big Shots Start New Cloud Standards Body (java.sys-con.com)
- Openflow: Internet 3.0? (zdnet.com)
- Tech Giants Push Smart Networking Standard (informationweek.com)
- OpenFlow: The NoSQL of Network Protocols (readwriteweb.com)
- How Software Will Redefine Networking (gigaom.com)
I also see the great potential of open flow. Has Cisco started to work on this?
Yes, Steve. You can read about it here:
http://www.itworldcanada.com/news/the-next-revolu…
…also:
http://wiki.openstack.org/NetworkContainers
/Hoff
Well of course it is sparse, dude. It's brand new. LOL
Openflow is not going to be a fit everywhere. It likely won't be used in HPC processing, for example, where time is measured in microseconds. But the benefit that Openflow brings to the table is the centralized view of network activity versus the many minds view today.
Of course, there are limitations. The opeflow model today is that only the first frame in an exchange is sent to the controller for route definition and then the forwarding tables are updated. I don't think revisiting existing flows is part of the model today. It could be (no reason not to, right?). Also, if a flow exists in the switch forwarding tables, there is no need to send a new flow between two nodes to the controller and that is by design.
You are right though, where this gets interesting is programmatic configuration of flow tables. You can use anything to investigate flows and alter the flow tables using OpenFlow. You could, for example, monitor traffic with Netflow, Sflow, etc, see a bump in DoS, and work to redirect that (though how you would do that is beyond me).
But you can also do more interesting ACL stuff as well. HP's solution, if memory serves, allows you to block/allow flows at the ingress port and thos ACL's have to follow the user which is difficult. Cisco's TrustSec, again if memory serves, enforces ACL's at the egress port–server side– so that ACL's don't "move" with users. With Openflow, flows can simply be blackholed.
There is a lot of cool potential and there is a lot of cool potential depending on how vendors integrate OpenFlow into their switches.
Here is a blatant pitch. Openflow will be doing some demos at Interop in Vegas on the show floor. It should be pretty cool and give you taste of what can be done today.