research article securing sdn southbound and...

Research ArticleSecuring SDN Southbound and Data PlaneCommunication with IBC

JunHuy Lam Sang-Gon Lee Hoon-Jae Lee and Yustus Eko Oktian

Department of Ubiquitous IT Division of Computer amp Information Engineering Dongseo University Busan 617-716 Republic of Korea

Correspondence should be addressed to Sang-Gon Lee nok60dongseoackr

Received 21 March 2016 Revised 22 June 2016 Accepted 4 July 2016

Academic Editor Juan C Cano

Copyright copy 2016 JunHuy Lam et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

In software-defined network (SDN) the southbound protocol defines the communication between the control plane and the dataplane The agreed protocol OpenFlow suggests securing the southbound communication with Transport Layer Security (TLS)However most current SDNprojects do not implement the security segment with only a few exceptions such asOpenDayLight HPVAN SDN andONOS implementing TLS in the southbound communication From the telecommunication providersrsquo perspectiveone of themajor SDN consumers besides data centers the data plane becomesmuchmore complicated with the addition of wirelessdata plane as it involves numerous wireless technologies Therefore the complicated resource management along with the securityof such a data plane can hinder the migration to SDN In this paper we propose securing the distributed SDN communicationwith a multidomain capable Identity-Based Cryptography (IBC) protocol particularly for the southbound and wireless data planecommunication We also analyze the TLS-secured Message Queuing Telemetry Transport (MQTT) message exchanges to find outthe possible bandwidth saved with IBC

1 Introduction

Software-defined network (SDN) is a new network tech-nology that separates the intelligence of the network bydecoupling the control and data planes In order to achievethat a newnetwork elementwas introduced into the networkthe SDN controller It centralizes the network control planemanages the network data plane and provides the platformthat eases the development of the management plane or inother words the network applications The network switchesthat take on the role of the networkrsquos data plane become for-warding devices in SDN they forward the packets in accor-dance with the flow tables received from the SDN controllerunquestioningly

SDN introduces three new protocols into the networknamely the northbound protocol eastwest-bound protocoland southbound protocol The conceptual view of SDN withboth the wired and wireless data planes is as shown inFigure 1

The northbound protocol is used by the managementplane or network applications to communicate with the con-trol plane (the SDN controllers) to perform tasks such as load

balancing via load adaption [1] and Quality of Service (QoS)[2] The security risks and requirements of the northboundcommunication are dependent on the network application

In the SDN environment security applications or toolscan also be used to provide network security from themanagement plane SDN allows applications to monitorthe network traffic and have a network-wide view Henceidentity revocation can be carried out easily with applicationsor tools that detect malicious nodes such as the intrusiondetection system (IDS) [3] Distributed Denial-of-Service(DDoS) detection [4] and network monitoring [5 6]

The eastwest-bound protocol is used for the communi-cation within the control plane or specifically the commu-nication between the SDN controllers and the data storesUnfortunately the SDN controllers currently available arevendor specific as those of the time of writing They haveneither the agreed eastwest-bound protocols nor the securityfor them with Open Network Operating System (ONOS)being the exception [7] However the security of this com-munication is especially important for the distributed SDNIt ensures that no malicious controllers are snooping fornetwork information or even driving the network

Hindawi Publishing CorporationMobile Information SystemsVolume 2016 Article ID 1708970 12 pageshttpdxdoiorg10115520161708970

2 Mobile Information Systems

Control plane

Controller B

Sout

hbou

nd

Northbound

Controller A

EastWest-bound

Management plane SDN App 3 SDN App 1 SDN App 2

Wireddata plane

Switch BSwitch A

Host A Host B

Wirelessdata plane

Wireless technologies

LTE UMTS WiFi WiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts

Sensor Sensor Sensor Sensor Sensor Sensor Sensor

Host A Host A

Figure 1The conceptual view of SDN with both wired and wirelessdata planes

In the single controller SDN implementation a com-promise of the controller will enable the attacker to controlthe entire network However in the distributed SDN thenetwork is spread across all the available controllers withinthe network In order to minimize the effect following thecompromise of a single controller in the distributed SDN theeastwest-bound communication has to be protected If it isleft unprotected the malicious controller will have the abilityto manipulate all other controllers in the entire network

The attacker can also insert a malicious data store into thenetwork to obtain a duplicate or backup copy of the networkinformation from other data stores within the network Byutilizing this information the attacker will then be able tolearn the network topology and carry out relevant attacksaccordingly Worse still the attacker can inject the desiredflow through a malicious data store

The southbound protocol defines the communicationbetween the control plane and the data plane There is acommonly agreed protocol for the southbound communi-cation which is the OpenFlow protocol [8] standardized bythe Open Networking Foundation (ONF) However other

southbound protocols are also available if OpenFlowdoes notsuit a particular purpose For instance Ciscorsquos ApplicationCentric Infrastructure (ACI) [9] is another alternative forOpenFlow However using such proprietary protocols willhence limit the devicersquos vendor choices

In order to protect the network from being driven bya malicious controller or to prevent a malicious switch ornetwork device from obtaining any network information thesouthbound communication must be operated in a securechannel OpenFlow suggested securing the southbound com-munication with Transport Layer Security (TLS)

Projects that do not implement TLS are prone to man-in-the-middle attacks [10] Attackers will be able to penetratetheOpenFlownetworkswhile remaining undetectedDespitethe security risks involved it is still not implemented inmanySDNprojects with exceptions such as OpenDayLight [11] HPVirtual Application Network (VAN) SDN [12] and ONOS[13]

One of the main reasons for why TLS is not used by SDNnetwork administrators is that the steps required to configureit correctly can be quite tedious [10]TheTLS implementationrequires a Certificate Authority (CA) to generate the CArsquos keycertificates for the controllers switches and then the signingof these certificates with the CArsquos key The certificates anddevicesrsquo keys will then be deployed to the respective devicesprior to the actual network deployment This tedious processis a hindrance for them when adopting the TLS to secure thecommunication channel

As illustrated in Figure 1 there are two general typesof data planes the wired and wireless variants SDN wasinitially built for the wired data plane and the data centeris the main consumer of it As the SDN technology growstelecommunication providers became interested in it andstarted experimenting with it in their network with ATampTsupporting both OpenDayLight and ONOS while VerizonChina Unicom NTT Communication and SK Telecom arebacking ONOS

However the original design neglected the wireless dataplane that was powered by numerous wireless technologiessuch as the Fourth-Generation Long Term Evolution (4G-LTE) [14] Universal Mobile Telecommunication System(UMTS) [15] Wireless Fidelity (WiFi) [16] and WorldwideInteroperability for Microwave Access (WiMax) [17] Henceit is difficult to manage the heterogeneous wireless data plane[18] even with the current advancement in SDN technologyIt is even more complicated when it comes to the securitymanagement between these wireless technologies

Unlike its wired counterpart the security for the wirelessdata plane cannot be neglected because anyone within thecoverage area of the wireless technology can tap into thenetwork and perform any malicious activities to disrupt thenetwork Therefore security becomes a crucial criterion forthewireless data plane before they can deploy it for real usage

