research article - hindawi publishing corporationwith se-floodlight [9], rosemary [10], and fresco...

Research ArticleAttribute-Guard Attribute-Based Flow Access ControlFramework in Software-Defined Networking

Xianwei Zhu ChaoWen Chang Qin Xi and ZhiBin Zuo

PLA Strategic Support Force Information Engineering University Zhengzhou 45004 China

Correspondence should be addressed to Xianwei Zhu zhu13939055330163com

Received 24 May 2019 Revised 18 October 2019 Accepted 16 November 2019 Published 10 January 2020

Academic Editor Roberto Di Pietro

Copyright copy 2020 XianWei Zhu et al is 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

Software-dened networking (SDN) decouples the control plane from the data plane oering exible network conguration andmanagement Because of this architecture some security features are missing On the one hand because the data plane only hasthe packet forwarding function it is impossible to eectively authenticate the data validity On the other hand OpenFlow can onlymatch based on network characteristics and it is impossible to achieve ne-grained access control In this paper we aim todevelop solutions to guarantee the validity of ow in SDN and present Attribute-Guard a ne-grained access control andauthentication scheme for ow in SDN We design an attribute-based ow authentication protocol to verify the legitimacy of thevalidity ow e attribute identier is used as a matching eld to dene a forwarding control e ow matching based on theattribute identier and the ow authentication protocol jointly implement ne-grained access control We conduct theoreticalanalysis and simulation-based evaluation of Attribute-Guard e results show that Attribute-Guard can eciently identify andreject fake ow

1 Introduction

Software-dened networking (SDN) [1] is a new networkstructure proposed by Clean Slate team of Stanford Uni-versity It separates the control plane from the data plane andenables high programmability and dynamic orchestrationIn the basic SDN architecture as shown in Figure 1 there arethree layers the application plane the control plane and thedata planee control plane dictates network behaviors andcongures network devices via a set of ow rules that controlthe network trac ows e data plane only has thefunction of data forwarding which makes it dicult tomonitor the data source by controller and cannot achieveend-to-end data authentication For SDN ow table for-warding there is no eective access control framework [2]which can prevent forgery attacks

A fully functional access and forwarding controlframework should have three points (1) preventing illegalusers from accessing network services (2) giving legitimateusers appropriate permissions to access protected services orresources (3) preventing legitimate users from accessing

network services that do not give user permissions BecauseOpenFlow can only be based on the rst four layers ofnetwork protocols controlling the forwarding it cannotdivide network services and is unable to achieve ne-grainedaccess control Attackers attack SDN using legitimate de-vices as springboards erefore ensuring the legality andcorrectness of ow access SDN and preventing the pro-liferation of malicious ow are clearly the main challenges inSDN security

Digital signature as a tool for validation of data has beenwidely used in the operating system and network FortNOX[3] encrypts and authenticates applications Attribute sig-nature [4 5] enables users to achieve ne-grained accesscontrol without access list By changing the access attributesthe access control structure is updated Based on above thesethe attribute signature meets diverse security needs [5]

11 Our Approach is paper analyses the shortcomings ofSDNrsquos access control frameworks According to lack of owauthentication and ne-grained network access control we

HindawiSecurity and Communication NetworksVolume 2020 Article ID 6302739 18 pageshttpsdoiorg10115520206302739

combine SDN with attribute signature and propose SDNsecurity access control framework based on the attributeidentifiermdashAttribute-Guard It uses device attributes togenerate attribute identifiers Attribute-Guard manages at-tribute identifiers in each packet that defines network for-warding To ensure authentication of each flow weintroduced an attribute-based signature scheme in switch toauthenticate the flow based on their signature thus toprevent invalid flow launching continuous malicious attacksto the network As a result the Attribute-Guard can im-plement fine-grained access control and data source iden-tification based on network services

To sum up the main contributions of this paper are asfollows

(i) We propose Attribute-Guard a fine-grained flowaccess framework 0e proposed framework re-defines the SDN forwarding framework that bindsthe flowwith its devicersquos attribute identifiers (AIDs)

(ii) We present flow authentication protocol that caneffectively prevent fake flow and filter invalid flowcreated by an attacker in unauthorized mannersand it has a fine-grained management

(iii) We prototype our approach in the OpenDaylightcontroller and evaluate the system performance0etheoretical analysis and experimental results dem-onstrate that the proposed framework can effec-tively prevent the forging flow attack and implementfine-grained access control

12 Background and Motivation 0e abstract SDN com-munication model contains the following elements (1)hosts (2) SDN controller (3) application that provides flowrules for controllers (4) OpenFlow switch and (5) securitydevices such as firewall and security gateways

If host a (a malicious attacker) wants to attack host c theattack proceeds as shown in Figure 2 (1) host a sends a

request to OpenFlow Switch1 (2) if there is no flow rulematching the request from host a in OpenFlow Switch1OpenFlow Swich1 sends the request to the controller andwaits for the response (3) application receives a flow ruleproduction request from the controller (4) the applicationproduces a flow rule and sends it to the controller (5) thecontroller receives the flow rule and it saves the flow rule inthe flow rule database and forwards the flow rule toOpenFlow Switch1 and OpenFlow Switch2 (6) the new flowrule matches the packets from host a and forwards thepackets to the security device through OpenFlow Switch1and OpenFlow Switch2 respectively and (7) the securitydevice detects the packet according to the rule and it de-termines that host a cannot communicate with host c

According to the SDN structure we constructed twoattack methods [67] which achieve illegal access by tam-pering with flow rules and controlling flow 0ere are otherdirect attack scenarios such as DDos

(i) As shown in Figure 3 the attacker tampers with theflow rule in OpenFlow Switch2 which allows malicioushost a to access host c directly 0us the packets fromhost a can bypass the security device and scan host c

(ii) As shown in Figure 4 Malicious Application Bgenerates two new flow rules 0e first flow rule isused to modify the source IP address of the packetfrom the malicious host a to the source IP address ofhost b that can access host c 0en the second flowrule changes the destination address of the packet tothe IP address of host a If the packet is deliveredfrom host c to host a the security device simplyallows forwarding the packet from host b to host c Inthis way the packets from host a can bypass thesecurity device 0e host can scan host c

0e two examples in Figures 3 and 4 show that an at-tacker can tamper with flow rules and control flow to

Application planeApplication

API API API

Control plane

Data plane

Request Flow rules

Network service

Switch Switch Switch

Switch Switch

Figure 1 SDN architecture

Controller

Host a

Host c

OpenFlow Switch1OpenFlow Switch2

Security device

Server

1

2

34

55

6

9

7

Figure 2 0e abstract SDN communication model

2 Security and Communication Networks

circumvent the security device deployed on fixed paths 0eessence of the aforementioned problems is the illegal accessof the flow 0erefore it is necessary to implement userauthentication in the data plane Our goal in this paper is topresent a fine-grained flow access framework

13 Related Work 0ere are two ideas to prevent illegalaccess in the network (1) the controller authenticates theflow rules and (2) the controller authenticates the devicesentering the SDN and sends network strategy 0e first ideais mainly based on the flow rules of role authenticationPorras et al introduced FortNOX [8] a security enforce-ment kernel on the NOX controller which provides a role-based authorization scheme for applications that produceflow rules in response to perceived runtime requests It

manages applications that create flow rules by default threeauthorization roles including the role of administrator therole of security applications and the role of nonsecurityapplications 0ese roles are assigned to each applicationand each application is required to sign its flow rules 0enPorras extended the scheme and proposed a new securitysystem named SE-Floodlight [9] 0e system introducedsecurity enforcement kernel to the Floodlight controllerimplementing role-based flow rule management SimilarlyRoseMary [10] and FRESCO manage flow rules by usingroles [11] Although above methods can defend against il-legal flow these may assign the same role to different se-curity applications and unable to achieve fine-grainedmanagement of flows 0us Wen et al proposed a set of 18permissions based on the interface of the controller and useda system called PermOF to distribute privileges Comparedwith SE-Floodlight [9] RoseMary [10] and FRESCO [11]WEN achieves fine-grained flow management but it cannotprevent forgery attacks at terminals Based on the secondidea Lopez-Millan et al [12] introduced a terminal man-agement system which protects the terminal by using theIPsec protocol and proposed a solution to manage IPsec SAsusing SDN But it did not divide the role of the terminal andcould not achieve the fine-grained management of the flowHowever these two ideas will greatly increase the load of thecontroller and reduce the performance of the controller

