DOCSDN: Dynamic and Optimal Configuration of Software-Defined Networks

TL;DR

This paper presents DOCSDN, a layered framework for optimizing software-defined network configurations to satisfy multiple conflicting requirements like security, performance, and reachability, with quick reconfiguration capabilities.

Contribution

The paper introduces a novel layered optimization framework for SDN configuration that jointly considers multiple network properties and constraints.

Findings

Configurations are generated within 1-5 minutes.

Framework effectively balances security and performance.

Validated on fat tree topology in data center networks.

Abstract

Networks are designed with functionality, security, performance, and cost in mind. Tools exist to check or optimize individual properties of a network. These properties may conflict, so it is not always possible to run these tools in series to find a configuration that meets all requirements. This leads to network administrators manually searching for a configuration. This need not be the case. In this paper, we introduce a layered framework for optimizing network configuration for functional and security requirements. Our framework is able to output configurations that meet reachability, bandwidth, and risk requirements. Each layer of our framework optimizes over a single property. A lower layer can constrain the search problem of a higher layer allowing the framework to converge on a joint solution. Our approach has the most promise for software-defined networks which can easily reconfigure their logical configuration. Our approach is validated with experiments over the fat tree topology, which is commonly used in data center networks. Search terminates in between 1-5 minutes in experiments. Thus, our solution can propose new configurations for short term events such as defending against a focused network attack.

Figures

Equations

$$share_{c_{1},c_{2},n}\Leftrightarrow n\in\left(\begin{array}[]{c}\left(\cup_{p\in P(c_{1}):active_{p,*}}N(p)\right)\\ \cap\\ \left(\cup_{p\in P(c_{2}):active_{p,*}}N(p)\right)\end{array}\right)$$

$$\sum _{p\in P(e),T\in \mathcal{T}}flo{w}_{p,T}\le cap(e),\forall e\in \mathcal{E}$$

$$\sum _{p\in P(s,t)}flo{w}_{p,T}\ge D(s,t,T),\forall (s,t,T)\in \mathcal{F}$$

$$activ{e}_{p,T}=1\to flo{w}_{p,T}\ge 1,\forall (s,t,T)\in \mathcal{F},p\in P(s,t)$$

$$\sum _{p\in P(s,t)}activ{e}_{p,T}=1,\forall (s,t,T)\in \mathcal{F}$$

$$equi{v}_{c,n}=\underset{p\in P(n)\cap P(c)}{\bigvee }(activ{e}_{p,T}),\forall T\in \mathcal{T},n\in \mathcal{N},c\in \mathcal{C}$$

$$shar{e}_{c_1,c_2,n}=equi{v}_{c_1,n}\wedge equi{v}_{c_2,n},\forall n\in \mathcal{N},(c_1,c_2)\in \mathcal{R}$$

$$loa{d}_n=\sum _{p\in P(n),T\in \mathcal{T}}flo{w}_{p,T},\forall n\in \mathcal{N}$$

$$\min\left(\begin{array}[]{lll}\alpha_{0}&\sum_{p,T}{len(p)*flow_{p,T}}&+\\ \alpha_{1}&\sum_{(c_{1},c_{2})\in{\cal R},n\in{\cal N}}{(share_{c_{1},c_{2},n}-1)}&+\\ \alpha_{2}&\sum_{n\in{\cal N}}{(load_{n})^{2}}&\end{array}\right)$$

$$\begin{array}[]{lcl}flowRisk(p,T)&=&\sum_{i\in d_{2}(s)\cup d_{2}(t)}risk(i,T)^{2}+\\ &&\sum_{i\in N(p)\setminus\left(d_{2}(s)\cup d_{2}(t)\right)}risk(i,T)^{2}\end{array}$$

$$fwO{R}_{n,T}=f{w}_{n,T}\vee f{w}_{n,\ast },\forall n\in \mathcal{N},T\in \mathcal{T}$$

$$\sum _{T\in \mathcal{T}\cup \{\ast \}}fwCos{t}_T\cdot f{w}_{n,T}+piCost\cdot p{i}_n\le me{m}_n,\forall n\in \mathcal{N}$$

