1

Software-Defined Perimeter (SDP): State of the ArtSecure Solution for Modern Networks

Abdallah Moubayed∗, Ahmed Refaey ∗†, and Abdallah Shami∗∗ Western University, London, Ontario, Canada; e-mails: {amoubaye, abdallah.shami, ahusse7}@uwo.ca

† Manhattan College, Riverdale, New York, USA; e-mail: {ahmed.hussein}@manhattan.edu

Abstract—The boom in evolution and adoption of new technologies,architecture, and paradigms such as cloud computing, softwaredefined networking (SDN), and network function virtualization(NFV) in recent years has led to a new set of security and privacychallenges and concerns. These challenges/concerns include properauthentication, access control, data privacy, and data integrity amongothers. Software defined perimeter (SDP) has been proposed as asecurity model/framework to protect modern networks in a dynamicmanner. This framework follows a need-to-know model where adevice’s identity is first verified and authenticated before gainingaccess to the application infrastructure. In this paper, a briefdiscussion of the security and privacy challenges/concerns facingmodern cloud-based networks is presented along with some ofthe related work from the literature. Moreover, the SDP concept,architecture, possible implementations, and challenges are described.Furthermore, an SDP-based framework adopting a client-gatewayarchitecture is proposed with its performance being evaluated usinga virtualized network testbed for an internal enterprise scenarioas a use case. To the best of our knowledge, no previous workprovided a quantitative performance evaluation of such a framework.Performance evaluation results show that the SDP-secured network isresilient to denial of service attacks and port scanning attacks despiteneeding longer initial connection setup time. The achieved results ce-ment the promising potential of SDP as a security model/frameworkthat can dynamically protect current and future networks.

Index Terms—Cloud Computing, Security, Privacy, Software-Defined Perimeter (SDP), Internal Enterprise

I. INTRODUCTION

Recent years have seen a boom in the evolution and the pro-liferation of technology in our daily lives. The number of smart-phones, mobile-connected wireless devices, social networks, andsensors being used has grown substantially due to the emergenceof the concept of Internet of Things (IoT). It was predicted bythe National Cable & Telecommunications Association (NCTA)that the number of IoT devices will reach approximately 50billion devices by the year 2020 [1]. To handle the increasingnumber of devices, several technologies and paradigms have beenproposed. At the forefront of these technologies and paradigmsare cloud computing, software-defined networking (SDN), andnetwork function virtualization (NFV). Cloud computing hasbecome a main component of the current technology landscapewith more than 93% of organizations using cloud services insome shape or form [2]. As the cornerstone of Internet-of-things(IoT)-based infrastructures, cloud computing has advanced a widevariety of applications such as patient monitoring and smart cities[3]. Projections performed by Microsoft predicts that the marketsize of cloud computing will reach 156.4 billion dollars by the

Corresponding author: Dr. Abdallah Shamiemail: abdallah.shami@uwo.ca

year 2020 [4]. Similarly, the global market for SDN and NFV isexpected to reach 54 billion dollars by the year 2022 [5,6].

However, the adoption of such technologies and architectureshas presented a new set of challenges, in particular those havingto do with security. For example, McAfee reported that 52%of the respondents surveyed for their report indicated that theytracked a malware infection to a Software-as-a-service (SaaS)application [2]. Moreover, it was reported that more than 6.1million DDoS campaigns occurred in 2017 with both the Mel-bourne IT registrar attack and DreamHost attack being the mostprominent [7]. Related challenges include having inadequate trustand authentication models, vulnerability to jamming and sniffingattacks, possibility of data loss or modification, and the possi-bility of information leakage [8]–[10]. Furthermore, other notablechallenges facing such deployments are their vulnerability to man-in-the middle attacks, having inadequate access control measures,and the possibility of network intrusion [9,11]. As a result, anexploration into new security measures to protect cloud-basednetworks has commenced. This is because traditional perimeterdefense techniques have proven to be inadequate in protecting theinfrastructure from network attacks [12,13].

A promising solution is a Software-defined perimeter (SDP),the concept proposed by the Cloud Security Alliance (CSA) asa security model/framework that has the potential to protect net-works in a dynamic manner [12,13]. This concept was developedbased on the Global Information Grid (GIG) Black Core networkinitiative proposed by the Defense Information Systems Agency(DISA) [14]. This model follows a need-to-know model wherethe device’s/application’s identity is first verified and authenticatedbefore it is granted access to the application infrastructure [12,13].Essentially, the infrastructure becomes “black”, meaning, it isundetectable by infrastructures unauthorized to see it [12,13]. Thisin turn can help mitigate many network-based attacks such asserver scanning, denial of service, password cracking, man-in-themiddle attacks, and many others [12,13].

