Enhancing Internet of Things Security using Software-Defined Networking

ContentslistsavailableatScienceDirect

Journal of Systems Architecture

journalhomepage:www.elsevier.com/locate/sysarc

Enhancing Internet of Things Security using Software-Defined Networking

Bander Alzahrani

^a,∗

, Nikos Fotiou

^b

aFaculty of Computing and Information Technology, King Abdulaziz University, Jeddah, Saudi Arabia

bMobile Multimedia Laboratory, Department of Informatics, School of Information Sciences and Technology, Athens University of Economics and Business, Athens, Greece

a r t i c le i n f o

Keywords:

Access control

Software-Defined Networking Constrained application protocol Internet of Things

a b s t r a ct

AccesscontroltechnologiesarefundamentalforaddressingthesecurityandprivacyrequirementsoftheInternet ofThings(IoT).ThispaperproposesanaccesscontrolsolutionforConstrainedApplicationProtocol(CoAP)- basedIoTservices.Theproposedsolutionconsidersanetworkofasingleproviderthatinterconnectsvarious IoTendpoints.ItleveragestheSoftware-DefinedNetworking(SDN)paradigmandimplementsapplicationaware policyenforcementatthenetworklevel.AlloperationsaretransparenttotheIoTendpointsandnomodifications arerequiredtotheIoTcommunicationprotocol.Furthermore,oursolutionisbuiltonstandardOpenFlow,hence itisrealisticanditcanbeeasilydeployedtoanexistingnetwork.Weprovethefeasibilityofoursolutionthrough aproofofconceptimplementationusingnetworkemulation.

1. Introduction

Nowadays,manyaspectsof ourlifearecontrolled–orassisted–by cyber-physical systems. The so-called Internet of Things (IoT) is al- readyusedinmanydomains,includingagriculture,patientmonitoring, homeautomation,well-being,smartcities,andmanyothers.TheIoTis mainlycomposedofdeviceswhichmaybedeprivedofcomputational power,continuousnetworkconnectivity,energy,orevenphysicalsecu- rity.Therefore,itcomesasnosurprisethatapplyingsecuritysolutions inthisenvironmentisachallengingproblem.Inthispaper,wefocus onaparticularaspectofsecurity,thatisaccesscontrol.Weconsider thecaseofanetworkofasingleoperatorthatinterconnectsvariousIoT devices.Thesedevicesprovideresourcesoractuationservices,andcan beaccessedusingtheConstrainedApplicationProtocol(CoAP)[1].

Inordertomotivateoursolution,weconsidertheusecaseofasmart citymanagementsystem.ThissystemiscomposedofIoTsensors(e.g., temperaturesensors)andactuators(e.g.,switches).Ourgoalistoen- ablesystemadministratorstodefinecontext-awareaccesscontrolpoli- ciesthatwillmediateaccesstotheIoTdevices.Moreformally,wewant toprovideaMandatoryAccessControl(MAC)solutionwherepoliciesare centrallydefinedbythesystemadministratorsandcannotbemodified oroverriddenbyendusers.Anexampleofsuchpolicy,inourrefer- encesystem,isthecaseofaswitchthatturnsonandoff streetlights;in thatcasethesystemadministratorcouldcreateanaccesscontrolpolicy thatdefinesthat“streetlightsswitchescanbeturnedonafter8pmand turnedoff after6am,andalloperationsshouldoriginatefromtheman- agementcenterbuilding”.Itcanbeobservedthatthispolicydefinesthe

∗Correspondingauthor.

E-mailaddress:baalzahrani@kau.edu.sa(B.Alzahrani).

resource(switch),theaction(turnon/off),anddefinesconstrainsre- latedtothetimethatanactioncantakeplaceandthephysicallocation fromwhichitcanoriginate.

Itcanbearguedthatitispossiblytoimplementsuchanaccesscon- trolsystembyfollowingadistributedapproach,usingmorepowerful

“gateways” attachedtotheIoTdevices.Wepostulate,however,that thisapproachhasmanydisadvantages,suchas(i)policymanagement becomesdifficult,sincepolicyupdateshavetobe“pushed” toallgate- ways,(ii)action“logging” isharder,(iii)agatewaymaynothavethe necessaryinformationtoperformanaccesscontroldecision(e.g.,thelo- cationfromwhicharequestoriginated),and(iv)unauthorizedrequests stillusenetworkresourceshence,theymaybeusedforattackssuchas DenialofService(DoS).Instead,inthispaperwefollowacentralized approachwhereaccesscontroldecisionsaremadebyacentralizeden- tityandtheyareenforcesclosetomessagesenders.Inordertoachieve ourgoal,weleverageSoftware-DefinedNetworking(SDN)[2]andEdge computing[3]paradigms,andtheOpenFlow[4]protocol.Insummary, thispapermakesthefollowingcontributions:

• Wedesign,build,andevaluateamandatoryaccesscontrol(MAC) systemfortheIoT.

• Weproposeafine-grainedcontext-awareaccesscontrolmechanism thatoperatesovernetworkflows.

• WemakeoursolutiontransparenttoIoTendpoints.

• Webuildoursolutionusingstandardizedprotocolswithoutrequir- inganymodification.

Therestofthispaperisorganizedasfollows.InSection2,wein- troduceCoAPandSDN,andwediscussrelatedworkinthisarea.We

https://doi.org/10.1016/j.sysarc.2020.101779

Received29October2019;Receivedinrevisedform29January2020;Accepted3April2020 Availableonline26April2020

1383-7621/© 2020ElsevierB.V.Allrightsreserved.

giveahighleveloverviewofoursysteminSection3,andwepresent itsdesigninSection4.Finally,weevaluateourapproachinSection5, andpresentourconclusionsandplansforfutureworkinSection6. 2. Backgroundandrelatedwork

2.1. Theconstrainedapplicationprotocol

TheConstrainedApplicationProtocol(CoAP)[1]aimstobecomethe HTTPequivalentfortheIoT.CoAPspecifiestwomainentities,theCoAP clientandtheCoAPserver.ACoAPserveroffersaresourcewhichisiden- tifiedbyaCoAP-URI,i.e.,aURIthatfollowsthesamesyntaxasHTTP URIs.ACoAPclientmayrequesttoaccessormodifyaresourceusing oneoftheCoAPmethods:GET,PUT,POST,DELETE.CoAPhasbeen designedtobeusedoverunreliabletransportprotocols(e.g.,UDP)for thisreasonitspecifiesacknowledgmentmechanisms.Asalientfeature ofCoAPisthatitallowsCoAPclientstorequestaresourcethatisnot yetavailable.Inthatcase,theCoAPserveracknowledgesthereception oftherequestandrespondswhenevertherequestedresourcebecomes available:in orderfor aCoAPclient tobe abletomatcharesponse witharequest,itincludesatokenintherequest,whichisrepeatedby theserverintheresponse.Oursolutiontakesadvantageofthistoken mechanism.

Inadditiontothetwomainentities,CoAPRFC(i.e.,RFC7257)spec- ifiesanoptionalentity,i.e.,theCoAPproxy.ACoAPproxycanbetrans- parent,orclientsand/orserversmaybeawareofit.Proxiesareused forprovidingadditionalfunctionality(e.g.,caching),aswellasproto- coltranslation(e.g.,CoAP-toHTTPproxiesandviceversa).Oursolution considersCoAPproxiesthattranslatesCoAPmessagesintotheappro- priateprotocolinvocationsofoursystem.

2.2. Software-DefinedNetworking

Software-DefinedNetworking(SDN)[2]isanemergingtechnology thathasreceivedwideattentionandhasalreadybeenadoptedbymajor networkproviders.SDNdecouplesthenetworkcontrolplanefromthe dataforwardingplane.ThelatterisimplementedbySDNswitchesusing

“rules” definedbya(logically)centralizedcomponent,i.e.,theSDNcon- troller.Usingaseparatecontrolnetwork,thecontroller“installs” flow- widerulestoswitchesthatspecifyhowaswitchshouldhandlenetwork flows.ThecommunicationbetweenSDNswitchesandthecontrolleris implementedusingprotocolssuchastheOpenFlowprotocol[4].

Flowrulesincludefiltersthatareappliedovervariousfieldsofin- comingoroutgoingflows,anddefinetheactionsthataswitchshould performincaseofamatch.Generally,allflowsshouldbematchedto arule:incaseaswitchisnotabletofindaruleforaspecificflowit forwardsthecorrespondingpackettothecontrollerwhichinreturnre- spondswiththeappropriateinstructions.

2.3. Relatedwork

SDNtechnologyasenablerfortheIoThasbeenstudiedbynumerous researchefforts(forasurveyinthisareainterestedreadersarereferred to[5,6]).Ourworkisorthogonaltotheseefforts.Weareconcernedwith theapplicationlayerandwedesignanaccesscontrolmechanismfor CoAP-basedIoTservices.Ourmechanismiscompatiblewithanyproto- colthatusestherequest-responsecommunicationparadigmtoretrieve namedresources,andhassupportforproxies(e.g.,HTTP).Similarly, oursolutionconcernsthecommunicationamongIoTendpointsanditis orthogonaltosystemsthatsecureaccesstoIoTdatastoredinacentralized powerfulnode(seeforexample[7])

Hongetal.[8]proposeanSDN-basedframeworkforenforcingac- cesscontrolpoliciesonusermobiledevicesincorporatenetworks(a.k.a BringYourOwnDevice–BYOD).Incontrast toourwork,thesolution in[8]considersalegacynetworkwithoutSDNswitchesandproposes modificationstouserdevices.Ourworkfollowstheoppositeapproach:

wemakenomodificationstoend-devicesandwerelyonSDNswitches toenforceouraccesscontroldecisions.

Sonchack et al.[9] leverage SDN toprovide in-network security mechanisms.However,intheirapproachtheydonotrelyonstandard OpenFlow,insteadtheyproposeandimplementOpenFlowextensions thatenableSDNswitchestoevaluatemorecomplexrules.Withtheseex- tensions,SDNswitchescanperformsecurity-relatedoperationswithout interactingwiththecontroller.Similarly,Voellmyetal.[10]proposed alanguage,code-namedProcera,fordefiningmorecomplexrulesthat reactinconditionssuchasuserauthentication,ortimeoftheday.Our solutiondoesnotrequiremodificationstotheOpenFlowprotocol.Fur- thermore,inordertodecreasetheamountoftrafficbetweentheSDN switchesandthecontroller,weshiftsomeofthecontrolplaneintelli- gencefromthecontrollertotheedgeofthenetwork.

Varioussystems,suchasFRESCO[11]andOpenSec[12],definehigh levelaccesscontroldefinitionlanguagesthataretranslatedintoOpen- Flowrules.Thesesystemscanbyusedbyoursolutionasmechanisms forcreatingaccesscontrolpolicies.

ThesystemproposedbyRiveretal.[13]hasthesamegoalswith ourworkbutinadifferentcontext:thissystemistailoredtoroboticap- plicationsandtheRoboticOperationsSystem(ROS).ROSisapublish- subscribesystemwhichinadditiontothecommunicatingendpoint,it considers anintermediate entityresponsibleforthe “topic” manage- ment.Theproposedsolutionrequiresmodifications(intheformofex- tensions)toallelementsofaROSsystem.

Papachristouetal.[14]proposeruntimeandroutingpoliciesfor enhancingthesecurityandthequalityofserviceinSDN-basedIoTar- chitectures.Theworkinthatpaperisahighlevelapproachanddoes notdiscusshowthesepoliciescanbeimplemented.Ourworkdefines amechanismthatallowsSDNcontrollersandnetworkedgenodesto enforceuser-definedaccesscontrolpolicies.

3. Systemoverview 3.1. Underlayarchitecture

Theunderlayarchitectureof oursolutionisbasedonthesystems describedin[15]and[16].Inthecoreofourarchitecturethereisan SDNnetwork,attheedgesofwhichthereexistNetworkAttachmentPoints (NAPs).EachNAPisidentifiedbyaNAP_idandallNAPsknowallNAP_ids. NAPsareconnectedtotheSDNnetworkusinganSDNswitch;inthe following, whenitis statedthatan“OpenFlow ruleisinstalled ina NAP” itismeantintheSDNwhichthattheNAPusesforconnectingto thenetwork.

