SDNShield: Reconciliating Configurable Application

Permissions for SDN App Markets

Xitao Wen⋆, Bo Yang§, Yan Chen⋆, Chengchen Hu‡, Yi Wang⋄, Bin Liu†, Xiaolin Chen◦

⋆Northwestern University, §Zhejiang University, ‡Xi’an Jiaotong University,⋄Huawei Future Network Theory Lab, Hong Kong, †Tsinghua University, ◦Chuxiong Normal University

Abstract—The OpenFlow paradigm embraces third-partydevelopment efforts, and therefore suffers from potential attacksthat usurp the excessive privileges of control plane applications(apps). Such privilege abuse could lead to various attacksimpacting the entire administrative domain. In this paper, wepresent SDNShield, a permission control system that helpsnetwork administrators to express and enforce only the minimumrequired privileges to individual controller apps. SDNShieldachieves this goal through (i) fine-grained SDN permissionabstractions that allow accurate representation of app behaviorboundary, (ii) automatic security policy reconciliation thatincorporates security policies specified by administrators into therequested app permissions, and (iii) a lightweight thread-basedcontroller architecture for controller/app isolation and reliablepermission enforcement. Through prototype implementation,we verify its effectiveness against proof-of-concept attacks.Performance evaluation shows that SDNShield introducesnegligible runtime overhead.

I. INTRODUCTION

The control plane is one of the most critical yet vulnerablepart of a network. Traditionally people have to put absolutetrust in the reliability of the control software, which from timeto time allows attackers to exploit network devices [1], [2], [3],[4]. Today, with software-defined networks (SDN), the controlsoftware becomes even more vulnerable. The mainstream SDNplatforms [5], [6] foster open and prosperous markets forcontrol-plane software [7], who provide a great range of appsfor network management. However, obtained from varioussources, the apps come with different quality guarantees andthus may contain flaws, vulnerabilities and even maliciouslogic. As a result, the security concern is ranked the top issuethat prevent enterprise and data center networks from adoptingSDN [8].

A natural solution to the over-privilege problem is accesscontrol. Typically, cryptographic authentication is employedby state-of-the-art SDN security solution in order to preventunauthorized accesses. In addition to authentication, someaccess control enforcement mechanisms based on Android-likepermissions [9], [10], [11], [12], [13] are proposed. However,although these mechanisms broadly extend the policyenforcement frontier, it remains challenging both to specifyappropriate permissions and to enforce permissions gracefully.Furthermore, most current SDN controllers implement amonolithic architecture that allows app code directly executedin the controller runtime. Although efficient, such architectureprovides merely no security isolation between controller andapps. Rosemary [10] explores to isolate apps with OS processcontainment. However, it still remains unexplored how to

NetworkAdmin

SecurityMediation

Layer Con

trol

lerApp

App

App Developers

ConfSecurity

Configurations

Fig. 1: Existing SDN access control systems.

enable the app developers and the administrators to cooperateon composing secure permission policies.

Therefore, we envision the next generation SDN permissionsystem with a fine-grained policy structure, a genericreconciliation model and a secure while efficient isolationarchitecture, as described in the three key features below.

1) App developers can express fine-grained permissionrequests. API-grained permissions are inadequate tospecify minimum privileges for SDN apps. We need aflexible set of permission abstractions that allow fine-grained representation of app behavior boundary.

2) Administrators can easily refine app permissions withhigher-level security policies. Fine-grained permissionsbring the challenge in permission management. To reducemanagement burden, we need a reconciliation process thatrefines and customizes the requested app permissions withthe security policies specified by the administrators.

3) The controller needs a secure while efficient isolationarchitecture to enforce permissions. Instead of amonolithic controller, we need to enforce isolationbetween controller and apps to ensure reliable permissionenforcement and robustness. Such an isolation architectureshould provide security properties while being compatiblewith existing apps and imposing minimal runtime overhead.

We present SDNShield, the first permission controlsystem for SDN apps that achieves all the above features.An overview of the SDNShield architecture is shown inFigure 2. The key challenges are as follows. The behaviorspace of controller apps has inherent complicated permissionstructure and thus 1) clean permission abstractions areneeded to capture such complexity. 2) Policy reconciliationneeds language support, for which the permission languageand security policy language need to be co-designed. 3)Enforcement overhead has to be minimal, since permissionenforcement is on the critical path of the control plane.

We made the following contributions.

• We design fine-grained permission abstractions as adomain-specific language (§IV). The abstractions featurea two-level structure: the coarse-grained permission token

App Developers

App

PermissionManifest

SDNShieldReconciliation

Engine

NetworkAdmin

Per-category or Global Security

Policies

ApplicationBinary

PM

SC

SDNShieldPermission

Engine

Ope

ratin

g Sy

stem

App

App

App

PM

Pre-runtime

Runtime

Con

trol

ler

Fig. 2: SDNShield overview.

and the fine-grained permission filter. Such structure allowthe flexible expression of permissions with structuredparameters, such as abstract topology, while hides thecomplexity of the controller specifics.

• We propose the architecture to conduct reconciliation onrequested permissions and security policies (§V). We definepermission boundary and mutual exclusion as two basicforms of security policies, which characterize a variety ofsecurity goals.

• We design a novel controller isolation architecture thatfeatures a thread-based lightweight isolation between con-troller and apps (§VI). We choose to isolate app executionswith Java threads by leveraging and extending Java build-insecurity sandbox, which provides comprehensive referencemonitoring, incurs negligible overhead and requires nomodification on legacy apps.

We implement a controller-independent prototype ofSDNShield as a standalone permission engine and a Java-based controller isolation framework. With some controllerspecific extensions, we demonstrate its effectiveness withOpenDaylight controller platform [5], one of the most popularSDN controller platforms, as well as Floodlight OpenFlowcontroller [14].

We present two use case scenarios in §VII, describeour prototype in §VIII and evaluation in §IX. The resultsdemonstrate that SDNShield introduces negligible latencyoverhead and imposes minimal impact on throughput of thecontroller runtime.

Although our implementation currently works with Java-based SDN controllers, the design of SDNShield universallyapplies to other SDN controller platforms. Furthermore,we also show that, with some extensions, SDNShield canbe adapted to the emerging controllers that provide richnorthbound interfaces (§VI-C).

The design of SDNShield is inspired by the large body ofstudies and practices of general access control systems (§X),especially on mobile OS and web browsers whose environmentresembles that on a SDN controller. However, the uniquedesign constraints in SDN environment, such as the resourcestructure, the threat models and the permission management

challenges, lead us to the design choices and the technicalcontributions of SDNShield.

II. THREAT MODEL

The novel threats on SDN apps stem from the fundamentalchallenge of verifying the trustworthiness of a programmodule [15]. Because apps directly interact with criticalresources, people expect apps to have a high level of securityas the controller. However, although the mainstream controllerplatforms are usually well verified, the quality and goodwillof all apps in the market are very challenging to guaranteewith the state-of-the-art program analysis techniques, thus theexistence of vulnerabilities and exploits is generally inevitable.Generally, either buggy or malicious apps can expose thecontroller platform to exploits. A number of traditional attackpatterns, such as web-based attacks to the managementinterface or host-based attacks on the app host machine, canpotentially give attackers the arbitrary code execution capacityon behalf of the app.

As long as an app is compromised, the attacker will haveunfettered control of the controller, the OF switches in thenetwork domain as well as the resources provided by the hostoperating system. Thus, the attacker can launch a full range ofpotential attacks. Among them, we are particularly interestedin the following four classes of attacks as shown in Figure 3,for which existing SDN security approaches do not delivergood protection.