In this paper, the security challenges/concerns facing mod-ern networks are presented. Moreover, the SDP framework- asa potential solution- is described in more detail in terms ofits concept, architecture, and possible implementations. Also,the anticipated challenges facing the SDP framework are alsoenumerated. Furthermore, an SDP-based framework adopting aclient-gateway architecture is proposed. The performance of theframework is evaluated using an internal enterprise scenario interms of connection setup time and network throughput undertwo types of network attacks, namely denial of service attack andport scanning attack. To the best of our knowledge, no previouswork provides a quantitative performance evaluation of such a

2

Fig. 1: Challenges/Concerns in Modern Networks

framework. Therefore, the contributions of this paper can besummarized as follows:

• Propose the SDP framework as a potential security solutionfor modern networks in terms of its concept, architecture,and possible implementations.

• Evaluate and analyze the performance of the SDP frameworkin an internal enterprise scenario using a virtualized networktestbed.

The remainder of this paper is organized as follows: SectionII discusses the security challenges/concerns and describes theSDP concept, architecture, and possible applications as a newproposed solution. Section III then presents some of the challengesfacing the SDP framework. Section IV describes the SDP-basedframework. Section V evaluates the performance of the proposedSDP client-gateway framework to secure an internal enterprisenetwork. Lastly, Section VI concludes the paper and presents somefuture directions.

II. SOFTWARE DEFINED PERIMETER (SDP)

Despite the many advantages provided by adopting innova-tive architectures such as both SDN-based architectures and fogcomputing-based architectures to enhance the connection betweenedge and cloud computing, several challenges/concerns arise insuch architectures [8]–[11]. As shown in Fig. 1, these chal-lenges/concerns can be divided into three main categories: securitychallenges/concerns, privacy challenges/concerns, and availabilitychallenges/concerns. More specifically, these categories includechallenges such as authentication, access control, data integrityand privacy, and data availability. This results in added pressureon providers to offer frameworks and services that address thesechallenges. For interested readers, further details are available in[8]–[11].

Software-defined perimeter (SDP) is a potential solution totackle many of the security and privacy challenges facing futurenetworks. SDP was originally proposed by the Cloud SecurityAlliance (CSA) as a security model/framework having a dynamicability to protect networks [12,13]. This was part of the GlobalInformation Grid (GIG) Black Core network initiative proposed bythe DISA agency [14]. It adopts a need-to-know model where the

device’s/application’s identity is granted access to the applicationinfrastructure upon first being verified and authenticated [12,13].Due to this selective process, the infrastructure is referred to as“black”. This is because it cannot be detected by users who areunauthorized to see it [12,13]. As a result, this can effectivelymitigate many network-based attacks including server scanning,denial of service, and man-in-the middle attacks among manyothers [12,13]. In what follows, the SDP concept, architecture,and possible implementations are discussed in more details.

A. Concept:

The SDP concept is built on the notion of providing applica-tion/service owner(s) with the power to deploy perimeter function-ality as needed to protect their servers. This is done by adoptinglogical components in place of any physical appliances. Thesecomponents are controlled by the application/service owner(s) andserve as a protection mechanism. The SDP architecture only pro-vides access to a client’s device after it verifies and authenticatesits identity. Such an architecture has been adopted by multipleorganizations within the Department of Defense in which serversof classified networks are hidden behind an access gateway.The client must first authenticate to this gateway before gainingvisibility and access to the server and its applications/services.The aim is to incorporate the logical model adopted in classifiednetworks into the standard workflow (presented in more details inSection II-B). Hence, the SDP architecture leverages the benefitsof the need-to-know model while simultaneously eliminating theneed for a physical access gateway. The general concept is thatclient’s devices/applications are first authenticated and authorizedbefore creating encrypted connections in real-time to the requestedservers.

The SDP architecture is composed of and relies on five separatesecurity layers:

1) Single Packet Authentication (SPA): SPA is the cornerstoneof device authentication. The SDP uses this SPA to rejecttraffic to it from unauthorized devices. The first packet iscryptographically sent from the client’s device to the SDPcontroller where the device’s authorization is verified beforegiving it access. The SPA is then again sent by the device