0erefore researchers had shifted their research di-rection from controllers to switches and SDN architectures0ey implement data plane security by modifying theprotocol stack Lopez-Millan et al [13] described the use caseof providing IPsec-based flow protection in SDN but it lacksfine-grained management As a supplement Wundsam et alimplemented OFRewind architecture [14] a new architec-ture to authorize the device in the network layer and supportmultiple granularity management Halpern et al studied theservice function chain SFC [15] using flow rules to controlthe flow Caprolu et al designed FORTRESS a statefulfirewall for SDN networks that leverages the stateful dataplane architecture to move the logic of the firewall from thecontrol plane to the data plane [16] Fayaz et al implementedBohatei a flexible and elastic DDoS defense system [17]

According to security requirement the flow is dividedinto different security levels assigning different functionchains and function link paths to flow of different securitylevels On the other contrary IEEE 8021X offers secure andflexible authentication mechanisms Garay et al [18] pro-posed flow-based network access control (FlowNAC) whichis a modified version of IEEE 8021X standard and has theadvantage to authorize access on the basis of flow natureBenzekki [19] introduced a secure SDN architecture withIEEE 8021X port-based authentication which devolves theaccess control capability to the data plane

Southbound protocol is mainly an OpenFlow protocoland it defines type and field limited to four network layerprotocols It provides limited forwarding granularity [20]However after OpenFlow v12 [21] matching fields use theTLV format of OXM architecture which makes it possible toexpand the scope of matching fields Atting et al designedthe parsing language PPL [22] which introduced a packet

Controller

Host a

Host c

OpenFlow Switch1

OpenFlow Switch2

Security device

Server

1

2

34

55

6

6

7

Figure 3 Example 1 an attacker tampers with flow rules and uses itto allow malicious packets bypass a security device

Controller

Host a

Host b

Host c

OpenFlow Switch1

OpenFlow Switch2

Security device

Server

1

2

34

55

6

6

7

Figure 4 Example 2 an attacker adds flow rules to change the IPaddress of the packet and thus to mislead the security device

Security and Communication Networks 3

header parsing algorithm and improved the packet per-formance in addition to the packet header parsing Arashlooet al introduced SNAP that offers a simpler ldquocentralizedrdquostateful programming model by allowing programmers todevelop programs on top of one big switch [23]

14 Organization 0is paper is organized as follows inSection 2 we describe overall architecture of Attribute-Guard Section 3 introduces the attribute-based group sig-nature scheme Section 4 proposes a flow table processingpipeline based on the attribute identifier In Section 5 weevaluate Attribute-Guard on security functionalities timeconsumption performance and availability Finally weconclude our study in Section 5

2 Overview of the Attribute-Guard Framework

In this section we describe the Attribute-Guard frameworkwhich is a fine-grained flow access control mechanism toensure the validity of flow in SDN

21 Overall Architecture As Figure 5 shows the conceptualdiagram of Attribute-Guard includes four components anattribute identifier authority an attribute identifier com-ponent a control plane based on the attribute identifier anda data plane based on the attribute identifier Attribute-Guard provides following security functionalities (1)managing the attribute cipher set of a valid host (2) verifyingthe validity of flow and (3) defining the forwarding be-haviour based on the attribute identifier

(i) Attribute identifier authority the attribute identifierauthority generates system public parameters andaccess public parameters for the destination deviceOn the contrary it generates an attribute identifierfor the source device and uses the attribute identifierto generate the attribute private key

(ii) Attribute identifier component the attribute iden-tifier component is an application installed on thehost First it is responsible for generating an at-tribute set for the new sourcedestination deviceSecond it obtains the attribute private key and theattribute identifier from the attribute identifierauthority and generates a packet of flow authenti-cation 0e attribute identifier encapsulation isimplemented by modifying the protocol stack of thehost and the host is not physically extended Finallyit stores access structureT (attribute set for verifyingthe signature as described in detail in Section 31)

(iii) Control plane based on the attribute identifier thecontrol plane includes packet parsing module at-tribute identifier invalidation module and a flowrule generation module By default there are twomain functions (1) Obtaining network topology bycollecting data plane information and (2) generatingflow rules based on attribute identification to im-plement forwarding control in the data plane

(iv) Data plane based on the attribute identifier the dataplane based on the attribute identifier is mainlycomposed of an authentication switch and a for-warding switch 0e authentication switch locatedbetween the backbone network and the accessnetwork authenticates the identity of flow It mainlyconsists of flow authentication module and flowtable module 0e flow authentication module usesthe signature generated by the attribute identifier toauthenticate the validity of flow 0e flow tablemodule verifies the validity of AID by means of flowtable matching and forwards legitimate flow to aspecified location 0e forwarding switch located inthe backbone network only has the flow tablemodule and the module directly matches andforwards the received flow

22 Communication Using Attribute-Guard We use thesource host H1 to access the destination host H2 as anexample to describe the communication process of theAttribute-Guard in Figure 6

(i) Before accessing the network H1 needs to be ini-tialized by a locally installed attribute identifiercomponent and H1 sets its attribute and destinationaddress upload to attribute identifier authority0en it receives the attribute private key andgenerates the attribute signature from the attributeidentifier authority

(ii) When H1 needs to communicate with H2 it sends aflow authentication request to the source authen-tication switch (SAS) that connects H1 It forwardsthe authentication request to the destination au-thentication switch (DAS) that connects H2through the controller DAS verifies the validity ofthe flow and returns the results to the controller0en the controller generates the flow rules withattribute identification

(iii) 0e forwarding switch receives the packet fromDAS and it directly performs the matching andforwarding

(iv) 0e destination authentication switch receives thepacket from the forwarding switch and uses the flowtable module to authenticate the validity of theattribute identifier

(v) 0e destination H2 receives the legal packet togenerate a general IP packet by using the local at-tribute identifier component to decapsulate

23 Generate Pocket with Attribute Identification 0e newhost H1 needs to define the identity of the device beforeaccessing the network 0e traditional method is to generatea unique device ID for each device and use an ID identitytable to verify the ID resulting in an increase in systemoverhead In fact the network needs a few attributes todetermine the identity of the device and the user is a le-gitimate user as long as certain attributes of the user meet the


requirements 0e authenticator does not care about thesignerrsquos name address and other irrelevant information0e platform defines device attributes from the departmentwhere the device is located the role of the owner and thebusiness involved 0ese attributes are represented byBoolean functions For example Dan is an IT departmentengineer who needs to write to a host His attribute set isIT departmentand enginerandwrite

Assuming that the attribute identifier component re-ceives the attribute that is not forged we define hashfunctions to create attributersquos length as we just desireH 0 1 lowast ⟶ Zlowastq We use an attribute string as the at-tribute identifier (AID) 0e AID is used as a license for

packets to enter and leave the network It is located be-tween the network layer and the transport layer We willencapsulate AID for all packets 0e message structure isshown in Table 1

(i) Version (4 digits) the version of the attributeidentifier

(ii) Secondary protocol (8 bit) the type of the protocolimmediately following the attribute identifier suchas 6 (TCP) 17 (UDP) or 50 (ESP)

(iii) Length (8 bits) the value is the length of the entireattribute identifier (including the header and met-adata) in units of 32 bits (4 bytes)

Flow rule generation

module

Attribute identifier

invalidation module

Flow rule Request

Attribute identifier authority

Forwarding switchAuthentication switch

Legal flow entry

Attributeidentification

database


componentUser

Expired flow entry

Filter flow entry

Legal flow entry

Basic forwarding

table

Flow table matching module

Basic forwarding table

Packet parsing module

Flow

iden

tific

atio

n m

odul

e

Control plane

Data plane

Figure 5 0e conceptual diagram of Attribute-Guard

Attribute identifierauthority

H1 (attribute identifiercomponent)


IP header IP headerAID Data Data

Control plane

Data plane

Controller

Upload

Authenticationswitch

AuthenticationswitchForwarding switch

Download

Controller

Figure 6 0e communication model of the Attribute-Guard


(iv) Reserved (12 bit) to be used in future extensions toattribute identification and the current protocolspecifies that this field should be set to zero