Class 1: Intrusion to data plane: With the capacityof packet-in/packet-out messages, the compromised app cansniff/inject arbitrary data-plane packets in realtime, whichenables attackers to directly manipulate the traffic.

Class 2: Leakage of sensitive information: Acompromised app can leak out obtained information via hostnetwork or other side channels on the host machine where thecontroller resides. This loophole breaches the confidentialityof the network configuration and traffic statistics, and canenable more advanced attacks by allowing attackers to conductanalysis on the flow tables, the control software and the modelsof OF switches.

Class 3: Manipulation of rules: A compromisedapp can manipulate forwarding behavior stealthily with theunfettered capacity to modify OF rules, resulting in variousactive network attacks, such as the man-in-the-middle attackand blackhole attack. Such capacity can be combined withnetwork-based attacks to generate more advanced exploits.

Class 4: Attacking other apps: A compromisedapp can deactivate other apps, especially security apps, byoverriding or bypassing their rules. Attackers can bypassthe ACL rules set by a security app through dynamic-flowtunneling [16], which evades existing security policies byestablishing a tunnel and modifying the packet header at bothends of the tunnel.

Table I compares the attack protection coverage of existingSDN security approaches and SDNShield. Among them, trafficisolation prevents the attacks launched from one networkslice to attack another slice, but delivers no security to appsdeployed on one network slice that collaboratively processthe same set of traffic. Network state analysis, on the otherhand, can detect global invariant violations (e.g., forwardingblack-hole) in forwarding rules, but is unable to detect the

Compromized App User App User App

SDN Controller

Switch

Switch

Switch Switch

Alice

BobInternet

Attacker

Compromised Host

Class 2: Information Leakage

Class 1: Direct Intrusion

Class 4: Attack Between Apps

Class 3: Manipulation of OF Rules

Fig. 3: Attack classes.

Class 1 Class 2 Class 3 Class 4

Traffic isolation CT CT CT CT

NW state analysis ✗ ✗ ✓ ✓

SDNShield ✓ ✓ ✓ ✓

TABLE I: Comparison of protection delivered by SDN securityapproaches. CT: only protect against attacks across tenants.

other malicious behavior, such as traffic sniffing/injection andinformation leakage.

In comparison, with proper permission settings, SDNShielddelivers good protection on all the four attack classes bypreventing apps from conducting security sensitive actions itis not authorized to.

III. SDNSHIELD OVERVIEW

SDNShield is a general SDN permission system forboth app developers and the administrators that allowseasy policy composition for the administrators and reliablepolicy enforcement on apps. We propose a configurablepermission and reconciliation system that allows administratorsto configure the app requested permissions with parametersand make it possible to write apps that gracefully reactto the denied permissions. As depicted in Figure 2, theprocess works as follows. 1) The app developer distributes apprelease together with the permission manifest representing thepotentially needed permissions. 2) Before app deployment, theadministrator configures and customizes the app permissionswith the local security policies, which contains parameters andconstraints to the app permissions. 3) The reconciliation enginethen reconciles the permission manifests with the securitypolicies, and produces the final parameterized permissions tobe enforced. 4) When the app is running, the permission enginemediates API calls and enforces the permissions. Utilities areprovided for app developers to check for permissions andhandle the permission denials before making an API call thatrequires permissions. 1

SDNShield contains two major components, the permissionengine and reconciliation engine.

Permission engine. SDNShield permission engine com-piles and enforces the permission policies written in SDNShieldpermission language. When the app is loaded, the permissionengine compiles the permission manifest into the runtime

1From the lesson of Android market, the app may crash or not function inthe desired manner if the developer doesn’t proactively handle the cases thatrequested permissions are denied.

checking code that is associated with every API call issuedfrom the app. During the lifetime of the app, the permissionengine keeps mediating all the API calls, making sure thepermission policies are consistently enforced.

In practice, the permission manifests provided by the appdevelopers are distributed along with app release packages,since the app developers have the most complete knowledgeof the apps. A permission manifest can be automaticallygenerated from app source code with static/dynamic analysistools employing the techniques similar to Android permissionanalysis [17], [18], [19]. Then, the developers can refine thepermission manifest to specify optional permission switchesfor specific functionalities, so that no redundant permissionsare requested if optional functionalities are disabled.

Reconciliation engine. SDNShield allows the administra-tors to configure app permissions via security policy. The secu-rity policy is represented with the domain-specific SDNShieldsecurity policy language, which provides abstractions for avariety of security constraints.

In practice, the administrators first describe their localsecurity policies in the security policy language, and feedthe policies to the reconciliation engine. The reconciliationengine then verifies the security policies by looking atthe input permission manifest. Once a policy violation isdetected, the reconciliation engine alerts the administrator andprovides possible alternative permissions for administrator’sconsideration. The alternative permissions are generated bytruncating the offending permissions or refining permissionswith environment variables.

The composition of the local security policies is guidedby potential threats. For example, to defend against Class 1attacks, SDNShield only needs to specify a security constraintto prevent an app to have both the packet-in/-out permissionand the access to host network of the controller. This preventsthe app from both the traffic sniffing/injection capacity andthe ability to communicate with a remote attacker via hostnetwork. In real deployment, those security policies for specificthreats can be distributed as templates, so as to lower the hurdleto have basic protection. For advanced protection, a GUI willbe provided to facilitate the policy customization/compositionprocess. In fact, such administration process is proveneffective with the prevalence of the similar administrationsystem for Enterprise Mobility Management (EMM), such asAirWatch [20] and Citrix XenMobile [21].

IV. PERMISSION ABSTRACTIONS

The heart of SDNShield is a domain specific permissionlanguage that defines the boundary of app behaviors.

Existing SDN permission systems typically model apppermissions at the granularity of the APIs provided bythe controller platform. For example, SE-Floodlight [11]can control whether an app can insert/modify a rule withFLOW MOD permission. However, such API-level permissionsare often too coarse-grained to specify a usable app permission.For example, it cannot make decisions based on the parametersof the API calls such as the switches, the subnet or the ruleactions.

SDNShield enables fine-grained parameterized permissiongranting by introducing a two-level permission abstraction

Resource Permission Token Notes

Flow table read flow tableinsert flow Including insert and modify.delete flowflow event Get callback notification.

Topology visible topology Specify partial or virtualtopology.

modify topology Change controller’s viewof physical topology.

topology event

Statistics read statistics& Errors error event

Pkt-in read payload Payload in pkt-in msg.& Pkt-out send pkt out

pkt in event

Host host network Network access outsidesystem control channel.

file systemprocess runtime Shell access, etc.

TABLE II: A subset of SDNShield permission tokens.

comprised of coarse-grained permission tokens and fine-grained permission filters.

A. Permission Token

Permission tokens are the coarse-grained app behaviorprivileges that can be either approved or denied for an app.We divide the set of SDN specific permission tokens alongtwo dimensions, namely SDN resources and app actions.The SDN resources we consider range from network states,controller states to low-level control messages. For eachresource, the app’s potential actions include read, writeand event notification. The permission tokens are designedorthogonal with each other, so that there is no inter-permissiondependency. Other than interacting with SDN APIs, apps mayalso need to interact with the host machine OS via systemcalls. We design permission tokens to limit the system calls,which may expose apps to unnecessary attack surface. Table IIshows a subset of our permission set.

B. Permission Filter