3

to the gateway to help it determine the authorized device’straffic and reject all other traffic.

2) Mutual Transport Layer Security (mTLS): Transport layersecurity (TLS) was originally designed to enable deviceauthentication and confidential communication over the In-ternet. Despite the fact that the standard offers mutual deviceauthentication, it has typically only been used to authenticateservers to clients. However, the SDP utilizes the full powerof the TLS standard to enable mutual two-way cryptographicauthentication.

3) Device Validation (DV): Device validation adds an extra layerof security by ensuring that the cryptographic key used is heldby the proper device. This is because mTLS only proves thatthe key has not expired nor has it been revoked. However,it cannot prove that it has not been stolen. Therefore, DVverifies that the device belongs to an authorized user and isrunning trusted software.

4) Dynamic Firewalls: In contrast to traditional static firewallsthat can have hundreds or thousands of rules, dynamic fire-walls have one constant rule which is to deny all connections.The SDP adopts a dynamic firewall policy at the gateway byvigorously adding and removing rules to allow authenticatedand authorized users to access the protected applications andservices.

5) Application Binding (AppB): Application binding refers tothe process of forcing authorized applications to use theencrypted TLS tunnels created by the SDP. This is doneafter the device and the user are properly authenticated andauthorized. This ensures that only authorized applications cancommunicate through the tunnels while unauthorized onesare blocked.

These protocols combined make it extremely challenging formalicious users and attackers to access protected applications andservices. Consequently, the SDP framework can address many ofthe aforementioned security, privacy, and availability challengesincluding: authentication & trust, access control, data privacy, dataavailability, and services availability.

It is worth mentioning that the complexity of this frameworkis mainly based on that of the hash function used as part ofthe encryption/decryption of the SPA packet since the other foursecurity layers of the framework already exist. For example, dy-namic firewalls are used in layer 3. In contrast to traditional staticfirewalls deployed in existing systems which can have hundredsor thousands of rules, dynamic firewalls have one constant rulewhich is to deny all connections. The proposed framework adoptsa dynamic firewall policy at the gateway by vigorously addingand removing rules to allow authenticated and authorized users toaccess the protected applications and services. This does not addto or change the existing system’s complexity.

B. Architecture:

The SDP framework’s architecture consists of three main com-ponents [12,13]:

a) SDP Controller: The SDP controller is the central ele-ment in the SDP framework. It is responsible for all the controlmessages exchanged by functioning as a trust broker between theinitiating SDP host and backend security controls. This includesissuing certificates and authenticating devices (both initiating and

accepting hosts). Moreover, it determines the services that eachinitiating host is authorized to access in the accepting host.Furthermore, it helps configure both the SDP initiating host andaccepting host in real time to create the mutual TLS tunnel [12,13].

b) SDP Client/Initiating Host (IH): SDP Initiating Hosts arethe SDP-enabled clients that submit a request to connect to a ser-vice or application. This request is submitted to the SDP controllerwhich will authenticate the IH by requesting information abouthardware or software within the IH. Once authentication usingthe previously issued certificate, a mutual TLS tunnel is createdthat connects the IH to the server or application for which it hasauthorization. This helps improve the access control since the IHonly gets access to the server or application after being properlyauthenticated [12,13].

c) SDP Accepting Hosts (AH): On the other hand, theSDP Accepting Host (AH) is the device instructed to acceptauthorized services or applications. It is originally set up to rejectall incoming packets and requests from all hosts except the SDPcontroller. The SDP host is typically protected by an SDP gatewaywhich acts as the protector. This gateway is the termination pointfor the mutual TLS tunnel from the IH. This is done after the SDPcontroller provides the gateway with the verified and authenticatedIH’s IP address and certificates [12,13].

C. Potential Applications:

The SDP architecture can be implemented in several waysdespite the workflow remaining the same. This includes client-to-gateway, client-to-server, server-to-server, and client-to-server-to-client; making it suitable for a variety of applications as shownin what follows.

1) Core Networks:Despite the appeal of NFV for core networks in terms of

