In one of my ExpertExpress engagements the customer expressed the desire to manage their firewall with OpenFlow (using OpenDaylight) and I said, “That doesn’t make much sense”. Here’s why:

Obviously if you can't imagine your life without OpenDaylight, or if your yearly objectives include "deploying OpenDaylight-based SDN solution", you can use it as a REST-to-NETCONF translator assuming your firewall supports NETCONF.

• OpenFlow was designed to control packet forwarding hardware. It’s good enough to install packet filters into controlled devices, reflexive ACLs already require extensions (for example OVS extensions), and it’s impossible to express any meaningful firewalling policies with OpenFlow unless you use OpenFlow as a transport protocol and totally redefine the meaning of table contents.
• OpenFlow forwarding model covers L2-L4 packet handling. Anything beyond that (in particular deep packet inspection) has to be punted to the controller, which becomes a central chokepoint like any stateful firewall, so why bother.
• While there’s nothing in OpenFlow standard that would prevent the forwarding hardware from performing IP defragmentation and TCP sequence number checking the typical hardware devices supporting OpenFlow don’t provide that functionality.

What might make sense is to use link a firewall with an adjacent switch to create per-flow shortcuts for elephant flows, particularly for protocols where the firewall doesn’t provide any additional functionality beyond packet filtering (example: network-based backups or encrypted database sessions), but even there you don’t need OpenFlow to get the job done. Arista demonstrated such a solution with Palo Alto firewalls, using syslog messages from the firewall to identify elephant flows.

Alternatively, the firewall might identify an intruder and tell the SDN controller to block him. Fortinet has demonstrated such a solution using HP SDN controller. The whole idea looks great but could also present a great DoS attack surface: all you have to do is to send probes from enough bogus IP addresses to exhaust the filtering capacity of the hardware.

Takeaway: just because something looks great in PowerPoint doesn’t mean it will work well in production deployment. Always make sure you understand the underlying technology and the true limitations of the proposed solution (because most vendors won’t be honest enough to tell you what they are).