Permission tokens can only be granted in an all-or-nonemanner. In order to specify permissions in a finer-grainedway, we introduce the permission filter, which is associatedwith a permission token to restrict its effective scope. Forexample, the app’s read flow table permission can berestricted to a specific port number when associated with aflow predicate filter as the parameter:

PERM read_flow_table LIMITING TCP_DST 80

Semantically, a permission token can be viewed as a booleanswitch of a set of static APIs; while a filter is a booleanfunction of a runtime API call (along with all the argumentsand the runtime context). We use the term attribute to referto any of the runtime arguments or context of an API call.A filter splits the space of API calls into two subspaces bylabeling each API call with ALLOW or DENY. In this way, afilter helps establish a middle state of a permission token byallowing a subset of API calls to pass through.

Next, we present the syntax and semantics of permissionfilters in detail.

a) Singleton Filter: Singleton filters are the buildingblock of filter expressions. A singleton filter labels an APIcall according to a specific attribute of the API call. Differentsingleton filters inspect different attributes, and thus areindependent of each other. Normally, an individual singletonfilter is only effective to modify a subset of permissions thatcontain the specific attributes it inspects. SDNShield defines anumber of singleton filters on several attributes as follows.

Flow filter. Flow filters act on flow-specific argumentsof an API call. Thus, they can be associated with thepermissions managing flow table resources. Based on theinspected attributes, flow filters include predicate filter, actionfilter, ownership filter, etc. As an example of flow filters,predicate filter compares the flow predicate in an API call withthe value or the value range specified in the filter parameters,and only allows API calls with narrower predicates to passthrough. A value range can be presented using a bit-wise mask:

PERM read_flow_table LIMITING \

IP_DST 10.13.0.0 MASK 255.255.0.0

this permission allows the app to see the flow entries targetingat the subnet 10.13.0.0/16. To provide more flexibility,SDNShield offers wildcard filter, which inspects the wildcardbits rather than the matched bits. When associated withinsert flow or delete flow permission token, itforces the apps to set specific wildcard bits in their rules. Forexample, a load-balancing app that shuffles flows according tothe lower 8 bits of IP dst should have the permission:

PERM insert_flow LIMITING \

WILDCARD IP_DST 255.255.255.0

This permission specifies that the upper 24 bits wildcard ofIP dst of any issued rules must always be set, i.e., the appcan only identify flows using the lower 8 bits that are notwildcarded.

In addition, action filter inspects flow actions. Ownershipfilter inspects and keeps track of the issuers of all the existingflows. Priority filter limits the maximum/minimum priorityvalue set in rules. Table size filter limits the maximum numberof rules an app can put into a switch. Packet out filter canprevent apps from issuing packet-out with an arbitrary content.In sum, flow filters are useful to restrict apps’ visibility ormanipulability of flow table entries.

Topology filters. Topology filters help administrators tocreate abstract topology for apps. Topology filters allow twotype of abstract topology. Physical topology filter helps toexpose a subset of physical switches and links to an app.Virtual topology filter helps create the illusion of big switches,each of which is comprised of multiple physical switches:

PERM visible_topology LIMITING \

VIRTUAL SINGLE_BIG_SWITCH LINK EXTERNAL_LINKS

The above permission allows the app to see the topology asa single big switch by translating the topology information inthe API request/response on the fly.

In addition to flow filters and topology filters, SDNShieldalso support a number of other filters. event callback filtersinspect how an app interacts with an event notification.Statistics filter helps to restrict an app’s visible statistics.

b) Filter Composition: While singleton filters areflexible in constraining a single attribute, the administra-tors may need to express complicated permissions withmultiple attributes. For example, one might want to grantread flow table permission to an app, but onlyrestricting to the flows previously issued by the app or theflows affecting the subnet 10.13.0.0/16.

SDNShield fulfills this demand through filter composition.SDNShield supports the composition of singleton filterswith logical operators including conjunction, disjunction andnegation. Intuitively, the conjunction (disjunction) of twofilters labels an API call true if and only if both operands(either operand) label(s) it true; while the negation of a filteralways outputs the opposite label produced by the operand.The composition of filters enables SDNShield to describe thepermissions with complicated logical conditions. Consider theabove example, which could be expressed as

PERM read_flow_table LIMITING OWN_FLOWS OR \

IP_SRC 10.13.0.0 MASK 255.255.0.0 OR \

IP_DST 10.13.0.0 MASK 255.255.0.0

SDNShield permission language syntax is in Appendix A.

V. SECURITY POLICY RECONCILIATION

A. Security Policy Language

SDNShield security policy language provides abstractionsfor two types of constraints: mutual exclusion and permissionboundary. To specify security policies, the administratorwrites constraint statements that are comprised of mutualexclusion expressions and permission boundary assertions. Forexample, an enterprise network may wish to prevent a singleapp from possessing two mutually exclusive permissions:insert flow and network access. A second exampleis to bound the permissions from a tenant to a partial topologyand/or a flow space.

In practice, a constraint statement, which describesa certain security property, is associated with a set ofapps. The constraint enforcement engine evaluates theconstraint expressions against the permissions of the associatedapps, determining whether the permissions fully satisfy theconstraints or not. The output includes a pass/fail labeltogether with a message pointing out any constraint-violatedpermissions. After a constraint is set up on a set of apps,the constraint enforcement engine keeps track of permissionupdates and ensures the constraint expressions are satisfiedpersistently.

Mutual Exclusion: Mutual exclusion expressionsspecify a pair of permissions that should never be possessed byone single app. Mutual exclusion is often required to describeglobal security properties based on specific attack patterns. Forexample, a combination of network access permissionand send packet out permission could potentially en-able the injection of arbitrary data-plane packets from a remoteattacker. To prevent such combination, we can set them as amutual exclusion:

ASSERT EITHER { PERM network_access } \

OR { PERM send_packet_out }

Semantically, this constraint prevents the two permissions frombeing possessed by a single app.

Permission Boundary: Permission boundary is apowerful tool to enforce static permission boundary anddynamic relations between multiple permission manifests.Permission boundary is implemented by checking logicalassertions. In a logical assertion, permission expressionsare computed and compared like sets using intersection,union, complement operations and inclusion relation. Thesemantics of the operations are naturally defined based on theallowed app behaviors. SDNShield supports set operations onpermission expressions: intersection, union and complement.The semantics of the operations are defined similarly withthe corresponding filter operations, namely conjunction anddisjunction.

The basic building block of a logical assertion is thepermission comparison expression. Thanks to the property ofcomparability of permissions, SDNShield offers two compari-son operations between permission expressions: inclusion andequality. They can be used to express permission boundary.For example, we can specify the permission boundary for allmonitoring apps to be no more than reading topology, readingport-level statistics and communicating with data collectingservers at 192.168.0.0/16:

LET templatePerm = {

PERM read_topology

PERM read_statistics LIMITING PORT_LEVEL

PERM network_access LIMITING \

IP_DST 192.168.0.0 MASK 255.255.0.0

}

ASSERT monitorAppPerm <= templatePerm

where the less than or equal to sign (<=) specifies thepermission boundary, which defines the super set of the appbehavior this app can possess.

Permission Customization: SDNShield allows twoways to customize the requested permissions. First, the appdeveloper can leave permission filter stubs for customizationpurpose, e.g., a stub macro named “administrative IP range”.The administrator just need to redefine the macro to the actualvalue in the local environment. Second, the administratorcan also restrict a specific permission by directly appendingpermission filters. For example, a cloud operator can restrictthe operating topology of a tenant app by appending virtualtopology filter to the requested permissions.