By replacing TLS with Identity-Based Cryptography(IBC) [19] the steps required for system setup will be greatlysimplified improving both the performance availability andbandwidth availability as well as minimizing storage andmanagement of the public keys and therefore saving on costs

Mobile Information Systems 3

Our Contributions In this paper we proposed securing theSDN communication with IBC protocol To the best of ourknowledge this is the first work that allows multidomainsecure communication with IBC in SDN along with its dataplane Our contributions are listed in detail as follows

(1) We described the security risks involved in SDN andits data plane as well as the reasons it needs to beprotected

(2) We described the reasons the other proposal is insuf-ficient to protect the SDN and why IBC is a preferablemethod

(3) We presented the proposal to secure the SDN and itsdata plane specifically the wireless data plane with amultidomain capable IBC protocol

(4) We provided some application scenarios in which themultidomain IBC protocol can be utilized We alsodescribed how it allowsmultidomain communicationand switch migration in the distributed SDN whichpreviously could not be performed

(5) We described the application of IBC in helping thecommunication within the data plane and an analysisto show the possible bandwidth saved with IBC

2 Background

21 Southbound Security The de facto standard of the SDNsouthbound protocol OpenFlow [20 21] suggested that thesouthbound communication should be secured with TLSProjects that do not implement TLS are prone toman-in-the-middle attacks [10] Adversaries will be able to penetrate theOpenFlow networks while remaining undetected

In order to prevent the compromise of a controller fromthe southbound communication channel and a maliciousswitch or network device from obtaining or modifying anynetwork information the southbound communication mustbe operated in a secure channel Despite this requirementit is not implemented in many SDN projects because TLSis only an optional feature in OpenFlow specifications andthe complicated certificate management Besides that thesecurity also comes at a cost to the bandwidth due to theexchange of the certificates for authentication purposes

22 Data Plane Security The data plane can be furtherdivided into two categories the wired andwireless data planeBoth data planes may share some security concerns but thereare also security concerns that are specific to either one of thedata planes The detailed security concerns will be discussedas follows

221 Wired Data Plane As illustrated in Figure 1 the wireddata plane is much simpler compared to the wireless dataplane It involves only the switches hosts or any other devicesthat are connected through the switch Even if the eastwest-bound and southbound communication channels are secureit does not guarantee that the communication between thedevices within the data plane is secure

Wirelessdata plane


LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts


Malicioususer 1

Attack

Malicioususer 2

Attack

Figure 2 Possible attacks within the wireless data plane

Possible attacks that can be launched within the dataplane are Denial-of-Service (DoS) attack and man-in-the-middle attacks that intercept messages from the insecurecommunication channel and so forth

222 Wireless Data Plane With the growing use of mobileand Internet of Things (IoT) devices the wireless data planebecomes enormous in size and involves complicated topolo-giesThe capability crisis arises whenmobile devices grow at apace that exceeds the wireless spectrum capabilityThereforethe wireless resource management becomes crucial in orderto sustain the network performance for the vast wireless dataplane

This also drives telecommunication providers to look foralternatives to fully utilize their network resources especiallyfor the wireless portion as the wireless bandwidth is limitedand expensive One such solution for them will be to managetheir wireless data plane with SDN

Besides the wireless resource management certificatemanagement will also be involved if TLS were to be usedto secure the data plane The certificate management can bevery complicated due to the enormous amount of devicesinvolved Besids that it is also bandwidth consuming to per-form the TLS handshake that involves certificate exchangesfor authentication

Figure 2 shows two sample attacks that can happenwithinthe wireless data plane Unlike the wired data plane themalicious user does not need to have physical access to theswitch to perform any malicious activity As long as themalicious user is within the wireless coverage range heshecan simply intercept the wireless communication or evenmodify the information if the wireless data plane is notprotected This compromises both the data integrity andconfidentiality and hence security is not a luxury feature buta necessity in the wireless communication especially for IoTdevices that are deeply involved in personal privacy or evenlife threatening in the case of IoT devices used in healthcare

23 IoT Application Protocols In order for IoT devices to becompliant with the oneMachine-to-Machine (oneM2M) [22]IoT standard two widely used application protocols can beused to facilitate the communication within the wireless data


plane Message Queuing Telemetry Transport (MQTT) [23]and Constrained Application Protocol (CoAP) [24]

231 MQTT MQTT is a lightweight asynchronous publish-subscribe messaging protocol that relies on the MQTTbroker to facilitate the messages between the publisher andsubscriber MQTT employs Transmission Control Protocol(TCP) to provide a reliable communication channel betweenthe IoT devicesThe small header of MQTT protocol (2 bytesonly) allows the message delivery with minimal bandwidthand yet reliable connection

A simple architecture that relies on the MQTT protocolconsists of only three main components broker publisherand subscriber Broker as the name implies is a messagingagency or server that distributes the messages between thepublisher and subscriber On the client side the publisher willsend themessage to the broker on a particular topic while thesubscriber that subscribed to the particular topic will receivethemessage from the brokerTheMQTT protocol also allowsmultiple subscribers on a topic but multiple publishers on asingle topic are not recommended even though it is possibleto do so because the subscriber cannot differentiate the sourceof the message

232 CoAP Similar to MQTT CoAP [25] is also a widelyused lightweight protocol for IoT devices but the similarityends here UnlikeMQTT CoAP is based on RepresentationalState Transfer (REST) architecture [26] Therefore CoAPrelies on the four REST verbs to perform the Create ReadUpdate and Delete (CRUD) operations as follows

(i) POST create a new resource identifier (ID)(ii) GET readretrieve the information of the resource

ID(iii) PUT update the state of the resource ID(iv) DELETE delete a resource ID

CoAP employs User Datagram Protocol (UDP) to deliverthe messages between the IoT devices and uses UniformResource Identifier (URI) to address the REST verbs to a par-ticular resource IDThese REST verbs allow it to be integratedwith the web mobile or even desktop applications easily

24 Revocation In the Public Key Cryptography (PKC)there are cases that the CA has to revoke the certificateseven before they expire This revocation can happen dueto certificate loss by the user a compromised certificate anemployee that has left the company and hence no longer havethe right to use the certificate to access company informationand so forth Certificate revocation can be done in one of thetwo common methods [27]

(1) Certificate Revocation Lists (CRL)(2) Online Certificate Status Protocol (OCSP)

CRL contains a list of revoked certificates that have yet toexpire along with the reasons for revocation In the case ofthe long certificate validity for instance 1 year this list will

be likely very long assuming that the CA has issued a lot ofcertificates Users will be required to obtain the complete listfrom the CA in order to verify the status of the certificate thatthey are going to use Hence this is an inefficient revocationmethod that involves a lot of network bandwidth to transmitthe long list of revoked certificate from the CA

In OCSP the user will send a certificate status requestto the CA and the CA will check it against its revocationlist before informing the user on the certificatersquos validityThis method reduces the network bandwidth consumptionbut increases the CA computation cost and the CA will berequired to be online to perform verification for the users