ThereareCoAPendpoints(i.e.,CoAPclientsandservers)attached toeachNAP.EachCoAPserveroffersaresourcewhichisassociatewith (atleast)oneCoAPURI.Itshouldbenotedthattherecanbemultiplere- sources,belongingtodifferentCoAPservers,sharingthesameURI(e.g., coap://city/lights).EachNAPknowsallCoAPURIsofallCoAPservers attachedtoit(e.g.,throughaconfigurationfileoraCoAPdiscoverypro- tocolsuchasCoREresourcedirectory[17]).NAPsactasCoAPproxies andCoAPclientsareconfiguredtocommunicatethroughtheproxyof theNAPinwhichtheyareattached.Therefore,allCoAPrequestsare routedthroughaNAPandNAPsareabletoparsetheserequestsandex- tractinformation.AllCoAPmessagesaresentusingtheIPv6protocol, itisassumedthatallCoAPrequestsincludeatoken,andthatasingle CoAPmessagefitsinasinglenetworkpacket,i.e.,packetfragmentation isnotrequired.¹

PacketforwardingamongNAPsisimplementedusingBloomfilters approach [18]whichhasbeendescribedin[19].Inanutshell,eachlink ofthecorenetworkisidentifiedbyabitarray,referredtoasthelink

1Thisassumptionhasbeenmadeforfacilitatingtheimplementationofour solution.Ourimplementationcanbeextendedtosupportpacketfragmentation.

Inanycase,consideringthat

identifier;thepaththatapacketshouldfollowisencodedinaBloom filter,referredtoasthepathidentifier,constructedbyORingthelink identifiersoftheappropriatelinks.PathidentifiersarestoredintheIPv6 addressfields,henceitiseasytoconstructtheappropriateflowrulesin ordertoachieveBloomfilter-basedforwarding.Inparticular,andfrom ahighlevelperspective,²eachSDNswitchisconfiguredwithanOpen- Flowruleperinterface,thisruleperformsasubnetmaskcheckonthe IPv6destinationaddress(i.e.,itchecksifthedestinationaddressbe- longstothenetworkdefinedbythenetmask)andifthechecksucceeds thepacketisforwardedfromthecorrespondinginterface;thischeckis performedforallinterfaces,henceapacketmaybeforwardedtomulti- pleinterfaces(achievingthiswaymulticast).Thenetmaskusedineach ruleisthelinkidentifierofthecorrespondinglink.³TheOpenFlowrules requiredforimplementingBloomfilter-basedforwardingareinstalled once,duringthenetworksetupphase.

Pathidentifiers in ourarchitecture arebi-directional,i.e.,apath identifierusedforforwardingapacketfromaNAPAtoaNAPB,can beusedforforwardingpacketsfromBtoAaswell.Anotherinteresting propertyofpathidentifiersisthattheycanbecombinedtocreatemulti- casttrees.Forexample,givenapathidentifierPath_A→Bofthepathfrom NAPAtoNAPBandanotherpathidentifierPath_A→Cofthepathfrom NAPAtoNAPC,thenPath_A→B|Path_A→C(where|denotesbitwiseOR) resultstoanewpathidentifierthatcanbeusedformulticastingpackets fromNAPAtoNAPsBandC.

Finally,oursystemassumesthattheSDNcontrollerknowsthenet- worktopology,alllinkidentifiers,andtheCoAPURIsassociatedwith eachNAP,anditprovidesa“Northbound” APIthatallowsresourceown- erstoinstall,update,orremoveaccesscontrolpolicies.

3.2. Systementitiesandinteractions

Oursystemiscomposedofthefollowingentities.

• Systemadministrator.Thisisarealworldentity(althoughthisrole canbesimultaneouslyassignedtomultiplerealworldentities)which isresponsiblefordefiningtheaccesscontrolpoliciesthatgovern accesstoIoTresources.

• CoAPclients.TheseareapplicationsthatinteractwithCoAPservers (seebelow)usingtheCoAPprotocol.CoAPclientsabidebytheCoAP RFCandareobliviousaboutouraccesscontrolsolution.

• CoAPservers.Theseareapplicationsthatmayprovidearesource oranactuationserviceusing theCoAPprotocol. SimilartoCoAP clients,CoAPserversabidebytheCoAPRFCandareobliviousabout ouraccesscontrolsolution.

• PolicyDecisionPoint(PDP).ThePDPisacentralizedsystemen- titylocatedalongsidetheSDNcontroller.Itisresponsibleforinter- pretinganaccesscontrolpolicyanddeciding(basedonthispolicy) whetherornotaCoAPoperationcanbepermitted.

• PolicyEnforcementPoint(PEP).ThePEPisadistributedsystem entitylocatedineachNAP.Itisresponsibleforimplementingthe accesscontroldecisionofthePDP.

Fromahighlevelperspectivetheseentitiesinteractwitheachother (throughtheunderlayarchitecture)asfollows(Fig.1).Thesystemad- ministratorusesthecontroller’s northboundAPItointeractwiththe PDPanddefinethedesiredaccesscontrolpolicies.ACoAPclientissues aCoAPrequestthatreachestheNAPinwhichtheclientisattached.If thePEPoftheNAPdoesnotknowhowtohandlethisrequestitcommu- nicateswiththePDP(greenline).ThePDPinspectstherequest,exam- inesifthereexistsanyapplicableaccesscontrolpolicy,andmakesthe appropriatedecision(redline).BasedonthePDPdecision,thePEPei- therallowstherequesttoreachtheintendedCoAPserver(s)ordropsit

2 Interestedreaderscanfinddetailsaboutthisapproachin[19]

3 OpenFlowspecificationsallow“arbitrary” networkmasks,i.e.,masksdonot havebeaseriesof1sfollowedby0s,insteadtheycanbeanybitarraywithsize equaltothesizeofanIPv4/v6address.

(orangeline).ApositivePDPdecisionisaccompaniedbyanOpenFlow rulewhichisusedbytheNAPinordertoforwardtheCoAPrequestto thenetwork.Thisrulemayhavealimitedlifetime,defined(implicitly orexplicitly)bytheaccesscontrolpolicyonwhichthepolicydecision wasbased.

3.3. Securityassumptions

InthispaperweassumethattheSDNnetworkistrusted,therefore itisnotpossibleforanattackertoaffecttheoperationoftheSDNcon- troller,toview/editSDNcontrolmessages,ormanipulatetheflowrules oftheSDNswitches.Furthermore,NAPsarealsoconsideredtrustedand asecure“networkattachment” processisassumed,i.e.,itshouldnotbe possibleforanattackertoattachanewNAPtothenetworknortoat- tachhimselftoanexistingNAPbybypassingthenetworkattachment process.

Furthermore, our system assumes that system administrators are properlyauthenticated,thereforeaccesscontrolpoliciesareprotected againstunauthorizedmodifications.Similarly,NAPsareabletoauthen- ticateCoAPserversandverifytheownershipofaCoAPURI.

OursystemtreatsallCoAPclientsasanonymoususersanditisnot concerned withCoAPclients’authentication.Similarly,itisassumed thatthesecrecyandtheintegrityofCoAPmessagesisprotectedusing higherlayermechanismswhichareoutofthescopeofthispaper.

Giventheabovesecurityassumptions,thethreatmodelofoursystem considers maliciousCoAPclientswishingtoaccessaprotectedCoAP server;althoughtheseCoAPclientsareauthorizedtoattachtoaNAP theyarenotauthorizedtoaccesstheresourceinquestion.

4. Systemdesign 4.1. Policydefinition

Policiesareexpressedinoursystemusinganadaptedversionofthe policydefinitionlanguagedefinedin[8].ThisXML-basedlanguagede- finesfourbasicelements:

• Target.ThiselementdefinestheCoAP-URIoftheresource(s) con- trolledbythatpolicy.Wildcardcharacterscanbeusedtoindicatea CoAP-URIprefix.

• Match.Thiselementdefinesafilter,intheformofanOpenFlowrule, thatcanbe usedforassociatingnetworkflowstopolicies(e.g.,a policyisappliedifaflowhasoriginatedbyaparticularmacaddress–

thatmaycorrespondtotheMACaddressofaNAP).

• Predicate.This elementdefinesfiltersforcontext-awarematching.

Currently the predicate element supports time-based and CoAP method-basedfiltering.

• Actions.ThiselementdefinestheOpenFlowrulesthatshouldbein- stalledintheNAPthatsenttherequest.

Twopoliciesshouldnotusethesamevaluesforthetarget,match, andpredicateelements.Theactionselementallowsthedefinitionofa path,whichcanbeusedasavariableintheOpenFlowrules.Thepath identifieriscalculatedatruntimeandthecorrespondingrulesaremod- ifiedaccordingly.Figure1showsanexampleofanaccesscontrolpolicy definition.ThispolicyisevaluatedwhentheURI“coap://city/lights” is invokedformaparticularnetworklocation,after8pm,usingtheCoAP PUTmethod;apathidentifieriscalculatedtowardssomeNAPsandthe appropriateOpenFlowruleiscreated.

4.2. NAPtocontrollercommunication

Inthefollowingsubsectionwewillpresentoperationsthatrequire communicationbetweenaNAPandtheSDNcontroller.Thisfunction- alityhasbeenimplementedasfollows.AsalreadydiscussedeachNAP is connectedtoan SDN switch.These switchesare configuredwith anOpenFlowrulethatinstructsthemtoforwardallpacketsthatuse

Fig.1. High-leveloverviewoftheproposedsolution.A CoAPrequestfromaclientisforwardedtothePDP(green line);thePDPinstallstheappropriaterules(redline);the PEPforwardstherequesttotheCoAPserver(orangeline).

(Forinterpretationofthereferencestocolourinthisfigure legend,thereaderisreferredtothewebversionofthis article.)

Listing1. Accesscontrolpolicydefinition.

“00:00:00:00:00:01” asanEthernetdestinationtothecontroller.There- fore, if a NAP sets the Ethernet destination address of a packetto

“00:00:00:00:00:01”,thispacketwilleventuallyreachthecontroller.

Similarly,whenacontrollerreceivessuchapacket,itcreatesaPacket- outOpenFlowmessage,thatcontainsthecontroller’sresponseandin- structstheSDNswitchtoforwardthismessagetoportinwhichtheNAP isconnected.

Intherestofthispaper,wehidethisdetailandwesimplysaythat

“aNAPsendsapackettothecontroller”.

4.3. CoAPrequestandresponsehandling

WheneveraCoAPrequestarrivestoaNAP,theNAPshoulddecide whichpathidentifiertouseforforwardingtherequesttothenetwork.

Similarly,wheneveraCoAPresponsearrivesfromthenetwork,aNAP shouldbeabletodecidetheCoAPclienttowhichitwillforwardthe responses.Inordertoachievethisfunctionality,each NAPmaintains

twodatastructures,arequestforwardingtableandapendingresponses table.

Therequestforwardingtablecontainsrowsoftheform[URI,Path_ID, expires].WheneverapacketthatcontainsaCoAPrequestarrivesata NAP,theNAPextractstheURIoftheresourceincludedintherequest, andsearchestheforwardingtableforanexisting,non-expiredentry.

Ifanentryisfound,theNAPreplacestheIPv6destinationfieldofthe packetwiththecorresponding pathidentifier,andforwardsittothe network.Otherwise,theNAPsendstherequesttothecontroller,the controllerextractsalltherequiredinformation,evaluatestheappropri- ateaccesscontrolpolicies,andrespondsaccordingly.Ifthecontroller’s responseincludesapathidentifier,thentheNAPupdatestheforwarding table,modifiesthepacket,andsendsittothenetwork.

The pending responses table contains rows of the form [token, Client_IP]. Wheneverapacketthat containsaCoAPrequestarrivesat aNAP,theNAPextractstheCoAPclientIPaddressandthetokenin- cludedintherequestandupdatesthependingresponsestableaccord- ingly.ThecorrespondingCoAPresponsemustincludethesametoken, therefore,wheneveraresponsearrivesataNAP,theNAPextractsthe token,retrievestheclient’sIPaddressfromthependingresponsestable andreplacesthepathidentifierofthepacketwiththeclientsaddress.

Finally,theNAPforwardstheresponsetotheclient.

5. Evaluation

WeimplementedoursolutionusingOpenvSwitch[20]SDNswitch andthePOX[21]SDNcontroller.WeimplementedCoAPendpointsand theCoAPproxy(locatedattheNAPs)usingthelibcoaplibrary.⁴We evaluatedourimplementationusingthemininetnetworkemulator[22]. OursolutionrequiresfromtheNAPstomaintaintwodatastructures, aswellastooccasionallyforwardCoAPrequeststothecontroller.We measurethisoverheadusingtheworkloadofthetemperaturemeasure- mentsensorsdeployedinthetestbedofSmartSantander,alarge-scale smartcitydeploymentlocatedinSantander,northernSpain.Thework- load,asreportedin[23],iscomposedof70temperaturesensors,gener-

4https://libcoap.net/.

Fig.2. Numberofentriesoftherequestforwardingtable,andnumberofmes- sagestothecontroller,asafunctionofthepathidentifiertimeout.

atingatemperaturemeasurementapproximatelyevery5min.Wecon- siderthateachtemperaturesensorisidentifiedbyaCoAPURI.Foreach CoAPURIthereisasingleaccesscontrolpolicythat“accepts” arequest andcreatesapathidentifier:theexpirationtimeofeachpathidenti- fierisusedasavariableinourmeasurements,andaswediscussinthe followingsubsectionthiscreatesasecurity-performancetradeoff.Weas- sumethateachclient-sideNAPcanaccommodateamaximumnumber ofclients(usedasavariableinourexperiments,aswell).Eachclient requestsarandomlyselectedsensormeasurement.Clients’requestin- tervalfollowanormaldistributionwithaverage1min.Themaximum numberofentriesthatresponsestablemaycontainequalstothenumber ofclientsconnectedtoaNAP.Thisrepresentstheextremecasethatall clientshavemadeaCoAPrequestandnoresponsehasbeenreceived.

Thesizeofeachentryinthistableis24bytes(16bytesforclientIPv6 addressand8bytesfortheCoAPtoken–thisisthemaximumvaluespec- ifiedby[1])).

