aim-sdn: attacking information mismanagement in sdn-datastores · 2020-06-25 · with the...

AIM-SDN Attacking Information Mismanagement inSDN-datastores

Vaibhav Hemant DixitArizona State University

vdixit2asuedu

Adam DoupeacuteArizona State University

doupeasuedu

Yan ShoshitaishviliArizona State University

yansasuedu

Ziming ZhaoArizona State University

zmzhaoasuedu

Gail-Joon AhnArizona State University and Samsung Research

gahnasuedu

ABSTRACTNetwork Management is a critical process for an enterprise to con-figure andmonitor the network devices using cost effectivemethodsIt is imperative for it to be robust and free from adversarial or ac-cidental security flaws With the advent of cloud computing andincreasing demands for centralized network control conventionalmanagement protocols like SNMP appear inadequate and newertechniques like NMDA and NETCONF have been invented How-ever unlike SNMP which underwent improvements concentratingon security the new data management and storage techniques havenot been scrutinized for the inherent security flaws

In this paper we identify several vulnerabilities in the widelyused critical infrastructures which leverage the Network Manage-ment Datastore Architecture design (NMDA) Software DefinedNetworking (SDN) a proponent of NMDA heavily relies on its data-stores to program and manage the network We base our researchon the security challenges put forth by the existing datastorersquos de-sign as implemented by the SDN controllers The vulnerabilitiesidentified in this work have a direct impact on the controllers likeOpenDayLight Open Network Operating System and their pro-prietary implementations (by CISCO Ericsson RedHat BrocadeJuniper etc) Using our threat detection methodology we demon-strate how the NMDA-based implementations are vulnerable toattacks which compromise availability integrity and confidentialityof the network We finally propose defense measures to address thesecurity threats in the existing design and discuss the challengesfaced while employing these countermeasures

1 INTRODUCTIONWe live our lives on the Internet Our entertainment financial so-cial and intimate interactions are increasingly happening onlinemanifesting as bits racing from network to network across theworld Though most of the time the technical details of the config-uration of these networks are ldquoout of sight and out of mindldquo thenetworks must be configured and maintained Traditionally thishas been a painstaking process involving manual configuration ofindividual devices across the network topology Recently howeverthis has begun to be revolutionized by Software Defined Networking(SDN)

SDN is an innovative architectural approach tomodern computernetworks where the control features of the infrastructure are ab-stracted from the network devices themselves and placed into a cen-tralized location This abstraction of the network allows for novel

approaches to network management including third-party applica-tions dynamic and adaptive configuration and cloud-hostingManyorganizations are realizing the benefit of SDN Googlersquos SDN-basednetwork increased network utilization in their WAN to 100 [14]

However this applicability comes with some risk as SDN tech-nology is used to configure monitor and manage computer net-works their security is of vital importance Attacks against anSDN system can bypass access controls take down the networkreroute traffic or even man-in-the-middle communication There-fore the security of an SDN system is of the utmost importanceNaturally security researchers have investigated the security ofthese networks identifying issues stemming from the maliciousapplications [29] vulnerable services [13] network configurationflooding [34 36] link saturation [16] and so on

Through our research into SDN security we observed a cen-tral theme shared by many of these vulnerabilities SpecificallySoftware Defined Networking suffers from a semantic gap problemin the way that data is shared between the centralized controllerand the distributed network devices This semantic gap leads todifferences in the treatment of data by different subcomponentsof a software defined network potentially manifesting in securityproblems

More interestingly a deeper look revealed that this semanticgap problem is not in fact solely the fault of SDNrsquos design deci-sions but rather is inherent in the modern standard for networkmanagement data storage architecture (RFC 8342)mdashthe NetworkManagement Datastore Architecture (NMDA) design [31]mdashusedby SDN and many other network configuration systems NMDAspecifies that management configuration and operational infor-mation that is required and generated during the life cycle of SDNcontrollers are stored in entities termed datastores Different statesand stages which appear during the control flow of an event governwhich datastores will be used to hold specific information and whatentities are responsible for processing it

The NMDARFC recognizes that its distributed architecture couldopen the door to security concerns but ultimately states in its Secu-rity Considerations section that the design has ldquono security impacton the network (Internet)rdquo We showcase that this is not the casedifferent datastore entities and SDN layers are governed by diversesemantics and the intercommunication between these entities canlead to a breach of trust boundaries in two forms First althoughcontinuous flow of information happens between SDN planes thereis no proposed mechanism to verify the integrity and amount ofdata that flows between the layers Second applications use and

1

Accepted submission 476 to ACM CCS 2018 (PREPRINT NOT FINAL)

modify information in datastores without a sense of ownershipwhich leads to conflicting responsibilities and loss of integrity ofthis information

In this paper we investigated the security of SDN in the contextof this design issue identified multiple security vulnerabilities stem-ming from the semantic gap These vulnerabilities impact widely-used enterprise-ready SDN controllers OpenDayLight (ODL) [27]Open Network Operating System (ONOS) [25] and their propri-etary implementations by vendors such as Juniper Ericsson CISCOand RedHat We disclosed these vulnerabilities to the impactedvendors as we discovered them and the vendors confirmed theidentified vulnerabilities resulting in three CVEs and a confirmedsecurity issue with no CVE yet assigned Additionally we workedwith the concerned engineering teams to design countermeasuresand assisted in identifying their implementation-level root causesbugs to help fix the software itself where possible Because the is-sues that we identified stemmed from design inadequacies some ofthem could not be fixed under the current SDN controller designwithout incurring significant performance penalties Inspired bythis we identified a number of mitigations that can be applied tothe NMDA specification (and subsequently propagated into SDNdesigns) to address this semantic gap

The key contributions of this work can be summarized as

(1) At the time of the writing this work is the first securityanalysis of the underlying design of SDN datastores and wedetermine that there exists a semantic gap in informationmanagement between different layers of abstraction in SDNWe examine the problems that stem from this semantic gapand identify ways to leverage it to adversely impact decisionsof services running inside an SDN controller Due to theevent-driven nature of SDN this can have a cascading effecton the security of the entire network

(2) We present an adversarial model and threat detectionmethod-ology (using an approach assisted by black box fuzzing) toselectively attack different datastores With this we iden-tify vulnerabilities (with corresponding exploits) in widelyadopted SDN controllers

(3) We propose potential countermeasures to prevent the ex-ploits that lead to attacks such as denial of service privilegeescalation integrity breach etc

Although this work focuses on security issues in SDN (a majorapplication of the NMDA standard) the applications of the vulner-able network management datastore design are not limited to SDNcontrollers (as shown in Table 5) Therefore vulnerabilities exposedin this work can potentially be extrapolated to other NMDA-basednetwork management platforms

2 BACKGROUNDIn this section we describe the fundamental concepts involved innetwork management SDN and organization of the stored infor-mation inside SDN controllers which result in the semantic gapproblem

Candidates (applicationuser)

Management Data

Configuration Data Operational Data

RPC REST CLI

OpenFlow

Admins QoS

User config

Rule add ACLFlow

Statistics

App config

Topology

APPLICATIONS

DB Files DB Files

Network Elements (switches links hosts etc)

Rule delRule modNode

Statistics

AAA Administrators

Registered usersUser privileges

Figure 1 The constitution of SDN Applications store net-work configuration in controller controller configures thenetwork and provides operational state back to applications

21 Network ManagementA network is composed of multiple entities (switches routers linkshosts etc) which can be individually managed and programmedwith forwarding logic However individually managing these en-tities increases the degree of management for the entire networkwhich in turn increases its cost of maintenance The Simple NetworkManagement Protocol (SNMP) marked the beginning of remotemonitoring and configuration of management devices The firstdraft of SNMP appeared in 1988 [4] has since undergone multipleamendments At its prime however SNMP started to appear re-dundant and unsuitable to manage dynamically scalable networksSNMP automation scripts are costly and fragile to maintain (egCISCO IOS scripts) as they lack API-based programming benefitsor support for transaction management

The next generation of network management is representedby model-driven architectures that work with dynamically scalingsystems such as cloud and data centers These architectures provideAPIs and models to describe not just the network elements butalso the policies services and transactions in a network Some ofthese new protocols which are quickly gaining popularity includeRESTCONF [3] NETCONF [6] and OpenFlow [22]

22 Rise in Adoption of NMDA with SDNThe Network Management Datastore Design (NMDA) [31] and theNetwork Configuration Protocol (NETCONF) [6] were introducedto address the challenges of portability of systems and mainte-nance cost in SNMP respectively However they suffered from lackof early adoption as their adoption required a massive change inthe architecture of existing systems and rewriting of automationframeworks

With the introduction of Software Defined Networking (SDN)and Network Function Virtualization (NFV) the merits of central-ized network programming were realized and adoption of API-based protocols and modular design started to gain momentumA recent report on NMDArsquos current state of affairs documents anexponential growth in the number of NMDA-based models [1]

The SDN architecture obsoletes SNMP constructs and necessi-tates the adoption of modeled datastores design The configuration

2


settings stored inside an SDN-controller are transferred to infras-tructure (in SDN terminology this is a movement of information todifferent physical and logical planes) and it is possible to miss a partor whole of the information during communication if a principleddesign is not followed Therefore SDN leverages NMDA to define aset of abstracted datastores which keep conceptual data in separateplaces (datastores) as shown in Figure 1