We modify the protocol type of the IP header and add AIDafter the IP header For example if the upper protocol withoutAID is TCP the protocol type of the IP header is changed to 6

3 Attribute-Based Group Signature Scheme

Our attribute-based signature scheme is an extension of theattribute-based group signature scheme presented by DaliaKhader et al [24]

31 Access Structure 0e access structure T is an authori-zation set of attributes for verifying the signature defined bya verifier When a verifier requests a signature of a host whosatisfies certain attributes a host will use his different privatekeys to generate the signature according to the verifierrsquosaccess structure 0e table is a linear structure If the verifieruses a table to represent the access structure the verificationalgorithm will be run as many times as the number of at-tributes in the signature thus compromising efficiency Weuse the attribute tree Γ that is a nonlinear structure to de-scribe the access structure and its constructor is based onthe constructor presented by Goyal et al [25] Each rootnode in the attribute tree has a threshold value and eachattribute is connected to it as its leaf node Each thresholdvalue indicates the number of conditions that needs to bemet in the leaf node to which it is connected that is thenumber of attributes required under the root node 0eaccess tree is shown in Figure 7

We use the attribute tree to generate the public key Onlythe signature of the user who meets the requirements of theattribute tree can pass the verification As shown in Figure 7the administrator of the ITdepartment needs to perform theread operation 0e user satisfies the attribute tree so thesignature can be verified Engineers in the IT departmentwant to perform a read operation that does not meet therequirements of the attribute tree and cannot be verified

32 Authentication Process 0e attribute signature verifica-tion and update the access control structure are implemented bythe attribute identifier component the attribute identifier au-thority and the authentication switch Access to services underAttribute-Guard architecture requires two basic stages

Step 1 it includes five processes and is shown in Fig-ure 8 Firstly the attribute identifier authority performsinitialization to generate system public parameters theauthentication switch creates an access control structure

T according to requirements and it uploads T to theattribute identifier authority 0e attribute identifierauthority uses the primary private key and the systempublic parameter to generate the public parameter of T

and stores it in the authentication switch the attributeidentifier component uploads the hostrsquos attribute set tothe attribute identifier authority According to the hostrsquosattribute the attribute identifier authority generates theattribute identifier and attribute private key and returnsit to the attribute identification component 0ereforedifferent hosts have different attribute identifiers andattribute private keys If the attacker controls a legiti-mate host DAS will update the access structure T togenerate the new public parameter of T 0e originalvalid attributes and the signature acquired by the at-tacker will be invalidStep 2 flow identification Based on the parametersgenerated by step 1 the authentication switchcompletes the flow identification and the process isshown in Figure 9

(1) 0e host initiates an authentication request to thecontroller 0e request packet contains the followingmessage hostrsquos AID signature mac destination macsource IP destination IP source port destination port

(2) 0e controller successfully receives the authentica-tion request packet from the source authenticationswitch (SAS) port To prevent malicious users fromusing the authentication request packet to initiate amalicious DDoS attack the default flow table will beinstalled on the SAS and the authentication packetfrom the port will be discarded in the T period

(3) According to the authentication request informationthe controller forwards the request to the destinationauthentication switch (DAS) 0e destination authen-tication switch acquires the access structure T of thedestination host according to the request

(4) 0e destination authentication switch verifies thesignature and sends the result protected by SSL to thecontroller

(5) 0e controller receives the result if the flow is legal itsends the flow rule with the attribute identifier toswitch otherwise the connection is refused

33 Formalization of the Scheme 0e relevant definitions ofattribute-based group signatures are given below

Definition 1 0e attribute tree Γ is used to represent theaccess structure T and the attribute tree uses the top-down-left-right order 0e root node is represented as (m n)where m indicating nthe threshold value and n indicating thenumber of leaf nodes κ indicates the number of leaves in theattribute tree as shown in the attribute tree in Figure 5

Γ (2 2) IT (1 2) (2 2) (2 2) administrator

