Software-Deﬁned Network Security over OpenStack Clouds:

A Systematic Analysis

Nicolas P. Lane

1 a

, Guilherme P. Koslovski

1 b

, Maur

ıcio A. Pillon

1 c

, Charles C. Miers

1 d

and Nelson M. Gonzalez

2 e

Graduate Program in Applied Computing (PPGCA), Santa Catarina State University (UDESC), Brazil

IBM Watson Research Center, Yorktown Highs, NY, U.S.A.

Keywords:

Cloud Computing, OpenStack, Security, Openﬂow.

Abstract:

Cloud computing infrastructure is an enticing target for malicious activity due to its network and compute

capacity. Several studies focus on different aspects of cloud security from the client (tenant) side, leaving

a gap regarding the cloud provider’s infrastructure perspective. To address this gap, this study conducts a

systematic review of the literature on OpenStack, the most adopted open source cloud operating system. We

present a qualitative assessment of security vulnerabilities related do Openﬂow usage on OpenStack network

management. Based on this analysis we identify a critical vulnerability which affects the cloud infrastructure

via Software-Deﬁned Networks. This reveals the urge for having more studies focusing on the provider’s

infrastructure side and associated tools and technologies.

1 INTRODUCTION

Cloud computing is a well-established concept of re-

source and service provisioning to which new features

and technologies are constantly being incorporated.

Cloud computing depends on several enabler tech-

nologies, particularly ones related to virtualization. In

that sense, several solutions have been developed over

the years to manage the cloud infrastructure and pro-

vide services to customers.

A cloud operating system encompasses features

both to create this cloud infrastructure, including the

setup of virtualized resources, and interfaces to allow

user access. The ecosystem of cloud operating sys-

tems comprise proprietary and open source solutions.

In terms of security, still one of the main concerns

of cloud computing, proprietary solutions can only be

inspected from its interfaces since there is no access

to the source code, therefore hindering the process of

investigating vulnerabilities (CSA, 2017). In contrast,

open source solutions allow a thorough investigation

of internal mechanisms.

https://orcid.org/0000-0001-8050-1638

https://orcid.org/0000-0003-4936-1619

https://orcid.org/0000-0001-7634-6823

https://orcid.org/0000-0002-1976-0478

https://orcid.org/0000-0003-3780-9025

OpenStack, one of the most prominent open

source cloud platforms, stands out in terms of source

code auditing, project maturity, versatility, and con-

stant updates (Wen et al., 2012; Mullerikkal and Sas-

tri, 2015; Vogel et al., 2016; Iqbal and Dagiuklas,

2017). In its 18

release (codename Rocky) (Open-

StackRocky, 2018a), OpenStack organises its net-

works using three NDs (Network Domains) (Rosado

and Bernardino, 2014): management, guest, and pub-

lic. These NDs comprise networks managed by four

SecNDs (Security Network Domains): management,

guest, public, and data (OpenStack, 2018a). Net-

working is a fundamental cloud building block which

depends on a combination of technologies such as

VLAN, L2 tunnelling, and SDN (Software-Deﬁned

Network).

In this paper we present the results of a system-

atic review of OpenStack security literature. We fo-

cus on OpenStack’s SDN-related mechanisms due

to vulnerabilities identiﬁed in the past (Thimmaraju

et al., 2016) and its relevance to the current Open-

Stack architecture. We identiﬁed a general lack of

studies on cloud networking performance and secu-

rity, in particular regarding cloud operating systems.

Also, most existing studies focus on a client per-

spective. Only one of the surveyed studies analyses

performance from an infrastructure provider perspec-

tive (Sciammarella et al., 2016), and none of them

Lane, N., Koslovski, G., Pillon, M., Miers, C. and Gonzalez, N.

Software-Deﬁned Network Security over OpenStack Clouds: A Systematic Analysis.

DOI: 10.5220/0009471304230429

In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 423-429

ISBN: 978-989-758-424-4

423

Table 1: Studies on OpenStack SecNDs (Security Network Domains).

Study

Addressed network security domain Focused upon

Public Guest Management Data Client Provider

(Lar et al., 2011) 3 7 7 7 3 7

(Ristov et al., 2014) 3 3 3 7 3 7