In addition to configuration and operational datastores of NMDAvendors that implement SDN controllers also add a third datastorefor storing the management information (such as network adminis-trator credentials authorized applications etc) Information cate-gorization is explained in further details in Section 24

23 SDNIn SDN remote applications configure a centralized server (runningmultiple services) to manage a physically separated networkinginfrastructure As shown in Figure 1 these entities are distributed indifferent layers which are important to the semantic gap problem

231 SDN Controller An SDN controller is a collection ofservices and sub-systems which manage configure and programthe entire network from a centralized location SDN controllers arerequired to maintain network states for management and distribu-tion of information [24] Numerous SDN controllers from differentvendors are available in the market

In this paper we primarily target the design issues in two ofthe most common open source SDN controllers in the marketOpenDayLight (ODL [23]) and Open Network Operating System(ONOS [2]) These controllers are the base systems for many en-terprise controllers from vendors such as Brocade CISCO andEricsson

The information shared or retrieved from controller is of vitalinterest to security research since these are the potential entrypoints for an attacker to abuse and compromise the information

232 Network Services andApplications To communicatewith network entities the SDN controller uses different southboundplugins (named after the typical SDN topology representationwhere the switches are below or ldquosouthrdquo of the controller) whichinclude OpenFlow [22] NETCONF [6] BGP etc In this paper weprimarily focus on security challenges involved when the networkis programmed using NMDA as the datastore management designand OpenFlow as a messaging channel between controller andswitches The payload of the OpenFlow messages contains sensi-tive information stored or retrieved from NMDA-defined datastoresand is used to configure and monitor the network This approachis taken by ODL and ONOS and thus inherited by a significant seg-ment of the SDN market Clearly the integrity of the informationstored inside datastores is critical for operation of an SDN network

An SDN controller is an advanced Network Operating System [723] that involves critical services like the learning switch the flowprogrammer topology discovery etc Availability of these servicesthat provision information to the users and govern network opera-tions is critical For example a service collects the configurationfrom an administrator and stores it in a datastore A notificationdaemon notifies a flow programming service to pick the new con-figuration create OpenFlow messages and send the messages to

APP APP APP

Applications to

datastore

Datastore-1

Service-1 Service-2 Service-3

Inter-service

communication

Network to datastore

Service to

datastore

Datastore-2

Figure 2 Threat model

the network devices for the final configuration A failed or incor-rect operation of any of these participating services will have animmediate impact on the dependent network functions

The applications that configure and monitor the network usea separate northbound plugins (REST RPC CLI etc) to commu-nicate with the services running in controller Applications likeload balancers and software firewall can be located in logically orphysically different locations and do not establish a direct commu-nication channel with network Since controller relays an applica-tionrsquos intent to the network access control and confidentiality ofapplicationrsquos information are functional obligations of controller

24 SDN Information OrganizationWe categorize the data used by SDN controllers into three categoriesbased on the datastore used (as shown in Figure 1) as the specificdatastore used influences security requirements

241 ControlConfigurationData Services and applicationsstore the network configuration inside the NMDA-based configura-tion datastore The configuration stored include flow rules accesscontrol policies quality of service criteria etc Notification servicesrun as a daemon inside the controller and periodically check forupdates to notify other registered services Control information isdynamically accessed and deployed and requires critical responsetimes meaning minimal performance overhead

242 InventoryOperational Data The centralized view ofthe network (topology runtime state traffic statistics) obtainedusing southbound plugins is stored in the NMDA-based operationaldatastore The consistency and accuracy of this information arecritical as it reflects the state of the physical network For instanceif a firewall application consumes incorrect topology its decisionto enforce access control is based on incorrect data leading tounauthorized communication in the network thus breaking policycontrol and potentially affecting the decisions of load balancingapplications in turn

243 ManagementData An SDN controller requires all man-agement level of information such as the list of SDN users groupsauthorization levels etc This information is often configured as

3


part of the initialization process of the controller and is often di-rectly stored in relational databases

3 THREAT MODELIn our threat model we consider any communication channel thatan external entity can establish with the controller as a threatHowever we assume that the channel to communicate with thecontroller is securemdashthat is we assume that the southbound channelbetween a controller and the network is encrypted and protected(using OpenFlow SSL TLS etc) Similarly we assume the north-bound communication is secure connections between applicationsand the controller (secured REST HTTPs etc)

In this paper we focus on the interactions between entities inSDNwhich involve the datastores and the information storedwithinthem As shown in Figure 2 we investigate three susceptible com-munication channels during information exchange

First the interaction between SDN applications and the SDNcontroller to install configurations for the resources operating inthe network Second the interaction between network devices andthe SDN controller for state management and monitoring Lastlythe coordination between SDN services which is an essential aspectof the SDN controller for operational purposes

We have identified the following threats that are relevant to ourdiscussion

Inconsistent Network State Applications that run on the SDNcontroller (and the controller software itself) particularly security-critical applications such as firewalls require a consistent view ofthe network state A consistent view of the network state meansthat when an application adds a flow rule to the controller thatflow rule is added to the network While not every inconsistentnetwork state is a vulnerability an inconsistent network state canbe a very serious security vulnerability (as we further demonstratein this paper) For instance if a firewall application inserts a flowrule to limit communication between two hosts if that rule is notactually implemented in the network (yet the firewall app thinksthat it is) then that is a vulnerable inconsistent network state

Denial of Service As the controller is the central ldquobrainsrdquo of theSDN network it is also the central point of failure If an adversaryis able to cause the controller to crash then the entire network isunusable A controller crash can be caused by depleting computingmemory or storage limits

Other commonly known threat models for SDN (such as thosepresented in DELTA [19] and [12]) focus on layers surroundingthe controller that exploit the controllerrsquos communication channelsHowever our model discusses exploiting the datastore design ofSDN controllers Additionally we consider that the vulnerabilitieswhich exist in the SDN-datastores can be exploited in both forcedand accidental situations

In the case of an adversarial threat an adversary can compromisethe security of the SDN controllers and the network by directlyexploiting the inherent weaknesses in its datastore design In theabsence of an adversary security issues identified in this paper canalso cause accidental misconfiguration leading to emergent trustviolations

Startupcandidate

running

configuration operational

Application semantics

Diffe

ren

t trust b

ou

nd

aries in

diffe

ren

t plan

es

Laten

cy incre

ase d

urin

g transfe

r of co

nfigu

ration

Controller semantics

Network semantics

v

xw

y

u

Figure 3 Control flow and disparity in information

4 THE SEMANTIC GAPAs described in Section 24 the SDN uses several different data-stores in which different types of data are stored Unfortunatelythe underlying specification for these datastores as determined bythe Network Management Datastore Architecture (NMDA) [31]lacks two critical considerations First it does not propose a wayfor applications interacting with one datastore to have guaranteesthat their information will actually be synchronized to anotherdatastore and second it does not provide any functionality for thetracking of the ownership of information

These design drawbacks of NMDA result in a design-level se-mantic gap in SDN and manifest in symptoms of both inconsistentnetwork states and to denial of service attacks In this sectionwe discuss the nature of this semantic gap and present a semi-automated tool that can help in probing for potential vulnerabilitiesspawning from it

41 The ProblemFigure 3 describes the flow of control and data in an SDN envi-ronment Inside the controller (middle of Figure 3) there are twodatastores one called configuration for the desired network stateand one called operational for the actual network state SDN ap-plications via the northbound API communicate network statechanges to the controller which the controller first places in theconfiguration datastore Controller services then apply these net-work state changes into the actual network via the southboundAPI (commonly OpenFlow) Later other services in the controllerrequest information about the state of the actual network devicesto update the operational datastore

As Figure 3 demonstrates we consider three different semanticlevels in the SDN environment application semantics controllersemantics and network semantics This idea of semantics capturesthe notion that a request by an application asking the controllerto insert a flow rule has a semantic meaning to that applicationIt wants that flow rule inserted in the network so that it can im-pact allowed communications The controller semantics handlethe managing of application network change events programming

4


of switches and monitoring of switches The network semanticsdefine the actual state of the network switches

This gap between the layers is the semantic gap problem andthere are three key causes (1) information disparity (2) blurredresponsibilities and (3) unreliable service chaining

411 Information Disparity In an ideal scenario when anapplication issues a network change request it is expected thatthe network will be configured as and when intended In fact theapplication semantics expect and demand this behavior If there is atemporal delay (caused by server load network load or adversarialbehavior) in the controller issuing the network change request tothe actual network then this can lead to an inconsistent networkstate

For instance if the administrator disables a terminated employeersquosmachinersquos network access through the firewall application and thefirewall application asks the controller to implement the desiredflow rule but the flow rule is delayed or even dropped then thefirewall application and the administrator have an inconsistentview of the network state

412 Blurred Responsibilities Another key aspect of the se-mantic gap problem is the blurred responsibilities in the datastoresConsider Figure 4 which shows a user producing rules A servicecalled the SAL Add-Flow controller module adds these rules tothe configuration datastore At a later point the controllerrsquos FlowProgrammer module adds the rules to the switches Finally theswitchrsquos rules are queried by the OpenFlow plugin and stored inthe operational datastore There is a fundamental question at thispoint Who owns the rules The User the SAL Add-Flow the FlowProgrammer or the OpenFlow plugin If the rule has a timeoutwho is responsible for deleting the rule after the timeout