Wenowmeasurethenumberofentriesintherequestforwarding tableof aNAP,aswellasthenumberof requestsa NAPsendstoa controller.Eachexperimentbeginswithawarmingupperiodequalto thepathidentifiertimeout. Thenwe continuetoruntheexperiment for1h. Fig.2showsthemaximumnumberofentriesof therequest forwardingtableandthetotalnumberofrequestssenttothecontroller asfunctionofthepathidentifiertimeout.Inthisexperimentthenumber ofCoAPclientsperNAPis setto10.Thesameexperimenthasbeen performedwiththenumber ofclients varyingfrom 5to20andthe resultsfollowasimilarpattern.

Fig.3shows themaximumnumberof entriesof therequestfor- wardingtableandthetotalnumberofrequestssenttothecontroller asfunctionof thenumberof clientsperNAP.Inthis experimentthe pathexpirationtimeissetto10min.

5.1. Securityevaluation

Oursolutiondoesnotconsidernetworkpropertiesoftheclients(e.g., currentlyitisnotpossibletodefineanaccesscontrolpolicybasedona CoAPclientnetworkaddress),neitherconsidersthecontextoftheclient applications(e.g.,itdoesnotperformuserauthorizationandaccesscon- trol.)Furthermore,oursolutionrequiresthatNAPsaretrusted,sincea misbehavingPEP(locatedinaNAP)mayignoreaPDPdecision(ora pathidentifiertimeout)anduseapathidentifierthatisalreadyknown.