$$fwO{P}_{p,T}=\underset{n\in N(p)}{\bigvee }(fwO{R}_{n,T}),\forall T\in \mathcal{T},p\in \mathcal{P}:activ{e}_{p,T}$$

$$RMf{w}_{p,n,T}=1-(.5{)}^{rank(n,p)}\cdot fwO{R}_{n,T},$$

$$\forall p\in P(s,t),n\in N(p),(s,t,T)\in \mathcal{F}$$

$$RMp{i}_{p,n,T}=1-0.1\cdot (.5{)}^{rank(n,p)}\cdot p{i}_n,$$

$$\forall p\in P(s,t),n\in N(p),(s,t,T)\in \mathcal{F}$$

$$r{f}_{p,T}=\min$$

$$\forall T\in \mathcal{T},p\in \mathcal{P}:activ{e}_{p,T}$$

$$\min\left(\!\!\begin{array}[]{lll}\beta_{0}\left(\sum_{n,T}{fwComp\cdot fw_{n,T}}+\sum_{n}{piComp\cdot pi_{n}}\right)+\\ \beta_{1}\sum_{n}{load_{n}\cdot pi_{n}}+\\ \beta_{2}\sum_{p,T}{penalty(p,T)\cdot flow_{p,T}\cdot fwOP_{p,T}}+\\ \beta_{3}\sum_{p,T}{flowRisk_{p,T}\cdot rf_{p,T}}\end{array}\!\!\right)$$

Full text

This need not be the case. In this paper, we introduce a layered framework for optimizing network configuration for functional and security requirements. Our framework is able to output configurations that meet reachability, bandwidth, and risk requirements. Each layer of our framework optimizes over a single property. A lower layer can constrain the search problem of a higher layer allowing the framework to converge on a joint solution.

Our approach has the most promise for software-defined networks which can easily reconfigure their logical configuration. Our approach is validated with experiments over the fat tree topology, which is commonly used in data center networks. Search terminates in between 1-5 minutes in experiments. Thus, our solution can propose new configurations for short term events such as defending against a focused network attack.

I Introduction

Network configuration is a crucial task in any enterprise. Administrators balance functionality, performance, security, cost and other industry specific requirements. The resulting configuration is subject to periodic analysis and redesign due to red team recommendations, emerging threats, and changing priorities. Tools assist administrators with this complex task: existing work assesses network reachability [1], wireless conflicts [2], network security risk [3, 4], and load balancing [5, 6]. These tools assess the quality of a potential configuration. Unfortunately, current tools suffer from three limitations:

Most tools assess whether a single property is satisfied, making no recommendation if the property is not satisfied. This leaves IT personnel with the task of deciding how to change the network. 2. 2.

Networks are assessed with respect to an individual goal at a time. This means a change to satisfy a single property may break another property. There is no guidance for personnel on how to design a network that meets the complex and often conflicting network requirements. 3. 3.

These tools do not react to changing external information such as the publication of a new security vulnerability.

Our Contribution

This work introduces a new optimization framework that finds network configurations that satisfy multiple (conflicting) requirements. We focus on data center networks (DCN) that use software defined networking (SDN). Background on these settings is in Section II. Our framework is called DocSDN (Dynamic and Optimal Configuration of Software-Defined Networks).

DocSDN searches for network configurations that simultaneously satisfy multiple properties. DocSDN is organized into layers that consider different properties. The core of DocSDN is a multistage optimization that decouples search on “orthogonal” concerns. The majority of the technical work is to effectively separate concerns so the optimization problems remain tractable. Our framework is designed to continually produce network configurations based on changing requirements and threats. It frees IT personnel from the complex question of how to satisfy multiple requirements and can quickly incorporate new threat information.

DocSDN focuses on achieving functional requirements (such as network reachability and flow satisfaction) and limiting security risk (such as isolating high risk nodes and nodes under denial of service attack). Naturally, other layers such as performance or cost can be incorporated. The search for a good configuration could be organized in many ways. State-of-the-art approaches assess different properties in isolation, frustrating search for a solution that satisfies all requirements. Ideally, a framework should search for a configuration that simultaneously satisfies all requirements. This extreme is unlikely to be tractable on all but the smallest networks. DocSDN mediates between these approaches separating the functional and security search problems but introducing a feedback loop between the two search problems based on cuts.