(Carlsson, 2015) 3 7 7 7 3 7

(Felsch et al., 2015) 3 7 7 7 3 7

(Astrova et al., 2016) 3 7 7 7 3 7

(Thimmaraju et al., 2016) 7 7 3 3 7 3

(Qiu et al., 2017) 3 7 7 7 3 7

(Benjamin et al., 2017) 3 7 7 7 3 7

(Thimmaraju et al., 2018) 7 7 3 3 7 3

address provider security. This is especially impor-

tant for IaaS (Infrastructure-as-a-Service) since it is

the provider’s responsibilities to implement protec-

tion mechanisms and deploy secure infrastructure ser-

vices (CSA, 2017).

The paper is organised as follows: Section 2

presents the motivation for the investigation; Sec-

tion 3 presents OpenStack networking and SDN; Sec-

tion 4 presents a vulnerability vector; Section 5 analy-

ses a particular set of vulnerabilities identiﬁed in this

study; and Section 6 presents related work.

2 LITERATURE REVIEW

Our initial investigation efforts revealed a limited

number of studies related to OpenStack SecNDs, as

presented in Table 1. In each cell of the table the

symbols 3 and 7 indicate if a particular aspect is

addressed or not by each studied work. Most of

the studies addressed the public SecND, which is

focused on the client perspective of the cloud to

show potential customers the beneﬁts of cloud com-

puting. Other client-focused studies have also been

published in less quantity over the years addressing

other SecNDs (Venzano and Michiardi, 2013; Sci-

ammarella et al., 2016). However, only two works

covered provider’s cloud infrastructure (Thimmaraju

et al., 2016; Thimmaraju et al., 2018). This lack of

provider-side studies is not desirable, especially con-

sidering that vulnerabilities (and potential mitigation

solutions) typically are a product of a wide spectrum

investigation of the mechanisms involved. One ex-

ample is the SDN-related vulnerability (Thimmaraju

et al., 2016) which could be exploited to compro-

mise the OpenStack’s cloud infrastructure. Moreover,

the consequences of a provider-side vulnerability may

spread through all infrastructure, therefore compro-

mising all its users. This motivated a more thorough

research of infrastructural security vulnerabilities fo-

cusing on the provider’s mechanisms.

3 OpenStack AND SDN

OpenStack’s main networking service is called Neu-

tron. Further technologies can be added using its

API (Application Programming Interface). Exam-

ples include FWaaS (Firewall-as-a-Service), SDN,

LBaaS (Load-Balancer-as-a-Service), and VPNaaS

(Virtual-Private-Network-as-a-Service) (OpenStack-

Rocky, 2018b). Particularly, SDN applied to Open-

Stack enhances the cloud network infrastructure man-

agement by providing elasticity, ﬂexibility, and net-

work programmability. SDN separates switching

logic in the data plane and control plane, centring

its management over a single dedicated controller

or a cluster of distributed controllers that act as

a single entity through the use of location trans-

parency (Ku

zniar et al., 2015; Yu et al., 2015; Ma-

soudi and Ghaffari, 2016; Singh and Jha, 2017).

The SDN abstraction comprises three planes. The

application plane allows applications to request net-

work services to the control plane. The controller

communicates with the data plane and the switches

will forward the data at the physical layer based on

ﬂow tables, which are managed by the SDN con-

troller. The SDN abstraction is solely based on vir-

tualization technologies. These three planes commu-

nicate using two speciﬁc types of APIs: the north-

bound API, for bidirectional communication between

the control plane and application plane; and the south-

bound API, for bidirectional communication between

control plane and data plane.

There are several SDN standards, such as Open-

Flow and ForCES. OpenStack uses OpenFlow, the

most prominent open source implementation for the

southbound API. The speciﬁcation depends on the

support for the SDN controller solution and for the

vSwitch solution.

OpenStack’s network infrastructure is organised

in different NDs as presented in Figure 1. The public

ND comprises the external network, the public net-

work, and the API network. The management ND

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

424

comprises the storage network and the management

network. The guest ND only contains the guest net-

work.

Figure 1: Network infrastructure of an OpenStack cloud.

NDs are used for servicing tasks and also for in-

ternal communication rules between cloud services

required for operability and portability. In Figure 2

