With that off my chest, I came across another interesting side benefit from using OpenFlow in the context of access-layer security: minimizing inadvertent disclosure of sensitive configuration information.
Yes, we can use things like load configurations from TFTP or other places, but being able to rely on dynamic configuration of the forwarding plane makes that process even easier. As a side note, more and more I think of OpenFlow in a similar way to controller-based wireless deployments, but without that mandatory tunnelling back to the controller. :-)
From F5's DevCentral blog entry at http://devcentral.f5.com/weblogs/macvittie/archive/2011/12/07/your-network-architecture-now-on-e-bay-for-9.95.aspx
"Imagine that instead of routing and processing decisions being triggered by traffic arriving on a port that some piece of data inside the traffic triggered the execution of the proper policy, including where the next “hop” in the network should be. Essentially, dynamically building the path through the network based on the content rather than on static, preconfigured paths."
Sounds familiar, doesn't it? :-)
To me, there's two ways of looking at this:
- OpenFlow as an alternative to F5's vision of 'content-driven network security configuration'
- OpenFlow as a complement to that vision
Now, F5 obviously wants to be able to provide the inspection of traffic to generate that proper policy, but perhaps it should consider a more harmonious integration with OpenFlow instead...
Not enough hours in the day to keep up with all this...