In the proposed organization the functional layer is “above” the security layer. Through the feedback loop, the security layer describes a problematic part of the network to the functional layer. The functional layer then refines its model and searches for a functional configuration that satisfies an additional constraint. This has the effect of blocking the problematic part of the configuration. Currently, the feedback signal is a pair of nodes that should not be proximate in the network. After multiple iterations the two layers jointly produce a solution that optimizes the SDN configuration both with respect to functionality and security risks.

DocSDN provides solutions of improving quality before the final solution. Thus, the network can be reconfigured once the objective improves on the current configuration by a large enough amount (to justify the cost/impact of reconfiguration).

While the underlying optimization problems are NP-hard, optimization technology has seen tremendous advances in performance during the past few decades. Since 1991, mathematical programming solvers have delivered speedups of 11 orders of magnitude [7, 8]. The advent of hybrid techniques such as Benders decomposition [9, 10, 11, 12] and column generation [13, 14, 15] (aka, Dantzig-Wolfe decomposition [16]) made it possible to harness huge problems thanks to on-demand generation of macroscopic variables and the dynamic addition of critical constraints. Large Neighborhood Search [17] further contributed to delivering high-quality solution within constrained time budgets.

These techniques are beginning to see adoption in network security. Yu et al. recently applied stochastic optimization with Bender’s decomposition to assess network risk under uncertainty for IoT devices [4]. They used Bender’s decomposition on a scenario-based stochastic optimization model to produce a parent problem that chooses a deployment plan while children are concerned with choosing the optimal nodes to serve the demands in individual scenarios. In comparison, our approach addresses both functional and security requirements. It relies on Bender’s cuts from the security layer (child) to rule out vulnerable functional plans whose routing paths fail to adequately minimize risks and maximize served clients. We now briefly describe the framework (a formal description is in Section III) and present an illustrative example.

Overview of DocSDN

Figure 1 presents an overview of the framework. The functional layer takes as input a Functional Model that describes the network including the physical topology, link speeds, the allowable communication patterns and the demand requirements. Network reachability begins with a priming procedure that generates the $k$-least cost paths to the optimizer for each source/destination pair in the demand requirements. The objective for the functional layer is to find a logical topology (a collection of routed paths) that meets all demand requirements while favoring shorter length routing paths and load balancing. The program is formulated as quadratic binary program (QBP). The solution as determined by the functional layer is passed to the security layer.

The output of the functional layer and a security model are the input for the security layer. The current configuration is fed to a module that uses risk assessments for the individual network devices (obtained for example using a vulnerability database) to assess the overall risk of the entire configuration. In our current implementation this risk calculation is based on a simple risk propagation model where a path’s risk is based on the risk of nodes on the path and close to the source and sink. The security layer can deploy firewalls and deep packet inspection as network defenses. Since these mechanisms affect route capacity, the security layer has a dual objective function: 1) maximizing the functional objective and 2) minimizing security risk. The security objective is formulated as a mixed integer program (MIP). When the security search completes, it proposes nodes to the functional layer that should be separated. As an example, a high value node with low risk may be placed in a different (virtual) LAN than a high risk node. These Benders cuts are designed to entice a better logical topology from a subsequent iteration in the functional layer. This feedback loop between the two layers can iterate multiple times. When no further cuts are available, the overall output is a set of configuration rules.

An example configuration

This section describes an application of our framework to automatically respond to a distributed denial of service (DDoS) attack. Current DDoS attacks demonstrate peak volume of 1 Tbps [18]. Many DDoS defense techniques require changes to the network behavior by rate limiting, filtering, or reconfiguring the network (see [19, 20, 21, 22, 23]). Recent techniques [24] leverage SDNs to react to DDoS attacks in a dynamic and flexible manner. We show how such a response would work in our framework using a toy network illustrated in Figure 2. A more realistic network and the framework’s response are described in Section V. We stress that DDoS attacks are often short in timescale making human diagnosis and reaction costly or impractical.