SDNShield security policy language syntax is in Ap-pendix B.

B. Reconciliation Mechanism

To enforce the security policies, SDNShield needs amechanism to evaluate the security policy expressions onconcrete permission manifest, and modify the permissionmanifest in case of policy violations. In this subsection, wedetail the reconciliation mechanism.

1) Permission Comparison: The evaluation of permissionpolicies fundamentally depends on the comparison of thepermission expressions. Abstractly, a permission expressioncan be viewed as a set of the allowed app behaviors.Since high-level permissions are orthogonal, the questionon permission expressions can be converted to the samequestion on the filters associated with the same permissionof the operands. For example, an insert flow permission on a

192.168.0.0/16 IP dst filter includes the same permission ona 192.168.1.0/24 IP dst filter, due to the inclusion relation ofthe filters.

It is trivial to determine the relation of two singleton filters.In the presence of complex filters, however, things become abit complicated.

Algorithm 1. The inclusion relation of a pair of filters can bedetermined algorithmically.

Without loss of generality, we assume we want todetermine if Filter A includes Filter B. The algorithm is asfollows:

Step 1: We first convert A to CNF, denoted as (a∧ b∧ ...),and convert B to DNF, denoted as (x∨y∨ ...). In this way, thequestion is converted to determine whether every disjunctiveclause (a, b...) in A includes every conjunctive clause in B(x, y...).

Step 2: We then scan over all possible pairs the disjunctiveclauses in A and the conjunctive clauses in B. We denote oneof the pairs as a = a1∨a2∨ ..., x = x1∧x2∧ .... Consider thefact that filters on different dimensions are independent, hencecannot include each other. Thus, we know a singleton filter canonly include another singleton filter on the same dimension ofattribute. We match the singleton filters on the same dimensionin a and x, and conduct singleton filter comparison. Therefore,we have a includes x if there exists ai ⊃ xj , otherwise a andx are independent.

2) Security Policy Reconciliation: SDNShield reconcilesthe permission boundary violation by conducting a conceptualintersection between the permission manifest and the permis-sion boundary. Due to the set nature of permission expressions,we can naturally define set operations, including intersection,union and complement, on permission expressions. Permissionoperations are generalization of filter composition, and canbe implemented using filter composition operations. Similarly,mutual exclusion violations are handled by truncating oneof the exclusive permissions. And permission customizationis implemented via a preprocessor that replaces stub macroswith the administrator-supplied local permission settings.It is worths noting that by default SDNShield alertsadministrators of any security policy violations, and thereconciled permissions are then offered for administrators’consideration.

VI. PERMISSION ENFORCEMENT

A. Controller Isolation Architecture

In SDNShield, the existence of multiple principals withdifferent privileges in a controller entails the demand forreference monitoring. Specifically, two types of actions, i.e.,the controller API access and the system calls to the host OS,should be reference monitored. Semantically, any referencemonitoring paradigm that offers complete access controlover both types of actions would suffice. While regardingperformance, we want to minimize the latency and throughputdegradation to the controller processing.

We compare the pros and cons of a number ofreference monitoring paradigms in Table III. Among thecandidates, isolating apps OS process container brings

Ctrl System Runtime Impl’nAPI Access Overhead Complexity

OS Process ✓ ✗ Median Low

HW Virt’n ✓ ✓ High Medium

PL Sandbox ✓ ✓ Low Median

TABLE III: Comparison of reference monitoring approaches.SDNShield opts for PL sandbox.

large context switching overhead to gain complete memoryspace isolation. Moreover, sandboxing OS process requiresadditional mechanism to mediate the interaction between a OSprocess and the OS kernel. Similarly, hardware virtualization(e.g., KVM) or OS-level virtualization (e.g., LXC) introduceseven greater overhead to reference monitor the apps running asguest OSes or containers, since the communications betweenapp and controller need to traverse OS kernel or even networksocket. Compared with the above paradigms, programming-language-level sandbox (e.g., Java VM and Python interpreter)provides a lightweight approach to offer necessary referencemonitoring capacity.

We design a general controller isolation architectureand embody it based on Java security model, as depictedin Figure 4. We propose to use sandboxed thread (e.g.,Java thread) as the basic unit for sandboxing and privilegeenforcement. In general, the app code runs in unprivilegedthreads and the trusted controller kernel runs in privilegedthreads. The thread container provides the following securityproperties:

• Control flow isolation. Threads isolation guarantees thata single thread isolation executes either trusted controllercode or untrusted app code. The reference monitor (e.g.,the customized Java SecurityManager) ensures that the appcode cannot convert an unprivileged thread into a privilegedone.

• Data isolation. Since the app/controller communicationis now through only limited communication channels,it is easier to prevent apps from getting references tocontroller kernel object, therefore preventing apps’ accessor modification to controller states.

• System call mediation. Security sensitive system calls fromapps are now mediated by the reference monitor (e.g.,Java SecurityManager), thus can be restricted by securitypolicies.

In SDNShield’s isolation architecture, both the controllerthreads and the app threads run on top of the sandbox shimlayer (i.e., a Java VM). The Kernel Service Deputy (KSD) islocated within the controller kernel acting as a choke point ofall the communications between the controller kernel and theapp threads. Another communication choke point is the accesscontrol point (i.e., the customized Java SecurityManager)located within the shim layer, which mediates system callsto the host OS. Note, the choke points do not mean serializedpoints. Actually, SDNShield’s isolation architecture is highlyscalable regarding the number of apps by exploiting thread-level parallelization. Multiple instances of KSDs can run inparallel to offload the API requests from apps.

B. Permission Engine

Every API call issued by apps is eventually checked by thepermission engine (PE). Generally, the PE reads the permission

Unprivileged Threads

UserAPP

UserAPP

KernelModule

API

KernelModule

API

Controller Kernel

KernelModules

APIQueue of Controller API calls Kernel

ServiceDeputy

PermEngine

DataSource

Policy

PermissionRetriever

API

Dispatcher

Java VMOperating System

Queues ofEvent Notifications

AppThread

AppThread

SecurityManager

System Calls

Untrusted Code SDNShield Library Code Controller Code

Fig. 4: SDNShield sandbox architecture.

manifest and compiles to the checking code to be executedat the reference monitor. We highlight two techniques ofSDNShield in implementing the PE.

1) Evaluation of Abstract Filters: The first challenge isthe semantic gap between the OF messages and the filterabstractions, esp., the abstract topology filters. Controllerstypically do not support abstract topology in their APIs. Asa result, the reference monitor has to interpret the networkview in realtime by overwriting the API calls and responses.

To fill the semantic gap, SDNShield actively maintainsthe topology mapping between the abstract topology and thephysical topology, as well as the flow tables and the statistics ofthe virtual switches. When a flow rule is added to a virtual bigswitch, SDNShield find the corresponding physical switchesand translate the flow rule to several physical rules that alongthe shortest path in the underlying physical topology. Statisticrequests are handled similarly by querying multiple physicalswitches and aggregating the results.

2) Transactional API calls: Consider the scenario thatmultiple rules are to be installed, while one of them violates thepermission. Conducting permission checking one by one mayresult in problematic intermediate state. SDNShield introducesAPI call transaction, which allows an app to group multiplesemantically related API calls into a transaction and issueatomically. An API call transaction will only be executed ifall the individual calls pass permission checking. In case ofpermission violation, the entire transaction will roll back andthe app will be notified of the reasons for the failed API call.