Cooper [27] also worked on the attacks of the revocationlist by manipulating the reason codes If the categorizationof the reason codes were not carefully analyzed the usermight be able to abuse it for example categorization of theseriousness of the revocation as the key is no longer neededor the keywas compromisedThe key that is no longer neededmight not be handled as quickly as the compromised key andhence this gives the attacker time to use the key as long as itis not updated to the user

Similar to the PKC in order to prevent the key misuse ofIBC key revocation has to be done on a compromised nodefailed node and so forth In the IBC of SDN key revocationcan be performed using one of the two methods

(i) A trusted third party mediator(ii) A network application on the management plane

A trusted third party mediator was used in PKC [28]and IBC [29] to revoke any malicious user in the system Inthis mechanism the PKG generates a private key of the userand then splits it into two portions for instance portion Aand portion B PKG will then send portion A to the user andportion B to the mediator Similar to the PKG the mediatoris a second trusted party that keeps portion B of the privatekeys for the users Besides that the mediator will keep trackof malicious users in the system

When a user requires his private key he will send anencrypted message to the mediator for partial decryptionThemediator will then check whether the user is malicious ornot If the user has been compromised themediator will denythe operation and the user will be revoked from the systemand unable to decrypt any message If the user is genuine themediator will then send the partially decrypted message tothe user and the user will then be able to decrypt the partiallydecrypted message and obtain the plaintext message

However the mediator method can be bandwidth con-suming since the user and mediator are required to transmitthe encrypted message and partially decrypted messagethrough the network Besides that the mediator requiresextra computing resources in order to perform the partialdecryption and has to be online at all times Figure 3 illus-trates the key revocation with the help of the mediator

The network application on the management plane [30]can be in the form of a firewall intrusion detection sys-tem (IDS) or intrusion prevention system (IPS) applicationidentitymanagement application or solely revocation controlapplication It oversees the network-wide view as per Figure 1


PKG Mediator

Userdevice

Partial private key (portion B)

Partial private key (portion A)

Userdeviceauthentication

Request for partial private key


Figure 3 Key revocation with mediator

(SDN app) and hence will be able to monitor the activities ofeach node easily

When the network application detects any maliciousbehavior in a particular node it will notify the controller toplace themalicious node in a sandbox by blocking all networkflows towards the switch The controller can do so by per-forming flow removals towards the malicious nodeThe con-troller (PKG for the node within its domain) can then analyzethemisbehavior If it is proven safe to continue the communi-cation the controller can then generate a new private key forthe affected switch and distribute this new key to the node

This network application method might increase thecontrollerrsquos load with the addition of network application andflows removal but a distributed SDN is able to distributethe load with the load balancing mechanism Hence thismethod is preferable in the SDN environment especiallywhere distributed SDN is concerned

25 Identity-Based Cryptography (IBC) IBC was first pro-posed by Shamir in the form of an identity-based signaturescheme [31] in 1985 His idea of IBC was then implementedby Sakai et al [32] and Boneh and Franklin [33] for theencryption scheme with pairing in the years 2000 and 2001respectively Both their implementations went on to form thebasis of many IBC researches thereafter with more beingbased on the latter

Similar to the PKCofTLS IBC requires a TrustedAuthor-ity (TA) to act as a Private Key Generator (PKG) that gener-ates keys for the users In the SDN environment controllerscan also act as PKGs for the switches that are located withinits domain

In PKC CA is used to generate the public and private keypairs whereas the PKG of IBC generates only the private keysIn IBC public keys will be derived from the identity of theuser in this case the userrsquos identity can be in the form of theMedia Access Control (MAC) address or any other networkidentities of the controllers and switches

With IBC the users or in this case the controllersswitches or data stores do not need to store every singlepublic key of every user in the domain or obtain a particularpublic key from the TA on demandThis in turn saves storagespace or network bandwidth that otherwise can decrease the

network performance or translate into high system setupcosts

Smart [34] whose research was based on the implemen-tation of Boneh and Franklin initiated the usage of IBC in keyagreement protocol Chen and Kudla [35] improved Smartrsquosprotocol by solving the key escrow problem allowing forcommunication between users ofmultiple TAs and providingforward secrecy

26 Related Research Santos et al [36] proposed apply-ing IBC to secure the communications between MasterController-Secondary Controller (MC-SC) SC-SC and theclient- and server-side or their framework In their proposalthe IBC protocol was based on the Sakai et al protocol[32] However two issues become apparent if this were tobe implemented for practical uses In their proposal theType 1 pairing was used to establish the key According tothe research by Chen et al [37] and Chatterjee et al [38]Type 1 pairing is suitable for security levels of up to 80 bitsfor security levels higher than 80 bits the performance willdegrade significantly For details on the 4 pairing types pleaserefer to [37 38]

Depending on the usage of the SDN a security level of80 bits might be sufficient for a network that manages time-sensitive data or data thatmight be useless after a short periodof time [39] For a SDN that manages time-insensitive data asecurity level of higher than 80 bits should be usedThereforethe key agreement protocol should be able to support otherpairing types

Another significant disadvantage of their proposal alsolies in the key agreement protocol It does not allow com-munication between devices that have obtained their privatekeys from different PKGs Hence it becomes impracticalespecially when it is to be used in the distributed SDN envi-ronment as a single PKGmight not be sufficient in providingprivate keys to the entire network This disadvantage alsolimits the scalability of the network

3 SDN Security with IBC

Identity-based key agreement protocol is used to establish thesymmetric session key that will secure the SDN communica-tion Due to the high amount of traffic that will be encryptedthe symmetric key is more preferable to the asymmetric oneThe asymmetric keys will be used to derive the symmetric keyfor session communication

Our proposal [40] employs the pairing-based key agree-ment protocol with separate TAs introduced by Chen andKudla [35] which was originally not meant for SDN In thisimplementation it assumes that the different PKGs share thesame domain parameters which is plausible in the case of theSDN setup

Although it is worth noting that the controller can actas a PKG for all the devices located within the network atthe same time due to the importance of PKG in IBC it isadvisable to have different PKGs generating the private keysfor the controllers and switches By doing so it can providebetter protection to the control plane when the controllersrsquo


A (119878A = 1199041119876A 119876A = 1198671(Arsquos ID)) B (119878B = 1199042119876B 119876B = 1198671(Brsquos ID))Choose 119886isin

119877Zlowast119902

Choose 119887isin119877Zlowast119902

Compute 119879A = 119886119875119882A = 119886119875pubctlr2 Compute 119879B = 119887119875119882B = 119887119875pubctlr1119879A

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr

119879Blarr997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888

119870AB = (119878A 119879B)(119876B119882A) 119870BA = (119878B 119879A)(119876A119882B)

119870AB = (1199041119876A 119887119875)(119876B 1198861199042119875) 119870BA = (1199042119876B 119886119875)(119876A 1198871199041119875)