Consider a focused DDoS attack against a number of services in an enterprise but not the entirety of its publicly accessible address space. (The Great Cannon’s attack against GreatFire targeted two specific Github repositories [25].) We assume a service hosted by $H_{1}$ is targeted, while services on $H_{2},H_{3}$ and $H_{4}$ are not.

Recall, the functional layer establishes a logical topology (forwarding rules) while the security layer adds network defenses (packet inspection modules and firewall rules). We elide how the attack is detected and assume it increases the risk score for $H_{1}$ in the security model.

The first iteration The functional layer proposes a candidate configuration where $G_{1}$ routes all traffic intended for $H_{1}$ and $H_{2}$ to $S_{1}$ which then forwards the traffic and $G_{1}$ routes traffic intended for $H_{3}$ and $H_{4}$ to $S_{2}$ which then forwards the traffic. This is the first candidate solution presented to the security layer.

Since $H_{1}$ is high risk the security layer proposes a firewall at $S_{1}$ to block all port $80$ traffic. This reduces risk at the cost of blocking all traffic to $H_{2}$. Of course, in real firewalls more fine-grained rules are possible, this simplified example is meant to illustrate a case where collateral damage to the functional objective is necessary to achieve the security objective. Since traffic is being blocked to a node with low risk, the security layer asks the functional layer to separate $H_{1}$ and $H_{2}$ so $H_{2}$ does not suffer.

Repeated iterations The functional layer now has a constraint that $H_{1}$ and $H_{2}$ should not be collocated in the network. As such, it proposes a new configuration with $H_{1}$ and $H_{3}$ under $S_{1}$ and $H_{2}$ and $H_{4}$ under $S_{2}$. This is then sent to the security layer. The security layer makes a similar assessment and proposes a firewall rule at $S_{2}$, finds this recommendation hurts functionality and requests separation of $H_{1}$ and $H_{3}$.

This process repeats with the functional layer proposing to collocate $H_{1}$ and $H_{4}$. The security layer similarly asks to separate $H_{1}$ and $H_{4}$. Finally, $H_{1}$ is segregated from all other nodes. This produces a configuration where $H_{1}$ is the only child of $S_{1}$. Note that having $H_{2},H_{3}$ and $H_{4}$ under a single switch may hurt performance but the effect is less than blocking traffic to one of the nodes entirely. DocSDN can then output the candidate solution as high level SDN fragments (using a high-level language like Pyretic [26]).

Recovery Importantly, when the DDoS abates, DocSDN automatically reruns with a changed risk for $H_{1}$, outputting a binary tree.

Organization The rest of the work is organized as follows: Section II provides background on our application and discusses related work, Section III describes our framework and accompanying optimization models, Section IV describes our experimental setup, Section V evaluates the framework and finally Section VI concludes.

II Background and Related Work

Data Center Networks (DCN) host, process and analyze data in financial, entertainment, medical, government and military sectors. The services provided by DCNs must be reliable, accurate and timely. Services provided by DCNs (and the corresponding traffic) are heterogeneous. The network must adapt to changing priorities and requirements while protecting from emerging threats. They scale to thousands of servers linked through various interconnects. Protocols used for these services are split roughly 60 percent web (HTTP/HTPS) and 40 percent file storage (SMB/AFS) [27]. The interdependence of device configurations make modifying any single configuration difficult and possibly dangerous for network health. A seemingly simple update can cause significant collateral damage and unintended consequences.

Simultaneously, the network fabric is changing with the advent of Software Defined Networking (SDN) [28]. SDNs are flexible and programmable networks that can adapt to emergent functional or performance requirements. Openflow [29] is a common open source software stack. Researchers have proposed high-level languages and compilers [30, 31, 26, 32] that bridge the semantic gap between network administrators and the configuration languages used by SDN devices. These languages focus on compositional and parametric SDN software modules that execute specific micro-functions (e.g., packet forwarding, dropping, routing, etc.). The use of a high level language is prompted by a desire to be able to select, instantiate and compose SDN modules with guarantees.

Our framework is intended to be modular and allow integration of prior work on evaluating network configurations. As such there is a breadth of relevant work. Due to space constraints we focus on the most relevant works. In the conclusion we elaborate on the characteristics needed to integrate a prior assessment tool into our framework (see Section VI).

