The following outlines OpenFlow, as one example of SDNs (Software Designed Networks) that can dynamically set or change a configuration, function, or performance of a network base on a software. OpenFlow switch includes a flow table including a plurality of flow entries. Each flow entry includes a match field to be matched with header field information of a received packet, a counter field including statistics information such as the number of received packets and the number of received bytes, and an action field with zero or more actions that dictate how the switch handles a received packet whose header matches with the match field. Upon reception of a packet, the OpenFlow switch retrieves the flow table thereof using header field information of the packet. In the case of miss-hit (non-match), the OpenFlow switch forwards the packet to OpenFlow controller over a secure channel.
Based upon information on a source and a destination of the packet specified in the header thereof, the OpenFlow controller computes a path for the packet from network topology information. Based upon the path, the OpenFlow controller generates and sets a flow entry for each of OpenFlow switches on the path. On reception of following packets, each having a header matching with a match field of the flow entry set by the OpenFlow controller, each of the OpenFlow switches on the path forwards the packets to a next node, for example, as prescribed in the action field of the flow entry. Regarding details of OpenFlow, reference may be made to NPL 6.
There have been extensive research and development efforts on secure networking, especially in SDN to reduce network vulnerabilities to attacks.
In NPL (Non Patent Literature) 1, there is proposed ROSEMARY controller, which implements a network application containment and resilience strategy based around the notion of spawning applications independently within micro-NOS (network operating system).
In NPL 2, there is proposed PermOF coping with potential trust issue on OpenFlow applications, in which abuse of trust could lead to various types of attacks impacting an entire network. In PermOF, isolation of control flow and data is established between a controller and applications. OpenFlow applications are isolated from Controller kernel, that is, OpenFlow applications cannot call kernel procedures or directly refer to a kernel memory. There is provided Access control layer between OpenFlow applications and OS (Operating System). The layer is controlled by the Controller kernel, so that undesirable interaction between OpenFlow applications and OS would be cut off.
In NPL 3, there is proposed AVANT-GUARD, a new framework to advance security and resilience of OpenFlow networks with greater involvement from the data-plane layer. Connection migration enables data plane to shield control plane from saturation attacks. Actuating triggers automatically insert flow rules when the network is under attack.
In NPL 4, there is disclosed a secure hypervisor, called TrustVisor, to provide a safe execution environment for security-sensitive code modules without trusting OS or application that invokes the code module. TrustVisor is so designed as to protect security-sensitive code and data from malware, even on untrusted commodity platforms.    [NPL 1] Seungwon Shin et al., “Rosemary: A Robust, Secure, and High-performance Network Operating System”, CCS'14    [NPL 2] Xitao Wen et al., “Towards a secure controller platform for openflow applications”, HotSDN '13    [NPL 3] Seungwon Shin et al., “AVANT-GUARD: scalable and vigilant switch flow management in software-defined networks”, CCS'13    [NPL 4] Jonathan M. McCune et al., “TrustVisor: Efficient TCB Reduction and Attestation”, Mar. 9, 2009, (revised Mar. 10, 2010) CMU-CyLab-09-003, CyLab Carnegie Mellon University Pittsburgh, Pa. 15213    [NPL 5] Jan Medved, Reinaldo Penno, OpenDaylight Update, November 2013, Internet <URL: http://www.ietf.org/proceedings/88/slides/slides-88-netconf-6.pdf>    [NPL 6] “Openflow Switch Specification” Version 1.0.0. (Wire Protocol 0x01), Internet<URL: http://www.openflowswitch.org/documents/openflow-spec-v1.0.0.pdf