119870AB = (119876A 119875)1199041119887(119876B 119875)

1199042119886 = 119870BA = (119876B 119875)1199042119886(119876A 119875)

1199041119887

Box 1 Illustration of the establishment of the IBC key agreement protocol

PKGs are disconnected from the network thus lowering therisk of the PKGs being exposed or attacked

However the controllersrsquo PKGs will be required to recon-nect to the network when the private keys expire (can be setat a fixed interval) or when a malicious controller is detected(can be triggered by a network application) whereby a new setof private keys will be needed to secure the control plane

(1) System Setup Suppose there are two PKGs PKG1and

PKG2 that generate the private keys for the controllers of

the SDN Each has a publicprivate key pair (119875 1199041119875 isin 119866

1

1199041isin119877Zlowast119902) and (119875 119904

2119875 isin 119866

1 1199042isin119877Zlowast119902) respectively where119875 and

1198661have been globally agreed onController A controllerA is registered under PKG

1with

its private key 119878A = 1199041119876A where 119876A = 1198671 (controllerArsquos ID)Controller B controllerB is registered under PKG

2with

119878B = 1199042119876B where119876B = 1198671 (controllerBrsquos ID) (Note that con-trollers A and B can also act as PKGs for the switchesthat are located within their respective domains) 119867

1is a

cryptographic hash function1198671 0 1

lowastrarr 1198661

(2) Key Establishment If controller A wants to communicatewith controller B the IBC key agreement protocol will be ini-tiated to establish the shared session keys Box 1 illustrates thekey establishment of the protocol Each of controllers A and Bpicks nonce at random 119886 and 119887isin

119877Zlowast119902 and computes119879A = 119886119875

119882A = 119886119875pubctlr2 and 119879B = 119887119875119882B = 119887119875pubctlr1 respectivelywhere 119875pubctlr1 = 1199041119875 and 119875pubctlr2 = 1199042119875 These computedvalues will then be exchanged between the two controllers

At the end of the protocol controller A computes theshared key119870AB = (119878A 119879B)(119876B119882A) and controller B com-putes the shared key119870BA = (119878B 119879A)(119876A119882B)

there4 119870BA = 119870AB (1)

Then the shared session key can be generated by hashingthe key 119878119870 = ℎ

2(119870AB) where ℎ2 is a secure hash function

for the purpose of key derivation However this session keydoes not offer TA forward secrecy and the key escrow issuestill exists

If TA forward secrecy is required and key escrow is notallowed the previously generated ephemeral keys can also beused to generate a variant of the shared session key 119878119870 =ℎ2(119870AB 119886119887119875) as suggested by Chen and Kudla [35] These

shared session keys that have been established by the IBC

key agreement protocol will then be used to provide messageconfidentiality

31 Southbound Security Controllers that were registeredunder their respective PKGs can also act as PKGs for theswitches located within their domain for southbound com-munication Southbound security is more straightforwardas it does not usually involve multiple domains Howeverduring the switch migration from one controller to anotherinterdomain communication is still required so as to handover the switch swiftly Therefore the same key agreementprotocol can also be used for southbound communications

To apply the IBC key agreement protocol to southboundsecurity the role of the PKGs will be transferred to thecontrollers themselves that is to generate the private keys forthe switches This reduces the load of the PKGs that managesthe control plane and also isolates the two communicationchannels

32 Data Plane Security

321 Wired Data Plane Multidomain key agreement is alsohelpful in the wired data plane to allow the communicationbetween hosts that obtained their private keys from differentcontrollers through the southbound communicationThe keyagreement protocol enables the multidomain communica-tion without keeping multiple public keys for each domainThis allows the data plane devices to establish the session byusing the identity information and the exchangedparameters

322 Wireless Data Plane The wireless data plane involvesmultiple wireless technologies and it gets complicated whenthe endhosts try to establish the communication throughhet-erogeneous backend infrastructure In order for the heteroge-neous communication to take place a multidomain domainkey agreement protocol is used for such a communication

Despite the multiple wireless technologies used theunderlying protocol to exchange messages may be the sameFor example the two popular communication protocols usedby IoT devices MQTT and CoAP are able to work withthe TCP and UDP respectively regardless of the underlyingwireless technologies used Therefore application of the IBCprotocol to either MQTT or CoAP will be able to provide the


Controller A (PKG A)

Switch 1

Controller B (PKG B)

Switch 3Switch 2

Master connection Slave connection

Figure 4 Switch migration for switch 2

necessary security for the communication between the IoTdevices

4 Application Scenarios

41 Southbound Communication Figure 4 shows the switchmigration for switch 2 Switch 2 is allowed tomigrate betweencontrollers A and B that also act as the PKGs for switch2 The load balancing application will notify the respectivecontroller that will be taking over the switch for migrationand key establishment will be performed between the switchand controller B

During this transition period switch 2 is still able tocommunicate with switch 1 or switch 3 by using the oldkey (the key obtained from controller A) and switch overto the new key (the key obtained from the controller thatwill be taken over) once the key establishment and handoverprocess are completed When switch migration is completedthe switch can then dispose of the old key and proceed withcommunication using the new key

This eases the switch migration process with a singleidentity information and saves the computing resources at thecontroller for certificate issuance and management Besidesit also reduces the bandwidth required for the new certificatedistribution in TLS

42 Data Plane Communication

421 Wired Data Plane Figure 5 illustrates the interdomaincommunication within the wired data plane that was madepossible with an interdomain key agreement protocol Withthe help of the protocol it allows the communication betweenswitch 1-switch 2 and host A-host B to be established withouthaving a second public key or identity in this case

Unlike TLS switch 1 and host A do not need to havecontroller B issue a new public key to them in order to derivethe session keyThe same goes to switch 2 and host B withoutneeding a second public key from controller A Thereforethe key agreement protocol saves computing resources at thecontroller that generates andmanages the certificate Besidesit also saves the bandwidth that will be used to distribute thecertificate

422 Wireless Data Plane The wireless data plane involvesheterogeneouswireless technologies and hence the advantage


Switch 1


Switch 2

Host A Host B

Figure 5 Interdomain data plane communication


LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts


Figure 6 Heterogeneous wireless communication

of this multidomain capable IBC key agreement protocolactually benefits this data plane communication the mostThe certificatemanagementwas simplifiedwith the controllermanaging only the private keys for each of these devicesinstead of managing multiple certificates for each wirelesstechnology

Figure 6 illustrates the heterogeneous wireless communi-cation where the mobile device is able to communicate withthe base station for IoT devices through the two differentwireless technologies The mobile device connects to thenetwork via Long Term Evolution (LTE) while the basestation connects to the network via Wireless Fidelity (WiFi)The communication between the LTE base station and WiFiaccess point is possible with only the identity informationof the mobile devices It saves the hassle of having multiplecertificates for a single device

Besides that the IBC key agreement protocol reducesthe bandwidth consumption as compared to the TLS for nocertificate exchanges will be required The bandwidth saved


Table 1 Security comparisons between SDN projects