C. Accommodating High-level SDN Languages

Today, the controller design increasingly moves towardsrich northbound interfaces with higher-level abstractions andnew programming paradigms. Hence, it is interesting toexplore how the design of SDNShield can be adapted andapplied to future SDN paradigms.

Novel Programming Paradigms: One of the majortrends in SDN’s northbound API is to provide app developersnovel programming paradigms, such as the functional reactiveprogramming [22], [23] and decision tree [24]. Theseprogramming paradigms typically expose SDN functionalitiesthrough explicit APIs, such as switch commands in Nettle [22]and rule insertion/invalidation in Maple [24]. SDNShield can

leverage these explicit APIs to enforce access controls overthe SDN specific resources; while system resources can stillbe enforced through programming-language-level sandbox.

Declarative Policy Languages: The other trend is toprovide new abstractions of network resources through domainspecific policy languages, such as Frenetic [25], Pyretic [26]and NetKAT [27]. Although the policy languages may containnovel abstractions, they are ultimately compiled to low-levelOpenFlow instructions, where SDNShield access control canbe enforced.

One of the challenges in enforcing SDNShield permissionlanguage is the difficulty to determine which app actuallyissues the OpenFlow instruction. In fact, the source appof an OpenFlow instruction can become ambiguous duringcompilation.

This challenge can be addressed by extending the compilerof the policy language and the ownership model of SDNShield.On the compiler side, we simply ask it to track the ownershipinformation at a finer granularity during the policy compositionprocess, and expose the information to SDNShield. OnceSDNShield obtains the ownership information, it can splitthe rule and feed them to the permission engine respectively.Furthermore, we can extend SDNShield to allow an API accessto be partially denied when some of the owner apps lack certainpermissions. We leave the systematic solution as our futurework.

VII. APPLICATION OF SDNSHIELD

In this section, we illustrate how SDNShield together withproper permissions prevents or mitigates the control-planeattacks with two hypothetical cases.

Scenario 1: Vulnerable Monitoring App: Considera monitoring app deployed to supervise network usage ofa tenant in a multi-tenant network. The app allows webconnection from the administrator for management purpose.Further, we assume the app bears a vulnerability that allowsarbitrary code execution.

The app release contains the following permissionmanifest:

PERM visible_topology LIMITING LocalTopo

PERM read_statistics

PERM network_access LIMITING AdminRange

PERM insert_flow

where two stubs, LocalTopo and AdminRange, are left foradministrator to complete. The administrator supplies thesecurity policy and local configurations as follows:

LET LocalTopo = {SWITCH 0,1... LINK 3,4...}

LET AdminRange = {IP_DST 10.1.0.0 \

MASK 255.255.0.0}

...

ASSERT EITHER { PERM network_access } \

OR { PERM insert_flow }

Next, the reconciliation engine extends the stub macros andverifies security policies. Then, it finds the mutual exclusionviolation and reconciles by truncating the insert flow

permission. Finally, it generates the final permissions:

PERM visible_topology LIMITING \

SWITCH 0,1... LINK 3,4...

PERM read_statistics

PERM network_access LIMITING \

IP_DST 10.1.0.0 MASK 255.255.0.0

With this permission manifest, SDNShield can effectivelymitigate the control plane attacks. The attacks through webinterface will be blocked at the very first step by checking thesource IP address. Even if the attacker launches the attack froman administrator’s IP address, all the active attacks will still beblocked when the attacker tries to add rules or inject packetsinto the network. In fact, two of the four attack classes (Class 1and 3) are completely prevented, since the monitoring app doesnot have the basic permissions to modify the network states.Class 4 attacks are extremely difficult to launch because theapp is executed in a sandbox where inter-app communication isdisallowed unless it is through socket communication and thedestination matches the AdminRange. The remaining attacksin Class 2, are also constrained to the leakage of the topologyand statistics to the administrator-controlled IP addresses.

Scenario 2: Malicious Routing App: Consider theadministrator deploys a routing app containing malicious code.The app implements shortest path routing in normal cases, butstealthily launches control-plane attacks at times. Assume theapp is configured with the following permission:

PERM visible_topology

PERM flow_event

PERM send_pkt_out

PERM insert_flow LIMITING \

ACTION FORWARD AND OWN_FLOWS

SDNShield provides three levels of protection against theattacks from the malicious app. First, the routing app cannotcommunicate with the outside world, which implies theattacker cannot control the app over the network or obtainthe sensitive information about the network. This propertyeliminates the possibility of Class 2 attack. Second, theapp cannot overwrite firewall rules or establish dynamic-flowtunnel [16] to bypass firewall rules, because it is not allowedto modify other app’s rules. As a result, Class 3 and Class4 attacks are mostly prevented. To entirely prevent Class 3and Class 4 attacks, the administrator can further specifytopology and flow space isolation with topology and flowfilters. Third, although the routing app can still insert maliciousrules and packet-out messages, the SDNShield can provide

activity logging, which enables forensic analysis after theattack happens.

VIII. IMPLEMENTATION

A. Permission Engine and Reconciliation Engine

We implement a prototype of SDNShield policy engines ascontroller-independent Java bundles. Our SDNShield prototypeimplementation consists of three major components: i) apermission compiler that compiles permission manifests intoabstract syntax trees (ASTs), ii) a reconciliation enginethat enforces security policies on a permission AST, iii) apermission checking engine that check whether a specific APIcall is compliant with the given permission AST. The prototypeconsists of ∼23k lines of java code.

B. Isolation Architecture

a) Java-based Reference Monitor.: We implement aJava thread based isolation architecture that can be easilyplugged into Java based SDN controllers with trivial changeson the controller and no changes on apps.

Inter-thread Communication and API Wrapper. Due tothe thread isolation, the direct function calls betweencontroller and apps now need to traverse through inter-threadcommunication channel. We implement a concurrent queue-based communication utility to facilitate the communication.In order to minimize the changes on the legacy system, weprovide wrappers for service interfaces or listener interfacesso that the apps are transparent of the underlying changesin the communication channels. As a highlight, the wrappersare generated automatically according to the source code ofservice interface or listener interface with code transformationtechniques, so that minimal human intervention is needed tosupport a new controller platform.

Controller and App Initiation. During the controller initiationtime, we start all controller modules and a pool of kerneldeputy threads with full privilege, and start an app thread withcorresponding privilege of each app. Then, each app threadexecutes the app initiation code to configure initial states,obtain controller services and register listeners. We makenecessary changes into the controller, so that the services andlistener builders supplied to the apps are all wrapped. Hencethe communication is enforced to traverse through inter-threadchannel. Further, we ensure that all threads spawned from aunprivileged thread inherit their parents’ privilege. During thelifetime of an app, all its API calls will traverse via inter-threadchannel and received by a kernel deputy thread, which checksfor permissions and, if permission allows, executes the APIcall on the behalf of the app.

We implement access control on top of Java SecurityMan-ager, a customizable reference monitor provided by standardJava runtime. Furthermore, SecurityManager ensures that allsystem calls from apps are mediated by SDNShield permissionengine. We extends Java SecurityManager to be able tocheck the customized permissions defined by SDNShield.Figure 4 depicts the architecture of the reference monitorimplementation.

b) OpenDaylight Platform Support: OpenDaylight [5]is a Java-based community-led open source SDN controllerplatform supported by major SDN switch vendors. To enableSDNShield, we implement two extensions on OpenDaylight.