1 2) engineer (1 2) readwrite notificationwrite( 1113865

(1)

Table 1 Attribute identifier message format

Version (4bit)

Secondaryprotocol(8 bit)

Length (8bit)

Reserved(12 bit)

Serial number (32 bit)AID (64 bit)

Data


Definition 2 ci represents the private key owned by eachuser μ indicates the number of private keys

Definition 3 User uses the attribute to signature and theelement in ζ i satisfies ci that is ζ i sube ci and the number of ζ i

is τ for example Γ (1 2) administrator engineer thatthe employee i can use ζ i engineer1113864 1113865 to verify

0e algorithm includes the following Setup KeyGenSign and Verify

Setup the attribute identifier authority chooses a bi-linear pair e G1 times G2⟶ GT where G1 G2 and GT

are multiplicative loop groups and of prime order p g2is the generator of G2 and there exists homomorphicmapping g1⟵ψ2 0e system chooses an open hashfunction H 0 1 lowast ⟶ ZlowastP Choose h isin G1 and ξ1 ξ2(ξ1 ξ2 isin ZlowastP) Set u v isin g1 such that uξ1 vξ2 h andrandomly select ω isin ZlowastP We set W g2 Define auniverse of attributes U 1 2 n and each j isin U

Select tf isin Zlowastp and then calculate the public parametersand system secret parameters

PK G1 G2 GT g1 g2 e H h u v W1113864 1113865

MK lang ti1113864 1113865iisinUω ξ1 ξ2rang(2)

KeyGen the process generates an attribute private keyand a public parameter of the access control structureT 0e system generates a base private key gsk[i]base

(Ai xi) for user i(1le ile n) through c and it is an SDHpair ie Ai g

1(ω+xi)1 isin G1

(1) KeyGenpublic(Γ) to generate a public key for anattribute tree Γ we select a polynomial qx for eachnonleaf node in the middle and use a top-downconstruction method for the root node 0e node x

in the tree has a polynomial qx whose number dx isless than its threshold kx ie dx kx minus 1 0e rootnode is q(0) q(index (x)) and select the polynomialq to construct attribute tree polynomials recursivelyFinally the public parameters of the attribute tree Γ

Threshold value = 2

Threshold value = 2 Threshold value = 2

IT department Threshold value = 1

Threshold value = 1Threshold value = 1 EngineerAdministrator

Read Write WriteNotification

Figure 7 Attribute tree structure

(1) Generate systemdisclosure parameters


Attribute identifiercomponent


(3) Generate the publicparameter of T

(5) The h

ostrsquos att

ribute s

et

(6) Attr

ibute iden

tifier

attri

bute

private

key

(2) Access control structure T

(4) The public parameter of T

Figure 8 System initialization

Host Controller DAS

Authenticationrequest

Send signature andattribute identifier

SAS

Return the result

Install flowtable

Install flowtable

Install the flowtable and discardthe packet fromthe same port

in T

Figure 9 Flow identification process


are obtained by Dx gqx(0)tj

2 hn hti andi att(x) And send the system public parametersTPK lang Dx hx1113864 1113865xisincΓrang to the authentication switch

(2) KeyGenprivate(gsk[i]base ci) we use attribute ci

owned by user i (ie j isin ci) to generate private keySK langAi xi Tij1113966 1113967

jisinci

rang by computer Γij Atj

Sign when the system enters the attribute set ci subeUjsubeci the public parameters of the attribute tree and themessage m it is calculated as follows

(1) Select attribute ζ sube ci and random number α β andrnd isin Zlowastp

(2) Calculate the linear encryption of Ai and Tij wherethe formula is as follows C1 ua C2 vβC3 Aih

α+β and CTj (Tijhjα+β)rnd

(3) Let δ1 xiα and δ2 xiβ Select the randomnumber rβ rx rδ1 and rδ2 Calculate R1 ucz R2 vcβ R5 C

cx

2 vminus cδ2 R4 Ccx

1 uminus cδ1 andR3 1113954e(C3 g2)

cx1113954e(hω)minus cαminus cβ1113954e(h g2)minus cδ1minus cδ2

(4) c H(M C1 C2 C3 R1 R2 R3 R4 R5) isin Zlowastp(5) Construct sα (cα + cα) sβ (cβ + cβ) sx (cx+

cx) sδ1 (cδ1 + cδ1) and sδ2 (cδ2 + cδ2)(6) Let η ωrnd and calculation signature

σ (m C1 C2 C3 c CTi1113864 1113865iisinζ sα sβ sx sδ1 sδ2 η)Finally the signature and attribute identifier(σAID) are sent to the verifier where the AID isthe hash of the attribute set ζ

Verify it includes two steps Firstly we define a re-cursive algorithm Verifynode For leaf nodes calculateas follows

Verifynode(x) 1113954e CTj Dj1113872 1113873if j att(x) j isin ζ

otherwise returnperp

⎧⎨

⎩ (3)

0e result is 1113954e(CTj Dj) 1113954e(Aihα+β grnd

2 )qj(0)If the node x is not a leaf node we perform the following

steps all child value z of node x are stored in function FWerecursively calculate the value of the root node Fx usingLagrangian interpolation Let Δsxindex(z) 1113937(minus j(index(z) minus j)) where j isin index(z) z isin sx minus index(z) andcompute

Fx 1113945zisinsx

FzΔsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qz(0)1113874 1113875

Δsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qparent(z)(index(z))1113874 1113875

Δsxindex(z)

Fx 1113954e Aihα+β

grnd21113872 1113873

qx(0)

(4)

Let Fx 1113954e(C3 η)If it is established it means that the signature satisfies the

attribute tree Γ and calculate R1 usαCminus κ1 R2 vsβCminus κ

2 R3

1113954e(C3 g2)sx1113954e(h W)minus sαminus sβ1113954e(h g2)

minus sδ1minus sδ2(1113954e(C3 W)1113954e (g1

g2))κ R4 C

sx

1 uminus sδ1 and R5 Csx

2 vminus sδ2 If κ H(m

C1 C2 C3 R1 R2 R3 R4 R5) then accept the signatureotherwise the signature is rejected

34 Flow Authentication Protocol Design We modify 8021xprotocol which is widely used at present and design a flowauthentication protocol to support the above process

0e standard Ethernet frame must have the destinationMAC address DST MAC and Ethernet frame type EtherType When the flow authentication protocol is running thehost client program cannot obtain the destination host MACaddress 0erefore we adopt the default multicast address01-80-C2-00-00-03 and the frame type is defined as 0X888Fwhich is different from 8021x 0e flow authenticationprotocol is carried out in the frame data portion Since themaximum length of the Ethernet frame data is currently setto 1 518 bytes the maximum length of the authenticationprotocol data is 1 500 bytes

As illustrated in Table 2 the semantic of each field in theflow authentication protocol format is as follows

Version the version number of the current protocolType type field 0is field is mainly used to indicate thestage of the current data frame 00 means registrationand 01 means flow identificationSequno this field indicates the sequence number of thecurrent packet which prevents the loss and out of orderof the packetLength this field is used to indicate the length of thedata bodyData body according to different identification stagesthe corresponding data is carried

4 Flow Matching Based on Attribute Identifier

0e attribute identifier is designed as a match field that theOpenFlow switch can recognize and a processing pipeline isdesigned based on the multiple flow tables 0e validity ofthe attribute identifier can be authenticated by the pro-cessing pipeline and the legal data are transferred to thespecified location

41 Structure of Flow Table Due to the addition of the at-tribute identifier in the packet the original OpenFlow needsto be extended as shown in Figure 10 According toOpenFlow 13 [18] we use the TLV format of the OXMarchitecture to define a new field called the attribute iden-tifier We add the attribute identifier in the Flow-Modmessage so that the flow rule with the attribute identifier canbe accepted by the authentication switch and forwardingswitch In this paper the southbound protocol is compatiblewith the OpenFlow13 protocol 0e controller that supportsthe OpenFlow13 protocol can generate the flow rule con-taining the attribute identifier


42 Multiple Flow Table Processing Pipeline As illustratedin Figure 11 multiple flow table processing pipelineconsists of two flow tables 0e verification flow table is alevel 0 flow table It classifies the packets according to thetype of the flow entry and selects an appropriate processingmanner

(1) Filter flow entry the filter flow entry drops thepacket without the attribute identifier (Ether-Type 0x0800 or 0x86dd) If the packet does nothave an attribute identifier it will be sent to theexpired flow entry

(2) Expired flow entry the expired flow entry is used toauthenticate the validity of the user and quicklyfilters the packet with the expired attribute identifier0e field type is the invalid attribute identifier andthe flow table action is ldquodroprdquo If the matchingsucceeds the SDN switch will discard the packet

(3) Legal flow entry the legal flow entry will match theattribute identifier and forward the valid packet tothe basic forwarding table for further matching

(4) Table-miss flow entry the table-miss flow entry isused to be compatible with non-IP packets anddirectly forwards non-IP packets to the basicforwarding table 0e field type is lowast (arbitrary)and the action is to jump to the basic forwardingtable

0e basic forwarding flow table is the Level 1 flow tablewhich is used for direct matching forwarding of packets Itsupports all matching fields and all types of instructionsactions 0e matching process is shown in Figure 9

5 Experiment and Evaluation

We have implemented and deployed an Attribute-Guardsystem0e system is based on OpenDaylight we extend thefunction of the OpenDaylight controller and the OVS switchto complete the function deployment and use SFlow tomonitor network traffic Finally the attribute-based groupsignature scheme is implemented through bilinear en-cryption library and C++ code Next we will evaluate it interms of functional effectiveness time consumption andperformance

51 Experimental Environment 0e experiment uses 10computers as the experimental environment and its con-figuration is shown in Table 3 Six of them are used tosimulate authentication switches and forwarding switches

Its network topology is shown in Figure 12

52 Functional Effectiveness Testing We test the two attackscenarios in Section 12 indicating that the malicious host acannot attack host c with the protection of Attribute-Guard

(i) As shown in Figure 2 host a directly accesses thedestination device c by tampering with the flow ruleHowever Attribute-Guard uses the authenticationswitch to verify the flow of host a Since the host doesnot satisfy the access structure of host c the packetscannot reach host c

(ii) An attacker can change the address of the packet bygenerating two new flow rules to scan host cHowever Attribute-Guard forwards the flow by

Table 2 Flow authentication protocol format

Version (8 bit) Type (8 bit) Sequno (8 bit) Length (8 bit)Data body (40ndash1498 byte)

Matchingfield Priority

Port

OXM

TLV

Data

Macaddress Eth type VLAN IP AID TCPUD

PICMPIP

header

Counter Instruction Cookie Flags

Figure 10 SDN flow entry structure based on attribute identification


multiple flow table processing pipeline and de-termines the flow path based on the attributeidentifier 0erefore the OpenFlow Switch1 cannotforward flow from host c to host a although the flowis valid

We test the function of SDN network based on theattribute identifier (1) whether the system can identify thevalidity of flow and (2) whether the system can realize theaccess control based on the attribute identifier

(1) Host h1rsquos authentication request carries a valid at-tribute identifier and signature Host h2rsquos authen-tication request carries the attribute identifier andsignature that do not conform to the h6 accessstructure h3 is that the general packet does not carryany attribute identifier and signature 0e abovethree hosts continuously send data to h8 at the rate of50 packagess 0e controller makes the pathh1h2h3⟶ e1⟶ a2⟶ a3⟶ e3⟶ h6 Weuse SFlow to monitor the traffic of e1 and e3 re-peating 10 times for 12 seconds each time and theresult is averaged 0e results are shown in Figures 9and 100e X-axis is the time and its unit is secondsthe Y-axis indicates the number of packets and itsunit is packagess and the positive direction rep-resents the inflow packet that is the authentication

Verification flow table


Field matching

Auth_tagFwdDrop

Ether Type

Instructionaction Field matching Instructionaction

Filter flow entry

Expired flow entry

Legal flow entryBasic flow entry

Basic forwardingflow table

Basic forwarding flow table

Multiple flow table processing pipeline

Table-miss Table-miss

Goto_table

Goto_table

Flow Flow

AIDiAIDi

IngressPortIP header

Fwd Drop Pushpopset filed

hellip


Table 3 Experimental environment configuration

Function Number ConfigurationController 1 i7-8400cpu 16G DDR4 4 network cardsAuthentication switch 3 i7-8400cpu 16G DDR4 6 network cardsForwarding switch 3 i7-8400cpu 16G DDR4 6 network cardsHost 6 i5-8400cpu 8G DDR4 2 network cards

a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller

Figure 12 Experimental network topology


switch receives the packets of h1 h2 and h3 and thenegative direction represents the outflow0e packetfrom (h1 h2 and h3) is forwarded to h6As it is illustrated in Figure 13 the authenticationswitch e1 receives packets from h1 h2 and h3 Sinceh1 and h2 carry the attribute identifier e1 onlyforwards h1 and h2 packets and h3 packets arediscarded directly However h2 started with a smallamount of forwarding and then discardedAs shown in Figure 14 the packets of h3 are dis-carded 0e packets of h2 are forwarded in the firstsecond and then discarded0e packets of h1 are stillforwarded We check the authentication switch e3do not add new flow rules and e1 generates aninvalid flow rule to discard the packets of h2From the experimental results it can be seen thatwhen the packet enters the network the authenti-cation switch first discards the packet that does notconform to the specification ie the attributeidentification is empty 0e destination authentica-tion switch verifies the validity of the authenticationrequest Invalid flow tables are sent to the sourceauthentication switch to discard its subsequentpackets 0erefore the network can reject the packetwith invalid attribute identification and the illegalpackets without the attribute identification into thenetwork

(2) h1 sends the packets that carry the attribute iden-tification conforming to the h6rsquos access structure toe1 at the rate of 50 data packets per second and thenthe path of h1 is modified to h4 by the controller inthe next 12 seconds SFlow is used to monitor e2 ande3 traffic repeating 10 times for 12 seconds eachtime and the results are averaged as shown inFigures 15 and 16

In Figures 15 and 16 if the attribute identifier in theswitch flow entry is the same as the attribute identifier of thepacket 0e packet would allow entering the device When itaccesses another device the authentication switch de-termines that it is illegal and discards it 0erefore fine-grained access control based on attribute identification canbe implemented

53 Scheme Comparison We compare the Attribute-Guardwith the six most recent schemes as illustrated in Table 4SE-Floodlight [9] RoseMary [10] FRESCO [11] andFortNOX [3] offer a role-based source authentication forflow rules and PERM- GUARD [26] and PermOF [27] offera source authentication based on the access list

Each new flow rule generated in the SDN networkrepresents a change of the flow and the flow needs to beauthenticated 0e number of flow rules is positively relatedto the number of authentications which reflects the gran-ularity of data flow management Figure 17 illustrates thenumber of authenticated identities comparison betweenAttribute-Guard and the most recent schemes Because SE-Floodlight RoseMary FRESCO and FortNOX provide only

three roles for authentication their bottleneck of identityauthentication first appears PERM-GUARD and PermOFare able to provide a better granularity due to the access lists

21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6

ndash50ndash40ndash30ndash20ndash10

01020304050

Pack

age (

s)

Figure 13 Authentication switch e1 traffic statistics

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121


Time (s)ndash60ndash50ndash40ndash30ndash20ndash10

0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6

Figure 15 Authentication switch e3 traffic statistics under theexperiment of access control


But their granularity is limited by the size of the access listOur scheme provides a fine-grained Attribute-Guard whichadopts the attribute signature 0e scheme defines the accessstructure according to requirements and only the signaturethat satisfies its access structure can be verified successfully0e signature algorithm implements access control and does

not need to create an access list so it is not limited by theaccess list and achieves better fine-grained management

As SDN design enables to push all the control func-tionality to a centralized controller SE-Floodlight Rose-Mary FRESCO FortNOX PERM-GUARD and PermOFdevelop network control applications and enforcing policies0us controllers might potentially become a bottleneck forthe network operations Attribute-Guard reduces the re-quest and the overhead on the SDN controller by delegatingthe access control capability to the data plane and has thelowest CPU utilization and memory utilization 0e result isshown in Figures 18(a) and 18(b) Attribute-Guard has abetter scalability than other schemes

54 Performance Analysis In this section we will evaluatethe performance of Attribute-Guard SDN network packetprocessing capability based on attribute identification

For the problem we measure the time consumption ofgenerating signature and verification signature to estimatethe performance of Attribute-Guard 0ese two featuresdetermine how many flows could be handled by Attribute-Guard However because the length of the authenticationrequest sent by the host is different and the traffic of the hostis different at different times the measurement results aredifferent To measure the maximum performance of Attri-bute-Guard we need to pay attention to the two points (1)increase the proportion of signature verification in packetgeneration and forwarding time and (2) measure time-

h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)