Measuring Network Risk Known threats against computer systems are maintained by governments and industry. Common Vulnerabilities and Exposures (CVE) is a publicly available dictionary including an identifier and description of known vulnerabilities [33], CVE does not provide a severity score or priority ranking for vulnerabilities. The US National Vulnerability Database (NVD) [34] is provided by the US National Institute of Standards and Technology (NIST). The NVD augments the CVE, adding severity scores and impact ratings for vulnerabilities in the CVE.

There are many mechanisms for measuring the security risk on a network [35, 36, 37, 38, 39]. Lippmann et al. present a network security model which computes risk based on a list of the most current threats [40]. This model implements a cycle of observe network state, compute risk, prioritize risk, and mitigate the risk.

This loop is often codified into an attack graph [3, 41, 42]. Attack graphs try to model the most likely paths that an attacker could use to penetrate a network. Attack Graphs often leverage one or more of the aforementioned vulnerability assessment tools as input, combined with a network topology and device software configurations to generate the graph. Current attack graph technologies provide recommendations to network administrators that effectively remove edges from the graph and trigger a re-evaluation of the utility for the attacker. To the best of our knowledge, current practice does not leverage network risk measurement into constraints used for the generation of new configurations.

Network Reachability The expansion of SDN has aided the applicability of formal verification to computer networks. Prior to SDN, the lack of clear separation between the data and control plain created an intractable problem when considering a network of any scale. Bounded model checking using SAT and SMT solvers [43, 44] can currently verify reachability properties in networks with several thousands of nodes.

Configuration Search Constraint Programming (CP) was introduced in the late 1980s [45] and is used for scheduling [46], routing, and configuration problems. Large-scale optimization problems are often decomposed including Benders [12] and Dantzig-Wolfe [16]. Soft constraints or Lagrangian relaxation are used for over-constrained problems or when the problem is too computationally expensive. Stochastic optimization techniques have been used for many applications in resilience [47, 48] and the underlying methodologies are a key part of this research. Prior work in configuration management with constraint programming [49, 50] focused on connectivity or security. We are not aware of any work that balances these two objectives in a meaningful way.

III Implementation

Figure 1 outlines the overall structure of the DocSDN framework. layer inter-connections as well as their internals. The functional layer uses a mathematical optimization model that is fed to a quadratic mixed Boolean programming (QBP) solver alongside an initial set of least-cost paths to be considered to service the required flows. The security layer receives the topology chosen by the functional layer and a security model to solve, with a mixed-integer programming (MIP) solver, the risk minimization problem. The output can result in low-risk flows being blocked as a consequence of deploying firewalls to mitigate high-risk flows. A result analysis module then produces a set of equivalence classes that is sent back to the functional layer to request the separation of specific flows that should not share paths, with the goal of minimizing the collateral damage to low-risk flows. These equivalence classes generate additional constraints, known as Bender’s cuts, that are added to the functional solver for a new iteration. The remainder of this section describes the major modules in Figure 1.

III-A Functional Layer

The mathematical optimization model in the functional layer is a quadratic mixed binary programming model. In constraint programming the four main components are Inputs, Variables, Constraints, and an Objective function. Inputs are below.

**Inputs

${\cal N}$** – the set of all network devices

${\cal E}$ – the set of edges (pair of vertices) connecting network devices

${\cal T}$ – the set of types of traffic to be routed

${\cal F}$ – the set of $(s,t,T)\in{\cal N}\times{\cal N}\times{\cal T}$ tuples defining desired traffic flows of type $T$ from source node $s$ to sink node $t$.

$D(f):{\cal F}\rightarrow\mathbb{R}$ – the actual demand for each flow $f\in{\cal F}$

${\cal C}\subseteq 2^{\cal N}$ – a subset of sets of network devices

${\cal R}\subseteq{\cal C}\times{\cal C}$ – pairs $(c_{1},c_{2})$ of equivalence classes that segregate traffic from $c_{1}$ to $c_{2}$.

${\cal P}$ – the set of all paths

$P(e):{\cal E}\rightarrow{\cal P}$ – the set of all paths containing edge $e$

$P(n):{\cal N}\rightarrow{\cal P}$ – the set of all paths containing node $n$