Aninterestingsecurity-performancetradeoff ofoursolutionisre- latedtothepathidentifiertimeout.Asshownintheprevioussubsec- tion,largetimeoutsresultinsignificantlylessmessagessenttothecon- troller.Thisnotonlydecreasestheoverheadimposedtothecontroller, butitalsoresultsinCoAPclientsexperiencingfasterresponsestotheir requests(sincearequestisforwardedbytheNAPwithoutcommuni-

Fig.3. Numberofentriesoftherequestforwardingtable,andnumberofmes- sagestothecontroller,asafunctionofthenumberofclientsofaNAP.

catingwiththecontroller).Ontheotherhand,whileapathidentifier isvalidaCoAPclientmayaccessaresourceforwhichisnotanymore authorized.Forthisreason,pathidentifierstimeoutsmustbecarefully selected.

5.2. Discussion

Oursystemtakesfulladvantageoftheforwardingsolutionpresented in [19].AllOpenFlowrulesrequiredforimplementingthisapproach areinstalledinallSDNswitchesduringsetup:onceapacketleavesa NAP,itisforwardeddirectlytoitsdestination(s)withoutanyfurther communicationwiththecontroller.Furthermore,andasdiscussedin moredetailin[15],thenumberofforwardingrulesinonlyrelatedto thenumberofNAPsandnottothenumberoftheIoTdevices.