The implications of blurred responsibility lead to either the sub-sequent tasks being done twice or not being done at all The formerposes performance issues when one or more applications performrepetitive tasks The latter has serious implications as it leads tolack of action and an inconsistent network state

Additionally such faulty or unintended configuration can havecascading affects on the network Hong et al [13] poison the topol-ogy information and demonstrate its global impact on network andfunctionality of other applications As we demonstrate in this papermost of the controllers in the market leverage this design and areprone to inconsistent network states (whether forced or accidental)

413 Unreliable Service Chaining When an application re-quests a network change there are several SDN services that acton that request and the application expects and requires that allthe services act on the request in the intended order In a similarfashion if an application requests a series of network changes inorder they expect those changes to act in that order However thedatastores fundamentally lack synchronization measures for ensur-ing a chained sequence of actions which can cause an inconsistentnetwork state

In fact Xu et al [35] showed that logic flaws (race conditions) inapplications developed for SDN controllers can be exploited froma remote location and can lead to a compromised network as aresult of unreliable service chaining We argue that race conditions

SAL Add-Flow

User

Flow Programmer

Producer

Consumer

Rule 1

Configuration Datastore

Rule 3

Rule 4

Rule 2

Rule 1

Rule 3

Rule 4

Rule 2

Operational Datastore

Producer

Consumer

Producer

Consumer

Rule 1

Json Batch Update

Rule 4

Rule 3

Rule 2

OpenFlow Plugin

Rule 1

Rule 1

Figure 4 Ownership issues (mixed patterns show conflicts)

in SDN applications is one symptom of the underlying unreliableservice chaining problem

42 Probing the Semantic GapAs mentioned Section 3 datastore-based vulnerabilities can be ex-ploited in both forced or accidental situations to trigger eitheran inconsistent network state or denial of service To automati-cally identify possible datastore-based vulnerabilities we designeda systematic procedure to exploit the semantic gap problem andimplemented it into a tool

421 Threat DetectionMethodology We propose a system-atic SDN-fuzzer to perform black-box fuzzing of mainstream SDNcontrollers OpenDayLight and Open Network Operating SystemUnlike existing work [34 36] we do not attempt to impact the per-formance of the controller by merely flooding it with random trafficInstead we acquire a list of critical services involving datastoresanalyze them to expose their entry points and selectively targetthe datastores by fuzzing the communication channels describedas part of our threat model (Section 3)

The fuzzer is provided with a list of services to be inspected Ititeratively detects the interfaces exposed by each service by check-ing the response header of the RESTful requests (GET POST PUTDELETE UPDATE)made to the service If a response such as HTTP-405 Method Not Allowed is received it is inferred that service hasdisabled certain operations This response is crucial for the fuzzeras it is consumed to infer the kind of datastore (configurationoper-ational) the service uses

According to the NMDA rule the operational datastore cannotbe configured (no POST DELETE etc) from the northbound ap-plications but can be read (GET) by all authorized applicationsConversely the configuration datastore can be both read and mod-ified by all applications As an example a flow statistics serviceprovides dynamic updates of network traffic and thus sends backthe information stored in the operational (state) datastore Becausethis information is stored only in the operational datastore a GETrequest to a configuration datastore for statistics will result ina HTTP-405 error Similarly when a PUSH request for the flow

5


Table 1 HTTP response codes and inference

Code Response reason Inference

200 Request successful Datastore found401 Unauthorized Wrong credentials404 Not found Datastore not supported405 Method not allowed Datastore with limited features429 Too many requests Rate limiting measures present500 Internal server error Exceptions crashes errors503 Service unavailable Latency and deadlocks507 Insufficient storage Resource cruch

programmer service is made for a configuration datastore a suc-cess HTTP-200 message is received However the same request forthe operational datastore will result in a HTTP-405 error and it isinferred that the service does not involve the operational datastoreand is used only for configurational purposes

In Table 1 we list the critical responses which the fuzzer receivesfrom the services in the SDN controller and the inference that isderived The fuzzer incorporates an input generator engine whichautomatically creates inputs in the supported format (eg JSON)and issues HTTP requests to the given URL

The response returned is interpreted and analyzed by the analysisengine Finally for successful responses (HTTP-200) the fuzzerchecks the state of the network to confirm the consistency of thenetwork as was intended from the configuration

If a mismatch between the applied configuration and expectedconfiguration is detected this is a inconsistent network state

To identify the root cause we manually examine the containerlogs and attempt to reproduce the problem We also rerun the testsfor inputs that cause misconfiguration in the system to determinethe persistence and impact of the problem Recoverable crashes(change of HTTP code from 500 to 200) are considered less harmfulthan the irrecoverable shutdown of services Similarly runtimeexceptions are considered less fatal than a crash

5 IDENTIFIED VULNERABILITIESIn this section we evaluate SDN-fuzzer and present our resultsbased on the security properties and the vulnerability classes thatwere exploited during the experiments on mainstream SDN con-trollers Our experimental setup consisted of the SDN controllers(ODL [27] and ONOS [25]) a real network (university datacenter)a simulated network (mininet [33]) and the fuzzer The SDN con-trollers had roughly 724 installed services (features) and we activelytracked the impact of fuzzing on 77 critical services Core serviceswhich were impacted are mentioned in Table 3 The extent of theseattacks in different platforms which implement theNMDA datastoredesign manifesting in its vulnerabilities is shown in Table 5

51 Attacks on AvailabilityIn SDN controllers the semantic gap problems discussed in Sec-tion 41 aggravate the central-point of failure of SDN by exposingsecurity vulnerabilities which impact the availability of a network

The performance of the SDN controller can be impacted in twoways depending on the threat source and the attack surface

bull Northbound attack As per the threat model (Section 3) thenorthbound communication with the SDN controller is forprogramming or monitoring the network which requires

applications to store the configuration in the datastoresUnchecked storage and improper management of the storedinformation can lead to memory overflows and impact thecontrollersrsquo availability

bull Southbound attack The forwarding plane can generate eventsnot triggered by the controller (eg host and switch migra-tion switch reboots or manual device configuration) whichare updated in the operational datastore This leads to perfor-mance overhead in the southbound channel and consump-tion of memory resources of the controller

For the communications that happen at the northboundAPI bothread and write controls for the configuration datastore are exposedto applications Also as described in Section 412 there is a blurredsense of ownership of the configuration stored in the configurationdatastore This arrangement means that servicesapplications insidethe controller do not have the responsibility to clean and managethe configuration after use and they depend on someone else todo it As part of our experiments we leveraged an applicationwith RESTful privileges to install configuration (flow rules) in theSDN controllers which support the datastore model There is nothreshold or limit of flows that an application can install Also theSDN controllers will always accept a new configuration

AT-1 (Northbound channel overflow) We installed applica-tions and attacked the services in a distributed fashion to evadedetection If an application is allowed to send unchecked amountsof configuration it impacts the overall latency to serve similarrequests and at some point in time causes service unavailability(HTTP-503) We validated the latency impact on RESTful configura-tions on an SDN controller with two different hardware capabilitiesas shown in Figure 5 At the time of this writing no SDN controllershad implemented preventive measures to implement rate limitingas shown in Table 5

0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]

Open Networking Operating System

32 cores 64GB4 cores 4GB

(a) Latency surge in ONOS

0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]

OpendayLight

32 cores 64GB4 cores 4GBshutdown

(b) Latency surge in ODL

Out_of_Memory_Error ( o s _ l i n u x cpp 2 6 4 3 ) p id =31631 t i d =0 x 0 0 0 0 7 f b 0 4 eb f 7 7 0 0JRE v e r s i o n OpenJDK Runtime Environment ( 8 0 _151minusb12 ) ( b u i l d 1 8 0 _151minus8

u151minusb12minus0ubuntu0 1 6 0 4 2 minus b12 )J ava VM OpenJDK 64minus B i t S e r v e r VM (25 151 minus b12 mixed mode l inuxminusamd64

compressed oops )

(c) Controller shutdown in ODL

Figure 5 Flooding attack on configuration datastores

AT-2 (Persistence) In our experiments using mutated flows tofuzz the configuration datastore we discovered issues with man-agement of stored information We found that the configuration(active or inactive) persists for an indefinite amount of time inside

6


Table 2 Summary of service disruptions while configuring operational network

No of rules Time Tracked services(total - 724)

Impact on Services Attacks Overall impactException Crash Dead Recovered

25 (default) 0 77 0 0 0 0 AT-1 None

20000 25 77 4 1 0 4 AT-1 AT-21 Low

38400 50 68 10 3 2 (deadlock) 8 AT-1 AT21AT-22 AT-3 Latency surge

54000 75 61 10 5 2 (deadlock) 2 AT-1 AT21AT-22 AT-3 High (service failure)

60000 100 0 (system crash) 14 7 Unknown Uknown AT21 AT-22AT-23 Severe

Table 3 Impacted services and datastores in ODL and ONOS(C configuration O operation M management)

Controller Service Datastore Result

ODL