$P(c):{\cal C}\rightarrow{\cal P}$ – the set of all paths containing a node in $c$

$N(p):{\cal P}\rightarrow{\cal C}$ – the set of nodes appearing in path $p$

$P(s,t):{\cal N\times N}\rightarrow{\cal P}$ – the set of all paths $s\rightarrow t$

$cap(e):{\cal E}\rightarrow\mathbb{R}$ – gives the capacity of an edge $e$.

**Variables

$active_{p,T}\in\{0,1\}$**, – for every path $p\in{\cal P}$ and traffic type $T\in{\cal T}$, indicates whether path $p$ carries traffic of type $T$

$flow_{p,T}\in\mathbb{R}_{\geq 0}$ – for every path $p\in{\cal P}$ and traffic type $T\in{\cal T}$, amount of flow of type $T$ that is sent along path $p$

$equiv_{c,n}\in\{0,1\}$ – does node $n\in{\cal N}$ appear in an active path together with a node in equivalence class $c$

$share_{c_{1},c_{2},n}\in\{0,1\}$ – indicates whether node $n\in{\cal N}$ appears on any active path with nodes in classes $c_{1},c_{2}\in{\cal C}$. Namely,

[TABLE]

$active_{p,*}=1$ if there is a type $T\in{\cal T}$ where $active_{p,T}=1$

$load_{n}\in\mathbb{R}$ – the amount of flow that goes through node $n$

$loadObj$ – the sum of squares of all $load_{n}$ variables.

**Constraints

**

[TABLE]

[TABLE]

[TABLE]

[TABLE]

[TABLE]

[TABLE]

[TABLE]

Equation 1 enforces the edge capacity constraint to service the demand of all paths flowing through it. Equation 2 ensures that enough capacity is available to meet the demand of an $(s,t,T)$ flow. Equation 3 ensures that some non-zero capacity is used if a specific path is activated (conversely, an inactive path can only have a 0 flow). Equation 4 states that a single path should be chosen to service a given flow $f\in{\cal F}$. Equations 5 define the auxiliary variables $equiv_{c,n}$ as true if and only if node $n\in{\cal N}$ appears on an active path sharing a node with the equivalence class $c\in{\cal C}$. Equation 6 defines an active path that shares at least one node with two classes. Finally, equation 7 defines the load of a node as the sum of the flows associated to active paths passing through node $n$.

**Objective

**

[TABLE]

The objective function 8 in this model is a weighted sum of three terms. The first term captures the total flows which are penalized by the length of the path used to dispatch those flows (such policies are codified in OSFP [51] and BGP practice [52]). The second term gives a unit credit each time equivalence classes on the segregation list ${\cal R}$ do not share a node. (Due to this term, the objective value of the final solution may change between iterations of the functional layer.) The third and final term contribute to a bias towards solutions that achieve load balancing thanks to the quadratic component which heavily penalizes nodes with large loads.

Solving the Functional Model The functional model starts with empty sets ${\cal C}$ and ${\cal R}$ which are augmented with each iteration of the framework. New sets of nodes are added to ${\cal C}$ and new segregation rules are added to ${\cal R}$ (by the security layer). In the current implementation, least cost paths between pairs of nodes $s,t$ are not generated “on demand”. Instead, the generation is limited to the first best $k$ such paths, for increasing values of $k$. This process will ultimately be improved to use column generation techniques [16].

III-B Risk Calculation

After the functional layer finds an optimal solution, it passes this solution to the risk calculation procedure. This input is the set of active paths. This module calculates the effective risk to the network for each path and traffic type.

**Inputs

$risk(n,T):{\cal N}\times{\cal T}\rightarrow\mathbb{R}$** – the risk inherit to network device $n$ for traffic of type $T$ ($risk(n,T)\geq 1$)

$d_{k}(n):{\cal N}\rightarrow 2^{\cal N}$ – the set of nodes at a distance at most $k$ from $n$ in the logical topology

**Calculation