dynamically creating, managing, and adjusting security zones dueto the automated placement of virtualized firewalls and creationof dedicated software firewalls on-demand, it is prone to severalsecurity vulnerabilities such as resource exhaustion, service hi-jacking through the self-service portal, and service insertion. Forexample, due to the sharing of the physical servers’ resourcesamong different VMs, severe resource exhaustion can occur thatcan negatively impact VM availability. An SDP framework cantackle this by defining and implementing a VM throttling detectionmechanism by the controller and having it instantly propose aremedy. Another example is the service hijacking through theself-service portal. Once again, the SDP proves its vital role ineliminating this risk by using administrative controls selectively,based on users’ roles and needs.

2) Mobile Networks:The emergence of Internet of Things (IoT) and machine-to-

machine (M2M) technologies due to the deployment of a billion-plus smart connected devices worldwide have positively impactedbusinesses. However, the protocols used in IoT raises a realconcern regarding aspects in security. Despite most of theseprotocols being designed for wireless sensor networks, they havehad a sudden and unanticipated role in the core of the IoTsolution. Message Queuing Telemetry Transport (MQTT) is agood example of a viable transport layer for wireless networksin the IoT era. When the MQTT protocol was designed, itssecurity was not a priority because it had been typically deployed

4

in secure, back-end networks for application-specific purposes.Moreover, due to the two-way handshake mechanism adopted,the protocol is vulnerable to hijacking and man-in-the-middleattacks. The SPA packet mechanism used in an SDP frameworkcan replace the username/password login mechanism. Moreover,the “blackening” of receiving devices is an added security layer toprotect against hackers since they become undetectable to them.Also, all SPA packets are encrypted and authenticated with anHMAC signature. This leads to malicious users having to firststeal the SDP credentials to be able to spoof an SPA packet.The combination of this with the logging of all validated SPApackets by the SDP gateway creates a broker immune to fakedand replayed SPA packets.

3) Internal Enterprises Networks:Given the continued adoption of the Bring your own device

(BYOD) concept and the increased number of mobile workers,the traditional perimeter concept becomes obsolete and uncontrol-lable. Hence, securing the internal enterprise network became atedious task with system administrators having to take aggressivedecisions just to avoid the threats. Virtual private networks (VPN)have provided secure access to virtual local area networks forremote users. However, such legacy VPNs were designed for the1990s networks and thus are obsolete due to their lack of agility inprotecting digital businesses [15]. In contrast, an SDP frameworkallows organizations and enterprises to keep cloud resourcesdark to unauthorized users. This helps protect against a varietyof attacks including network flood attacks, brute-force attacks,and TLS vulnerabilities. Hence, by having a “dark net” aroundthe servers, an SDP framework can facilitate the managementand security of organizations’ cloud resources. Therefore, SDPcan provide an ideal VPN solution for any size organizationas it provides cloud-based controllers, gateways, and up-to-datesoftware defined security perimeters to deliver secure, dynamicvirtual connectivity.

This work focuses on the internal enterprise case and proposesan SDP-based framework to protect it. Since the SDP frameworkadopts a zero-trust architecture by authenticating and verifying ahost for every session, it can address the potential lateral threatmodel often found in such environments. The performance of theframework is evaluated for both the SDP and non-SDP case toshow the potential of SDP as a security model and alternative toVPNs for internal enterprise networks.

III. SDP OPEN CHALLENGES

Despite the many advantages that the SDP architecture pro-vides with respect to protecting against various network securitybreaches and attacks, it faces several challenges:

• Possible Network Disruption: Since the SDP architectureis different than traditional security measures deployed innetworks, integrating a complete SDP solution can lead tonetwork and infrastructure disruption. This can be problem-atic due to the size of the services that may be off duringsuch a disruption.

• Configuration Updates: A second challenge is updating allthe applications and system configurations in such a mannerthat they become aware of the SDP. This will allow them toaccess the workflow and the secure tunnels created withinthe SDP.

Fig. 2: Proposed SDP Framework For Internal Enterprise Network

• Controller Vulnerability: Because the SDP controller has amajor role in the architecture and hence the overall securityof the network, protecting it becomes paramount. Moreover,given that it is a possible centralized point of failure, it needsto be made highly available and secured.

IV. PROPOSED FRAMEWORK

As mentioned earlier, the SDP is composed of three maincomponents: client, gateway and controller. For the purpose ofthis work, the SDP architecture proposed and implemented is theclient-gateway architecture as shown in Fig. 2 which can faithfullydescribe an internal enterprise network scenario. In this case, thegateway also acts as the application server and hosts the serviceto be accessed. The functions of the three components are asdescribed below:

• Controller: The controller is the main component of SDP.It contains the details of the authorized clients and servers,provides the details of rules to the gateway and controls theauthentication of each component. The controller proposed inthis work makes use of a database for all the above purposes.The database contains the details of all the hosts involved,which is then sent to the gateway. It authenticates these hostswith the help of certificates.

• Gateway: The gateway enforces the rules which preventany unauthorized access to the service hidden behind it. Bydefault, the gateway blocks all traffic. However, once thecontroller provides the list of authorized initiating (clients)and accepting hosts (servers) and the list of services, it setsup rules which allow a connection to be established betweenthe two while preventing all other traffic. This includes anyattempt by the authorized hosts to establish a connection to aservice they are not authorized to access. In this work, theserules are setup using the iptables.

• Client: The client is the machine trying to access a service. InSDP, the client first connects to the controller and informs itabout the service it wishes to access. Once the verification iscomplete, it attempts to connect to the service hidden behindthe gateway. The gateway will allow the connection requestto go through and thus, the client-server data transfer can take

5

place. Ideally, once the connection is established it should notbe reset until specifically requested.

The whole process of SDP, as shown in Fig. 3, involves thefollowing steps:

1) The gateway initiates a TLS connection to the controller andsends an SPA packet.

2) The controller verifies the gateway using a certificate presentin the gateway.

3) The controller establishes a mTLS secured connection be-tween itself and the gateway.

4) The controller then proceeds to send all the information aboutthe initiating and accepting hosts as well as the authorizedservices to the gateway.

5) The client initiates a TLS connection to the controller andsends its own SPA packet.

6) The controller verifies the client using a certificate present inthe client.

7) The controller establishes a mTLS secured connection be-tween itself and the client.

8) The client sends another encrypted authentication SPA packetto the gateway.

9) The packet is decrypted with the keys provided by thecontroller.

10) The information in the decrypted packet is then crosscheckedwith the information it received from the controller.

11) The gateway sets up the corresponding firewall rules after apositive crosscheck.

12) The client attempts to connect to the service.13) The connection is established once the gateway allows the

connection request to pass and data transfer can take place.

V. PERFORMANCE EVALUATION

A. Virtualized Network Testbed Description:

Waverly Labs’ OpenSDP project was used to implement theproposed framework with the previously discussed componentsbeing programmed using C, Python, and NodeJS. Each componentwas set up on a separate virtual machine with a fourth acting asan unauthorized host.

A mySQL database was implemented in the controller to formthe basis of the list of authorized hosts and services. Within thisdatabase, several tables have been created including: sdpid, ser-vice, service gateway and sdpid service. The first table containsthe details of each component within the SDP-enabled setup, theSDP ID assigned to each component, their decryption and HMACkeys, and timestamps of the last update done on the keys etc. Thesecond table is used to define the service ID for each serviceauthorized to be accessible by a host SDP ID while the thirddefines the gateway ID which protects a particular service. Finally,the fourth table specifies the mapping of the service ID to theprotocol and port number of the service. The controller creates ahash of this information and sends it to the gateway to be usedas a verification mechanism. Once the authentication is complete,a SSL connection is established, and the keys are updated. Theseconnections are persistent as long as both sides keep them open.The controller also informs all gateways about any changes madein the SDP network and immediately transmits it to them.

On the other hand, the gateway sets up the forwarding rulesfor successful transmission of authorized packets by making use

of the iptables. Another available option is firewalled wherein thegateway makes use of the FireWall KNock OPerator (FWKNOP)mechanism for packet authorization. Using this mechanism, theclient sends the Single Packet Authorization (SPA) packet, a spe-cially craft encrypted packet, to the gateway. To authenticate thepackets, the gateway first connects to the controller and downloadsall the necessary information. Note that the firewall’s default ruleis drop-only. Iptables consists of three tables: INPUT, OUTPUTand FORWARD. Their functions are self-explanatory. FWKNOPcreates another table called FWKNOP INPUT which contains thedetails of the source and destination IP of the authorized packet.It also contains details of the protocol and port number of theservice. The gateway attempts to decode the packet as soon as itreceives it with the keys obtained from the controller. Once thepacket is decoded, it verifies the details such as the SDP ID of thesending host and the service ID requiring access among others.Ensuing the verification of the packet, the gateway then creates arule in iptables which allows the client to connect to the service.This rule is present for a limited amount of time (default value of10s). The established connection is a mutual TLS connection andpersists even after the expiry of the rule. The gateway goes backto its original state of blocking all packets. As soon as a packetfrom an authorized machine arrives, it opens the firewall, allowsthe packet to pass through it and then closes the firewall again.