LearningSwitch O event missTopologyManager CO exceptionsHostTracker O event missDLUX UI CO deadlockMD-SAL (core) COM crashSwitchManager O posionedRESTCONF CO latencySALFlowManager CO misconfig

ONOS

SwitchManager O poisonedFlowAnalyzer CO event missReactiveForwarder C misconfigLinkManager CO latencyHostMobility O event miss

the configuration datastore The results of these experiments areelaborated in Table 2 Due to blurred responsibility the expiredconfiguration (flow rules with timeouts) is never deleted by servicesrunning inside the controller even after the expiration of timeoutvalues The communicating entity outside of the controller believesthat the timeout value has a purpose which will be respectedmdashtheconfiguration will be cleared from the network (and operationaldatastore) and the controller (configuration datastore)

AT-21 (Service crash) Before we could notice an impact on theavailability of the controller critical services (eg flow programmer)of both ODL and ONOS were impacted as shown in Table 3 Therepeated experiments on ODL are shown in Table 2 the trackedservices faced deadlock exceptions and crash Some of these servicescould recover other services (eg clustering and UI) remained dead

AT-22 (Southbound latency surge) As the amount of flowsstored in the datastore kept increasing the time required for ser-vices to query valid flows (flow programmer) and push them tonetwork degraded Surge in latency to learn the events from thenetwork had a logical impact on dependent services

AT-23 (Controller shutdown) The blurred responsibility leadsto information to accumulate within the controller SDN controllerssuch as OpenDayLight which run inside a Java virtual environ-ment depend on the configured JVM memory If an application isallowed to send unchecked amount of configurations theoreticallyevery controller will run out of memory eventually The MD-SALservice which is a kernel of the OpenDayLight controller ran out ofmemory to maintain the running state of the controller and even-tually crashed causing the shutdown as shown in Figure 5b (errormessage shown in Listing 5c)

Flow table (init)A ndashgt B DENY

APP1

j

Flow table (configured)A ndashgt B ALLOW 30s

Flow table (runtime-1)A ndashgt B ALLOW 1s

Flow table (runtime-2)A ndashgt B DENY

Flow table (reset)A ndashgt B ALLOW 30s

APP3

CONTROLLER

APP2

l n o

k

m

Configurational Operational

A B

j

l

n

6

o

Legend

Hacked loop

Ideal case

Potential attack zones

Figure 6 Configuration poisoning attack an attacker com-promises the flow table and establishes a hacked loop to in-definitely allow communication in the network

AT-3 (Unused Configuration) The NMDA design allows SDNcontrollers to store the configuration for nodes which are absentfrom the network SDN-fuzzer could install configurations forswitches that were not active in the networkAlthough this is asper the design requirement of NMDA [31] the feature gives anadvantage to the attacker to degrade the performance of the con-troller without impacting the network and successfully hiding themalicious behavior by the traffic monitoring service

52 Attacks on IntegrityMost of the information that is placed into the configuration datas-tore is for programming the network therefore manipulating theconfiguration datastore information leads to a direct impact on thenetwork The consistency and accuracy of the information that isstored in the datastores and passed to the network can be manipu-lated using two communication channels with SDN controller

bull Northbound attack Applications and users install configu-ration in the configuration datastore which are later prop-agated to the network The details of how and when thisinformation is propagated are security-critical If the config-uration is installed in the network at the time not primarilyintended by the administrator unauthorized and undesiredtraffic may be allowed in the network

bull Southbound attack Services in the SDN controller registerlisteners for events that happen in the forwarding plane

7


Changes are updated in the operational store which triggerdesired (or spoofed) actions from the registered services

AT-4 (Advance Persistent Threat) As illustrated in Figure 6we base the APT attack on the design flaw to retain informationeven after its expiration

As part of the root cause analysis of detected policy conflict wediscovered that one of the switches in our network had droppedoff of the network then re-spawned automatically as the TCPIPconnection channel between the switch and controller was reestab-lished When the flow programmer service inside the controllerdetects such an event it checks where there is existing configu-ration data for the new node Because the service find a storedconfiguration for the node in the configuration datastore it wasrestored as part of a process called node reconciliation With thisprocess the otherwise-expired configuration was re-installed in thenetwork as part of reconciliation and its time-to-live was reset tothe originally-configured amount as opposed to the amount it wasat when the switch disconnected

We regularly monitored the traffic against the policies definedby the fuzzer and found that the communication that was intendedto take place in the past had suddenly started again

This attack is carried out as follows 1 A switch initiates aconnection with the controller and is configured with the defaultforwarding rules 2 An application installs the network flow con-figurations with timeouts 3 The flow programmer service installsthis configuration because it does not cause any direct policy vi-olation 2 The application persistently installs similar configura-tions in the network for the switches which physically exist inthe network 5 At any point in the future when there is a switchreconnection procedure (forced [19 21] or natural) 6 the existingconfiguration (which includes the expired configuration) will beinstalled in the switch