SDN projectsSecurity

Eastwest-bound Southbound Data plane

OpenDayLight mdash TLS TLSHP VAN SDN mdash TLS TLSONOS TLS TLS TLSD-SDN (Santoset al [36])

IBC (singledomain)

IBC (singledomain)

IBC (singledomain)

Our proposal IBC(multidomain)

IBC(multidomain)

IBC(multidomain)

can then accommodate more wireless hosts with the sameinfrastructure which in turn saves cost

5 Analysis and Discussions

OpenDayLight and HP VAN SDN implemented TLS tosecure the southbound security but neglected the eastwest-bound security which is also crucial for a distributed SDNONOS secured both the southbound and eastwest-boundcommunications but the system setup is still rather incon-venient since the user is still required to deploy the keysmanually

Santos et al [36] proposed securing the communicationsbetween MC-SC SC-SC and the client- and server-sideor their framework with IBC However there are severalflaws in their proposal and their scheme is not suitablefor a distributed SDN when interdomain communication isrequired

Table 1 is a comparison between the securities of differentSDN projects To simplify the comparison SDN projects thatdo not implement a secure channel were excluded from thistable Do note that the protocol can also be added to any opensource SDN project as a security module

Since TCP is the preferred transport protocol to providereliable communication channel we chose the MQTT proto-col which is one of the most commonly used communicationprotocols in the world of IoT (relies on TCP) besides CoAP(relies on UDP) and secured it with TLS Then we analyzedthe communication between the MQTT broker (server) andMQTT client (publisher) to find out the possible bandwidthsaved by using IBC instead of TLS

In the communication analysis we used a networksniffing tool Wireshark [41] to monitor the network trafficand the exchanged information between the MQTT client(publisher) andMQTT broker Figure 7 illustrates a completeTLS handshake for the MQTT protocol and details of hand-shake messages will be shown in Figure 7

Figure 8 shows the first message exchange initiated bythe MQTT client (in this case the publisher) to the MQTTbroker The communication started with the TLS handshakemechanism client hello In this message it sends the clientrsquosnonce cipher suites compression methods extensions andany other special features that the client supports to the serveror in this case the MQTT broker

Encrypted channel

MQTT client (publishersubscriber)

MQTTserver (broker)

Client hello

Server hello

Serverrsquos certificate server key exchange

certificate request and server hello done

Clientrsquos certificate client key exchangecertificate verification change cipher specand clientrsquos finished

MQTT session ticket change cipher spec

and serverrsquos finished

Figure 7 MQTT-TLS handshake mechanism

Figure 8 MQTT client hello message from the MQTT publisher

Similar to the client hello message Figure 9 shows theserver hello message which is the serverrsquos response uponreceiving the client hello message In this message theserver (MQTT broker) will choose the best or most suitablecryptography setting such as themost secure cipher suite sup-ported by the client compression method used or any otherextensions that were included in the client hello message

If the IBC protocols were to be applied here the sizeof the cipher suites compression methods or other featuressupported might be much lesser initially and hence a smallerclient hellomessage can be usedHowever if the IBCprotocolis adopted by more organizations it might grow to a sizesimilar to the TLS protocol Hence the bandwidth saved inclient hello message can be negligible then On the otherhand the message length of the server hello message shouldbe similar whether it is in TLS or IBC mode since it onlychooses one of the cryptography settings from each type


Figure 9 Server hello message fromMQTT broker

Figure 10 MQTT broker sends its certificate to the client

Figure 11 MQTT broker request for clientrsquos certificate

Therefore the bandwidth saved in the client hello and serverhello messages are negligible

After the MQTT broker (server) sends the server hellomessage to the client it will proceed to send its own certificateto the client as shown in Figure 10 and send a certificaterequest message to the client as shown in Figure 11 so thatthe server and client can authenticate each other prior tosending any actual data If IBC protocol is used here thesetwomessages will no longer be needed because the client willbe able to derive the ldquocertificaterdquo from the serverrsquos identity and

Figure 12 MQTT client sends its certificate to the MQTT broker

Figure 13 MQTT client sends the certificate verificationmessage tothe broker

the same goes to the server where it will be able to derive theldquoclientrsquos certificaterdquo with the clientrsquos identity

Figure 10 shows that the certificate handshake messageused 1900 bytes from the bandwidth while the certificaterequest message in Figure 11 used 42 bytes of data resultingin a total of 1942 bytes saved The bandwidth saved here issignificant as the size of the entire client hello and server hellomessages is only 376 bytes By switching it to the IBCprotocolthe bandwidth saved here can actually accommodate foranother 5 pairs of server-client hello message exchanges

Figure 12 shows the MQTT client (in this case pub-lisher) sending its own certificate to the MQTT broker uponreceiving the certificate request message from the broker andthe information required to verify the client was sent in thecertificate verification message as shown in Figure 13 to thebroker Again if the IBC protocol was to be applied herethese handshake messages will be redundant as the broker isable to derive the ldquoclientrsquos certificaterdquo from the clientrsquos identityand with the exchanged nonce and derived ldquocertificatesrdquo thebroker will be able to verify the client without needing thecertificate verification message as well

Figure 12 shows that the clientrsquos certificate used 1888 byteswhile the certificate verification message in Figure 13 used269 bytes of data Again a total of 2157 bytes can be savedby switching to the IBC protocol


Figure 14 Session ticket fromMQTT broker

Figure 15 Encrypted channel

Finally Figure 14 shows the session establishment of theserver-client pair while Figure 15 shows the first applicationdata exchange with the established sessionrsquos cryptographicparameters The bandwidth required for these messageexchanges should be similar whether it is in TLS or IBCprotocol if the same handshake mechanism and symmetriccryptography are used because the size of a session ticketand change cipher spec message is not affected by the cryp-tography protocol

The serverrsquos finished or the encrypted handshakemessageshown in Figure 14 and the first encrypted data in Figure 15will have a similar length regardless of whether TLS orIBC was used because TLS and IBC are used to derive thesymmetric key with the provided asymmetric keys via thehandshake mechanism and the symmetric key cryptographyused to encrypt these messages will be the same for both TLSand IBC Hence no bandwidth can be saved here

By referring to Figure 7 the size of each handshakemessage is listed as follows

Client hello message 305 bytes (refer to Figure 8)Server hello message 71 bytes (refer to Figure 9)Serverrsquos certificate 1900 bytes (refer to Figure 10)Server key exchange 338 bytes (5 bytes of header +length refer to Figure 10)Certificate request and server hello message done 51bytes (refer to Figure 11)Clientrsquos certificate 1888 bytes (refer to Figure 12)Client key exchange 75 bytes (refer to Figure 12)

Certificate verification message 269 bytes (refer toFigure 13)

Change cipher spec (client) 6 bytes (refer to Fig-ure 13)

Clientrsquos finished 45 bytes (refer to Figure 13)

New session ticket 1087 bytes (refer to Figure 14)

Change cipher spec (server) 6 bytes (refer to Fig-ure 14)