the OpenStack NDs are presented with some exam-

ples of main services and their relation to OpenStack

SecNDs.

Figure 2: OpenStack services associated to NDs.

Each ND has speciﬁc security mechanisms de-

ﬁned by the SecND, which also speciﬁes if communi-

cation between two NDs is possible and how it should

be conducted while addressing trust levels required by

each ND. The services associated to the SecNDs are

presented in Figure 3.

Figure 3: OpenStack services associated to security NDs.

4 OpenStack SDN Vulnerability

Vector

Based on the initial literature review we conducted

systematic research. We veriﬁed that OpenStack uses

Open vSwitch among several SDN and vSwitch con-

troller technologies. A SDN controller must be able

to communicate with Neutron through REST (Rep-

resentational State Transfer) in order to be supported

by OpenStack. Currently there are three main solu-

tions: Floodlight, OpenDaylight, and Ryu. Each solu-

tion has speciﬁc attributes, such as support for differ-

ent OpenFlow speciﬁcations and for different imple-

mentations of TLS (Transport Layer Security). There

are also similar aspects, such as open source projects

which support the same communication protocol.

Regarding vulnerabilities, we adopted two selec-

tion criteria to identify and evaluate SDN vulnerabil-

ities in OpenStack: 1)The results reported by the au-

thors of each study, focusing on main ﬁndings and the

potential impact of these vulnerabilities; and 2)Our

own analysis of the implications of the vulnerabilities

over the affected technologies regarding implementa-

tion, development, and ofﬁcial documentation from

each of the described projects.

Since OpenFlow is a common denominator for

these solutions, our systematic review used the fol-

lowing search string: “OpenFlow vulnerability OR

OpenFlow vulnerabilities OR OpenFlow ﬂaw OR

OpenFlow ﬂaws OR OpenFlow vulnerability* OR

OpenFlow vulnerabilities* OR OpenFlow ﬂaw* OR

OpenFlow ﬂaws*”. We adopted several scientiﬁc

search tools, such as Web of Knowledge, Engineer-

ing Village, and Scopus SciVerse. Table 2 presents

details of the results regarding the search tools used.

A hyphen indicates that the access to the tool was

restricted. Symbols 3 and 7 indicate service avail-

ability. This study was conducted until Decem-

ber 23, 2019.

Table 2: Scientiﬁc research tools and results.

Scientiﬁc research tool Results Promising Service tool

results status

Web of Knowledge - - 3

Engineering Village - - 3

Scopus SciVerse - - 7

IEEE Xplore 29 11 3

ACL DL 5.552 0 3

Science Direct 127 1 3

Springer Link 27 2 3

BASE 2 0 3

Scirus - - 7

InSpire HEP 0 0 3

CiteSeerX 1.787.998 0 3

DBLP 0 0 3

Ingenta Connect 0 0 3

Google Scholar 100 17 3

Due to the lack of studies addressing OpenStack

provider perspective, we also mapped all technolo-

gies with known vulnerabilities used in OpenStack.

The results are presented in the mind map in Figure 4,

which shows ﬁve major classes of potentially vulner-

able technologies. Our study focuses on SDNs since

there is a signiﬁcant number of security reports re-

lated to it. Also, the ﬁgure addresses related technolo-

Software-Deﬁned Network Security over OpenStack Clouds: A Systematic Analysis

425

Figure 4: Technologies associated to OpenStack.

gies speciﬁcally from the management network since

it is a very restricted network in terms of access from

the provider’s network. To the best of our knowl-

edge, these aspects have been not properly addressed

by previous works. One possible reason for this fact

is that this level of SecND is typically regarded as se-

cure, and therefore does not require further investiga-

tion, or because it does not directly face users, so the

main threat that could compromise the internal infras-

tructure are malicious insiders. However, the level of

trust delegated to this SecND heavily depends on ex-

isting bridges it has with other SecNDs, which lowers

its trust level. This is illustrated by Figure 5.

Figure 5: Trust between different OpenStack SecNDs,

Adapted from (OpenStack, 2018b).

5 ANALYSIS

Following the methodology and preliminary results

presented in the previous sections, we identiﬁed sev-

eral security vulnerabilities associated to technologies

used by OpenStack. Also, we identiﬁed chain re-