**Given an active path $p\in{\cal P}$ with source $s$ and sink $t$, the calculation proceeds by partitioning the set of nodes of the path into three segments: the nodes “close” to the source $s$, “close” to the sink $t$ and the nodes “in between”. Closeness is characterized by the function $d_{k}$ and is meant to capture any connected node over the logical topology which sits no more that $k$ hops away. Given this partition, $flowRisk(p,T)$ is:

[TABLE]

We use $k=2$ to model nodes on the same LAN. The rationale is to impart to source $s$ and sink $t$ risk resulting from lateral movement of attacks. All other nodes contribute to the overall path risk in proportion to the square of their own risks. We expect in most networks for $d_{2}(s)$ (and $d_{2}(t)$) to include nodes not directly on the path (like nodes on the same LAN). The input path risk calculation $flowRisk(p,T)$ is modular and can be augmented using other risk calculation methods.

III-C Security Layer

The mathematical optimization model in the security layer is a mixed integer programming model. We similarly present the inputs, variables, constraints, and objective for the security layer. Its inputs are given below. Also note that all the variables from the functional model are constants.

**Inputs

$mem(n):{\cal N}\rightarrow\mathbb{R}$** – the memory resources of SDN device $n$

$fwCost(T):{\cal T}\rightarrow\mathbb{R}$ – the memory footprint for a firewall blocking traffic type $T$

$piCost$ – the memory footprint for a packet inspection post

$fwComp$ – the complexity footprint for adding a firewall

$piComp$ – the complexity footprint for adding a packet inspection post to the network

$penalty(p,T):{\cal P}\times{\cal T}\rightarrow{\mathbb{R}}$ – the penalty for blocking a unit of flow of type $T$ along path $p$

$rank(n,p):{\cal N}\times{\cal P}\rightarrow{\mathbb{Z}}$ – the position of node $n$ in path $p$

$flowRisk(p,T):{\cal P}\times{\cal T}\rightarrow\mathbb{R}_{\geq 0}$ – above risk calculation

**Variables

$fw_{n,T}\in\{0,1\}$** – does a firewall block traffic type $T$ at $n$

$pi_{n}\in\{0,1\}$ – is there packet inspection at network device $n$

$fwOR_{n,T}\in\{0,1\}$ – is there a block everything or block traffic of type $T$ firewall at network device $n$

$fwOP_{p,T}\in\{0,1\}$ – is there a firewall on path $p$

$rf_{p,T}\in[0,1]$ – risk factor for path $p\in P(s,t)$ servicing flow $(s,t,T)\in{\cal F}$

$RMfw_{p,n,T}\in[0,1]$ – used in the riskFactor calculation

$RMpi_{p,n,T}\in[0,1]$ – used in the riskFactor calculation

**Constraints

**

[TABLE]

[TABLE]

[TABLE]

[TABLE]

[TABLE]

[TABLE]

Equation 9 is used to define the presence of a firewall that will block traffic of type $T$ at a node $n$. Equation 10 ensures that the memory footprint in SDN node $n$ for the deployment of the firewall and the packet inspection logic does not exceed the device memory. Equation 11 links the presence of a firewall that will block traffic of type $T$ on a path with the presence of a firewall that will block traffic of type $T$ on any node along the active path.

Equation 12 defines the minimum risk factor associated to a firewall. The earlier on the path the firewall is deployed, the lower the risk. Equation 13 similarly defines the minimal risk. Equation 14 defines the composite risk factor.

**Objective

**

[TABLE]

The objective function defined in equation 15 is a weighted sum of four distinct terms that focus on minimizing the network complexity based on security resources deployed, the load induced by inspection posts, the penalties incurred from dropping desirable flows due to firewall placement and finally the residual risk. This model is a classic mixed integer programming formulation.

III-D Result Analysis

The result analysis module tries to generate cuts for the functional layer with the goal of improving both functionality and security. To generate cuts, this module will form equivalence classes of network nodes and pass back certain pairs of these classes, one at a time, to the functional layer. Each pair of classes describes a segregation rule, or a cut, to which to functional layer will adhere to as much as possible.

After the functional and security layers are re-optimized using the most recent cut, the result analysis module determines whether the cut was beneficial or harmful based on the objectives of each layer. If the cut is deemed to have been beneficial, we permanently keep it as a constraint, repopulate the cut queue, and continue the process.