Anotheraspectthataffectstheperformanceofoursystemisthenum- berandthecomplexityofaccesscontrolpolicies.Ofcourse,thisisa concernthatallaccesscontrolsystemsshare.Forthisreason,inthispa- perwedecidedtonotfocusonthisaspect.However,itshouldbenoted thattheonlyentityaffectedbythecomplexityoftheaccesscontrolpoli- ciesisthe(centralized)PDS:allotherentities,includingIoTdevices,are oblivioustothepolicies.

6. Conclusionsandfuturework

InthisworkweproposedanSDN-basedsolutionforenforcingaccess controlinCoAP-basedIoTapplications.Oursolutiondoesnotrequire any modificationtotheIoTendpoints,anditisbuiltusingstandard

OpenFlowfunctionality.Oursolutioncanbe deployedusing existing infrastructureandimposesminimaloverhead.

Astrongsecurityrequirementofoursolutionisthatthenetwork attachmentspoints (NAPs),which alsoactasthepolicyenforcement points(PEPs)tobe trustedandtonot usepathidentifiers thathave expired.OurapproachcanbeprotectedagainstmisbehavingNAPsby usingmechanismsthatrenderapathidentifieruselessafterthetime- outperiod,e.g.,linkidentifiersmaynotbeconstant,insteadtheymay changeaftersometimerelatedtothepathidentifiertimeout.Itisinour futureworkplanstoexploresolutionstowardsthisdirection.

DeclarationofCompetingInterests

Theauthorsdeclarethattheyhavenoknowncompetingfinancial interestsorpersonalrelationshipsthatcouldhaveappearedtoinfluence theworkreportedinthispaper.

Acknowledgments

ThisprojectwasfundedbytheDeanshipofScientificResearch(DSR) atKingAbdulazizUniversity,Jeddah,undergrantno.G-235-611-1440. Theauthor,therefore,acknowledgewiththanksDSRfortechnicaland financialsupport.

References

[1] Z. Shelby , K. Hartke , C. Bormann , The Constrained Application Protocol (CoAP), RFC, IETF, 2014 .

[2] W. Xia, Y. Wen, C.H. Foh, D. Niyato, H. Xie, A survey on software- defined networking, IEEE Commun. Surv. Tutor. 17 (1) (2015) 27–51, doi: 10.1109/COMST.2014.2330903 .

[3] A. Yousefpour , C. Fung , T. Nguyen , K. Kadiyala , F. Jalali , A. Niakanlahiji , J. Kong , J.P. Jue , All one needs to know about fog computing and related edge computing paradigms: a complete survey, J. Syst. Archit. 98 (2019) 289–330 .

[4] A. Lara, A. Kolasani, B. Ramamurthy, Network innovation using open- flow: a survey, IEEE Commun. Surv. Tutor. 16 (1) (2014) 493–512, doi: 10.1109/SURV.2013.081313.00105 .

[5] N. Bizanis , F.A. Kuipers , Sdn and virtualization solutions for the internet of things:

a survey, IEEE Access 4 (2016) 5591–5606 .

[6] S. Bera , S. Misra , A.V. Vasilakos , Software-defined networking for internet of things:

asurvey, IEEE Internet Things J. 4 (6) (2017) 1994–2008 .

[7] M. Wazid , A.K. Das , R. Hussain , G. Succi , J.J. Rodrigues , Authentication in cloud–

driven IoT-based big data environment: survey and outlook, J. Syst. Archit. 97 (2019) 185–196 .

[8] S. Hong , R. Baykov , L. Xu , S. Nadimpalli , G. Gu , Towards SDN-Defined Pro- grammable BYOD (Bring Your Own Device) security, 23rd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, California, USA, February 21–24, 2016, 2016 .

[9] J. Sonchack , J.M. Smith , A.J. Aviv , E. Keller , Enabling practical software-defined net- working security applications with OFX, 23rd Annual Network and Distributed Sys- tem Security Symposium, NDSS 2016, San Diego, California, USA, February 21–24, 2016, 2016 .