In contrast, the client creating the SPA packet to send it to thegateway for verification includes the following fields within thepacket:

1) SDP ID2) Service ID3) Gateway IP4) Timestamp5) Random 16-byte data

The first two fields are used to disclose the clients identity andinform the gateway of the service it wishes to connect to. The thirdfield is the specific gateway’s IP address that the client wishesto establish a connection to. The timestamp, used to verify the“age” of a packet, is another authentication mechanism of SDP. Ifthe timestamp of the packet exceeds a pre-determined limit, thenthe packet is rejected. This, combined with the random 16-bytedata, is used to ensure that the replay attacks cannot be used onthe network. The gateway establishes rules in itself as soon as itverifies the SPA packet to allow packets from client to travel tothe destination service. Then the client establishes a connectionto the service and data transfer can take place.

B. Results Analysis & Discussion:

The connection setup time and the overall network throughputare the two metrics considered when evaluating the performanceof the proposed framework. This is done for both the SDP andnon-SDP scenarios. Moreover, two attacks are simulated, namelya distributed denial of service (DDOS) attack and a port scanningattack. The DDoS attack was chosen as it represents a threat tothe data and services availability for modern networks. Similarly,the port scanning attack represents a threat to the data privacy.Therefore, these two attacks were considered as they representtwo threats and concerns within modern networks that the SDPframework aims to address. The results reported are the averageof ten different runs.

6

Fig. 3: Proposed Framework’s Process Workflow

1) Connection Setup Time: The first performance metric con-sidered is the connection setup time. This metric refers to the timetaken by a client to connect to a service with and without SDP.In this experiment, the time needed to setup a SSH connectionbetween the client and the gateway is determined. The results areshown in Table I. It can be observed that a higher setup time isneeded when adopting SDP. This is expected given the decryptionand verification process of the SPA packet as well as the setuprules for the firewalls needed before the client connection canattempt to go through. On the other hand, none of these stepsoccur in the non-SDP case, therefore allowing for a significantlyfaster connection process.

2) Distributed Denial of Service Attack:The second performance metric considered is the network

throughput which refers to the measured network speed at the portwhere a connection is being established in case of a DDoS attack,with and without SDP. To simulate the DDoS attack, one VM isset up as an authorized client, while the other as an unauthorizedclient. The unauthorized client runs a software to emulate theDDoS attack by attempting to establish multiple connections tothe port and hence attempting to consume all of the networkbandwidth available. The experiment involved sending both TCPand UDP traffic. For the TCP case, the available bandwidth waskept at 2 Gbps whereas for UDP, the bandwidth was kept at10Mbps. This is because when using UPD in such a setup, itis extremely difficult to consume the entire 2 Gbps bandwidth.The average network throughput results are shown in Table I.

The connection was attempted on port 5000. Ideally, the SDPis assumed to block all unauthorized traffic and only allowauthorized traffic. This keeps the bandwidth value as the one setup for the connection. However, this is not the case in practice.The firewall opens up once it receives an authorized packet toallow it to pass while also allowing all other traffic through before

TABLE I: Performance Evaluation Results

Criterion Without SDP With SDPConnection Setup Time 0.09 sec 1.02 secAverage NetworkThroughput

TCP 6.86 Mbps 1.51 GbpsUDP 1.7 kbps 8.8 Mbps

it closes up again. Hence, the available bandwidth to the clientslightly decreases. However, the results clearly show the impactof SDP when using both TCP and UDP protocols. When usingTCP, the average throughput without SDP falls to around 0.343%of the available bandwidth whereas in the case of SDP, it hoversaround 75.5%. Similarly, when using UDP, the average throughputwithout SDP falls to around 0.017% while that of the SDP isaround 88% range. This further highlights the fact that SDP worksfairly well in protecting networks from DDoS attacks.