Table 4 0e granularity of flow authentication comparison

Schemes Signature Permission management 0e granularity of authenticationSE-Floodlight Role-based Role-based 0ree authorization rolesRoseMary Role-based Role-based 0ree authorization rolesFRESCO Role-based Role-based 0ree authorization rolesFortNOX Role-based Role-based 0ree authorization rolesPERM-GUARD Identity-based Identity-based and access list 16 permissionPermOF No Access control list and PKI 18 permissionAttribute-Guard Attribute-based Attribute-based Custom the number of access structure

SE-FloodlightRoseMaryFRESCOFortNOX

PERM-GUARDPermOFAttribute-Guard

1000 2000 3000 4000 5000 6000 7000 80000Number of flow rules

0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es

Figure 17 Granularity comparison of identity authentication


consumption when the network is most active For (1) wecontinue to send short messages with a fixed length of 64bytes on the host For (2) we refer to Stanford 300 users [25]and 22000 [28] user SDN experiments and Berkeley Lab [8]statistics on more than 8000 user SDN networks and theyindicate that the number of packets forwarded by each activehost mainly ranges from 9 to 25 minutes 0erefore first wecount the generating time of 200 authentication requestswithin the 9 to 25 minutes of the host running As shown inFigure 19 the X-axis corresponds to the number of au-thentication request and the Y-axis corresponds to the time-consumption of generating authentication request From thefigure we can calculate that the average time to generate anew authentication request with attribute identification is2576ms 0at is 38 sets of authentication requests withdifferent attribute identifiers and signatures can be sent persecond at a rate of about 760ms

We test 200 authentication requests to measure the av-erage time for the authentication switch verifying each signedauthentication request As shown in Figure 20 the averagetime for the authentication switch to verify the signed au-thentication request is about 5177ms which means that theauthentication switch can handle 386m per second

According to the literature [6 8 9 28 29] the switchneeds to handle the traffic in daily use as shown in Table 4According to Table 5 the Attribute-Guard system perfor-mance can meet the basic network requirements

When the authentication switch receives more packetsthe authentication time will increase It becomes a problemwhether the verification efficiency will decrease as thepackets increase becomes the bottleneck of data throughputFigure 21 illustrates the authentication time required for theauthentication switch under different packets with the X-axis corresponding to the number of packets of which 20Meach According to the result the relationship between thenumber of authentication packets and the time of the




05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)

Figure 18 (a) CPU utilization comparison of schemes (b) Memory utilization comparison of schemes

495500505510515520525530535540545550555

Tim

e (m

s)

50 100 150 2000Number of authentication request

Figure 19 0e time for the host to generate authentication requestwith attribute identifier and signature

495500505510515520525530535540545550555

Tim

e (m

s)


Figure 20 0e time for the authentication switch to verify theauthentication request


authentication switch is linear0e rate of the authenticationpacket does not change with the increase of the packet

55 Network Overhead Attribute-Guard introduces a newsingle point of failure in the ldquoattribute identifier authorityrdquoand deploys security modules in the controller and dataplane and the limitation of the Attribute-Guard is needed tobe discussed and the additional performance overhead of thecontroller host and forwarding device should be evaluated

For the controller we continuously send legal packets atdifferent locations on the host and count controller addi-tional performance overhead at different Pack_in rates

Firstly we compare the CPU utilization of the nativeOpenDaylight controller with the CPU utilization of theAttribute-Guardrsquos controller In Figure 22 the CPU utilizationof the controller in the Attribute-Guard system is slightlyhigher than that of the native OpenDaylight controller at thesame Pack_in rate Secondly we compare the memory uti-lization of the native OpenDaylight controller with Attribute-Guardrsquos controller As illustrated in Figure 23 0e memoryutilization of Attribute-Guardrsquos controller is slightly higherthan the native OpenDaylight controller with a differenceabout 13 It indicates that the Attribute-Guard system doesnot increase the controller load toomuch under the premise ofimplementing the security function

We use hping3 to inject data packets into the network at50Mbits 100Mbits 150Mbits 200Mbits 250Mbits