actions that might occur if a vulnerable technology

is used by another more complex technology that is

used by OpenStack, which consequently can be used

to exploit OpenStack infrastructure. This led to the

deﬁnition of a vulnerability vector which allows to

evaluate all the identiﬁed vulnerabilities. This vec-

tor affects OpenStack infrastructure solely through its

SDN-related mechanisms. The results are presented

in Table 3. Table 3 shows a total of 11 vulnerabili-

ties. We provide a qualitative classiﬁcation based on

the severity and potential impact on OpenStack in-

frastructure:

• High Severity: Vulnerability with potential to

compromise the SDN controller, subduing Neu-

tron’s architecture and allowing an attacker to

take control of the OpenStack infrastructure or

highly compromise its operability (Thimmaraju

et al., 2016). From the control plane the attacker

acquires privileged and unrestricted access over

OpenStack infrastructure.

• Average Severity: Vulnerability with potential to

obtain sensitive information and even modify it,

which combined with other attacks has the po-

tential to compromise speciﬁc areas of the SDN

architecture. This access, however, is limited in

terms of privilege to a speciﬁc node.

• Low Severity: Vulnerability with potential to ac-

quire information about the SDN architecture.

This typically is an initial step before launching a

more dangerous attack, so although it might have

low severity, it must be stopped before the attacker

acquires enough information about the system to

then compromise it with more severity.

Nine of the identiﬁed vulnerabilities are related to

ambiguities in OpenFlow speciﬁcation (from version

1.0.0 on 2009 to 1.5.1 on 2015), most due to the lack

of a clear feature deﬁnition. The other two vulnerabil-

ities identiﬁed in our study are due to the implementa-

tion of unspeciﬁed services in regard to the OpenFlow

speciﬁcation. One vulnerability only affects Open-

Daylight, while the other affects all controllers tested.

The most severe vulnerability is related to the usage of

the TLS 1.0 implementation for SDN controller com-

munication.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

426

Table 3: Vulnerability vector over OpenStack’s SDN architecture.

Open source affected solutions

SDN controllers vSwitches

Floodlight 1.2 OpenDaylight Fluorine Ryu 2.28 OvS 2.10.90

Index Implicates Vulnerability alias Severity

TLS

Man-in-the-Middle High 3 3 3 3

2 Switch authentication High 3 3 3 7

3 Flow table Flow Table overlap Average 3 3 3 7

Excessive requests

towards the SDN

controller

Widespread

DoS– I

Low 3 3 3 7

Low network

intrusiveness DoS – II

Average 3 3

Undeﬁned

authorization criteria

for distributed

SDN architecture

High 3 3 3 7

Undeﬁned granular

access/management

for distributed SDN

architecture

High 3 3 3 7

Switch tampering

High 3 3 3 3

9 Information

disclosure

Aggregation

link information

disclosure – I

Low 3 3 3 7

RTT

information

disclosure – II

Low 3 3 3 7

Host tracking

service

Host hijacking attack Average 7 3 7 7

Table 3 also reveals that the majority of the iden-

tiﬁed vulnerabilities is related to excessive number

of requests to the SDN controller. An alternative

OpenFlow speciﬁcation was produced in 2013 (ONF,

2013) to address this particular issue. However, the

security aspects are still not being adequately ad-

dressed in a timely fashion once discovered. A signif-

icant number of security studies (NWG, 2012; Chung

et al., 2013; OTHMAN, 2013; Dover, 2013; Ben-

ton et al., 2013; Kloti, 2013; Kandoi and Antikainen,

2015; Tiwari et al., 2014; Hong et al., 2015; Brooks

and Yang, 2015; Kandoi and Antikainen, 2015; Chel-

lani, 2016; Thimmaraju et al., 2016; Cui et al., 2016;

Agborubere and Sanchez, 2017; Dargahi et al., 2017;

Mostovich et al., 2017; Li et al., 2017; Zhou et al.,

2018; Mutaher et al., 2018; Bhatia et al., 2018; Ilyas

and Khondoker, 2018) identiﬁed vulnerabilities in

OpenFlow and we observed that they usually exploit

the same vulnerability or a small variation over the

years until present time (2019). The vulnerability vec-

tor we engineered only maps vulnerabilities relevant