Architecture. OpenDaylight has a monolithic architecture,meaning the controller core and the apps runs in a singleexecution instance without runtime context separation. Sincethe boundary between the core controller functionalitiesand app modules is ambiguous on OpenDaylight, we drawa boundary according to our understanding to place ourpermission checking. We modify the app initialization processso that OpenDaylight apps runs in SDNShield thread container.The modification involves less than 100 lines of code onOpenDaylight source code.

We customize the API wrapper generation tool to adaptfor OpenDaylight service interfaces and notification listenerinterfaces. We also implement a number of API convertersin order to convert the OpenDaylight internal objects intothe abstractions SDNShield permission engine can read.Specifically, a runtime API call is wrapped into a permissionchecking object, which contains the information including thecaller app identity, the required permission and the parameters.

In addition to runtime access control, we also implementcoarse-grained loading-time access control leveraging OSGiframework security. Specifically, OpenDaylight employs OSGiframework to dynamically load Java apps into the runtime.When an app is loaded, OSGi links the APIs that the appconsumes with the modules that provide the APIs. We performpermission checking when OSGi loads the apps so that if noruntime permission checking is needed in case when the appdoes not have the required permission tokens at all.

Permission Checking. OpenDaylight employs model-drivennorthbound interfaces, i.e., most controller northbound inter-faces are implemented as accessing the YANG data model. Asa result, some SDNShield permission policies are enforced bymediating the read and write access to the YANG data model.Specifically, we extend the YANG data model so that sensitivenodes are associated with the necessary permissions requiredto read or write it. We also modify the data broker so thatall data accesses are mediated by the permission engine withthe associated permissions. We mediate event notifications andremote procedure calls (RPCs) at the kernel deputy thread,where necessary permission checking is performed.

c) Floodlight Controller Support: Floodlight [14] is anopen-source Java-based OpenFlow controller. We also makeextensions on the above two aspects to support SDNShield.

Architecture. Although Floodlight has a clear boundarybetween the controller core and the apps on code-level, itstill runs monolithically. We make similar modification intoFloodlight’s app loading process to isolation Floodlight appsinto SDNShield thread containers. We also customized the APIwrapper generation tool for Floodlight.

Permission Checking. Different from the model-drivennorthbound interfaces of OpenDaylight, Floodlight opts foran API-style northbound interfaces. We also implement anumber of API conversion functions to convert Floodlight APIparameters into SDNShield abstractions.

IX. EVALUATION

In this section, we evaluate the effectiveness and per-formance of SDNShield on SDNShield-enabled OpenDaylightSDN controller and Floodlight OpenFlow controller.

A. Methodology

We first evaluate the effectiveness of SDNShield permissionengine and reconciliation engine with proof-of-conceptmalicious apps on Floodlight. Then, we focus on understandingthe overhead brought by SDNShield. The same experimentsare repeated on both Floodlight and OpenDaylight and exhibitqualitatively similar results. In the interest of space, we onlyshow the runtime overhead results on OpenDaylight. We omitshowing the reconciliation engine overhead, since it onlyoccurs at the app installation time and the processing timenever exceeds one second during our pressure tests.

The runtime overhead of SDNShield mainly stems fromthe permission checking and the asynchronous communicationdue to the thread isolation. The permission checking overheadmainly involves the permission evaluation and the book-keeping tasks. The asynchronism overhead is introduced bythe asynchronous function calls via thread signaling, whichleads to CPU context switching and potential waiting.

We use micro benchmarks to evaluate the permissionchecking throughput on a single CPU core. We then simulatetwo use scenarios to evaluate the end-to-end overhead ofSDNShield on the controller runtime.

We deploy the controllers on an Intel Quad-core i73.40GHz workstation with 8GB RAM. We deploy acustomized CBench [28] as our OF message generator hostedon another dedicated physical machine. We use OpenDaylightLithium SR1 and Floodlight v0.90 as our baseline controllers.We simulate two use scenarios.

• L2 Learning Switch. The user network configures switchflow tables using the OpenDaylight l2switch app, whichlearns host position and generates switching rules bylistening to OpenFlow packet-ins containing ARP packets.In this scenario, SDNShield checks permissions at the timeof both the listener notification and the switching ruleissuance.

• Traffic Engineering based on Application-Layer TrafficOptimization(ALTO) information. The ALTO app onOpenDaylight provides real-time topology and routing costinformation to upper-layer apps. We write a simple trafficengineering (TE) app that listens to the ALTO app eventsand reacts with flow-mods that changes the routing paths.In this scenario, SDNShield checks permissions at thetime of the listener notification to ALTO app, data modelpublication from ALTO app, data model event notificationto TE app and routing rule issuance from TE app.

B. Experimental Results

1) Effectiveness: We first verify the effectiveness of thepermission enforcement on four proof-of-concept maliciousapps that conduct attacks as described in Section II. The firstapp monitors active flows by looking at packet-in messagesand injects TCP RST to all active HTTP sessions. Thesecond app collects network topology as well as switch/portconfigurations, and leaks out to outside attackers via HTTP

Small Medium Large0

2

4

6

8

10#

of A

PI c

alls

(milli

on/s

ec)

(a) Insert FlowSmall Medium Large

0

2

4

6

8

10

# of

API

cal

ls (m

illion

/sec

)

(b) Read StatisticsFig. 5: Permission checking throughput on one core.

POST. The third app changes the existing routes betweentwo hosts to traverse through a third host controlled by theattacker. The fourth app establishes a dynamic-flow tunnelthrough a firewall that only allows HTTP traffic at port 80. Werun these apps on SDNShield with permissions in Scenario 1described in Section VII and on original Floodlight. The resultsshow original Floodlight is vulnerable to all the attacks, whileSDNShield-enabled Floodlight is immune to all of them.

We also verify the effectiveness of the security policyreconciliation by checking over-privileged permission man-ifests with security policies generated based on the attackpatterns. The results show that the over-privilege problem canbe effectively prevented with appropriate security policies thatcut off the apps’ access to unnecessary resources. The onlyexception is that some apps (e.g., forwarding apps) essentiallyrequire access to the resources that enable certain attacks (e.g.,insert forwarding rules), which is the inherent limitation ofaccess control.

2) Permission Engine Performance: In this experiment, weevaluate the efficiency of the standalone SDNShield permissionengine, i.e., how many the permission checks the enginecan handle in a time unit on a CPU core. We measure thepermission engine throughput with three manually generatedpermission manifests, which represent small, medium andlarge permission complexity. Three manifests respectivelycontain 1, 5 and 15 permission tokens, and each tokenis associated with 10-20 filters. The app behavior trace isa sequence of flow insertions and statistics requests thatguarantees 5% of the API calls violate the permissions.

Figure 5 shows the permission checking throughput of twoAPI calls (insert flow and read statistics) on a single corevarying the complexity of the permission policies. The resultsshow that permission checking latency is always less than onemicrosecond. Furthermore, since the permission checking isstateless, we can easily scale out the permission engine withparallelism.

3) End-to-end Performance: We then evaluate the overalloverhead of SDNShield in the context of an OpenDaylightcontroller.We compare OpenDaylight controller with andwithout SDNShield in two scenarios. We measure the control-plane latency and throughput at the simulated switches byobserving the issued packet-ins/topology changes and thereceived flow-mods.

End-to-end Latency: The overall latency introducedby SDNShield is dominated by the permission checking andthe reference monitoring. Our evaluation shows that the totallatency overhead introduced by SDNShield is around tens ofmicroseconds, with varying app complexity and CPU coreabundance. The latency overhead is two orders of magnitudesmaller than the typical end-to-end latency in a data center