300Mbits 350Mbits 400Mbits 450Mbits and 500Mbits0e CPU utilization and memory utilization of host and dataplane aremeasured in different scenarios It is repeated 10 timesat different rates and the average value is taken each time

For the host as shown in Figure 24 the CPU utilizationof the host with the attribute identification component isslightly higher than that of the standard host and bothincrease with the increase in the traffic As the network trafficincreases the number of packets requiring authenticationincreases and the difference in CPU usage gradually in-creases because the host with the attribute identificationcomponent needs to generate a signature and encapsulatethe attribute identifier before sending the packet Althoughthe computational cost of generating a signature is large it isonly related to device attributes and is independent of thepacket It only needs to perform one operation and the

Table 5 0e number of packets forwarding per second in differentnetworks

Schemes Size ofnetwork

0e number of packets per second (ms)

[25] Over 300 hosts 246[28] 22000 hosts 497[8] 8000 hosts 356[9] 4 hosts 196[26] 100 hosts 320

Verification phase

0

2

4

6

8

10

12

Tim

e (s)

50 100 150 2000Number of authentication packets

Figure 21 Time cost in the verification phase

00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion

05 10 15 20 25 30 35 40 45 5000Pack_in rate (103 packets)

Native OpenDaylightAttribute-Guard OpenDaylight

Figure 22 CPU utilization of controller comparison


0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion


Figure 23 Memory utilization of controller comparison


computational overhead of encapsulating signatures andattribute identifiers is small0erefore the difference in CPUusage between the two schemes is small as the rate increasesand the maximum difference is 08 Similarly in Figure 25the more the network traffic the more the packets needed tobe encapsulated and thus the more the memory utilization0e difference between the standard host and the host withattribute identifier component is not very large which iswithin the acceptable range

For the data plane the Attribute-Guardrsquos data plane iscomposed of the authentication switch and forwarding switch0erefore we compare the network overhead between theauthentication switch the forwarding switch and theOpenFlow switch 0e authentication switch deploys a flowidentification module and a processing pipeline based on theattribute identifier When the flow enters the authentication

switch it needs to be authenticated 0is process increases thecomputing overhead In Figure 26 we can see that as thepacket rate increases the CPU utilization of the forwardingswitch is the same as that of the OpenFlow switch and theauthentication switch suffers from a linear growth of CPUutilization rapidly As shown in Figure 27 the authenticationswitch and the forwarding switch have higher memory uti-lization than the OpenFlow switch because the authenticationswitch and the forwarding switch add a pipeline based onattribute identification 0e authentication switch and theforwarding switch require more flow tables than the Open-Flow switch Finally we compare the delay of the authenti-cation switch the forwarding switch and the OpenFlowswitch 0e result is shown in Figure 28 0e delay of theforwarding switch is slightly higher than that of the OpenFlow

100 200 300 400 5000Packet rate (Mbits)

Standard hostHost with attribute identifier component

0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()

Figure 24 CPU utilization of host comparison



0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)

Figure 25 Memory utilization of host comparison

OpenFlow switchForwarding switchAuthentication switch

0

2

4

6

8

10

12

14

CPU

util

izat

ion

()

100 200 300 400 5000Packet rate (Mbitss)

Figure 26 CPU utilization of switch comparison


0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()


Figure 27 Memory utilization of switch comparison


switch and the delay of the authentication switch is larger thanthe others 0e authentication switch needs flow authentica-tion and forwarding while the forwarding switch and theOpenFlow switch only need forwarding 0erefore the al-gorithm complexity of the signature is main network over-head and the pipeline based on attribute identification haslittle effect on network overhead

We have extended the SDN by adding an attributeidentifier authority that needs to communicate with the au-thentication switch and host In order to describe the impact ofthe attribute identifier authority on the authentication switchand the host we count the traffic between the authenticationswitch and the attribute identifier authority and the trafficbetween the host and the attribute identifier authority Fig-ure 29 shows the traffic ratio of the attribute identifier

authority to the authentication switch and the traffic ratio ofthe attribute identifier authority to the host 0e attributeidentifier authorityrsquos traffic accounts for less than 12 of thetotal traffic and decreases as the packet rate increases

56 Availability Analysis We compare the packet loss rateand delay between Attribute-Guard and SDN networks andanalyse network availability First we send packets with alength of 1514 bytes at different rates and different ports andcount the packet loss rate as shown in Figure 30

As shown in Figure 30 as the packet-receiving rateincreases the packet loss rate of the network increasesbecause the packet with the attribute identifier needs to beverified and the flow table adds the math field based on theattribute identifier in the switch 0e packet rate is largerthan the network without attribute identifier and signature


0102030405060708090

100110120

Del

ay (m

s)


Figure 28 Delay of switch comparison

HostAuthentication switch

0

2

4

6

8

10

12

Traf

fic ra

tio(

)


Figure 29 Traffic ratio of the authentication switch and host

SDNAttribute-Guard

400 600 800 1000 1200 1400 1600 1800 2000 2200200Packets transmission rate (packetss)

0

2

4

6

8

10

Pack

et lo

ss ra

te (

)

Figure 30 Packet loss rate comparison

TNndashAttributendashGuard

TAttributendashGuard

0 20 30 40 5010Measurement time (s)

20

40

60

80

100

120

140D

elay

(ms)

Figure 31 Network delay comparison


0e result shows that the network has an extra packet lossrate of 256

0en the average delay is obtained by counting 50 timesof ACK return In the Attribute-Guard scheme the delay ofeach ACK return is TAttributeminus Guard 0e delay of the systemwithout the attribute identifier and signature isTNminus Attributeminus Guard

From Figure 31 the average network delay ofTNminus Attributeminus Guard is 3148ms while the average network delayof TAttributeminus Guard is 1032ms and the average delay is in-creased by 7172ms 0e analysis shows that the time togenerate signature and verify the signature accounts for654 of the total delay0erefore the algorithm complexityof the signature directly determines the network delay but itis still within the feasible communication delay

6 Conclusion

In this paper we propose Attribute-Guard an access controlframework based on the attribute identifier 0e goal ofAttribute-Guard is to make flow in the data plane morecredible 0is framework implements flow authenticationand fine-grained access control which enables the data planeto shield the host from varieties of malicious flow attacksWe have implemented and deployed Attribute-Guard on theOpenDaylight andOVSwhile verifying the functionality andusability of the network and the verification results showthat the framework ensures the availability of the network Inthe future we will make more efforts in flow verification toimprove the performance of flow forwarding

Data Availability

All data included in this study are available upon requestfrom the corresponding author

Conflicts of Interest

0e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

0is work was funded in part by the National NaturalScience Foundation of China

References

[1] Z Sun J Li and K Yang ldquoSoftware-defined networkingrdquo ZteCommunications vol 56 no 9 pp 16ndash19 2013

[2] E Al-Shaer and S Al-Haj ldquoFlowchecker configurationanalysis and verification of federated openflow in-frastructuresrdquo in Proceedings of the 3rd ACM workshop onassurable and usable security configuration pp 37ndash44 ACMChicago IL USA 2010

[3] N Gude T Koponen J Pettit et al ldquoNoxrdquo Acm SigcommComputer Communication Review vol 38 no 3 pp 105ndash1102008

[4] R Guo H Shi Q Zhao and D Zheng ldquoSecure attribute-based signature scheme with multiple authorities for

blockchain in electronic health records systemsrdquo IEEE Accessvol 6 pp 11676ndash11686 2018

[5] H Xiong Y Bao X Nie and Y I Assor ldquoServer-aided at-tribute-based signature supporting expressive access struc-tures for industrial internet of thingsrdquo IEEE Transactions onIndustrial Informatics vol 6 pp 1ndash5 2019

[6] P Porras S Shin V Yegneswaran M Fong M Tyson andG Gu ldquoA security enforcement kernel for OpenFlow net-worksrdquo in Proceedings of the First Workshop on Hot Topics inSoftware Defined Networks vol 1ndash17 pp 121ndash126 ACMHelsinki Finland August 2016

[7] A Abdou P C Van Oorschot and T Wan ldquoComparativeanalysis of control plane security of sdn and conventionalnetworksrdquo IEEE Communications Surveys amp Tutorials vol 20no 4 pp 3542ndash3559 2018