Serverrsquos finished 45 bytes (refer to Figure 14)

Complete handshake 6086 bytes

Based on the analysis of the possible bandwidth thatcan be saved with IBC it shows that removing the certifi-cate related messages (serverrsquos certificate certificate requestclientrsquos certificate and certificate verification) from the TLShandshake alone can save up to 4099 bytes per communicat-ing pair A complete handshake requires 6086 bytes and 4099bytes are more than half of the bandwidth saved

Hence this can lead to lower power consumption as lessdata are required to be exchanged between the server andclient The bandwidth saved here will also allow the samenetwork infrastructure to accommodate for more communi-cating pairs and hence improve performance

Besides that the multidomain IBC protocol also allowsthe MQTT client that has the key generated by a controllerof a different domain to communicate through the MQTTbroker of another domain

6 Conclusion

There are several notable benefits when securing the SDNcommunication with IBC steps required for system setupwill be significantly simplified while performance and net-work bandwidth vastly improved Furthermore as a smallerstorage space is needed to store the keys all these will thentranslate to a decrease in cost

Besides that IBC also speeds up the key exchange processsince the two communicating parties do not need to obtaineach otherrsquos public key from the CA to derive the session keyThis reduces the time for the key setup and hence less time isspent on the key exchange process

With this IBC scheme even the nodes of differentsubdomains will be able to derive the shared session keyThis not only improves the network scalability but also easesswitch migration in the southbound communication andenables interdomain data plane communication

Lastly the analysis shows the possible bandwidth thatcan be saved by switching to IBC certificate exchanges arethe most bandwidth consuming part during a handshakeprocess By removing the use of certificates inTLS bandwidthconsumption is reduced by as much as 4099 bytes per com-municating pair during the handshake process In otherwords more than half of the bandwidth is saved as a completehandshake requires 6086 bytes

This will lead to lower power consumption of the IoTdevices and higher network performance as it can now


accommodate more IoT devices without upgrading the net-work infrastructure

Disclosure

Part of this paper was presented in the International Confer-ence on Ubiquitous and Future Networks (ICUFN) 2015

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This research was supported by Basic Science Research Pro-gram through National Research Foundation of Koreafunded by the Ministry of Education Science and Technol-ogy (Grant no NRF-2014R1A1A2060021) The third author(Hoon-Jae Lee) was supported by the National ResearchFoundation of Korea NRF2011 Project (Grant no NRF-2011-0023076) and NRF2016 Project (Grant no NRF-2016R1D1A1B01011908)

References

[1] A Dixit F Hao S Mukherjee T V Lakshman and R Kom-pella ldquoTowards an elastic distributed SDN controllerrdquo in Pro-ceedings of the 2nd ACM SIGCOMM Workshop on Hot Topicsin Software Defined Networking (HotSDN rsquo13) pp 7ndash12 HongKong August 2013

[2] M F Bari S R Chowdhury R Ahmed and R Boutaba ldquoPoli-cyCop an autonomic QoS policy enforcement framework forsoftware defined networksrdquo in Proceedings of the Workshop onSoftware Defined Networks for Future Networks and Services(SDN4FNS rsquo13) pp 1ndash7 Trento Italy November 2013

[3] R Skowyra S Bahargam and A Bestavros ldquoSoftware-DefinedIDS for securing embedded mobile devicesrdquo in Proceedings ofthe 2013 IEEEHigh Performance Extreme Computing Conference(HPEC rsquo13) pp 1ndash7 Waltham Mass USA September 2013

[4] R Braga E Mota and A Passito ldquoLightweight DDoS floodingattack detection using NOXOpenFlowrdquo in Proceedings of the35th Annual IEEE Conference on Local Computer Networks(LCN rsquo10) pp 408ndash415 Denver Colo USA October 2010

[5] J R Ballad I Rae and A Akella ldquoExtensible and scalable net-work monitoring using openSAFErdquo in Proceedings of the Inter-net Network Management Conference on Research on EnterpriseNetworking (INMWREN rsquo10) p 8 2010

[6] C Yu C Lumezanu Y Zhang V Singh G Jiang and H VMadhyastha ldquoFlowSense monitoring network utilization withzero measurement costrdquo in Proceedings of the 14th InternationalConference on Passive and Active Measurement (PAM rsquo13) vol7799 pp 31ndash41 Springer Berlin Germany 2013

[7] J H Lam S-G Lee H-J Lee and Y E Oktian ldquoTLS channelimplementation for ONOSrsquos eastwest-bound communicationrdquoin Electronics Communications and Networks V vol 382 ofLecture Notes in Electrical Engineering pp 397ndash403 SpringerSingapore 2016

[8] OpenFlow httpswwwopennetworkingorgsdn-resourcestechnical-library

[9] ldquoCisco Application Centric Infrastructure Use ACI as a Tech-nology-Based Catalyst for IT Transformation White Paperrdquohttpwwwciscocomcenussolutionscollateraldata-center-virtualizationapplication-centric-infrastructurewhite-paper-c11-734501html

[10] K Benton L J Camp and C Small ldquoOpenFlow vulnerabilityassessmentrdquo in Proceedings of the 2nd ACM SIGCOMM Work-shop on Hot Topics in Software Defined Networking (HotSDNrsquo13) pp 151ndash152 Hong Kong August 2013

[11] Open Daylight ldquoCross Project Open Daylight Security Anal-ysisrdquo httpswikiopendaylightorgviewCrossProjectOpen-Daylight Security Analysis

[12] HP HP VAN SDN Controller Administrator Guide revision 21st edition 2014 httph20564www2hpcomhpscdocpublicdisplaydocId=c04003114

[13] ONOS ldquoSecure OpenFlow connection using TLSSSLrdquo httpsjiraonosprojectorgbrowseONOS-1319

[14] Y Zaki ldquoLong Term Evolution (LTE)rdquo in Future Mobile Com-munications LTE Optimization andMobile Network Virtualiza-tion vol 1 of Advanced Studies Mobile Research Center Bremenpp 13ndash33 Springer Wiesbaden Germany 2013

[15] M Stasiak M Głąbowski A Wisniewski and P Zwierzykow-ski ldquoUniversal mobile telecommunication systemrdquo inModelingand Dimensioning of Mobile Networks From GSM to LTE JohnWiley amp Sons Chichester UK 2010

[16] M D Aime G Calandriello and A Lioy ldquoDependability inwireless networks can we rely on WiFirdquo IEEE Security ampPrivacy vol 5 no 1 pp 23ndash29 2007

[17] S W Peters and R W Heath Jr ldquoThe future of WiMAX mul-tihop relaying with IEEE 80216jrdquo IEEE Communications Mag-azine vol 47 no 1 pp 104ndash111 2009

[18] F Bari and V C M Leung ldquoAutomated network selection in aheterogeneous wireless network environmentrdquo IEEE Networkvol 21 no 1 pp 34ndash40 2007