to the OpenStack SDN context, which operates along

with the OpenFlow southbound protocol of communi-

cation. Several of these vulnerabilities were ﬁrst dis-

covered circa 2013 and they still affect the OpenFlow

protocol.

Figure 6 summarises our ﬁndings in terms of num-

ber of vulnerabilities associated to each solution or

technology. Most vulnerabilities are associated to

OpenFlow’s speciﬁcation. If the speciﬁcation ad-

dressed vulnerabilities and issues already identiﬁed

by previous works, changed the TLS cryptography

standard to the required, and if OpenStack SDN re-

lated technologies implemented the appropriate TLS

standard at least four out of eleven ( 36%) vulnerabil-

ities would be mitigated, several with high severity.

Figure 6: Vulnerability distribution across technologies.

6 RELATED WORK

Due to the lack of studies focusing on the security

of management networks, we also analysed works

related to networking performance. (Venzano and

Michiardi, 2013) evaluate OpenStack’s capacity to

execute applications with high data volume. The au-

thors did not address aspects related to security. (Sci-

ammarella et al., 2016) provide a characterisation of

Software-Deﬁned Network Security over OpenStack Clouds: A Systematic Analysis

427

management network trafﬁc. The authors also did not

address security of these networks.

(Thimmaraju et al., 2016) provide a proof of con-

cept for vulnerabilities in Open vSwitch applied to

OpenStack. The authors exploited this vulnerability

over the SDN data plane, compromising the manage-

ment network domain and therefore acquiring unre-

stricted access to the cloud infrastructure. Finally,

(Thimmaraju et al., 2018) propose a new threat model

for virtual switches to satisfy the requirements identi-

ﬁed in their previous study.

7 CONSIDERATIONS & FUTURE

WORK

This work proposes a vulnerability vector addressing

security aspects related to technology and implemen-

tation with focus on the SDN technologies used by

OpenStack. We identiﬁed eleven vulnerabilities with

different levels of severity, which are related to the

potential damage they might inﬂict to OpenStack’s

infrastructure. Those with the highest severity can

be exploited to fully compromise the infrastructure.

Moreover, several of these vulnerabilities can be mit-

igated by adopting newer and more secure methods

to protect the trafﬁc between different planes and se-

curity domains. We intend to extend our research to

other open source cloud platforms.

ACKNOWLEDGEMENTS

The authors would like to thank the support of

the LabP2D/UDESC, providing its facilities and re-

sources to the accomplishment of this research.

FAPESC supported LabP2D infrastructure.

REFERENCES

Agborubere, B. and Sanchez, E. (2017). OpenFlow Com-

munications and TLS Security in Software-Deﬁned

Networks. pages 560–566.

Astrova, I., Koschel, A., and Henke, M. L. (2016). IaaS

Platforms: How Secure are They? In 2016 30th In-

ternational Conference on Advanced Information Net-

working and Applications Workshops (WAINA), pages

843–848.

Benjamin, B., Coffman, J., Esiely-Barrera, H., Farr, K.,

Fichter, D., Genin, D., Glendenning, L., Hamilton, P.,

Harshavardhana, S., Hom, R., Poulos, B., and Reller,

N. (2017). Data Protection in OpenStack. In 2017

IEEE 10th International Conference on Cloud Com-

puting (CLOUD), pages 560–567.

Benton, K., Camp, L. J., and Small, C. (2013). OpenFlow

vulnerability assessment. page 151. ACM Press.

Bhatia, S., Nathani, K., and Sharma, V. (2018). Review

on Software-Deﬁned Networking: Architectures and

Threats. In Bhateja, V., Nguyen, B. L., Nguyen, N. G.,

Satapathy, S. C., and Le, D.-N., editors, Information

Systems Design and Intelligent Applications, volume

672, pages 1003–1011. Springer Singapore, Singa-

pore.

Brooks, M. and Yang, B. (2015). A Man-in-the-Middle

Attack Against OpenDayLight SDN Controller. In

Proceedings of the 4th Annual ACM Conference on

Research in Information Technology, RIIT ’15, pages

45–49, New York, NY, USA. ACM.

Carlsson, A. (2015). Model of network attack on the cloud

platform OpenStack. In 2015 Second International