If the cut is deemed to have been harmful, it is removed from the functional layer’s constraint pool. Then the next cut in the queue will be passed back to the functional layer. If the cut queue is empty, the feedback mechanism terminates and we output the best solution found.

We note that since this process only provides pairs of nodes it is a heuristic, it may be necessary for many nodes to simultaneously be separated to arrive at a global optimum. This mechanism performed well in our experiments.

III-E Layer Coordination

It is valuable to review how the layers coordinate. The functional layer sends to the security layer a set of paths that implements the routing within the network to serve the specified flows while satisfying a set of segregation requirements. The security layer first computes risks for these paths (in polynomial time) based on its knowledge of the traffic. The paths, their risk and the security model are then tasked with deploying packet inspection apparatus as well as firewalls within that logical topology to monitor the traffic and block threats (risky traffic). Once the security model is solved to optimality, an analysis can determine whether the proposed logical topology is beneficial or not (w.r.t. its objective) and even suggest further equivalence classes for network nodes as well as segregation rules to be sent back to the functional layer for another iteration. Fundamentally, the coordination signal boils down to additional equivalence classes to group nodes together with segregation rules to separate paths that include network nodes in “antagonistic” equivalence classes.

III-F Outputs

When the set of potential cuts is empty, the proposed configuration can be parsed and translated into SDN language fragments to be deployed on the network devices in order to obtain the desired logical network topology put forth by our framework.

IV Experimental Setup

A fundamental component of our work is the separation of the physical and logical networks. Our framework has potential in applications where many different logical topologies are possible from a single physical topology. Physical topology is an input to our framework and the empirical evaluation is based on a popular topology: Fat-Tree [53].

The instance of Fat-Tree we use is shown in Figure 3. The updated design avoids bottlenecks through multiple equal capacity links between layers. This design uses four layers of switches: gateway, core, aggregate and edge with hosts connected at the bottom.

Within our sample network, we consider having two main types of devices: switches/routers and hosts. In order to model traffic between internal and external entities we utilize two gateway switches which represent the boundary of our network. For generality we consider two traffic types A and B which could represent any types of traffic such as web and storage. We also classify traffic as internal and external, with external traffic traversing one of the gateways. We allow only half of our hosts to communicate with external sources by allowing them to connect to one of the two gateways. Further, all hosts are involved in internal communications. In our network we have 16 hosts and we generated 60 flows, 44 of them being internal and 16 being external.

Additionally, our setup simulates an emergent vulnerability/active attack. We select two hosts that are highly vulnerable to, or being targeted on, a specific type of traffic, resulting in a significant increase in their risk for the corresponding type of traffic. In particular, this could represent at DDoS attack on these two hosts.

We run multiple experiments providing the framework increasing numbers of starting paths between source and destination (from the priming procedure) to determine the impact on the solution quality.

Our implementation was built in Python 3.6 using the Gurobi 8.1 optimization library [54]. The experiments were run on a machine running Ubuntu 18.04 and equipped with an Intel Core i9-8950HK processor operating at 2.90 GHz with a 12 MB Cache and 32 GB of physical memory.

V Evaluation/Results

We begin with the model’s resolution on the above scenario using the 10 shortest paths per source and destination pair to prime the optimization. We assume equal demand for each of the 60 flows and two high risk hosts (in red in Figure 4). In the first iteration, the functional layer of the framework generates a candidate topology and passes this solution to the security layer. The security layer then calculates the network risk and deploys firewalls (represented with rectangles).

In the first iteration, the gateway on the right serves both low risk (shown in green) and high risk hosts (shown in red). Deploying a firewall on this gateway significantly reduces the network risk and is the output of the security layer. Importantly, this results in collateral damage as flows to low risk hosts are blocked. In total, the first iteration through the framework deploys 3 firewalls which block 12 flows, 8 of which are high risk.

Iteratively, the security layer proposes separation of these collateral nodes from the high-risk nodes. The solution of the last framework iteration (493 candidates cuts are proposed, 40 prove beneficial) is shown on the right. This configuration routes all high risk flows through one core switch where a firewall is now deployed. Meanwhile, all the low risk flows access the gateways through a separate core switch.