[19] C PengQ Zhang andC Tang ldquoImprovedTLS handshake pro-tocols using identitybased cryptographyrdquo in Proceedings of the2009 International Symposium on Information Engineering andElectronic Commerce (IEEC rsquo09) pp 135ndash139 Ternopil UkraineMay 2009

[20] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo ACM SIGCOMMComputer Communication Review vol 38 no 2 pp 69ndash742008

[21] S J Vaughan-Nichols ldquoOpenFlow the next generation of thenetworkrdquo IEEE Computer vol 44 no 8 pp 13ndash15 2011

[22] Standards for M2M and the Internet of Things oneM2MRelease 1 Specifications httpwwwonem2morgtechnicalpublished-documents

[23] D Locke ldquoMQ Telemetry Transport (MQTT) V31 ProtocolSpecificationrdquo August 2010 httpwwwibmcomdeveloper-workswebserviceslibraryws-mqttindexhtml

[24] Z Shelby K Hartke and C Bormann ldquoThe constrained appli-cation protocol (CoAP)rdquo RFC 7252 2014 httpsdatatrackerietforgdocdraft-ietf-core-coap

[25] C Bormann A P Castellani and Z Shelby ldquoCoAP an applica-tion protocol for billions of tiny internet nodesrdquo IEEE InternetComputing vol 16 no 2 pp 62ndash67 2012

[26] R T Fielding andRN Taylor ldquoPrincipled design of themodernWeb architecturerdquo in Proceedings of the ACM22nd InternationalConference on Software Engineering (ICSE rsquo00) pp 407ndash416Limerick Ireland June 2000


[27] D A Cooper ldquoA closer look at revocation and key compromisein public key infrastructuresrdquo in Proceedings of the 21st NationalInformation Systems Security Conference pp 555ndash565 October1998

[28] D Boneh X Ding G Tsudik and C M Wong ldquoA methodfor fast revocation of public key certificates and securitycapabilitiesrdquo in Proceedings of the 10th Conference on USENIXSecurity Symposium vol 10 pp 297ndash308 Berkeley Calif USA2001

[29] X Ding and G Tsudik ldquoSimple identity-based cryptographywith mediated RSArdquo in Topics in CryptologymdashCT-RSA 2003The Cryptographersrsquo Track at the RSA Conference 2003 SanFrancisco CA USA April 13ndash17 2003 Proceedings vol 2612 ofLecture Notes in Computer Science pp 193ndash210 Springer BerlinGermany 2003

[30] C Yoon T Park S Lee H Kang S Shin and Z Zhang ldquoEna-bling security functionswith SDN a feasibility studyrdquoComputerNetworks vol 85 pp 19ndash35 2015

[31] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology Proceedings of theCRYPTO rsquo84 Section I pp 47ndash53 Springer 1985

[32] R Sakai K Ohgishi and M Kasahara ldquoCryptosystems basedon pairingrdquo in Proceedings of the Symposium on Cryptographyand Information Security (SCIS rsquo00) Okinawa Japan January2000

[33] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Proceedings of the 21st Annual InternationalCryptology Conference Santa Barbara Calif USA August 2001

[34] N P Smart ldquoIdentity-based authenticated key agreement pro-tocol based on Weil pairingrdquo Electronics Letters vol 38 no 13pp 630ndash632 2002

[35] L Chen and C Kudla ldquoIdentity based authenticated key agree-met protocols from pairingsrdquo in Proceedings of the 16th IEEEComputer Security Foundations Workshop vol 2 pp 219ndash233Pacific Grove Calif USA July 2003

[36] M A S Santos B A A Nunes K Obraczka T Turletti BT De Oliveira and C B Margi ldquoDecentralizing SDNrsquos controlplanerdquo in Proceedings of the 39th Annual IEEE Conference onLocal Computer Networks (LCN rsquo14) pp 402ndash405 EdmontonCanada September 2014

[37] L Chen Z Cheng and N P Smart ldquoIdentity-based key agree-ment protocols frompairingsrdquo International Journal of Informa-tion Security vol 6 no 4 pp 213ndash241 2007

[38] S Chatterjee D Hankerson andAMenezes ldquoOn the efficiencyand security of pairing-based protocols in the type 1 and type4 settingsrdquo in Arithmetic of Finite Fields Third InternationalWorkshop WAIFI 2010 Istanbul Turkey June 27ndash30 2010Proceedings vol 6087 of Lecture Notes in Computer Science pp114ndash134 Springer Berlin Germany 2010

[39] N P Smart V Rijmen B Warinschi et al ldquoAlgorithms KeySizes and Parameter Reportmdash2013 recommendationsrdquo Euro-pean Union Agency for Network and Information Security(ENISA) version 10 October 2013

[40] J-H Lam S-G Lee H-J Lee and Y E Oktian ldquoSecuring dis-tributed SDN with IBCrdquo in Proceedings of the 7th InternationalConference on Ubiquitous and Future Networks (ICUFN rsquo15) pp921ndash925 Sapporo Japan July 2015

[41] Wireshark httpswwwwiresharkorg

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014


Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in



Control plane

Controller B

Sout

hbou

nd

Northbound

Controller A

EastWest-bound

Management plane SDN App 3 SDN App 1 SDN App 2

Wireddata plane

Switch BSwitch A

Host A Host B

Wirelessdata plane


LTE UMTS WiFi WiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts


Host A Host A

Figure 1The conceptual view of SDN with both wired and wirelessdata planes

In the single controller SDN implementation a com-promise of the controller will enable the attacker to controlthe entire network However in the distributed SDN thenetwork is spread across all the available controllers withinthe network In order to minimize the effect following thecompromise of a single controller in the distributed SDN theeastwest-bound communication has to be protected If it isleft unprotected the malicious controller will have the abilityto manipulate all other controllers in the entire network

The attacker can also insert a malicious data store into thenetwork to obtain a duplicate or backup copy of the networkinformation from other data stores within the network Byutilizing this information the attacker will then be able tolearn the network topology and carry out relevant attacksaccordingly Worse still the attacker can inject the desiredflow through a malicious data store

The southbound protocol defines the communicationbetween the control plane and the data plane There is acommonly agreed protocol for the southbound communi-cation which is the OpenFlow protocol [8] standardized bythe Open Networking Foundation (ONF) However other

southbound protocols are also available if OpenFlowdoes notsuit a particular purpose For instance Ciscorsquos ApplicationCentric Infrastructure (ACI) [9] is another alternative forOpenFlow However using such proprietary protocols willhence limit the devicersquos vendor choices

In order to protect the network from being driven bya malicious controller or to prevent a malicious switch ornetwork device from obtaining any network information thesouthbound communication must be operated in a securechannel OpenFlow suggested securing the southbound com-munication with Transport Layer Security (TLS)

Projects that do not implement TLS are prone to man-in-the-middle attacks [10] Attackers will be able to penetratetheOpenFlownetworkswhile remaining undetectedDespitethe security risks involved it is still not implemented inmanySDNprojects with exceptions such as OpenDayLight [11] HPVirtual Application Network (VAN) SDN [12] and ONOS[13]