Fig. 4 shows the impact of a DDoS attack on the performanceof the network without SDP by plotting the throughput over time.It is observed that the data transfer could not happen in one shotdue to the DDoS attack clogging up the network. It is worth notingthat since the attack is being perpetrated from one host, its overallimpact may be quite limited. However, it is enough to disruptthe data transfer by not allowing the full transfer to take place.The average throughput during the entire data transfer processis around 6.86 Mb/s. This is a significant drop from the 2 Gb/sbandwidth actually available within the network. In contrast, thepositive impact of adopting SDP is highlighted. In this case, thedata transfer was completely successful and the average bandwidthduring the process is 1.51 Gb/s. Since the DDoS attack is runningfrom a single host, the impact on the bandwidth is minimal. Notethat if the same attack was launched with multiple hosts, thebandwidth may fall even further. However, it will still be enoughfor the application to function normally.

7

Fig. 4: Network Throughput Over Time

3) Port Scanning Attack:The second attack simulated is the port scanning attack. This

attack involves running a check and listing all the available ports.Such an attack is an active form of attack, where using a tool canbe used to discover the hosts and services on a network. It canfurther be used to execute attacks on specific ports such as port80 (HTTP) etc. This experiment uses nmap, a free port scanningutility. Nmap ran from the unauthorized host on the gateway, withand without SDP. The results of this attack are presented in Figs.5a and 5b for the non-SDP and SDP scenarios respectively. Notethat the scan ran on ports 1-1000, covering some of the moreimportant services such as HTTP, FTP, SSH etc.

a: Without SDP

b: With SDP

Fig. 5: Port Scanning Attack Results

It can be clearly seen that without SDP, the scan reportshows that an SSH connection is open and available. In contrast,SDP gives no information whatsoever about the number of openports and the service hosted on them. This enforces the securityof the application and confirms the unavailability of access tounauthorized clients.

VI. CONCLUSION

This paper described the SDP framework as a potentialsolution to the different security challenges/concerns facing mod-ern networks in terms of its concept, architecture, and possibleapplications. Also, the challenges facing the SDP frameworkwere briefly presented and discussed. Furthermore, an SDP-basedframework adopting a client-gateway architecture was proposedand its performance was evaluated using an internal enterprise

scenario in terms of connection setup time and network throughputunder two types of network attacks, namely distributed denialof service attack and port scanning attack. The performanceevaluation of the implemented virtualized network testbed showedthat an SDP-secured network is more resilient to port scanningand distributed denial of service attacks by not providing anyinformation and maintaining a high average network throughputrespectively despite needing longer time to initially establish theconnection. These results cement the promising potential of SDPin protecting current and future networks.

Despite the early promise of SDP, more open research ar-eas exist. In particular, exploring how to integrate SDP withother paradigms such as SDN and NFV is essential since theseparadigms will play a significant role in future networks.

ACKNOWLEDGMENTS

The authors would like to thank Mr. Palash Kumar for hishelp in the implementation of the proposed framework. Hiscontributions have been extremely valuable for the completionof this work.

REFERENCES

[1] National Cable & Telecommunications Association (NCTA),“Behind The Numbers: Growth in the Internet of Things,”Mar. 2015. [Online]. Available: http://www.ncta.com/whats-new/behind-the-numbers-growth-in-the-internet-of-things

[2] McAfee, “Building Trust in a Cloudy Sky: The State of Cloud Adoptionand Security,” Jan. 2017. [Online]. Available: http://www.mcafee.com/us/solutions/lp/cloud-security-report.html

[3] C. Esposito, A. Castiglione, F. Pop, and K. K. R. Choo, “Challenges ofconnecting edge and cloud computing: A security and forensic perspective,”IEEE Cloud Computing, vol. 4, no. 2, pp. 13–17, Mar. 2017.

[4] Microsoft, “Digital Transformation at Work: Empowering Together,” Mar.2017.

[5] N. Bannerman, “SDN and NFV Market to be Work 54 $ billion by 2022,”Aug. 2017.

[6] H. Hawilo, L. Liao, A. Shami, and C.M. Leung, “NFV/SDN-based vEPCSolution in Hybrid Clouds,” in 2018 IEEE Middle East and North AfricaCommunications Conference (MENACOMM), April 2018, pp. 1-6.

[7] A. Moubayed, M. Injadat, A. Shami, and H. Lutfiyya, “DNS Typo-squattingDomain Detection: A Data Analytics & Machine Learning Based Approach,”in IEEE Global Communications Conference (GLOBECOM’18), December2018, pp.1-7.