0 0.5

1 1.5

2 2.5

3 3.5

4 4.5

1 2 3 4 5 6 7 8

Late

ncy

(ms)

Number of Switches

OriginalSDNShield

(a) L2 Learning Switch

0 10 20 30 40 50 60 70 80

1 2 3 4 5 6 7 8

Late

ncy

(ms)

Number of Switches

OriginalSDNShield

(b) ALTO TE

Fig. 6: Latency comparison. The bar and error bar show the medianand the 10th/90th percentile of the measured end-to-end latency.

0 500

1000 1500 2000 2500 3000 3500 4000

1 2 3 4 5 6 7 8

Thro

ughp

ut (r

ules

/sec

)

Number of Switches

OriginalSDNShield

Fig. 7: Throughput comparison. The bar and error bar show themedian and the 10th/90th percentile of the measured end-to-endthroughput.

network.

We conduct experiments to compare the overall control-plane latency of original OpenDaylight controller andSDNShield-enabled OpenDaylight controller in two usescenarios. Each experiment is repeated for 100 times. Figure 6shows the results varying the number of switches in thenetwork. The median result is shown as the bar and the 10/90percentile results are shown as the error bar. We can see thatthe additional overhead introduced by SDNShield is almostunnoticeable in both experiments. Such results are confirmedby similar experiments on Floodlight controller.

End-to-end Throughput: We finally conduct pressuretest to understand how much throughput penalty the threadisolation architecture of SDNShield brings, in comparison toa monolithic architecture of the original OpenDaylight. Weconduct it on the L2 learning switch scenario, since the updatethroughput of ALTO app is limited to 2 updates per seconddue to unknown reasons. Figure 7 shows the results. From thefigure we can see that SDNShield brings negligible throughputdegradation compared to the original OpenDaylight controller.Such results are also confirmed by similar experiments onFloodlight controller.

Scalability: We evaluate the scalability of SDNShieldto large networks and complicated apps. We collect the latencyoverhead varying the number of concurrent apps and thecomplexity of apps (measured by the API calls issued by theapp). The results in Figure 8 demonstrates that the latencyoverhead of SDNShield increases linearly with the number ofconcurrent apps and the complexity of apps, thus SDNShieldis highly scalable even if the number of concurrent apps andthe complexity of individual apps grow in the future.

X. RELATED WORK

a) Security on OpenFlow infrastructure: The demandfor a more secure OF infrastructure has been partiallyaddressed by prior research efforts. Network slicing [29],

0 2 4 6 8 100

50

100

150

200

# of API calls per Request

Late

ncy

(µs)

0 2 4 6 8 100

50

100

150

200

# of concurrent apps

Late

ncy

(µs)

Fig. 8: Scalability of latency overhead with # of API calls per requestand # of concurrent apps. The error bars show the 10th and 90thpercentile. # of concurrent apps is fixed to 1 in the left subfigure; #of API calls per request is fixed to 1 in the right one.

[30], [31], [32] focuses on isolating control for disjoint trafficslices and prevents cross-slice attacks. In contrast, SDNShielddelivers protection to not only disjoint network slices but alsothe apps that sequentially or collaboratively processing thesame set of traffic. Network state analysis techniques [33],[16], [34] verifies network properties, such as reachabilityand middlebox traversal order, by analyzes network-wideflow rules. SDNShield could detect a broader set of controlplane attacks and conduct access control with fine-grainedpermissions.

A few proposals also adopt the approach of permissioncontrol in SDN controllers [9], [10], [11], [12], [13]. Differentfrom previous efforts, SDNShield is the first to providethe fine-grained parameterized permission abstractions andto introduce the reconciliation mechanism that customizesrequested permissions with security policies.

b) Access control system design: The design of accesscontrol systems has been studied for decades. The largebody of researches on design principles and practices [35],[36], [37] inspires our design of SDNShield mandatory accesscontrol system. Also, we learn important lessons from therecent studies on designing mobile OS permission systems.Particularly, some works design fine-grained permissions andenforcement mechanisms [38], [39], [40] for finer accesscontrol of general resource access. Other works [41], [42],on the other hand, identify that higher permission complexitymay decrease users’ ability and willingness to review thedeclared permissions. In comparison, SDNShield features theparameterized fine-grained permission abstractions for SDNenvironment. To provide better usability, SDNShield designssecurity policy reconciliation mechanism that generate fine-grained permissions by customizing declared permissions withlocal security policies.

c) High-level SDN languages and controllers: Today’sOF controllers feature with low-level northbound interfacesthat are closely coupled with the underlying switch hardwarerather than the general network programming concepts. Incontrast, intensive recent research efforts have been spent onidentifying the “right” high-level abstraction for control planesoftware composition. These emerging proposals [23], [24],[25], [26] embrace a variety of programming paradigms andintroduce abstractions on all levels of network programmingentities, such as packet, network topology and compositionoperation. Specifically, Frenetic [25] designs different piecesof high-level language for state querying, packet forwardingand logic composition. Their following work, NetCoreprogramming language [43], expands the query language andthe packet-processing language, and provides formal semanticsfor the novel language. A parallel work Procera [23] embraces

a fully reactive programming paradigm and introduces adifferent abstraction of the network resources. Pyretic [26]proposes dramatically different programming models forpacket, network topology and policy operation.

All these SDN policy languages serve as vehicles tospecify concrete network forwarding policies. In comparison,SDNShield permission language specifies the behavior priv-ileges of SDN apps, and thus has different semantics andscope with the above SDN policy languages. Moreover, noneof these works devote sufficient attention to potential controlplane attacks. We believe SDNShield is orthogonal to theabove works and we show that SDNShield can be adapted toprovide access control to them. Although SDNShield does notcurrently have an implementation on any of the next-generationOF controllers, we think with reasonable engineering efforts,SDNShield can be adapted and deployed on these high-levelabstractions of network programming.

XI. CONCLUSION

With the involvement of third-party apps, OF controllersare subject to the privilege abuse problem, which actuates aseries of control-plane attacks that could compromise the entirenetwork. To deal with the threats, we propose SDNShield,a privilege enforcement system comprising a fine-grainedpermission system and an automatic reconciliation systemthat merges requested permissions with local security policies.Our prototype implementation demonstrates the effectivenessand the acceptable efficiency of SDNShield compared withbaseline.

ACKNOLEDGEMENT

This material is based upon work supported in part by theNSF under grant No. CNS-1219116 and by NSFC under grantNo. 61472359, 61472209, 61432009, 60963021.

REFERENCES

[1] Cisco ios ftp server remote exploit by andy davis. http://bit.ly/Yj21sO.Accessed: 7/30/2015.

[2] Mike lynn’s ’exploit’, in plain (non-technical) english.http://bit.ly/10zx5ou. Accessed: 7/30/2015.

[3] A remote cisco ios exploit. http://bit.ly/WAYG2V. Accessed: 7/30/2015.

[4] F. Lindner. Developments in cisco ios forensics. Recurity Labs, White

Paper, 2008.

[5] OpenDaylight Platform. http://bit.ly/1HJi57D. Accessed: 7/30/2015.

[6] ONOS. http://bit.ly/1KrvSl9. Accessed: 7/30/2015.

[7] HP SDN App Store. https://hpn.hpwsportal.com/catalog.html.Accessed: 7/30/2015.

[8] SDN Security Attack Vectors and SDN Hardening.http://bit.ly/1KO0Zgc. Accessed: 7/30/2015.