Since the configuration datastore holds the original (configuration-level time-to-live rather than the actual remaining operation-levelone the TTL was reset to its full value In effect this allows flowrules in the network to persist beyond their original expiration timethus allowing communication between hosts that should otherwisebe unable to communicate

Interestingly switch disconnections from the controller can benatural or forced For example forced disconnections can be ini-tiated by attacking the network time protocol (NTP) [19 21] orthrough the triggering of DoS vulnerabilities in a switch itself Thismeans that in addition to being caused by accidental switch dis-connections this issue can be triggered by an adversarial agent toretain access to network resources that should otherwise time out

AT-41 (Switch Table Overflow) SDN controllers are requiredto store the entire networkrsquos configuration and therefore may pos-sess massive storage capacity However OpenFlow switches havelimited storage capacity and as part of the reconnection procedurewhen a switchrsquos flow tables receive too many flow rules (everythingsince the beginning of time) the flow tablersquos upper bound can beeasily reached and a table overflow attack is eventually realized

AT-42 (Infinite Access) Since the flawed reconciliation pro-cess installs configuration data which is not necessarily intended atthe time of installation an OpenFlow switch being reconciled mayallow unintended traffic or block allowed traffic When this attack

Match Action Statistics Time-out Priority

No of packets matched by rule

IdleHard timer for rule deletion

Flow packet headers to match

Action on matched packet

Processing order of rule

Figure 7 OpenFlow rule format

0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched

Poisoned flow statistics

benign packetsmalicious packetsbenign payloadmalicious payloadbeginning of attack

0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond

(a) Packets and payload statistics for benign and malicious traffic

src10001dst10002

allowpacket count 33flow count 1byte count 1532

hard-timeout25sduration 24s

priority100

src10001dst10002


hard-timeout25sduration24s

priority100

(b) Reseting of rule and poisoning of statistics

Figure 8 Poisoned statistics during rule reset

is carefully crafted an application needs to configure the networkjust once and then force the controller to configure the switch in aloop 5 ndash 6 ndash 5

The reconnection workflow is initiated at a regular interval justbefore the rule expiry (when timeout in Figure 7 is expiring) Thusthe switch always retains the rule for the ongoing (malicious) flowThis circumvents the OpenFlow policy (switch should send the firstpacket of an unknown flow to the controller for taking decision)and allows the traffic between two hosts in the network for anindefinite period

As shown in Figure 6 both switch and hosts can be potentialtrigger zones for these attacks

AT-43 (QoS Poisoning) OpenFlow rules support metering andstatistics (as a field in Figure 7) for network monitoring and Qualityof Service (QoS) purposes A side-effect of AT-4 is the potential topoison these statistics As shown in Figure 8b a reset (expired) flowrule resets not only the timers (used inAT-42) but also the countersthat are assigned to each flow rule For example a flow rule withtimeout 25 seconds is installed in a switch to allow communicationbetween two connected hosts (10001 10002) After the benign

8


Table 4 Attack analysis

Attack Origin Impacteddatastore

Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity

Severity Detectionrisk

Scope StatusC I A

AT-1 APP Cflow-managernorth channelcontroller-core

times times short M L H M H reported

AT-221 APP C general impact times long L L M L M CVE1 CVE222 APP NW C south channel times times long L L L L H reported23 APP NW COM controller-core times long L M H M H CVE1

AT-3 APP CM config datastore times times long M H L L M reported

AT-441 APPNW CO nw-hardware times times long LM M M H H CVE242 APPNW CO firewall times moderate LM H H L H CVE2 in-progress43 APPNW CO load-balancer times moderate LM H L L M in-progress

AT-5 APPNW O host-tracker times long L H L M H on-holdAT-6 APP M AAA ACL times times short L L H L L CVE3

CVEs (1 DoS 2 APT 3 credentials) Risk measurement metrics (L low M medium H high) Security properties (C Confidentiality I Integrity A Availability)

communication is completed a reset of the expired flow rule (viaswitch reconciliation) leads to reset of the timers and counters Atthis point unauthorized traffic is allowed in the network for theadditional 25 seconds (shown red in Figure 8a) overwriting thevalues with the statistics of the flow

In this attack when a QoS service (for eg a load balancer) pollsfor the flow statistics the information collected from the networkis misleading which will influence its further decisions

AT-5 (Unsolicited Configuration) As mentioned in AT-3 theNMDA datastore architecture allows the applications to store theconfiguration for nodes and entities not present in the networkPresent implementations of this otherwise-essential feature lacksecurity consideration The present datastore in OpenDayLightlacks the capability for the user to specify when the timer for theflow rules (Figure 7) stored in the configuration datastore shouldactually begin Such issues are primarily due to no sense of state ortime maintenance in the configuration datastore The operationaldatastore simply stores the current operational state of the networkThe future of the present configuration for the absent nodes remainunclear and thus leads to security issues in the network in the eventof a previously-configured node joins the network

53 Attacks on ConfidentialityAs described in Section 24 the management information of theSDN controller is stored in a datastore which is different from thosedefined by the NMDA (configuration and state) The design flawspresent in the configuration and state datastores may not appearin the management datastore Therefore we undertake a differentapproach to detect security issues with the storage and access ofmanagement information

Unlike the previously-mentioned vulnerabilities the attacks onmanagement data primarily originate from the northbound channelThis is because events and updates in the forwarding plane do nothave impact on the information stored in management datastore

AT-6 (Cache invalidation) In our testing we observed thatOpenDayLight controller failed to delete the cache after an updateof the usersrsquo credentials Thus even after modifying the controllerrsquosmanagement credentials the old credentials still could be used to

authenticate users and north-bound applications This leads to priv-ilege escalation and spoofed authentication by anyone allowing anattacker full access to controllerrsquos services and stored information

54 Impact AnalysisFrom our investigation we observe that there are inherent vulnera-bilities stemming from the semantic gap problem in the datastoredesign adopted by SDN The attacks described in this work invali-dates the claim by RFC-8342 (NDMA) [31] which mentions that thedatastore design does not have any security impact on the networkbeing managed

In Table 4 we capture the principal characteristics of the vulner-abilities and attacks reported in this paper We analyze the riskswith respect to the ease of execution required privileges and the du-ration of a successful exploit Additionally we evaluate the threatsagainst the possibility of detection and also the extent of the prob-lem in diverse SDN-based platforms With this we derive an overallview of the prevailing issues in SDN that stem from the problem ofsemantic gap

AT-1 takes an advantage of limited resources in SDN controllerwhich is also a central point of failure (controller) and can be trig-gered by one malicious application as also shown in [20] When anattacker crashes the SDN controller applications cannot configurethe network and control over the network is entirely lost (denial ofservice)

AT-2 and AT-3 are covert threats targeted on impacting theavailability of SDN controller Unlike AT-1 an attacker in AT-2 andAT-3 does not require one continuous attempt at the target (whichincreases the probability of evading detection) The attack in AT-1requires large amount of configurational updates to be made in ashort duration However in the case of AT-2 and AT-3 the attackcan be spread out for a considerably longer duration (even months)

The size of configuration updates in AT-2 and AT-3 does nothave a lower bound making detection difficult When performedin a distributed manner over a long period these attacks make itdifficult to perform root cause analysis small amounts of updatesfrom a large number of clients over a long duration increases theentropy of attack footprint

The attacks under AT-4 leverage the idea and techniques of flowtable attackwhen an attack originates from the network (adversarial

9


Table 5 Summary of impacted SDN platforms and enterprises

Platform Base design Vendor Management Open Source ImpactOpenDayLight (ODL) - Linux-NF NETCONF NMDA AT-(123456)

Open Network OS (ONOS) - Linux-NF NETCONF NMDA AT-(1345)Cisco Open-SDN ODL Cisco Systems NETCONF NMDA times AT-(123456)

Contrail OpenContrail - Juniper OPENSTACK times

Lumina SDN ODL Lumina NETCONF NMDA times AT-(123456)Ericsson Cloud SDN ODL OpenStack Ericsson NETCONF NMDA times AT-(123456)

Huawei Agile ODL ONOS Huawei NETCONF NMDA times AT-(12345)Big Cloud Fabric (BCF) FloodLight Big Switch Networks OF times AT-(12345)

HP VAN Controller - HP - times -Cisco APIC - Cisco Systems OF NETCONF AT-(24)

Open Networking Platform ODL Inocybe NETCONF NMDA times AT-(123456)ATampT Integrated Cloud (AIC) Juniper ATampT OF OPENSTACK times AT-1

ZENIC vDC Controller OpenStack ZTE Corporation OPENSTACK times AT-1

hosts) For attacks originating from the southbound channel thereexist work on the detection of flow table flooding attacks [34 36]However an attacker in our scenario does not primarily target theswitchrsquos flow tables The attackerrsquos interest lies in the intermediateimpact that a flow table attack has on the controller (and datas-tores) The performance of the controller can be impacted in sucha situation even if the flow table attack was not successful

We also analyzed the capabilities that adversary gains when aforwarding element (eg a switch) is already compromised SDNsecurity is often analyzed from the scenario of an attacker being ableto compromise a switch on the network and attack the controller-switch channel These attacks are widely popular and thereforethe counter measures are readily available For example switchtable overflow can be mitigated [36] and a SYN-Flood attack canbe prevented using [34] However the attacks that we describedonrsquot need to flood the communication channel but rather targetthe datastore evading detection from existing techniques

Lastly because we do not focus on the vulnerabilities in appli-cations that run inside SDN controllers our attacks are agnosticto any specific implementation of controller Therefore the designflaws highlighted in this work are not limited in nature to ODL andONOS and their users [26 28] As shown in Table 5 they also im-pact SDN controllers and cloudmanagement systemsmdashusingNMDAdesignmdashby enterprises such as RedHat Cisco Brocade IBM Erics-son Extreme Networks Huawei etc

55 Responsible DisclosureWe demonstrated the importance of the discovered vulnerabili-ties by verifying them in different carrier-grade controllers (ODLONOS) The organizations involved in the design and developmentof these platforms verified the feasibility and impact of the attacksthat we reported Additionally in conjunction with the organiza-tions we responsibly disclosed some of the vulnerabilities and wereassigned CVEs CVE-2017-1000411 (DoS) CVE-2018-1078 (AdvancePersistent Threat) CVE-2017-1000406 (cached credentials)1 We areactively working with engineers to identify the root cause of someother attacks which are not publicly disclosed yet including oneconfirmed issue on the ONOS bug tracker ONOS-74562

1Note searching for these CVEs will compromise our anonymity2Note this issue is not publicly available as it concerns an open security vulnerability

6 BRIDGING THE SEMANTIC GAPThrough our assistance to the engineers responsible for the SDNcontrollers impacted by our identified vulnerabilities we have iden-tified several approaches can be incorporated to prevent at leastsome of the attacks mentioned in this paper The mitigation mea-sures can be employed at several different layers of the SDN designHowever as the underlying issue lies in the NMDA design eachmitigation has drawbacks

61 External applicationsTo prevent the overflow of data we propose to use a mechanismto limit the amount of configuration that an application can installOne can use a rate limiting proxy at the API level to monitor theREST channel for any suspicious amount of traffic For strength-ening the security of the management data the management APIswithin SDN controller should only ever be deployed within a seg-regated private network

62 Mitigating denial of servicePreventive measures should be placed at the controller level asthe applications are consumers of the services provided by thecontroller Therefore we propose to set the percentage of heap uti-lization for the resources and datastores inside the controller Thisthreshold can be defined as part of the modeling scheme (YANG)used by services inside the controller Based on the dynamic statis-tics of heap utilization the resources within the controller can bedynamically scaled After reaching the threshold of utilization theapplication can no longer install the configuration and server willrespond accordingly

Lack of systematic synchronizations between configuration andoperational datastores is a major downside in the present designThe expired configuration persists in the configuration datastoreonly because the datastore is oblivious to the state of the configu-ration in the network It will be a huge performance overhead if anapplication must continuously (every millisecond) probe the stateof the network in the operational datastore Instead we proposeto introduce a system clock in the datastores An application caneasily know the state of the configuration with respect to time ifevery configuration in the datastore has a time variable associatedwith it along with other model defined headers This way whenthe configuration expires (system clock vs timeout value) it can

10


be pruned from the datastore by an automatic garbage collectorThis also provides the information of the remaining time for theconfiguration which is important in the case of resetting the lastknown configuration to avoid the reset of timers to zero

63 Mitigating misconfigurationsLargely there are two ways an incorrect configuration can be in-troduced into the network First when an applicationrsquos configu-ration is poisoned by another application or service This is nota datastore-specific issue and can be handled by the applicationlogic by implementing a better threat model and strengthening thecontrol over the information

Second when the two primary datastores inside the SDN con-troller are not in sync and therefore the configuration datastoreis misconfigured A reconciliation in the network should be doneusing the last known information of the node being reconciledWhen the configuration datastore is picked for reconciliation thestate that will be reconfigured cannot be trusted as it might havepartial life remaining or it might be expired altogether

The application which installed the configuration in the config-uration datastore should implement listeners to the updates in theoperational datastore Upon events a snapshot of the operationaldatastore (last known state) should be updated in the configurationdatastore

As mentioned in earlier mitigation implementing a probing (orsyncing) mechanism is not a good approach as it introduces a lotof overhead This also can be prevented using a system clock tiedwith the configuration When the configuration is pulled from thedatastore the clock can be verified with the timeout values Thisway a flow reconciliation manager inside of SDN controller canunderstand that a flow is already expired and should not be pushedto the network

During an event of removing the data tree for the nodes re-moved from the network before updating the network state inthe operational datastore a snapshot of the most-recent runningconfiguration should be updated in the configuration datastoreUpon reconciliation the data which will be reconciled from theconfiguration datastore will not be the initial configuration of thenode but the most recent configuration itself Such a preventivemeasure does not break the programming model either (two ormore applications modifying the same data)

The OpenFlow plugin which installs the configuration for anapplication into the network breaks the programming model onlywhen it modifies the configuration (two or more entities not sharingapplication context) With the configurational clock the plugin cansimply ignore the data This leaves the responsibility of deletion ofthe information with the application or the rightful owner

64 Tracking ownershipWe propose to introduce metadata with the configuration to miti-gate the issue of conflicting ownership of the configuration storedin the datastore The metadata can be included as a configurationalelement provided to the subscribers of the service An applicationconfiguring the network when implementing a configuration ownsthe data and the ownership in the configuration is automatically

assigned Similarly when the information is moved within the con-troller without any external worldrsquos interaction the metadata willbe updated with the producer of the configuration This also solvesthe problem when no participating entity is willing to take theownership of the data

This is the closest to a design-level change and the drawbackof this mitigation is that it will require modifications to any SDNcomponent that produces data Thus the implementation of thismitigation represents a significant undertaking

7 DISCUSSIONSDN suffers from vulnerabilities that are specific to the new de-sign and architecture of network management systems The attacks(what we discussed in this paper) violate key security principlesof cloud-based systems (eg SDN) and do not necessarily have asimilar impact on a traditional network systems On the contrarywell studied network attacks (eg IPMAC spoofing DoS) can becrafted differently in SDN making present defense measures ob-solete Therefore an evolving architecture like SDN demands asecurity reanalysis of its components and the adopted design

Being a hot topic of Internet and datacenters SDN is activelyresearched by academia and industry Although security in SDNis not an ignored subject anymore the architectural weaknessesare still unexplored which subside the merits of the SDN power-house Prior work have found vulnerabilities in implementationsof the SDN services [13 38] and underlying threats in channelsconnecting to the controller [37] A ground zero analysis of theexisting issues would have exposed the platform-agnostic design-level problems discussed in this paper However researchers havefocused on finding more such issues in the implementations whichlimits the scope of the work to the specifically studied systems(SDN controllers)

As SDN is changing the world a robust and reliable backbone(design) becomes a principal requirement However there existsminimal or no security analysis of management transfer and useof the information stored inside SDN controllers The datastorestandard defined in RFC-8342 [31] acknowledges the disparity ofinformation across datastores but lacks security analysis It fails toidentify the information disparity as a security problem as part ofsecurity considerations it mentions that the design has ldquono securityimpactrdquo on the network In this work we identify weaknesses inthe design which lead to serious security impact on the network

The vendors which implement the NMDA design trust the stan-dard for what it mentions about the inherent security Thereforeorganizations tend to focus only on improving the scalable andmod-ular attributes of SDN Security considerations are ignored duringthe modeling and development of these controllers and are workedupon only when researchers highlight serious security problemsThis became increasingly apparent in our research and involve-ment with these organizations Many enterprise SDN controllersare based on open-sourced systems and also contribute to theirdevelopment Therefore the security issues discussed in this workspread to a breadth of cloud-based platforms as shown in Table 5

To continue to harness the benefits of SDN it is important toensure that the identified security risks are attended Merely ac-knowledging the security problems and delaying to address them

11


may not be a fruitful approach in the long run Likewise providingworkarounds to contain a specific threat is a costly approach as itdoes not guarantee a solution or a threat-free SDN controller Tothis extent a re-design of the datastore management system mightbe costly at the moment but can be deemed necessary profitableand a more secured approach for safeguarding the future

8 RELATEDWORKIn this section we analyze the security research done in networkmanagement systems and discuss the relevant attack classes ofSDN

Security Research inNetworkManagement Networkman-agement system has been continuously studied and improved sincethe inception of the Internet SNMPv1 [4] suffered many perfor-mance and security issues which were only partially addressed bySNMPv2 [9] (with community-based security) and fully addressedwith SNMPv3 [8] which encrypted the traffic and detected mal-formed packets However based on Management Information Base(MIB) SNMP appears as a costly alternative to manage advancingnetworks

The modern protocols such as NETCONF [6] and OpenFlow [22]receive research attention from the security community RFC-5539[11] and RFC-4742 [10] propose to use Transport Layer Security(TLS) and Secure Shell (SSH) channel to secure exchanges usedin the protocol Similarly OpenFlow is actively researched for im-provements against spoofing packet tampering denial of serviceand side channel attacks as surveyed in [18 30] However much ofthe research focus has been in securing the channel of communi-cation and consequently secured mechanisms to manage criticalinformation within the controller have not been addressed

Kim and Feamster [17] have attempted to realize the criticalityof robust network management However the work is limited toleveraging the merits of SDN (abstraction and centralized control)to improve the conventional management techniques and handlea deluge of network events Kim and Feamster did not investigatethe security impact of a poorly designed management system overthe entire network and other services

SDN Attacks and Defense Frameworks SDN is hot topic ofnetwork security research with noteworthy work done to addressthe weaknesses in protecting the availability and integrity of thenetwork Various frameworks exist to attack and identify threatsin SDN and its abstracted planes Most recently DELTA [19] re-instantiated and combined the attacking mechanisms defined inearlier work in a platform agnostic tool (opensourced) and addedprotocol-aware fuzzing mechanism to discover vulnerabilities Al-though DELTA succeeded in discovering 27 security threats indiverse SDN environments its black-box fuzzer could only targetthe communication channels with the controller (northbound andsouthbound) To discover the vulnerabilities within the controllerthe fuzzer cannot identify a datastore from the behavior of theservice being fuzzed Therefore DELTA cannot detect the securityissues that surface from the NMDA design (incorporated by mostof the controllers that it is tested against) We were motivated bythe design of DELTArsquos fuzzer to create the randomization in the

flow entries to fuzz the target service after identifying its datastoreas mentioned in Section 42

FlowWars [38] presents a consolidated report on the the currentattack surfaces and threats in SDN and showcases common designand implementation pitfalls that allow the abuse of SDN networksHowever since no earlier work has attempted to attack the SDNdatastores potential issues in the NMDA design (a critical aspectof the most SDN controllers) are missed as part of its findings

Other attacks target specific network functions in SDN Dhawanet al [5] detect policy violations in the forwarding plane but doesnot take into account the impact on controller and its services Leeet al [20] elaborate on attacks induced from seemingly benign ap-plications against implementation flaws in other SDN applications

Xu et al [35] target the novel TOCTOU attacks against SDNSimilar to our work the authors propose a framework in whichforced or natural race conditions in the event-driven system cre-ate chaos in the network and ultimately lead to breach of trustboundaries The framework however is not agnostic an attackerrequires implementation knowledge and expertise to carefully craftan attack inducing race condition

Potential defense mechanisms against threats in SDN are pro-posed in NOSArmor [15] and Avant-guard [32] As mentionedin Section 54 these systems provide defenses only against theknown attacks in SDN The attacks mentioned in this paper willgo undetected as they endure a covert execution pattern and donot necessarily depend on the abuse of communication channelswith controller Upon integrating these unknown attack classeswith subverting mechanisms such as SDN Rootkits [29] an adver-sary outside of the controller can successfully evade detection andlaunch an advanced persistent threat to manipulate the network

Denial of Service and Poisoning Attacks in SDN Variousworks study the impact of availability and integrity of SDN networkthrough denial of service and poisoning attacks DoS attacks com-monly originate from the SDN data plane and target either the for-warding element (switch) by flooding the local flow tables [34 36]or impacting the availability of controller by flooding the southbound channel between the controller and network [37]

However the threat model incorporated by the frameworks todetect the DoS attacks primarily concentrate on detecting the ab-normal surge in the traffic being handled by the controller Thatis the focus is placed on identifying the saturation of communica-tion channels Design problems that lead to resource consumptionwithin SDN datastores as we discuss in this paper are not exploredyet

To impact the integrity of the information stored within the con-troller TopoGuard [13] aims to detect poisoning attacks TopoGuardtakes advantage of poor implementation and coordination of ser-vices (host tracking topology) within enterprise SDN controllersto spoof the controllerrsquos view of the infrastructure and impactingthe decision of other dependent services The paper highlights theimpact that vulnerabilities in one service can have over the entirenetwork However the root cause analysis of the detected issue isnot discussed in the work Therefore in this work we focus on theroot cause for various controller-level violation of trust boundaries

12


9 CONCLUSIONIn this work we perform a first-of-its-kind security analysis ofthe NMDA-defined datastores as implemented by carrier-gradeSDN controllers We identify new vulnerabilities that stem from asemantic gap problem between different abstractions as part of thenetwork and the datastore design We present new attacks on SDNthat leverage the semantic gap and compromise the controllerrsquosperformance force misconfigurations in the network cause races inthe control flow of core services in the controller and finally disruptthe critical functionalities of SDN ultimately leading to the crashof the SDN controller We demonstrate the proof and impact ofthese vulnerabilities by attacking enterprise SDN controllers (ODLand ONOS) and later working with the concerned organizations toformulate defensive measures

REFERENCES[1] YANG Data Models in the Industry Current State of Affairs (March

2018) httpwwwclaisebe201803yang-data-models-in-the-industry-current-stte-of-affairs-march-2018

[2] Pankaj Berde Matteo Gerola Jonathan Hart Yuta Higuchi Masayoshi KobayashiToshio Koide Bob Lantz Brian OrsquoConnor Pavlin Radoslavov William Snow andGuru Parulkar 2014 ONOS Towards an Open Distributed SDN OS In Proceed-ings of the Third Workshop on Hot Topics in Software Defined Networking (HotSDNrsquo14) ACM New York NY USA 1ndash6 httpsdoiorg10114526207282620744

[3] Andy Bierman Martin Bjorklund and Kent Watsen 2017 RESTCONF protocol(2017)

[4] Jeffrey D Case Mark Fedor Martin L Schoffstall and James Davin 1990 Simplenetwork management protocol SNMPv1 RFC-1067 (1990)

[5] Mohan Dhawan Rishabh Poddar Kshiteej Mahajan and Vijay Mann 2015SPHINX Detecting Security Attacks in Software-Defined Networks In Pro-ceedings of the Network and Distributed System Security Symposium 2015

[6] Rob Enns 2006 Network configuration protocol (NETCONF) (2006)[7] Internet Research Task Force Software-Defined Networking (SDN) Layers and

Architecture Terminology RFC-7426[8] Network Working Group Simple network management protocol SNMPv3 RFC-

3418[9] Network Working Group 1993 Simple network management protocol SNMPv2

RFC-1452 (April 1993)[10] Network Working Group 2006 Using the NETCONF Configuration Protocol

over Secure SHell (SSH) RFC-4742 (2006)[11] Network Working Group 2009 NETCONF over Transport Layer Security (TLS)

RFC-5539 (2009)[12] Jennia Hizver 2015 Taxonomic modeling of security threats in software defined

networking In BlackHat Conference 1ndash16[13] Sungmin Hong Lei Xu Haopei Wang and Guofei Gu 2015 Poisoning Network

Visibility in Software-Defined Networks New Attacks and Countermeasures InProceedings of the Network and Distributed System Security Symposium 2015

[14] Sushant Jain Alok Kumar Subhasree Mandal Joon Ong Leon Poutievski ArjunSingh Subbaiah Venkata Jim Wanderer Junlan Zhou Min Zhu et al 2013 B4Experience with a globally-deployed software defined WAN In ACM SIGCOMMComputer Communication Review Vol 43 ACM 3ndash14

[15] Hyeonseong Jo Jaehyun Nam and Seungwon Shin 2018 NOSArmor Building aSecure Network Operating System Security and Communication Networks 2018

[16] Min Suk Kang Virgil D Gligor and Vyas Sekar 2016 SPIFFY Inducing Cost-Detectability Tradeoffs for Persistent Link-Flooding Attacks In Proceedings ofthe Network and Distributed System Security Symposium 2016

[17] Hyojoon Kim and Nick Feamster 2013 Improving network management withsoftware defined networking IEEE Communications Magazine 51 2 114ndash119

[18] R Kloumlti V Kotronis and P Smith 2013 OpenFlow A security analysis In 201321st IEEE International Conference on Network Protocols (ICNP) 1ndash6

[19] Seungsoo Lee Changhoon Yoon Chanhee Lee Seungwon Shin Vinod Yeg-neswaran and Phillip Porras 2017 DELTA A Security Assessment Frameworkfor Software-Defined Networks In Proceedings of the Network and DistributedSystem Security Symposium 2017

[20] Seungsoo Lee Changhoon Yoon and Seungwon Shin 2016 The smaller theshrewder A simple malicious application can kill an entire sdn environmentIn Proceedings of the 2016 ACM International Workshop on Security in SoftwareDefined Networks amp Network Function Virtualization ACM 23ndash28

[21] Aanchal Malhotra Isaac E Cohen Erik Brakke and Sharon Goldberg 2016 At-tacking the Network Time Protocol In Proceedings of the Network and DistributedSystem Security Symposium 2016

[22] Nick McKeown Tom Anderson Hari Balakrishnan Guru Parulkar Larry Pe-terson Jennifer Rexford Scott Shenker and Jonathan Turner 2008 OpenFlowenabling innovation in campus networks ACM SIGCOMM Computer Communi-cation Review 38 2 (2008) 69ndash74

[23] J Medved R Varga A Tkacik and K Gray 2014 OpenDaylight Towards aModel-Driven SDN Controller architecture In Proceeding of IEEE InternationalSymposium on a World of Wireless Mobile and Multimedia Networks 2014 1ndash6httpsdoiorg101109WoWMoM20146918985

[24] Thomas D Nadeau and Ken Gray 2013 SDN Software Defined Networks AnAuthoritative Review of Network Programmability Technologies OrsquoReilly MediaInc

[25] SDN Open Network Operating Sysyem Open Networking Foundation Project[26] OpenContrail OpenContrail Silicon Valley Meetup[27] SDN OpenDaylight Linux Foundation Collaborative Project 2013[28] The Linux Foundation Projects User Stories - OpenDayLight[29] Christian Roumlpke and Thorsten Holz 2015 SDN Rootkits Subverting Network

Operating Systems of Software-Defined Networks In Research in Attacks In-trusions and Defenses Herbert Bos Fabian Monrose and Gregory Blanc (Eds)Springer International Publishing Cham 339ndash356

[30] Sandra Scott-Hayward Gemma OrsquoCallaghan and Sakir Sezer 2013 SDN securityA survey In Future Networks and Services (SDN4FNS) 2013 IEEE SDN For IEEE1ndash7

[31] Philip Shafer Martin Bjorklund Robert Wilton Juumlrgen Schoumlnwaumllder and KentWatsen 2018 Network Management Datastore Architecture RFC-8342 Network(2018)

[32] Seungwon Shin Vinod Yegneswaran Phillip Porras and Guofei Gu 2013 Avant-guard Scalable and vigilant switch flow management in software-defined net-works In Proceedings of the 2013 ACM SIGSAC conference on Computer amp commu-nications security ACM 413ndash424

[33] Mininet Team 2014 Mininet httpmininetorg[34] Haopei Wang Lei Xu and Guofei Gu 2015 Floodguard A dos attack prevention

extension in software-defined networks In Dependable Systems and Networks(DSN) 2015 45th Annual IEEEIFIP International Conference on IEEE 239ndash250

[35] Lei Xu JeffHuang SungminHong Jialong Zhang and Guofei Gu 2017 Attackingthe Brain Races in the SDN Control Plane In 26th USENIX Security Symposium(USENIX Security 17) USENIX Association 451ndash468

[36] T Xu D Gao P Dong C H Foh and H Zhang 2017 Mitigating theTable-Overflow Attack in Software-Defined Networking IEEE Transactionson Network and Service Management 14 4 1086ndash1097 httpsdoiorg101109TNSM20172758796

[37] Q Yan F R Yu Q Gong and J Li 2016 Software-Defined Networking (SDN) andDistributed Denial of Service (DDoS) Attacks in Cloud Computing EnvironmentsA Survey Some Research Issues and Challenges IEEE Communications SurveysTutorials 18 1 602ndash622

[38] C Yoon S Lee H Kang T Park S Shin V Yegneswaran P Porras and G Gu2017 Flow Wars Systemizing the Attack Surface and Defenses in Software-Defined Networks IEEEACM Transactions on Networking 25 6 3514ndash3530httpsdoiorg101109TNET20172748159

13

Abstract

1 Introduction

2 Background

21 Network Management

22 Rise in Adoption of NMDA with SDN

23 SDN

24 SDN Information Organization

3 Threat Model

4 The Semantic Gap

41 The Problem

42 Probing the Semantic Gap

5 Identified Vulnerabilities

51 Attacks on Availability

52 Attacks on Integrity

53 Attacks on Confidentiality

54 Impact Analysis

55 Responsible Disclosure

6 Bridging the Semantic Gap

61 External applications

62 Mitigating denial of service

63 Mitigating misconfigurations

64 Tracking ownership

7 Discussion

8 Related Work

9 Conclusion

References


modify information in datastores without a sense of ownershipwhich leads to conflicting responsibilities and loss of integrity ofthis information

In this paper we investigated the security of SDN in the contextof this design issue identified multiple security vulnerabilities stem-ming from the semantic gap These vulnerabilities impact widely-used enterprise-ready SDN controllers OpenDayLight (ODL) [27]Open Network Operating System (ONOS) [25] and their propri-etary implementations by vendors such as Juniper Ericsson CISCOand RedHat We disclosed these vulnerabilities to the impactedvendors as we discovered them and the vendors confirmed theidentified vulnerabilities resulting in three CVEs and a confirmedsecurity issue with no CVE yet assigned Additionally we workedwith the concerned engineering teams to design countermeasuresand assisted in identifying their implementation-level root causesbugs to help fix the software itself where possible Because the is-sues that we identified stemmed from design inadequacies some ofthem could not be fixed under the current SDN controller designwithout incurring significant performance penalties Inspired bythis we identified a number of mitigations that can be applied tothe NMDA specification (and subsequently propagated into SDNdesigns) to address this semantic gap

The key contributions of this work can be summarized as

(1) At the time of the writing this work is the first securityanalysis of the underlying design of SDN datastores and wedetermine that there exists a semantic gap in informationmanagement between different layers of abstraction in SDNWe examine the problems that stem from this semantic gapand identify ways to leverage it to adversely impact decisionsof services running inside an SDN controller Due to theevent-driven nature of SDN this can have a cascading effecton the security of the entire network

(2) We present an adversarial model and threat detectionmethod-ology (using an approach assisted by black box fuzzing) toselectively attack different datastores With this we iden-tify vulnerabilities (with corresponding exploits) in widelyadopted SDN controllers

(3) We propose potential countermeasures to prevent the ex-ploits that lead to attacks such as denial of service privilegeescalation integrity breach etc

Although this work focuses on security issues in SDN (a majorapplication of the NMDA standard) the applications of the vulner-able network management datastore design are not limited to SDNcontrollers (as shown in Table 5) Therefore vulnerabilities exposedin this work can potentially be extrapolated to other NMDA-basednetwork management platforms

2 BACKGROUNDIn this section we describe the fundamental concepts involved innetwork management SDN and organization of the stored infor-mation inside SDN controllers which result in the semantic gapproblem

Candidates (applicationuser)

Management Data

Configuration Data Operational Data

RPC REST CLI

OpenFlow

Admins QoS

User config

Rule add ACLFlow

Statistics

App config

Topology

APPLICATIONS

DB Files DB Files

Network Elements (switches links hosts etc)

Rule delRule modNode

Statistics

AAA Administrators

Registered usersUser privileges

Figure 1 The constitution of SDN Applications store net-work configuration in controller controller configures thenetwork and provides operational state back to applications

21 Network ManagementA network is composed of multiple entities (switches routers linkshosts etc) which can be individually managed and programmedwith forwarding logic However individually managing these en-tities increases the degree of management for the entire networkwhich in turn increases its cost of maintenance The Simple NetworkManagement Protocol (SNMP) marked the beginning of remotemonitoring and configuration of management devices The firstdraft of SNMP appeared in 1988 [4] has since undergone multipleamendments At its prime however SNMP started to appear re-dundant and unsuitable to manage dynamically scalable networksSNMP automation scripts are costly and fragile to maintain (egCISCO IOS scripts) as they lack API-based programming benefitsor support for transaction management

The next generation of network management is representedby model-driven architectures that work with dynamically scalingsystems such as cloud and data centers These architectures provideAPIs and models to describe not just the network elements butalso the policies services and transactions in a network Some ofthese new protocols which are quickly gaining popularity includeRESTCONF [3] NETCONF [6] and OpenFlow [22]

22 Rise in Adoption of NMDA with SDNThe Network Management Datastore Design (NMDA) [31] and theNetwork Configuration Protocol (NETCONF) [6] were introducedto address the challenges of portability of systems and mainte-nance cost in SNMP respectively However they suffered from lackof early adoption as their adoption required a massive change inthe architecture of existing systems and rewriting of automationframeworks

With the introduction of Software Defined Networking (SDN)and Network Function Virtualization (NFV) the merits of central-ized network programming were realized and adoption of API-based protocols and modular design started to gain momentumA recent report on NMDArsquos current state of affairs documents anexponential growth in the number of NMDA-based models [1]

The SDN architecture obsoletes SNMP constructs and necessi-tates the adoption of modeled datastores design The configuration

2










APP APP APP

Applications to

datastore

Datastore-1


Inter-service

communication


Service to

datastore

Datastore-2








3











Startupcandidate

running



Diffe

ren

t trust b

ou

nd

aries in

diffe

ren

t plan

es

Laten

cy incre

ase d

urin

g transfe

r of co

nfigu

ration


Network semantics

v

xw

y

u






4











SAL Add-Flow

User

Flow Programmer

Producer

Consumer

Rule 1


Rule 3

Rule 4

Rule 2

Rule 1

Rule 3

Rule 4

Rule 2


Producer

Consumer

Producer

Consumer

Rule 1

Json Batch Update

Rule 4

Rule 3

Rule 2

OpenFlow Plugin

Rule 1

Rule 1







5


















0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]