[8] G. Kulkarni, J. Gambhir, T. Patil, and A. Dongare, “A security aspects incloud computing,” in IEEE International Conference on Computer Scienceand Automation Engineering (CSAE’12), June 2012, pp. 547–550.

[9] S. Yi, Z. Qin, and Q. Li, “Security and privacy issues of fog computing: Asurvey,” in International Conference on Wireless Algorithms, Systems, andApplications (WASA’15). Springer International Publishing, 2015, pp. 685–695.

[10] R. von Solms and J. van Niekerk, “From information security tocyber security,” Computers & Security, vol. 38, pp. 97 – 102,2013, cybercrime in the Digital Economy. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0167404813000801

[11] I. Stojmenovic and S. Wen, “The fog computing paradigm: Scenariosand security issues,” in Federated Conference on Computer Science andInformation Systems (FedCSIS’14), Sep. 2014, pp. 1–8.

[12] Software Defined Perimeter Working Group-Cloud Security Al-liance (CSA), “Software Defined Perimeter,” Dec. 2013. [On-line]. Available: http://downloads.cloudsecurityalliance.org/initiatives/sdp/Software Defined Perimeter.pdf

[13] P. Kumar, A. Moubayed, A. Refaey, A. Shami, and J. Koilpillai,“Performance Analysis of SDP For Secure Internal Enterprises”, in IEEEWireless Communications and Networking Conference (WCNC’19), April2019.

[14] Department of Defense, “Department of Defense Global Information GridArchitectural Vision,” Jun. 2007.

[15] SAIFE, “SAIFE Extends the Software Defined Perimeter,”Jun. 2017. [Online]. Available: https://www.saife.io/press-releases/saife-extends-software-defined-perimeter/

8

Abdallah Moubayed received his B.E. degree in Electri-cal Engineering from the Lebanese American University,Beirut, Lebanon in 2012, his M.Sc. degree in ElectricalEngineering from King Abdullah University of Scienceand Technology, Thuwal, Saudi Arabia in 2014, and hisPh.D. in Electrical & Computer Engineering from theUniversity of Western Ontario in August 2018. Currently,he is a Postdoctoral Associate in the Optimized Com-puting and Communications (OC2) lab at University ofWestern Ontario. His research interests include wirelesscommunication, resource allocation, wireless network

virtualization, performance & optimization modeling, machine learning & dataanalytics, computer network security, cloud computing, and e-learning.

Ahmed Refaey received his B.Sc. and M.Sc. degreesfrom Alexandria University, Egypt in 2003 and 2005,respectively; and Ph.D. degree from Laval University,Quebec, Canada in 2011. Currently, he is an AssistantProfessor at Manhattan College as well as an adjunctresearch professor at The University of Western Ontario.Previously, Dr. Hussein’s positions included: Sr. Embed-ded Systems Architect, R&D group, Mircom Technolo-gies Ltd from 2013-2016; and as a Postdoctoral Fellowat ECE department, The University of Western Ontariofrom 2012-2013. His research interests include Adap-

tive Communication Systems and Networks Security, IoT/Emerging Communi-cations/Computing Technologies and Applications, and Embedded Systems/FPGAPrototypes Implementation.

Abdallah Shami received his B.E. degree in Electricaland Computer Engineering from Lebanese Universityin 1997 and his Ph.D. degree in Electrical Engineeringfrom the Graduate School and University Center, CityUniversity of New York, in September 2002. Further, inSeptember 2002, he joined the Department of Electri-cal Engineering at Lakehead University, Thunder Bay,Ontario, Canada, as an Assistant Professor. Since July2004, he has been at Western University, where he iscurrently a Professor and Acting Chair in the Departmentof Electrical and Computer Engineering. His current

research interests are in the areas of network optimization, cloud computing, andwireless networks.

Fig. 1: Challenges/Concerns in Modern Networks

Fig. 2: Proposed SDP Framework For Internal Enterprise Network

Fig. 3: Proposed Framework’s Process Workflow

TABLE I: Performance Evaluation Results

Criterion Without SDP With SDPConnection Setup Time 0.09 sec 1.02 secAverage NetworkThroughput

TCP 6.86 Mbps 1.51 GbpsUDP 1.7 kbps 8.8 Mbps

Fig. 4: Network Throughput Over Time

a: Without SDP

b: With SDP

Fig. 5: Port Scanning Attack Results