[9] Xitao Wen, Yan Chen, Chengchen Hu, Chao Shi, and Yi Wang. Towardsa secure controller platform for openflow applications. In HotSDN’13.

[10] Seungwon Shin, Yongjoo Song, Taekyung Lee, and etc. Rosemary:A robust, secure, and high-performance network operating system. InCCS ’14.

[11] Phillip Porras, Steven Cheung, et al. Securing the Software-DefinedNetwork Control Layer. In NDSS, 2015.

[12] S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, and M. Tyson.Fresco: Modular composable security services for software-definednetworks. In NDSS’13.

[13] Xin Jin, Jennifer Gossels, Jennifer Rexford, and David Walker. CoVisor:A Compositional Hypervisor for Software-Defined Networks. InUSENIX NSDI’15.

[14] FloodLight OpenFlow controller. http://bit.ly/UIL73z. Accessed:7/30/2015.

[15] M. Canini, D. Venzano, P. Peresini, D. Kostic, and J. Rexford. A niceway to test openflow applications. In USENIX NSDI’12.

[16] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu. Asecurity enforcement kernel for openflow networks. In HotSDN’12.

[17] Ryan Johnson, Zhaohui Wang, Corey Gagnon, and Angelos Stavrou.Analysis of android applications’ permissions. In SERE-C 2012.

[18] Kathy Wain Yee Au, Yi Fan Zhou, Zhen Huang, and David Lie. Pscout:analyzing the android permission specification. In CCS 2012. ACM.

[19] Wei Xu, Fangfang Zhang, and Sencun Zhu. Permlyzer: Analyzingpermission usage in android applications. In ISSRE 2013. IEEE.

[20] AirWatch. http://www.air-watch.com/. Accessed: 7/30/2015.

[21] Citrix XenMobile. https://www.citrix.com/xenmobile/. Accessed:7/30/2015.

[22] Andreas Voellmy and Paul Hudak. Nettle: Taking the sting out ofprogramming network routers. In PADL, pages 235–249, 2011.

[23] Andreas Voellmy, Hyojoon Kim, and Nick Feamster. Procera: alanguage for high-level reactive network control. In Proceedings of

HotSDN 2012.

[24] Andreas Voellmy, Junchang Wang, Y Richard Yang, Bryan Ford, andPaul Hudak. Maple: simplifying sdn programming using algorithmicpolicies. In Proceedings of the ACM SIGCOMM 2013.

[25] Nate Foster, Arjun Guha, et al. Languages for software-definednetworks. Communications Magazine, IEEE, 51(2):128–134, 2013.

[26] Joshua Reich, Christopher Monsanto, Nate Foster, Jennifer Rexford,and David Walker. Composing software defined networks. In USENIXNSDI’13.

[27] Carolyn Jane Anderson, Nate Foster, et al. Netkat: Semantic foundationsfor networks. In POPL ’14.

[28] Cbench controller benchmarker. http://bit.ly/YyICCs. Accessed:7/30/2015.

[29] Rob Sherwood, Glen Gibb, et al. Can the production network be thetestbed?

[30] Ali Al-Shabibi, Marc De Leenheer, et al. OpenVirteX: Make YourVirtual SDNs Programmable. HotSDN ’14.

[31] Teemu Koponen, Keith Amidon, et al. Network virtualization in multi-tenant datacenters. In NSDI, 2014.

[32] Roberto Doriguzzi Corin, Matteo Gerola, et al. Vertigo: networkvirtualization and beyond. In EWSDN. IEEE, 2012.

[33] Ahmed Khurshid, Xuan Zou, Wenxuan Zhou, Matthew Caesar, andP Godfrey. Veriflow: verifying network-wide invariants in real time.In USENIX NSDI’13.

[34] Peyman Kazemian, Michael Chan, and etc. Real time network policychecking using header space analysis. In NSDI, pages 99–111, 2013.

[35] Peter A Loscocco, Stephen D Smalley, and etc. The inevitabilityof failure: The flawed assumption of security in modern computingenvironments. In NISSC, 1998.

[36] Ravi S Sandhu and Pierangela Samarati. Access control: principle andpractice. Communications Magazine, IEEE, 32(9):40–48, 1994.

[37] Pierangela Samarati and Sabrina Capitani de Vimercati. Access control:Policies, models, and mechanisms. In Foundations of Security Analysis

and Design. Springer.

[38] Stephen Smalley and Robert Craig. Security Enhanced (SE) Android:Bringing Flexible MAC to Android. In NDSS, volume 310, pages 20–38, 2013.

[39] Jinseong Jeon, Kristopher K Micinski, et al. Dr. android and mr. hide:fine-grained permissions in android applications. In SPSM 2012. ACM.

[40] Soteris Demetriou, Xiaoyong Zhou, et al. What’s in Your Dongle andBank Account? Mandatory and Discretionary Protection of AndroidExternal Resources. In NDSS, 2015.

[41] A.P. Felt, K. Greenwood, and D. Wagner. The effectiveness ofapplication permissions. In WebApps, 2011.

[42] A.P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagner.Android permissions: User attention, comprehension, and behavior. InSOUPS, 2012.

[43] Christopher Monsanto, Nate Foster, Rob Harrison, and David Walker.A compiler and run-time system for network programming languages.In ACM SIGPLAN Notices, volume 47, pages 217–230. ACM, 2012.

APPENDIX ASDNShield PERMISSION LANGUAGE SYNTAX

Permission

perm := perm expr | perm perm expr

perm expr := PERM perm | PERM perm LIMITING filter expr

filter expr := filter expr AND/OR filter| NOT filter expr | ( filter expr ) | filter

Filter Categories

filter := flow f | topology f | callback f | statistics f

flow f := pred f | action f | owner f | table size f| priority f | pkt out f

pred f := field val | field val MASK val| WILDCARD field val

action f := DROP | FORWARD | MODIFY field

owner f := OWN_FLOWS | ALL_FLOWSpriority f := MAX_PRIORITY <INT> | MIN_PRIORITY

<INT>

table size f := MAX_RULE_COUNT <INT>

pkt out f := FROM_PKT_IN | ARBITRARYtopology f := phy topo f | virt topo f

phy topo f := SWITCH switch set LINK link set

virt topo f := VIRTUAL switch map LINK link set

callback f := EVENT_INTERCEPTION |MODIFY_EVENT_ORDER

statistics f := FLOW_LEVEL | PORT_LEVEL | SWITCH_LEVEL

Helpers

field := IP_SRC | IP_DST | TCP_SRC | TCP_DST ...

val := <INT> | <INT>.<INT>.<INT>.<INT>ip fmt := <INT>.<INT>.<INT>.<INT>

switch set := { sw idx , ... }

switch map := { switch set AS sw idx , ... }

link set := { link idx , ... }

APPENDIX BSDNShield SECURITY POLICY LANGUAGE SYNTAX

Security Policy Language

expr := binding | constraint

constraint := ASSERT exclusive | ASSERT assert expr

exclusive := EITHER perm expr OR perm expr

assert expr := assert expr AND/OR boolean expr| NOT assert expr | ( assert expr )| boolean expr

boolean expr := perm expr cmp op perm expr

cmp op := < | > | == | <= | >=binding := LET var perm = { perm expr }

| LET var perm = APP app name| LET var perm = perm expr

perm expr := perm expr MEET/JOIN var perm| ( perm expr ) | var perm | { perm }

var perm := <STRING>

app name := <STRING>