0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]

OpendayLight





compressed oops )




6





25 (default) 0 77 0 0 0 0 AT-1 None

20000 25 77 4 1 0 4 AT-1 AT-21 Low






ODL


ONOS







APP1

j





APP3

CONTROLLER

APP2

l n o

k

m


A B

j

l

n

6

o

Legend

Hacked loop

Ideal case







7


















0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched



0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond


src10001dst10002



priority100

src10001dst10002



priority100







8




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References










APP APP APP

Applications to

datastore

Datastore-1


Inter-service

communication


Service to

datastore

Datastore-2








3











Startupcandidate

running



Diffe

ren

t trust b

ou

nd

aries in

diffe

ren

t plan

es

Laten

cy incre

ase d

urin

g transfe

r of co

nfigu

ration


Network semantics

v

xw

y

u






4











SAL Add-Flow

User

Flow Programmer

Producer

Consumer

Rule 1


Rule 3

Rule 4

Rule 2

Rule 1

Rule 3

Rule 4

Rule 2


Producer

Consumer

Producer

Consumer

Rule 1

Json Batch Update

Rule 4

Rule 3

Rule 2

OpenFlow Plugin

Rule 1

Rule 1







5


















0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]




0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]

OpendayLight





compressed oops )




6





25 (default) 0 77 0 0 0 0 AT-1 None