[8] R Pang M Allman M Bennett J Lee V Paxson andB Tierney ldquoA first look at modern enterprise trafficrdquo inProceedings of the 5th ACM SIGCOMM conference on InternetMeasurement p 2 USENIX Association Berkeley CA USAOctober 2005

[9] P A Porras S Cheung M W Fong K Skinner andV Yegneswaran ldquoSecuring the software defined networkcontrol layerrdquo in Proceedingsof the 2015 Network and Dis-tributed System Security Symposium San Diego CA USAFebruary 2015

[10] S Shin Y Song T Lee et al ldquoRosemary a robust secure andhigh-performance network operating systemrdquo in Proceedingsof the 2014 ACM SIGSAC conference on computer and com-munications security pp 78ndash89 ACM Scottsdale AZ USANovember 2014

[11] S W Shin P Porras V Yegneswara M Fong G Gu andM Tyson ldquoFresco modular composable security services forsoftware-defined networksrdquo in 20th Annual Network ampDistributed System Security Symposium San Diego CA USAFebruary 2013

[12] G Lopez-Millan R Marin-Lopez and F Pereniguez-GarcialdquoTowards a standard SDN-based IPsec management frame-workrdquo Computer Standards amp Interfaces vol 66 Article ID103357 2019

[13] G Lopez-Millan R Lopez and A Abadcarrascosa Software-Defined Networking (Sdn)-Based Ipsec Flow Protection In-ternet Engineering Task Force Fremont CA USA 2016

[14] A Wundsam D Levin S Seetharaman and A FeldmannldquoOFRewind enabling record and replay troubleshooting fornetworksrdquo in Proceedings of the USENIX Annual TechnicalConference pp 327ndash340 USENIX Association Portland ORUSA June 2011

[15] J Halpern and C Pignataro ldquoService function chaining (SFC)architecturerdquo No RFC 7665 2015

[16] M Caprolu S Raponi and R Di Pietro ldquoFortress an efficientand distributed firewall for stateful data plane sdnrdquo Securityand Communication Networks vol 2019 Article ID 687459216 pages 2019

[17] S K Fayaz Y Tobioka V Sekar and M Bailey ldquoBohateiflexible and elastic ddos defenserdquo in Proceedings of the 24thUSENIX Security Symposium (USENIX Security 15)pp 817ndash832 Washington DC USA August 2015

[18] J M J Garay A Mendiola N Toledo and E JacobldquoFlowNAC Flow-based network access controlrdquo in Pro-ceedings of the Lird European Workshop on Software-DefinedNetworks EWSDN 2014 pp 1ndash3 IEEE London UK Sep-tember 2014


[19] K Benzekki Devolving IEEE 8021X Authentication Capa-bility to Data Plane in Software-Defined Networking SDNArchitecture John Wiley amp Sons Hoboken NY USA 2016

[20] B Jun ldquoSDN architecture and future network architectureinnovation environmentrdquo Telecommunications Sciencevol 29 no 1 pp 6ndash15 2013

[21] Open Network Foundation OpenFlow Switch SpecificationVersion 120 Open Network Foundation 2014 httpswwwopennetworkingorgimagesstoriesdownloadssdn-resourcesonf-specificationsopenflowopenflow-spec-vl20pdf

[22] M Attig and G Brebner ldquo400 Gbs programmable packetparsing on a single FPGArdquo in Proceedings of the 2011 ACMIEEE Seventh Symposium on Architectures for Networking andCommunications Systems pp 12ndash23 IEEE Brooklyn NYUSA October 2011

[23] M T Arashloo Y Koral M Greenberg J Rexford andD Walker ldquoSNAP stateful network-wide abstractions forpacket processingrdquo in Proceedings of the 2016 ACM SIG-COMM Conference pp 29ndash43 ACM Florianopolis BrazilAugust 2016

[24] D Khader ldquoAttribute based group signaturesrdquo IACR Cryp-tology ePrint Archive vol 159 2007

[25] V Goyal O Pandey A Sahai and B Waters ldquoAttribute-based encryption for fine-grained access control of encrypteddatardquo in Proceedings of the 13th ACM Conference on Com-puter and Communications Security pp 89ndash98 ACMAlexandria VA USA October 2006

[26] M Wang J Liu J Chen X Liu and J Mao ldquoPerm-guardauthenticating the validity of flow rules in software definednetworkingrdquo Journal of Signal Processing Systems vol 86no 2-3 pp 157ndash173 2017

[27] X Wen Y Chen C Hu C Shi and Y Wang ldquoTowards asecure controller platform for openflow applicationsrdquo inProceedings of the second ACM SIGCOMM workshop on Hottopics in software defined networking pp 171-172 ACMHong Kong China August 2013

[28] M Casado T Garfinkel A Akella et al ldquoSANE a protectionarchitecture for enterprise networksrdquo in Proceedings of theUSENIX Security Symposium vol 49 p 50 VancouverCanada August 2006

[29] D Boneh X Boyen and H Shacham ldquoShort group signa-turesrdquo in Proceedings of the Annual International CryptologyConference pp 41ndash55 Springer Santa Barbara CA USAAugust 2004

[30] M Canini P Kuznetsov D Levin and S Schmid ldquoA dis-tributed and robust SDN control plane for transactionalnetwork updatesrdquo in Proceedings of the IEEE INFOCOM2015mdashIEEE Conference on Computer Communications IEEEKowloon China April 2015


International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

combine SDN with attribute signature and propose SDNsecurity access control framework based on the attributeidentifiermdashAttribute-Guard It uses device attributes togenerate attribute identifiers Attribute-Guard manages at-tribute identifiers in each packet that defines network for-warding To ensure authentication of each flow weintroduced an attribute-based signature scheme in switch toauthenticate the flow based on their signature thus toprevent invalid flow launching continuous malicious attacksto the network As a result the Attribute-Guard can im-plement fine-grained access control and data source iden-tification based on network services

To sum up the main contributions of this paper are asfollows

(i) We propose Attribute-Guard a fine-grained flowaccess framework 0e proposed framework re-defines the SDN forwarding framework that bindsthe flowwith its devicersquos attribute identifiers (AIDs)

(ii) We present flow authentication protocol that caneffectively prevent fake flow and filter invalid flowcreated by an attacker in unauthorized mannersand it has a fine-grained management

(iii) We prototype our approach in the OpenDaylightcontroller and evaluate the system performance0etheoretical analysis and experimental results dem-onstrate that the proposed framework can effec-tively prevent the forging flow attack and implementfine-grained access control

12 Background and Motivation 0e abstract SDN com-munication model contains the following elements (1)hosts (2) SDN controller (3) application that provides flowrules for controllers (4) OpenFlow switch and (5) securitydevices such as firewall and security gateways

If host a (a malicious attacker) wants to attack host c theattack proceeds as shown in Figure 2 (1) host a sends a

request to OpenFlow Switch1 (2) if there is no flow rulematching the request from host a in OpenFlow Switch1OpenFlow Swich1 sends the request to the controller andwaits for the response (3) application receives a flow ruleproduction request from the controller (4) the applicationproduces a flow rule and sends it to the controller (5) thecontroller receives the flow rule and it saves the flow rule inthe flow rule database and forwards the flow rule toOpenFlow Switch1 and OpenFlow Switch2 (6) the new flowrule matches the packets from host a and forwards thepackets to the security device through OpenFlow Switch1and OpenFlow Switch2 respectively and (7) the securitydevice detects the packet according to the rule and it de-termines that host a cannot communicate with host c

According to the SDN structure we constructed twoattack methods [67] which achieve illegal access by tam-pering with flow rules and controlling flow 0ere are otherdirect attack scenarios such as DDos

(i) As shown in Figure 3 the attacker tampers with theflow rule in OpenFlow Switch2 which allows malicioushost a to access host c directly 0us the packets fromhost a can bypass the security device and scan host c

(ii) As shown in Figure 4 Malicious Application Bgenerates two new flow rules 0e first flow rule isused to modify the source IP address of the packetfrom the malicious host a to the source IP address ofhost b that can access host c 0en the second flowrule changes the destination address of the packet tothe IP address of host a If the packet is deliveredfrom host c to host a the security device simplyallows forwarding the packet from host b to host c Inthis way the packets from host a can bypass thesecurity device 0e host can scan host c