Scientiﬁc-Practical Conference Problems of Infocom-

munications Science and Technology (PIC S T), pages

245–247.

Chellani (2016). Enhancing Security in OpenFlow.

Chung, C., Khatkar, P., Xing, T., Lee, J., and Huang,

D. (2013). NICE: Network Intrusion Detection and

Countermeasure Selection in Virtual Network Sys-

tems. IEEE Transactions on Dependable and Secure

Computing, 10(4):198–211.

CSA (2017). Security Guidance For Critical Areas of Focus

in Cloud Computing v4.0.

Cui, H., Karame, G. O., Klaedtke, F., and Bifulco, R.

(2016). On the Fingerprinting of Software-Deﬁned

Networks. IEEE Transactions on Information Foren-

sics and Security, 11(10):2160–2173.

Dargahi, T., Caponi, A., Ambrosin, M., Bianchi, G., and

Conti, M. (2017). A Survey on the Security of State-

ful SDN Data Planes. IEEE Communications Surveys

Tutorials, 19(3):1701–1725.

Dover (2013). A denial of service attack against the Open

Floodlight SDN controller.

Felsch, D., Heiderich, M., Schulz, F., and Schwenk, J.

(2015). How Private is Your Private Cloud?: Secu-

rity Analysis of Cloud Control Interfaces. pages 5–16.

ACM Press.

Hong, S., Xu, L., Wang, H., and Gu, G. (2015). Poison-

ing Network Visibility in Software-Deﬁned Networks:

New Attacks and Countermeasures.

Ilyas, Q. and Khondoker, R. (2018). Security Analysis of

FloodLight, ZeroSDN, Beacon and POX SDN Con-

trollers. In Khondoker, R., editor, SDN and NFV Secu-

rity, volume 30, pages 85–98. Springer International

Publishing, Cham.

Iqbal, M. and Dagiuklas, A. (2017). Infrastructure as a Ser-

vice (IaaS): A Comparative Performance Analysis of

Open-Source Cloud Platforms.

Kandoi, R. and Antikainen, M. (2015). Denial-of-service

attacks in OpenFlow SDN networks. In 2015

IFIP/IEEE International Symposium on Integrated

Network Management (IM), pages 1322–1326.

Kloti, R. (2013). OpenFlow: A security analysis. pages

1–6. IEEE.

zniar, M., Pere

ıni, P., and Kosti

c, D. (2015). What You

Need to Know About SDN Flow Tables. In Mirkovic,

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

428

J. and Liu, Y., editors, Passive and Active Measure-

ment, Lecture Notes in Computer Science, pages 347–

359. Springer International Publishing.

Lar, S. u., Liao, X., and Abbas, S. A. (2011). Cloud com-

puting privacy & security global issues, challenges,

& mechanisms. In 2011 6th International ICST Con-

ference on Communications and Networking in China

(CHINACOM), pages 1240–1245.

Li, C., Qin, Z., Novak, E., and Li, Q. (2017). Securing

SDN Infrastructure of IoT–Fog Networks From MitM

Attacks. IEEE Internet of Things Journal, 4(5):1156–

1164.

Masoudi, R. and Ghaffari, A. (2016). Software deﬁned net-

works: A survey. Journal of Network and Computer

Applications, 67:1–25.

Mostovich, D., Fabrikantov, P., Vladyko, A., and

Buinevich, M. (2017). High-level vulnerabilities

of software-deﬁned networking in the context of

telecommunication network evolution. In 2017 IEEE

Conference of Russian Young Researchers in Elec-

trical and Electronic Engineering (EIConRus), pages

184–186, St. Petersburg and Moscow, Russia. IEEE.

Mullerikkal, J. P. and Sastri, Y. (2015). A Comparative

Study of OpenStack and CloudStack. In 2015 Fifth

International Conference on Advances in Computing

and Communications (ICACC), pages 81–84.

Mutaher, H., Pradeep, K., and Abdul, W. (2018). Open-

Flow controller-based SDN: Security issues and coun-

termeasures. International Journal of Advanced Re-

search in Computer Science.

NWG (2012). Security Analysis of the Open Networking

Foundation (ONF) OpenFlow Switch Speciﬁcation.