20000 25 77 4 1 0 4 AT-1 AT-21 Low






ODL


ONOS







APP1

j





APP3

CONTROLLER

APP2

l n o

k

m


A B

j

l

n

6

o

Legend

Hacked loop

Ideal case







7


















0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched



0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond


src10001dst10002



priority100

src10001dst10002



priority100







8




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References











Startupcandidate

running



Diffe

ren

t trust b

ou

nd

aries in

diffe

ren

t plan

es

Laten

cy incre

ase d

urin

g transfe

r of co

nfigu

ration


Network semantics

v

xw

y

u






4











SAL Add-Flow

User

Flow Programmer

Producer

Consumer

Rule 1


Rule 3

Rule 4

Rule 2

Rule 1

Rule 3

Rule 4

Rule 2


Producer

Consumer

Producer

Consumer

Rule 1

Json Batch Update

Rule 4

Rule 3

Rule 2

OpenFlow Plugin

Rule 1

Rule 1







5


















0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]




0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]

OpendayLight





compressed oops )




6





25 (default) 0 77 0 0 0 0 AT-1 None

20000 25 77 4 1 0 4 AT-1 AT-21 Low






ODL


ONOS







APP1

j





APP3

CONTROLLER

APP2

l n o

k

m


A B

j

l

n