One of the main reasons for why TLS is not used by SDNnetwork administrators is that the steps required to configureit correctly can be quite tedious [10]TheTLS implementationrequires a Certificate Authority (CA) to generate the CArsquos keycertificates for the controllers switches and then the signingof these certificates with the CArsquos key The certificates anddevicesrsquo keys will then be deployed to the respective devicesprior to the actual network deployment This tedious processis a hindrance for them when adopting the TLS to secure thecommunication channel

As illustrated in Figure 1 there are two general typesof data planes the wired and wireless variants SDN wasinitially built for the wired data plane and the data centeris the main consumer of it As the SDN technology growstelecommunication providers became interested in it andstarted experimenting with it in their network with ATampTsupporting both OpenDayLight and ONOS while VerizonChina Unicom NTT Communication and SK Telecom arebacking ONOS

However the original design neglected the wireless dataplane that was powered by numerous wireless technologiessuch as the Fourth-Generation Long Term Evolution (4G-LTE) [14] Universal Mobile Telecommunication System(UMTS) [15] Wireless Fidelity (WiFi) [16] and WorldwideInteroperability for Microwave Access (WiMax) [17] Henceit is difficult to manage the heterogeneous wireless data plane[18] even with the current advancement in SDN technologyIt is even more complicated when it comes to the securitymanagement between these wireless technologies

Unlike its wired counterpart the security for the wirelessdata plane cannot be neglected because anyone within thecoverage area of the wireless technology can tap into thenetwork and perform any malicious activities to disrupt thenetwork Therefore security becomes a crucial criterion forthewireless data plane before they can deploy it for real usage

By replacing TLS with Identity-Based Cryptography(IBC) [19] the steps required for system setup will be greatlysimplified improving both the performance availability andbandwidth availability as well as minimizing storage andmanagement of the public keys and therefore saving on costs








2 Background





Wirelessdata plane


LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts


Malicioususer 1

Attack

Malicioususer 2

Attack





























PKG Mediator

Userdevice

























119877Zlowast119902



997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr

119879Blarr997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888

119870AB = (119878A 119879B)(119876B119882A) 119870BA = (119878B 119879A)(119876A119882B)

119870AB = (1199041119876A 119887119875)(119876B 1198861199042119875) 119870BA = (1199042119876B 119886119875)(119876A 1198871199041119875)

119870AB = (119876A 119875)1199041119887(119876B 119875)

1199042119886 = 119870BA = (119876B 119875)1199042119886(119876A 119875)

1199041119887







1

1199041isin119877Zlowast119902) and (119875 119904

2119875 isin 119866



1with


2with


1is a


lowastrarr 1198661





there4 119870BA = 119870AB (1)















Switch 1


Switch 3Switch 2













Switch 1


Switch 2

Host A Host B



LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts











IBC (singledomain)

IBC (singledomain)

IBC (singledomain)


IBC(multidomain)

IBC(multidomain)









Encrypted channel


MQTTserver (broker)

Client hello

Server hello







































6 Conclusion








Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in










2 Background





Wirelessdata plane


LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts


Malicioususer 1

Attack

Malicioususer 2

Attack





























PKG Mediator

Userdevice

























119877Zlowast119902



997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr

119879Blarr997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888

119870AB = (119878A 119879B)(119876B119882A) 119870BA = (119878B 119879A)(119876A119882B)

119870AB = (1199041119876A 119887119875)(119876B 1198861199042119875) 119870BA = (1199042119876B 119886119875)(119876A 1198871199041119875)

119870AB = (119876A 119875)1199041119887(119876B 119875)

1199042119886 = 119870BA = (119876B 119875)1199042119886(119876A 119875)

1199041119887







1

1199041isin119877Zlowast119902) and (119875 119904

2119875 isin 119866



1with


2with


1is a


lowastrarr 1198661





there4 119870BA = 119870AB (1)















Switch 1


Switch 3Switch 2













Switch 1


Switch 2

Host A Host B



LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts











IBC (singledomain)

IBC (singledomain)

IBC (singledomain)


IBC(multidomain)

IBC(multidomain)









Encrypted channel


MQTTserver (broker)

Client hello

Server hello







































6 Conclusion








Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in
























PKG Mediator

Userdevice

























119877Zlowast119902



997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr

119879Blarr997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888

119870AB = (119878A 119879B)(119876B119882A) 119870BA = (119878B 119879A)(119876A119882B)

119870AB = (1199041119876A 119887119875)(119876B 1198861199042119875) 119870BA = (1199042119876B 119886119875)(119876A 1198871199041119875)

119870AB = (119876A 119875)1199041119887(119876B 119875)

1199042119886 = 119870BA = (119876B 119875)1199042119886(119876A 119875)

1199041119887







1

1199041isin119877Zlowast119902) and (119875 119904

2119875 isin 119866



1with


2with


1is a


lowastrarr 1198661





there4 119870BA = 119870AB (1)















Switch 1


Switch 3Switch 2













Switch 1


Switch 2

Host A Host B



LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts











IBC (singledomain)

IBC (singledomain)

IBC (singledomain)


IBC(multidomain)

IBC(multidomain)









Encrypted channel


MQTTserver (broker)

Client hello

Server hello







































6 Conclusion








Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





119877Zlowast119902



997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr

119879Blarr997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888

119870AB = (119878A 119879B)(119876B119882A) 119870BA = (119878B 119879A)(119876A119882B)

119870AB = (1199041119876A 119887119875)(119876B 1198861199042119875) 119870BA = (1199042119876B 119886119875)(119876A 1198871199041119875)

119870AB = (119876A 119875)1199041119887(119876B 119875)

1199042119886 = 119870BA = (119876B 119875)1199042119886(119876A 119875)

1199041119887







1

1199041isin119877Zlowast119902) and (119875 119904

2119875 isin 119866



1with


2with


1is a


lowastrarr 1198661





there4 119870BA = 119870AB (1)















Switch 1


Switch 3Switch 2













Switch 1


Switch 2

Host A Host B



LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts











IBC (singledomain)

IBC (singledomain)

IBC (singledomain)


IBC(multidomain)

IBC(multidomain)









Encrypted channel


MQTTserver (broker)

Client hello

Server hello







































6 Conclusion








Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





Switch 1


Switch 3Switch 2













Switch 1


Switch 2

Host A Host B



LTEUMTS WiFiWiMax

BSAP for IoT

End hosts

BSAP for IoT

IoT hosts











IBC (singledomain)

IBC (singledomain)

IBC (singledomain)


IBC(multidomain)

IBC(multidomain)









Encrypted channel


MQTTserver (broker)

Client hello

Server hello







































6 Conclusion








Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in








IBC (singledomain)

IBC (singledomain)

IBC (singledomain)


IBC(multidomain)

IBC(multidomain)









Encrypted channel


MQTTserver (broker)

Client hello

Server hello







































6 Conclusion








Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in
































6 Conclusion








Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





Disclosure


Competing Interests


Acknowledgments


References


















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in


























Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in



research article securing sdn southbound and...

Documents