ONF (2013). OpenFlow speciﬁcation 1.3.3.

OpenStack (2018a). OpenStack Docs: Networking ser-

vices.

OpenStack (2018b). OpenStack Docs: Security boundaries

and threats.

OpenStackRocky (2018a). OpenStack Docs: Rocky.

OpenStackRocky (2018b). OpenStack Docs: Service Ex-

tensions.

OTHMAN (2013). Securing Distributed Control of Soft-

ware Deﬁned Networks. IJCSNS International Jour-

nal of Computer Science and Network Security , VOL.

13 No .9.

Qiu, Y., Shen, Q., Luo, Y., Li, C., and Wu, Z. (2017). A

Secure Virtual Machine Deployment Strategy to Re-

duce Co-residency in Cloud. In 2017 IEEE Trust-

com/BigDataSE/ICESS, pages 347–354.

Ristov, S., Gusev, M., and Donevski, A. (2014). Secu-

rity Vulnerability Assessment of OpenStack Cloud.

In 2014 Sixth International Conference on Computa-

tional Intelligence, Communication Systems and Net-

works, pages 95–100.

Rosado, T. and Bernardino, J. (2014). An Overview of

Openstack Architecture. In Proceedings of the 18th

International Database Engineering & Applications

Symposium, pages 366–367, New York, NY, USA.

ACM.

Sciammarella, T., Couto, R., Rubinstein, M., Campista, M.,

and Costa, L. (2016). Analysis of Control Trafﬁc in a

Geo-Distributed Collaborative Cloud. pages 224–229.

Singh, S. and Jha, R. K. (2017). A Survey on Software De-

ﬁned Networking: Architecture for Next Generation

Network. Journal of Network and Systems Manage-

ment, 25(2):321–374.

Thimmaraju, K., Shastry, B., Fiebig, T., Hetzelt, F., Seifert,

J.-P., Feldmann, A., and Schmid, S. (2016). Reigns

to the Cloud: Compromising Cloud Systems via the

Data Plane. page 15.

Thimmaraju, K., Shastry, B., Fiebig, T., Hetzelt, F., Seifert,

J.-P., Feldmann, A., and Schmid, S. (2018). Taking

Control of SDN-based Cloud Systems via the Data

Plane. pages 1–15. ACM Press.

Tiwari, V., Parekh, R., and Patel, V. (2014). A Survey on

Vulnerabilities of Openﬂow network and its impact on

SDN/Openﬂow controller. World Academics Journal

of Engineering Sciences, 01(01):1005.

Venzano, D. and Michiardi, P. (2013). A Measurement

Study of Data-Intensive Network Trafﬁc Patterns in a

Private Cloud. In Proceedings of the 2013 IEEE/ACM

6th International Conference on Utility and Cloud

Computing, pages 476–481, Washington, DC, USA.

IEEE Computer Society.

Vogel, A., Griebler, D., Maron, C. A. F., Schepke, C.,

and Fernandes, L. G. (2016). Private IaaS Clouds:

A Comparative Analysis of OpenNebula, CloudStack

and OpenStack. In 2016 24th Euromicro International

Conference on Parallel, Distributed, and Network-

Based Processing (PDP), pages 672–679.

Wen, X., Gu, G., Li, Q., Gao, Y., and Zhang, X. (2012).

Comparison of open-source cloud management plat-

forms: OpenStack and OpenNebula. In 2012 9th In-

ternational Conference on Fuzzy Systems and Knowl-

edge Discovery, pages 2457–2461.

Yu, C., Lumezanu, C., Sharma, A., Xu, Q., Jiang, G., and

Madhyastha, H. V. (2015). Software-Deﬁned Latency

Monitoring in Data Center Networks. In Mirkovic, J.

and Liu, Y., editors, Passive and Active Measurement,

Lecture Notes in Computer Science, pages 360–372.

Springer International Publishing.

Zhou, Y., Chen, K., Zhang, J., Leng, J., and Tang, Y. (2018).

Exploiting the Vulnerability of Flow Table Overﬂow

in Software-Deﬁned Network: Attack Model, Evalua-

tion, and Defense. Security and Communication Net-

works, 2018:1–15.

Software-Deﬁned Network Security over OpenStack Clouds: A Systematic Analysis

429