6

o

Legend

Hacked loop

Ideal case







7


















0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched



0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond


src10001dst10002



priority100

src10001dst10002



priority100







8




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References











SAL Add-Flow

User

Flow Programmer

Producer

Consumer

Rule 1


Rule 3

Rule 4

Rule 2

Rule 1

Rule 3

Rule 4

Rule 2


Producer

Consumer

Producer

Consumer

Rule 1

Json Batch Update

Rule 4

Rule 3

Rule 2

OpenFlow Plugin

Rule 1

Rule 1







5


















0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]




0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]

OpendayLight





compressed oops )




6





25 (default) 0 77 0 0 0 0 AT-1 None

20000 25 77 4 1 0 4 AT-1 AT-21 Low






ODL


ONOS







APP1

j





APP3

CONTROLLER

APP2

l n o

k

m


A B

j

l

n

6

o

Legend

Hacked loop

Ideal case







7


















0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched



0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond


src10001dst10002



priority100

src10001dst10002



priority100







8




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References


















0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]




0 20 40 60 80 1000102030405060708090

Time [min]

Latency[m

s]

OpendayLight





compressed oops )




6





25 (default) 0 77 0 0 0 0 AT-1 None

20000 25 77 4 1 0 4 AT-1 AT-21 Low






ODL


ONOS







APP1

j





APP3

CONTROLLER

APP2

l n o

k

m


A B

j

l

n

6

o

Legend

Hacked loop

Ideal case







7


















0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched



0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond


src10001dst10002



priority100

src10001dst10002



priority100







8




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References





25 (default) 0 77 0 0 0 0 AT-1 None

20000 25 77 4 1 0 4 AT-1 AT-21 Low






ODL


ONOS







APP1

j





APP3

CONTROLLER

APP2

l n o

k

m


A B

j

l

n

6

o

Legend

Hacked loop

Ideal case







7


















0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched



0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond


src10001dst10002



priority100

src10001dst10002



priority100







8




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References


















0 5 10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

90

Time [sec]

Packetsm

atched



0 5 10 15 20 25 30 35 40 45 500

02

04

06

08

1middot104

Bytesp

ersecond


src10001dst10002



priority100

src10001dst10002



priority100







8




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References




Affectedassets

CIA Attackduration

Privilegesrequired

Attackcomplexity


Scope StatusC I A





















9




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References




















10

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References

















11
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References
















12







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References







































13

Abstract

1 Introduction

2 Background



23 SDN


3 Threat Model

4 The Semantic Gap

41 The Problem






54 Impact Analysis







7 Discussion

8 Related Work

9 Conclusion

References

aim-sdn: attacking information mismanagement in sdn-datastores · 2020-06-25 · with the...

Documents