0e two examples in Figures 3 and 4 show that an at-tacker can tamper with flow rules and control flow to

Application planeApplication

API API API

Control plane

Data plane

Request Flow rules

Network service

Switch Switch Switch

Switch Switch

Figure 1 SDN architecture

Controller

Host a

Host c

OpenFlow Switch1OpenFlow Switch2

Security device

Server

1

2

34

55

6

9

7

Figure 2 0e abstract SDN communication model








Controller

Host a

Host c

OpenFlow Switch1

OpenFlow Switch2

Security device

Server

1

2

34

55

6

6

7


Controller

Host a

Host b

Host c

OpenFlow Switch1

OpenFlow Switch2

Security device

Server

1

2

34

55

6

6

7



























module


invalidation module

Flow rule Request



Legal flow entry


database


componentUser

Expired flow entry

Filter flow entry

Legal flow entry

Basic forwarding

table




Flow

iden

tific

atio

n m

odul

e

Control plane

Data plane






Control plane

Data plane

Controller

Upload



Download

Controller






















(1)


Version (4bit)


Length (8bit)

Reserved(12 bit)


Data









PK G1 G2 GT g1 g2 e H h u v W1113864 1113865




1(ω+xi)1 isin G1



Threshold value = 2











(5) The h

ostrsquos att

ribute s

et

(6) Attr

ibute iden

tifier

attri

bute

private

key




Host Controller DAS



SAS

Return the result

Install flowtable

Install flowtable


in T







jisinci







cx










⎧⎨

⎩ (3)




Fx 1113945zisinsx

FzΔsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qz(0)1113874 1113875

Δsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873


Δsxindex(z)


grnd21113872 1113873

qx(0)

(4)



2 R3



g2))κ R4 C

sx




























Port

OXM

TLV

Data


PICMPIP

header









Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia








Controller

Host a

Host c

OpenFlow Switch1

OpenFlow Switch2

Security device

Server

1

2

34

55

6

6

7


Controller

Host a

Host b

Host c

OpenFlow Switch1

OpenFlow Switch2

Security device

Server

1

2

34

55

6

6

7



























module


invalidation module

Flow rule Request



Legal flow entry


database


componentUser

Expired flow entry

Filter flow entry

Legal flow entry

Basic forwarding

table




Flow

iden

tific

atio

n m

odul

e

Control plane

Data plane






Control plane

Data plane

Controller

Upload



Download

Controller






















(1)


Version (4bit)


Length (8bit)

Reserved(12 bit)


Data









PK G1 G2 GT g1 g2 e H h u v W1113864 1113865




1(ω+xi)1 isin G1



Threshold value = 2











(5) The h

ostrsquos att

ribute s

et

(6) Attr

ibute iden

tifier

attri

bute

private

key




Host Controller DAS



SAS

Return the result

Install flowtable

Install flowtable


in T







jisinci







cx










⎧⎨

⎩ (3)




Fx 1113945zisinsx

FzΔsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qz(0)1113874 1113875

Δsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873


Δsxindex(z)


grnd21113872 1113873

qx(0)

(4)



2 R3



g2))κ R4 C

sx




























Port

OXM

TLV

Data


PICMPIP

header









Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


























module


invalidation module

Flow rule Request



Legal flow entry


database


componentUser

Expired flow entry

Filter flow entry

Legal flow entry

Basic forwarding

table




Flow

iden

tific

atio

n m

odul

e

Control plane

Data plane






Control plane

Data plane

Controller

Upload



Download

Controller






















(1)


Version (4bit)


Length (8bit)

Reserved(12 bit)


Data









PK G1 G2 GT g1 g2 e H h u v W1113864 1113865




1(ω+xi)1 isin G1



Threshold value = 2











(5) The h

ostrsquos att

ribute s

et

(6) Attr

ibute iden

tifier

attri

bute

private

key




Host Controller DAS



SAS

Return the result

Install flowtable

Install flowtable


in T







jisinci







cx










⎧⎨

⎩ (3)




Fx 1113945zisinsx

FzΔsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qz(0)1113874 1113875

Δsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873


Δsxindex(z)


grnd21113872 1113873

qx(0)

(4)



2 R3



g2))κ R4 C

sx




























Port

OXM

TLV

Data


PICMPIP

header









Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





















(1)


Version (4bit)


Length (8bit)

Reserved(12 bit)


Data









PK G1 G2 GT g1 g2 e H h u v W1113864 1113865




1(ω+xi)1 isin G1



Threshold value = 2











(5) The h

ostrsquos att

ribute s

et

(6) Attr

ibute iden

tifier

attri

bute

private

key




Host Controller DAS



SAS

Return the result

Install flowtable

Install flowtable


in T







jisinci







cx










⎧⎨

⎩ (3)




Fx 1113945zisinsx

FzΔsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qz(0)1113874 1113875

Δsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873


Δsxindex(z)


grnd21113872 1113873

qx(0)

(4)



2 R3



g2))κ R4 C

sx




























Port

OXM

TLV

Data


PICMPIP

header









Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia









PK G1 G2 GT g1 g2 e H h u v W1113864 1113865




1(ω+xi)1 isin G1



Threshold value = 2











(5) The h

ostrsquos att

ribute s

et

(6) Attr

ibute iden

tifier

attri

bute

private

key




Host Controller DAS



SAS

Return the result

Install flowtable

Install flowtable


in T







jisinci







cx










⎧⎨

⎩ (3)




Fx 1113945zisinsx

FzΔsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qz(0)1113874 1113875

Δsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873


Δsxindex(z)


grnd21113872 1113873

qx(0)

(4)



2 R3



g2))κ R4 C

sx




























Port

OXM

TLV

Data


PICMPIP

header









Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia






jisinci







cx










⎧⎨

⎩ (3)




Fx 1113945zisinsx

FzΔsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873

qz(0)1113874 1113875

Δsxindex(z)

Fx 1113945zisinsx

1113954e Aihα+β

grnd21113872 1113873


Δsxindex(z)


grnd21113872 1113873

qx(0)

(4)



2 R3



g2))κ R4 C

sx




























Port

OXM

TLV

Data


PICMPIP

header









Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


















Port

OXM

TLV

Data


PICMPIP

header









Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia







Field matching

Auth_tagFwdDrop

Ether Type


Filter flow entry

Expired flow entry






Goto_table

Goto_table

Flow Flow

AIDiAIDi



hellip




a2 e2 e3

a3a1

e1

h1 h2 h3 h4 h5 h6

Controller









21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia








21 3 4 5 6 7 8 9 10 11 12

Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)


Time (s)

h1-h6h2-h6h3-h6


01020304050

Pack

age (

s)

2 3 4 5 6 7 8 9 10 11 121



0102030405060

Pack

ets (

s)

2 3 4 5 6 7 8 9 10 11 121

h1-h6








h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia







h1-h4

14 15 16 17 18 19 20 21 22 23 2413Time (s)

0

10

20

30

40

50

Pack

ets (

s)







0

5

10

15

20

25

30

35

40

Num

ber o

f ide

ntiti

es










05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia









05

10152025303540455055606570758085

CPU

util

izat

ion

(a)




0

20

40

60

80

100

Mem

ory

utili

zatio

n (

)

(b)


495500505510515520525530535540545550555

Tim

e (m

s)



495500505510515520525530535540545550555

Tim

e (m

s)















Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia













Verification phase

0

2

4

6

8

10

12

Tim

e (s)



00

02

04

06

08

10

12

14

16

18

CPU

util

izat

ion





0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion









0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia







0

1

2

3

4

5

6

7

8

9

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80

Mem

ory

utili

zatio

n (

)



0

2

4

6

8

10

12

14

CPU

util

izat

ion

()




0

10

20

30

40

50

60

70

80M

emor

y ut

iliza

tion

()










0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia








0102030405060708090

100110120

Del

ay (m

s)




0

2

4

6

8

10

12

Traf

fic ra

tio(

)



SDNAttribute-Guard


0

2

4

6

8

10

Pack

et lo

ss ra

te (

)





20

40

60

80

100

120

140D

elay

(ms)






6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





6 Conclusion


Data Availability




Acknowledgments


References




































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia

















RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


research article - hindawi publishing corporationwith se-floodlight [9], rosemary [10], and fresco...

Documents