[10] A. Voellmy , H. Kim , N. Feamster , Procera: A language for high-level reactive network control, in: Proceedings of the First Workshop on Hot Topics in Software Defined Networks, in: HotSDN ’12, ACM, New York, NY, USA, 2012, pp. 43–48 . [11] S. Shin , P. Porras , V. Yegneswaran , M. Fong , G. Gu , M. Tyson , FRESCO: modular

composable security services for software-defined networks, Internet Society NDSS., 2013 .

[12] A. Lara , B. Ramamurthy , Opensec: policy-based security using software-defined net- working, IEEE Trans. Netw. Serv. Manage. 13 (1) (2016) 30–42 .

[13] S. Rivera , S. Lagraa , C. Nita-Rotaru , S. Becker , R. State , Ros-defender: Sdn-based security policy enforcement for robotic applications, in: 2019 IEEE Security and Privacy Workshops (SPW), 2019, pp. 114–119 .

[14] K. Papachristou , T. Theodorou , S. Papadopoulos , A. Protogerou , A. Drosou , D. Tzo- varas , Runtime and routing security policy verification for enhanced quality of ser- vice of IoT networks, in: 2019 Global IoT Summit (GIoTS), 2019, pp. 1–6 . [15] N. Fotiou, V.A. Siris, G. Xylomenos, G.C. Polyzos, K.V. Katsaros, G. Petropoulos,

Edge-icn and its application to the internet of things, in: 2017 IFIP Networking Con- ference (IFIP Networking) and Workshops, 2017, pp. 1–6, doi: 10.23919/IFIPNet- working.2017.8264880 .

[16] N. Fotiou, D. Mendrinos, G.C. Polyzos, Edge-assisted traffic engineering and ap- plications in the IoT, in: Proceedings of the 2018 Workshop on Mobile Edge Communications, in: MECOMM’18, ACM, New York, NY, USA, 2018, pp. 37–42, doi: 10.1145/3229556.3229561 .

[17] Z. Shelby , K. Koster , C. Bormann , P. van der Stok , C. Amsuess , CoRE Resource Di- rectory, Internet-draft, IETF, 2019 .

[18] B.H. Bloom , Space/time trade-offs in hash coding with allowable errors, Commun ACM 13 (7) (1970) 422–426 .

[19] M.J. Reed, M. Al-Naday, N. Thomos, D. Trossen, G. Petropoulos, S. Spirou, Stateless multicast switching in software defined networks, in: 2016 IEEE International Con- ference on Communications (ICC), 2016, pp. 1–7, doi: 10.1109/ICC.2016.7511036 . [20] B. Pfaff, J. Pettit , T. Koponen , E. Jackson , A. Zhou , J. Rajahalme , J. Gross , A. Wang , J. Stringer , P. Shelar , K. Amidon , M. Casado , The design and implementation of open vswitch, in: 12th USENIX Symposium on Networked Systems Design and Implemen- tation (NSDI 15), USENIX Association, Oakland, CA, 2015, pp. 117–130 . [21] N. Gude , T. Koponen , J. Pettit , B. Pfaff, M. Casado , N. McKeown , S. Shenker , NOX:

Towards an operating system for networks, SIGCOMM Computer Communications Review 38 (3) (2008) 105–110 .

[22] B. Lantz , B. Heller , N. McKeown , A network in a laptop: Rapid prototyping for soft- ware-defined networks, in: Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, in: Hotnets-IX, ACM, New York, NY, USA, 2010, pp. 19:1–19:6 . [23] V.A. Siris , N. Fotiou , A. Mertzianis , G.C. Polyzos , Smart application-aware IoT data

collection, J. Reliab. Intell. Environ. 5 (1) (2019) 17–28 .

Bander A Alzahrani is an associate professor at King Ab- dulaziz University, Saudi Arabia. He completed his M.Sc. in Computer Security (2010), and his Ph.D. in Computer Science (2015), both from University of Essex , United Kingdom. His research interests include Wireless sensor networks, Informa- tion centric networks, Bloom filter data structure and its ap- plications, secure content routing, authentication protocols in IoT. Bander has published more than 37 research papers in International Journals and conferences.

NIKOS FOTIOU received the Dipl. in information and com- munication systems engineering from the University of the Aegean, Samos, Greece in 2005, the M.Sc. degree in Internet- working from the Royal Institute of Technology (KTH), Stock- holm, Sweden in 2007, and the Ph.D. degree in computer sci- ence, for the Athens University of Economics and Business (AUEB), Athens, Greece, in 2014. Since 2014, he has been a Researcher in the Mobile Multimedia Laboratory at AUEB.

His research interests include future Internet architectures, se- curity and privacy, IoT systems, and applications of the dis- tributed ledgers technology.