exploiting the vulnerability of flow table overflow in ...researcharticle exploiting the...

Research ArticleExploiting the Vulnerability of FlowTable Overflow in Software-Defined NetworkAttack Model Evaluation and Defense

Yadong Zhou 1 Kaiyue Chen1 Junjie Zhang2 Junyuan Leng1 and Yazhe Tang1

1MOE Key Lab for Intelligent Networks and Network Security Xirsquoan Jiaotong University Xirsquoan China2Department of Computer Science and Engineering Wright State University Fairborn OH USA

Correspondence should be addressed to Yadong Zhou yadongzhougmailcom

Received 28 September 2017 Accepted 6 December 2017 Published 9 January 2018

Academic Editor Zhiping Cai

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

As the most competitive solution for next-generation network SDN and its dominant implementation OpenFlow are attractingmore and more interests But besides convenience and flexibility SDNOpenFlow also introduces new kinds of limitations andsecurity issuesOf these limitations themost obvious andmaybe themost neglected one is the flow table capacity of SDNOpenFlowswitches In this paper we proposed a novel inference attack targeting at SDNOpenFlow network which is motivated by thelimited flow table capacities of SDNOpenFlow switches and the following measurable network performance decrease resultingfrom frequent interactions between data and control plane when the flow table is full To the best of our knowledge this is the firstproposed inference attack model of this kind for SDNOpenFlow We implemented an inference attack framework according toour model and examined its efficiency and accuracy The evaluation results demonstrate that our framework can infer the networkparameters (flow table capacity and usage) with an accuracy of 80 or higher We also proposed two possible defense strategies forthe discovered vulnerability including routing aggregation algorithm and multilevel flow table architecture These findings give usa deeper understanding of SDNOpenFlow limitations and serve as guidelines to future improvements of SDNOpenFlow

1 Introduction

By decoupling the control plane from the data planeSoftware-Defined Network (SDN) makes programmability abuilt-in feature for networks thereby introducing automatic-ity and flexibility to the networking management SDN hastherefore been foreseen as the key technology that enables thenext generation of networking paradigmDespite its promiseone of the most significant barriers towards SDNrsquos widepractical deployment resides in overwhelming security con-cerns [1] Therefore proactively detecting quantifying andmitigating its security vulnerabilities become of fundamentalimportance

In spite of its novelty SDN indeed reuses various designand implementation elements ranging from architecturesand protocols to systems from traditional network It isnot surprising that SDN inheres the vulnerabilities intrinsicto these elements For example similar to any networkedservice secure channels between controllers and switches

might be disrupted by DDoS attacks like firewall rulesthe flow entries may also conflict with each other leakingunwanted traffic malicious arp spoofing generated by attack-ers may poison the controller MAC table disturbing the nor-mal topology information gathering and packet forwardinguntrusted applications may instrument SDN controller toperform malicious behaviors without proper access controlwhich is one of the design objectives for modern operatingsystems In response existing research in the context ofSDN security mainly focuses on detecting and mitigatingthese vulnerabilities For example [2] evaluates man-in-the-middle attacks that target at SDNOpenFlow secure channelsFortNOX [3] brings security enforcement module into NOX[4] and enables real-time flow entry conflict check VeriFlow[5] detects network-wide invariant violations by acting as atransparent layer between control plane and data plane

In this paper we introduce a novel SDN vulnerabilityThe novelty of this vulnerability stems from the feedback-loop nature of SDN a fundamental difference compared

HindawiSecurity and Communication NetworksVolume 2018 Article ID 4760632 15 pageshttpsdoiorg10115520184760632

2 Security and Communication Networks

with traditional networks Particularly this vulnerability canbe extremely severe in SDN-based networks where networktraffic from different sources shares the same SDN switchrsquosflow table for example different tenants in a SDN-basedcloud computing network

Specifically most commercial SDNOpenFlow switcheshave limited flow table capacities ranging from hundreds tothousands [6] Such capacity is usually insufficient to handlemillions of flows that are typical for enterprise and data centernetworks [7] Nevertheless the flow table capacity was justconsidered as a potential bottleneck of resource consumingattacks in the past motivating researches on flow cachingsystems like [8ndash10] But according to our analysis the flowtable capacity can lead to inference attack and privacy leakageunder certain circumstances

As a consequence of flow table overflow the SDNcontroller needs to dynamically maintain the flow table byinserting and deleting flow entries The maintaining processtypically includes packet information transferring routingrule calculation and flow entry deployment which leads tomeasurable network performance decrease

Particularly once the flow table is full extra interactionsbetween controller and switch are needed to remove certainexisting flow entries to make room for newly generated flowentries resulting in further network performance decreaseAn attacker can therefore leverage the perceived performancechange to deduce the internal state of the SDN To be morespecific we consider the scenario that an attacker resides ina network that is managed by a SDN The attacker can thenactively generate network traffic triggering the interactionsbetween the controller and switch with respect to flow entryinsertion and deletion The attacker can then measure thechange of the network performance to estimate the internalstate of the SDN including the flow table capacity and flowtable usage We have designed innovative algorithms toexploit this vulnerability and quantify their effectiveness onexploiting this vulnerability based on extensive evaluation

Additionally to mitigate this vulnerability we have pro-posed two possible defense strategies The first strategy isa new routing aggregation algorithm to compress the flowentries so they will consume less flow table spaceThe secondstrategy is building a multilevel flow table architectureMultilevel flow table architecture can implement flow tableswith larger capacities without introducing additional powerassumption or charges

To summarize in this paper we made the followingcontributions

(i) We have identified a novel vulnerability introducedby the limited flow table capacities of SDNOpenFlowswitches and formalized that threat

(ii) We have designed effective algorithms that can suc-cessfully exploit this vulnerability to accurately inferthe internal states of the SDN network including flowtable capacity and flow table usage

(iii) We have performed extensive evaluation to quantifythe effectiveness of proposed algorithms The experi-mental results have demonstrated that the discovered

vulnerability indeed leads to significant security con-cerns our algorithm can infer the network parame-ters with an accuracy of 80 or higher across variousnetwork settings

(iv) We have proposed two possible defense strategiesfor the discovered vulnerability including routingaggregation algorithm to compress the flow entriesand multilevel flow table architecture to implementflow tables with larger capacities

The rest of this paper is organized as follows Section 2gives an overall statement of the inference attack problemSection 3 gives detailed inference algorithms targeting atFIFO and LRU replacement algorithms respectively Sec-tion 4 gives a detailed evaluation of the simulation resultsSection 5 proposes two possible defense methods against thiskind of inference attack Section 6 is a brief discussion aboutour findings and future research Section 7 describes somerelated works in this area Finally Section 8 concludes thispaper

2 Problem Statement

The vulnerability of flow table overflow in SDN potentiallyexists in SDN-based cloud computing network and otherimportant SDN-based networking systems [11 12]

After analyzing current structure and implementation ofSDNOpenFlow its decoupled nature gives us inspiration theinteractions between control plane and data plane will leadto network performance decrease which can be measuredthrough performance parameters like round trip time (RTT)If a flow matches one flow entry the flow will be forwardeddirectly according to the matched entry This process is fastand will cost little timeWhen the flow table is full some flowentry will be removed then the controller has to calculatethe rule and send a new flow entry to the switch and thisprocess is more complex and has more interactions betweencontroller and switch than the previous case which will costmore time

Figure 1 gives an overall flowchart of packet processingin an OpenFlow switch The three rectangular regions sur-rounded by dotted line stand for three possible packet pro-cessing branches respectively When the switch encountersan incoming packet it will parse it and send the parsed packetinto the subsequent processing pipeline

Then as the first step of the pipeline the switch willlook up its flow table to search flow entries matching thepacket When there is a match the switch will directlyforward the packet according to actions associated with thecorresponding flow entry This branch is illustrated in theinnermost rectangle of Figure 1

When there is no corresponding flow entry in the flowtable extra steps will be introduced into the procedureAdditional interactions between the switch and the controllerwill happen to acquire corresponding routing rules includingpacket information transferring routing rule calculation andflow entry deployment The middle rectangle of Figure 1illustrates this process

Security and Communication Networks 3

Packetparsing

Flow table lookup

Flow table status check

Flow table replacement

Insert new flow entry

Packet forwardIncomingpacket

Match

No match

Not full

Full

Outcoming packet

Figure 1 OpenFlow packet processing flowchart

T3

T2

T1

Pkt1 Pkt1 Pkt1

RTT

Packet sequence

TS1

(a)

Pkt2 PktNPkt3 Pkt4

RTT

Packet sequence

TS3

TS2

(b)

Figure 2 RTT measurement of different flow table state

Before the switch inserts the newly generated flow entryit has to check the flow table status to make sure that there isenough space in the flow tableWhen the flow table is full thecontroller has to perform flow table replacement operationsto make room for the upcoming flow entry These operationsinclude deciding which old flow entry to delete accordingto certain flow table replacement algorithm and flow entrydeletion The outermost rectangle in Figure 1 stands for thisbranch

That is exactly where the vulnerability lies In traditionalnetworks the switches and routers are autonomous whichmeans they can maintain their routing tables locally withoutinteracting with an external device But due to the decouplednature of SDNOpenFlow maintaining switch flow tablesneeds frequent interactions between switches and controllersmaking it possible for an attacker to leverage the perceivedperformance change to deduce the internal state of the SDNnetwork

As shown in Figure 1 the rectangular regions surroundedby dotted line correspond to different possible packet pro-cessing branches The larger a rectangle is the longer theprocessing time of that branch will be because of the extrasteps that rectangle contains When there is a match in the

flow table the processing time will be the shortest whenthere is no match in the flow table and the flow table is notfull the processing time will be longer because of additionrouting calculation and flow entry deployment when thereis no match in the flow table and the flow table is fullthe processing time will be the longest because a flow tablereplacement operation has to be performed So as a networkparameter directly influenced by the processing time theRTT of a packet can serve as an indicator of flow table stateand flow entry state

The process of deciding RTT thresholds for flow tablestate detection is shown in Figure 2

Figures 2(a) and 2(b) represent two cooperating threadsthe 119909-axis represents the packet sequence and the 119910-axisrepresents the recorded RTT of every packet Firstly inthe upper thread we generate a packet with a specificsrc ip dst ip src mac dst mac combination calling it Pkt1Send Pkt1 to the target OpenFlow switch and record thecorresponding RTT as 1198792 Currently there is no correspond-ing flow entry in the OpenFlow switch because Pkt1 is anew packet After a time span TS1 send Pkt

1to the target

OpenFlow switch again and record the corresponding RTTas 1198791 If TS1 is chosen properly the newly installed flow


entry matching Pkt1should still exist in the OpenFlow

switch Next in the lower thread we continuously generatepackets Pkt

2Pkt3 Pkt

119873 each with a different combi-

nation of src ip dst ip src mac dst mac and send thesepackets to the target OpenFlow switch with the time spanof TS

2 Because there are no flow entries matching their

packets in the OpenFlow switch the recorded RTTs will beapproximately the same as 1198792 Keep generating and sendingpackets until we observe a sudden increase of the RTT whichindicates that the flow table is full Then in the upper threadwe send Pkt1 again immediately and record the RTT as 1198793To achieve higher precision we can repeat the process anduse average values of 1198791 1198792 and 1198793 as final results

From the process above we can see that 1198791 1198792 and

1198793will serve as thresholds for flow table state detection

when the measured RTT is around 1198791 we can infer that

there is corresponding flow entry in the flow table when themeasured RTT is around 119879

2 we can infer that there is no

corresponding flow entry in the flow table and the flow tableis not full when themeasured RTT is around119879

3 we can infer

that there is no corresponding flow entry in the flow table andthe flow table is full

We model the SDNOpenFlow network as a black boxand observe its response (RTT) to different input (networkpackets) then we use the response to estimate the flow tablestate and flow entry state and perform further inference Thewhole process comes in three steps

Firstly we send probing packets into the network totrigger the interaction As there is still no mature routingaggregation algorithm or hierarchical routing rule solutioncurrent SDNOpenFlow switches typically use exact matchrules That means if we send 119899 packets with different fakedmetainformation like src ip and dst ip there will be 119899 newlygenerated flow entries inserted into the flow table If wesend excessive probing packets in a short period of time theflow table will overflow and then the interaction process willbe triggered Secondly we measure RTTs of the respondedpackets and infer the flow table state and flow entry stateThirdly we use observed flow table states and flow table statesas controlling signals in our inference algorithm and performflow table capacity inference

Having to achieve a hit rate as high as possible in a ratherlimited space flow table serves like a ldquocacherdquo in operatingsystems and web proxy servers In this paper we choose FIFOand LRU because they are common and popular [13]

3 Inference Algorithm

The logical structure of our inference algorithm is shownin Figure 3 The inference algorithm consists of two mainpart flow table state detection and flow table state controlFor flow table state detection we perform RTTmeasurementto classify the different states of flow table and specificflow entry For flow table state control we generate specificsequence of attacking network packets to manipulate thestate of flow entries For different flow table replacementalgorithms the relation betweennetwork traffic sequence andflow entry state will be different so we will have different

LRUinferencealgorithm

Strategy for FIFO

Strategy for LRU

Flow table state controlRTT measurement

FIFO inferencealgorithm Flow table state detection

traffic generation strategy

Figure 3 Inference algorithm

A

B

C

D

Figure 4 FIFO inference principle

network traffic generation strategy for different flow tablereplacement algorithms like FIFO and LRU We will intro-duce the inference algorithms for FIFO andLRU respectively

31 FIFO Inference Algorithm Asmentioned in Section 2 theinference process of FIFO algorithm will be as follows wegenerate and send a huge amount of probing packets eachwith a different combination of src ip dst ip src mac anddst mac and the newly inserted flow entries matching thegenerated packets will ldquopushrdquo the other usersrsquo flow entries outof the flow table We can detect if the flow table is full and theexistence of our flow entries Combined with the number ofinserted flow entries we recorded we can infer the flow tablecapacity and flow table usage The process of flow table statetransformation is shown in Figure 4

We use 119865our to represent the number of our inserted flowentries and use 119865other to represent the number of flow entriesfrom other users in the flow table Both 119865our and 119865other arefunctions of timeWe use119879

119860119879119861119879119862 and119879

119863to represent four

time points corresponding to four subfigures respectivelyand use 119862 to represent the flow table capacity

Figure 4 (119860) shows the flow table and the flow entriesit contains just before the experiment starts The rectangleitems represent the flow entries from other users sharing theOpenFlow switch The current number of other usersrsquo flowentries can be expressed as 119865other(119879119860)

Figure 4 (119861) illustrates the time when we start to sendgenerated packets inserting new flow entries into the flowtable The grey rectangles represent the flow entries insertedby us As we can see our flow entries keep pushing otherusersrsquo flow entries to the front of the FIFO queue During theexperiment we should keep a record of the generated packetsincluding their attributes and serial numbers


Require(1) Packet-Sending Function 119878119890119899119889119875119886119888119896119890119905()(2) List of IP 119868119875Ensure(3) The flow table capacity 119865capacity(4) The number of other usersrsquo flow entries 119865other(5) 119865capacity larr 0(6) 119865other larr 0(7) 119873 larr 0(8) 119873

1larr 0

(9) 1198732larr 0

(10) while 119873 lt length(119868119875) do(11) 119894119901 larr 119868119875[119873](12) SendPacket(119894119901)(13) 119873 larr 119873 + 1(14) if Flow table is full then(15) 119873

1larr 119873

(16) continue(17) end if(18) if One of our flow entries is deleted then(19) 119873

2larr 119873

(20) break(21) end if(22) end while(23) 119865capacity larr 1198732(24) 119865other larr 1198732 minus 1198731(25) return 119865capacity 119865other

Algorithm 1 FIFO inference algorithm

Figure 4 (119862) shows the timewhenwe detect the flow tableis full At this point of time flow entries from us and otherusers add up to fill the whole flow table precisely We have

119865our (119879119862) + 119865other (119879119862) = 119862 (1)

Figure 4 (119863) shows the time when we detect that one ofour inserted flow entries has been deleted That means theflow table is now full of our flow entries without any flowentries from other users We have

119865our (119879119863) = 119862 (2)

Combine the two equations above we have

119865other (119879119860) = 119865other (119879119862) = 119862 minus 119865our (119879119862)

= 119865our (119879119863) minus 119865our (119879119862) (3)

According to the analysis above we describe the inferenceprocess for FIFO algorithm as shown in Algorithm 1

The main error of the inference comes from the flowentries inserted by other users when our insertion is inprogressWe assume that our flow entry insertion speed is fastenough so that during the period of experiment the newlyinserted flow entries are all from us But that is not alwaysthe truth Ignoring the possible flow entries inserted by otherusers will make our inference result smaller than the actualvalue

Considering the flow entries inserted by other users theactual equations are listed below

When we detect the flow table is full if we use 119864(119860 119861)to represent the number of just inserted flow entries fromother users from time point 119860 to time point 119861 the equationbecomes

119865our (119879119862) + 119865other (119879119862) + 119864 (119879119860 119879119862) = 119862 (4)

And when we detect that one of our inserted flow entriesis deleted the equation becomes

119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863) = 119862 (5)


119865other (119879119862) = 119865our (119879119863) minus 119865our (119879119862) + 119864 (119879119862 119879119863) (6)

So the actual equation considering flow entry insertionsduring inference should be

119862 = 119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863)


Compared with our former equation ignoring flow entryinsertions

119862 = 119865our (119879119863)

119865other (119879119862) = 119865our (119879119863) minus 119865our (119879119862) (8)

We can see that the inferred flow table usage119865other and theinferred flow table capacity 119865capacity will both be smaller thanthe actual value

32 LRU Inference Algorithm The experiment principle ofLRU algorithm has something in common with that of FIFOalgorithm because under these two circumstances we canboth keep our flow entries stay in the back of the cache queueusing certain operations However there are still differenceslies in the flow entry maintaining process

The nature of FIFO algorithm ensures that the position ofthe flow entries only depends on the time they are insertedThe earlier inserted flow entries are sure to be nearer to thefront of the cache queue comparedwith the later inserted flowentries But in LRUalgorithm the positions of the flow entriesdepend not only on the time they are inserted but also on thelast time they are accessed In order to keep our flow entriesstay in the back of the cache queue we need to continuouslyaccess the previously inserted flow entries

During the maintain process every time we insert anew flow entry we need to access all previously insertedflow entries for one time to ldquoliftrdquo them to the backof the cache queue The access history may be like1198751 1198751 1198752 1198751 1198752 1198753 1198751 1198752 1198753 1198754 and we call it aldquorollingrdquo maintaining process The maintaining algorithm isshown in Algorithm 2 According to the analysis above wedescribe the inference process for LRU in Algorithm 3

The feasibility and error analysis of LRU algorithm issimilar to that of FIFO algorithm The inferred flow tableusage 119865other and the inferred flow table capacity 119865capacity willboth be smaller than the actual value because of ignoring theflow entries inserted by other users during the experiment


Require(1) Packet-Sending Function 119878119890119899119889119875119886119888119896119890119905()(2) List of Inserted IP 119868119875inserted(3) function RollingPacketSender(119868119875inserted)(4) 119894 larr 1(5) while 119894 lt length(119868119875inserted) do(6) for 119895 larr 0 119895 lt 119894 119895 + + do(7) 119894119901 larr 119868119875inserted[119895](8) SendPacket(119894119901)(9) end for(10) 119894 larr 119894 + 1(11) end while(12) end function

Algorithm 2 Rolling maintaining algorithm


1larr 0

(9) 1198732larr 0

(10) 119868119875inserted larr [](11) while 119873 lt length(119868119875) do(12) 119894119901 larr 119868119875[119873](13) 119868119875inserted larr 119868119875inserted + 119894119901(14) RollingPacketSender(119868119875inserted)(15) 119873 larr 119873 + 1(16) if Flow table is full then(17) 119873

1larr 119873


2larr 119873


Algorithm 3 LRU inference algorithm

4 Evaluation

41 Implementation The emulation environment of ourexperiment consists of three parts a network prototypingsystem used to emulate host and switch a network controllerand our inference attack toolkit

We choose Mininet [14] as the network prototypingsystem because it encapsulates host and switch emulationand thus easy to use Our emulated network prototype

for evaluation uses a star topology consisting of 20 hostsconnected to a single OpenFlow switch We build FIFO andLRUcontroller applications using Python on the basis of POX[15] OpenFlow controller As for the inference attack toolkitwe use libnet [16] to generate probing packets and libpcap[17] to capture replied packets To simulate the backgroundtraffic in real network we built a SDN testbed using Mininetand POX On the SDN testbed we performed a series ofbasic SDN operations These operations include buildinga customized SDN network topology setting up the linkbetween SDN switches and performing the ping test betweenall SDN nodes We captured the network traffic generatedduring these operations and use them as the backgroundnetwork traffic sample

42 RTT Measurement As we have mentioned in Sec-tion 2 the difference between traditional network andSDNOpenFlow network in handling previously unseenpackets gives us a possible indicator of the flow table stateand the flow entry living state RTT When there is notcorresponding flow entry existing in the flow table the RTTof a packet will significantly increase due to the interactionsbetween controller and switch in order to acquire new flowentries That is the case when there is still space in the flowtable Once the flow table is full the RTT of a packet willfurther increase as a result of extra flow table replacementoperations To prove the effectiveness of using RTT as theflow table state and flow entry state indicator we measuredpacket RTTs corresponding to different flow table state andflow entry state

Figure 5 gives the RTT measurement result showing thedifference The points with different symbols represent thetotal 300 times of RTTmeasurements we have conducted 100times ofmeasurement for each combination of flow table stateand flow entry state The square points stand for RTTs whenflow entry exists in flow table The circle points and trianglepoints both stand for RTTs when flow entry does not exist inflow table the circle points are measured when the flow tableis full and the triangle points are measured when the flowtable is not full

As can be seen from the figure when flow entry existsin flow table the packet RTTs are highly concentrated in the


50 100Group

8

7

6

5

4

3

2

1

00

RTT

(ms)

Flow entry exists in flow tableFlow entry does not exist and flow table is not fullFlow entry does not exist and flow table is full

Figure 5 RTT measurement

Table 1 Default timeout values

Controller Hard timeout Idle timeoutRyu 0 0Beacon 0 5 sFloodlight 0 5 sNOX 0 5 sPOX 30 s 10 sTrema 0 60 sMaestro 180 s 30 s

range of 02sim03ms when flow entry does not exist in flowtable and flow table is not full the packet RTTswill increase toabout 3sim5ms when flow entry does not exist in flow table andflow table is full the packet RTTs will be the highest rangingfrom 6ms to 8ms These three groups of RTTs all distributeintensively in a small rangewithout overlapping other groupsshowing the excellent discrimination of using RTT as a flowtable state and flow entry state indicator

43 Timeout

431 Default Timeout Values According to our previousanalysis the feasibility of our inference attack depends onwhether we can generate enough flow entries to fulfill theflow table within a single timeout cycle That means wemust have the ability to generate as many flow entries as theflow entry can hold during a timeout period So we analyzeseveral popular open-source controllers and search for theirdefault timeout values in the built-in applications The resultis presented in Table 1 The zero values in the table mean thecorresponding timeout will not take effect or in other wordsthe timeout value is ldquopermanentrdquo As can be seen from thetable most available controllers have timeout values in therange of 5 s to 30 s

If we take the flow table capacity of 2000 flow entries asan example the minimum packet generating speed requiredwill be 20005 = 400 packets per second while libnet can

generate tens of thousand packets per second So the defaulttimeout values ensure the feasibility of our inference attack

432 Timeout Measurement Though default timeout valuesof mainstream OpenFlow controllers can be read from theirsource codes it is still possible for SDN network administra-tors to manually change the default timeout values In orderto handle nondefault timeout values and provide basis foradjusting packet generating speed it is essential to examinethe accuracy of passive timeout measurement

Figure 6 illustrates relative errors (see equation (9)) ofhard timeout and idle timeout measurement respectivelyWemanuallymodify hard timeout and idle timeout values ofPOX OpenFlow controller to 5 s 10 s 15 s 20 s 25 s and 30 sand then we use timeout measurement algorithmmentionedin Section 2 to measure these timeout values and calculaterelative errors

relative error =1003816100381610038161003816valuedetected minus valuetrue

1003816100381610038161003816valuetrue

lowast 100 (9)

Every line in Figures 6(a) and 6(b) corresponds to 10times of repeated measurements conducted under a certaintimeout setting from 5 s to 30 sThemargin stays in the rangeof plus-or-minus 10 percent showing the effectiveness andhigh accuracy of our timeout measurement algorithm

44 Flow Table Capacity Flow capacity is the primary targetof our inference attack It reflects the hardware specificationof an OpenFlow switch Figure 7 illustrates the flow tablecapacity measurement result when controller adopts FIFOreplacement algorithm We manually limited the switch flowtable capacity to 10 different values from 100 flow entries to1000 flow entries and used our framework to perform theinference

The dark bars represent the manually set flow tablecapacities or real capacities The light bars represent themeasured flow table capacities For every manually set flowtable capacity we conduct 10 times of repeatedmeasurementsand take their mean value as the final result From thefigure we can see that the measured capacities are quite closeto the real capacities indicating the high accuracy of ourinference framework For example when the real capacity is400 flow entries our measured capacity is 408 flow entrieswith an error of only 8 flow entries As the real capacitygrows the packet generating speed required becomes fasterplacing higher requirements on packet sending receivingsynchronization and accurate timing But our inferencealgorithm shows unbelievable stability and accuracy whenthe real capacity is 1000 flow entries our measured capacityis 973 flow entries with an error of just 27 flow entries

Like Figure 7 Figure 8 also illustrates the flow tablecapacity measurement results with the only difference ofbeing performed under LRU replacement algorithm insteadof FIFO

According to our previous analysis the inference princi-ple of LRU replacement algorithm is more complex becauseof the unavoidable mixed nature of flow entries in the flowtable and the rolling maintaining process But our inference


Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

Hard timeout relative error

(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

Idle timeout relative error

(b)

Figure 6 Timeout relative error

100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group

Real capacityMeasured capacity

Figure 7 FIFO flow table capacity

framework still shows high accuracy and reliability Evenwhen the real flow table capacities are set to be rather largevalues like 900 and 1000 the errors of our measure capacitiesare just around 20 flow entries

Only illustrating the mean value of measured flow tablecapacities may not be enough the mean value may bethe result of error compensations and hide the detailed

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021

Figure 8 LRU flow table capacity

measurement errors of every separate experiment So inFigure 9 we illustrate the relative error of every single flowtable capacity measurement

We choose 5 groups of different flow table capacitiesfrom 200 flow entries to 1000 flow entries and perform 10times of measurements under every single flow table capacityvalue Figure 9(a) stands for relative error of flow tablecapacity measurements conducted under FIFO replacement


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

FIFO capacity relative error

(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

LRU capacity relative error

(b)

Figure 9 Flow table capacity relative error

algorithm showing that the margin is no larger than plus-or-minus 10 percent Figure 9(b) stands for relative errorof flow table capacity measurements conducted under LRUreplacement algorithm Due to the more complex inferenceprinciple and the rolling maintaining process the marginbecomes larger but still has not exceeded 15 percent even inthe worst case

The above inference attacks are performed without anybackground network traffic When performing inferenceattack in real networks the impact of background networktraffic cannot be ignored So it is necessary to examine the effi-ciency of our inference algorithm under these circumstances

In this evaluation we choose the background networktraffic dataset from a SDN testbed Figures 10 and 11 havethe same experiment setting with Figures 7 and 8 with theonly difference of replaying background traffic captured fromSDN testbed during the inference attack process Even withthe impact of background traffic our inference algorithm stillshows high accuracy

45 Flow Table Usage In this section we evaluated ourframeworkrsquos efficiency of inferring the number of flow entriesfrom other users sharing the same flow table or the flow tableusage Flow table usage is our secondary inference target andit reflects the network resource consuming condition of othertenants in the same SDN network Figures 12 and 13 illustratethe flow table usage measurement results conducted underFIFO and LRU replacement algorithm respectively

100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


Figure 10 FIFO flow table capacity with testbed background traffic

Again wemanually set 10 different flow table usage valuesfrom 100 to 1000 flow entries by manually generating andinserting corresponding number of flow entries into the flowtable beforehand Then we use our inference algorithm toinfer the flow table usage and take mean values of every 10times of measurements as the final results The errors of allthese measurements show the high accuracy stability andreliability of our inference algorithm


0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978

Figure 11 LRU flow table capacity with testbed background traffic

10 3 6 5 8 9 4 7 2 1 Group

Real usageMeasured usage

0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809

Figure 12 FIFO flow table usage

We also conducted the flow table usage inference attackwith background traffic Experiment results with testbedbackground traffic are shown in Figures 14 and 15 Ourinference algorithm can smoothly handle the impact ofbackground traffic which ensures the stability and robustnessdemonstrated in the experiment results

The relative errors are shown in Figure 16 We emulate5 groups of different flow table usage values and conducted10 times of flow table usage inference for every single valueFor both FIFO and LRU replacement algorithm the relativeerrors of flow table usage inference stay in a quite small rangeThe results prove that our algorithm can infer other tenantsrsquoflow table usage condition in high accuracy

5 Defense

From the previous sections we can conclude that the infer-ence attack is rooted in the flow table overflow To defendthat kind of inference attack we have to prevent flow tableoverflow in two aspects one aspect is to compress the flow

10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378

Figure 13 LRU flow table usage

10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935

Figure 14 FIFO flow table usage with testbed background traffic

entries to save flow table space and the other one is toimplement a larger flow table to store more flow entries

51 Routing Aggregation Routing aggregation is to combinemultiple entries in the flow table without changing the nexthops for packet forwarding This approach is particularlyappealing because it can be done by a software upgrade at theOpenFlow switch and its impact is limited within that switchRouting aggregation has already been used in traditionalnetworks but it has not been deployed in SDNOpenFlownetworks To fully utilize the flexibility of SDNOpenFlownetwork under certain scenarios like load balancing we pro-posed a global routing schedule using packing optimizationalgorithms

Traditional routing aggregation algorithms [18] can beused to compress the flow table but their effectiveness cannotbe ensured If thematching fields and next hops are dispersedenough chances are that we may not be able to performany routing aggregation because we cannot find flow entriessharing commonmatching fields and next hopsThis is often


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935

Figure 15 LRU flow table usage with testbed background traffic

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group

FIFO usage relative error LRU usage relative error

Figure 16 Flow table usage relative error

the case when dealing with web traffic for example load bal-ancing services For that reason we introduced an extra stageof routing aggregation global routing schedule optimizationFirst we model this routing aggregation problem as a packingoptimization problem and solve it then we perform globalrouting reschedule by rewriting the flow entries accordingto the optimization result and finally we perform anothertime of traditional routing aggregation on these new flowentries After the global routing reschedule there will be

much more aggregatable flow entries so the effectiveness ofrouting aggregation is ensured

52 Multilevel Flow Table Architecture It is important to notethat routing aggregation is not a replacement for the long-term architectural solutions because it does not address theroot causes of the flow table scalability problem and thefollowing inference attack To eliminate the inference attackvulnerability a flow table architecture with larger capacity is


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Figure 17 Single-level flow table architecture

Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout

Flow tablereplacement

Figure 18 Multilevel flow table architecture

required which can be achieved throughmultilevel flow tableconsisting of both TCAM and SRAM

The original single-level flow table architecture is shownin Figure 17 In this architecture the flow table is completelyimplemented using TCAM An input packet will traversefrom table 0 to table119898 and add corresponding actions to theaction set Then all actions in the action set are executed andthe packet is forwarded according to these actions

Our proposed multilevel flow table architecture is shownin Figure 18 Besides flow table implemented using TCAMwe add another flow table implemented using SRAM whichis cheaper and can provide larger flow table space Underthis multilevel flow table architecture the packet processingpipeline will be different first an input packet will findmatching flow entries in TCAM flow table just like in theoriginal single-level flow table architecture If there is amatchthe packet will execute the corresponding actions and getforwarded If there is no match the packet will continueits lookup in the SRAM flow table If there is a match inthe SRAM flow table the packet can then be forwardedotherwise it will be sent to the controller

From the process above we can see that if the capacityof TCAM flow table is 119898 the capacity of SRAM flow table is119899 and then the multilevel flow table will have a capacity of119898 + 119899 Actually 119899 is far more larger than 119898 so this approachcan greatly increase the flow table capacity thus preventingflow table overflow

6 Discussion

SDNOpenFlow has become a competitive solution for next-generation network and is being more and more widelyused in modern datacenters But considering its key role asthe fundamental infrastructure we have to admit that thesecurity issues of SDNOpenFlow have not been exploredto a large extent Particularly the flow table capacity ofSDNOpenFlow switch is only considered as a vulnerable partfor DDoS and flooding attacks in published researches Butaccording to our analysis in previous sections the flow tablecapacity can lead to potential inference attack if combinedwith reasonable assumptions and RTT measurements

Firstly we found in Section 2 that exactmatch flow entriesas well as the lack of route aggregation would consume a lot


of flow table space making it impossible to process millionsof flows per seconding using SDNOpenFlow Secondly wefound in Section 4 that assigning the decision making jobof flow table replacement to the controller would lead tosignificant network performance decrease which had to bechanged in time Thirdly there is currently no mature attackdetection mechanism for SDNOpenFlow network so it isquite easy for criminals to exploit system vulnerabilities orinvoke DDoS attacks

The inference method proposed in this paper just usessome basic elements and parameters of OpenFlow such asidle timeout and hard timeout which are significant for theimplementation of SDN These features will not be removedexcept very huge changes made On the other hand althoughsome security frameworks [3] were proposed to detect themalicious insertion of flow rules attackers can also bypass thedetection by some well-designed insertion strategies

All these security issues call for improvements to currentOpenFlow switch and flow table design The improvementsshould at least contain the following aspects (1) New Open-Flow switch architecture like embedding local caches inthe switch or implementing multilevel flow table to achievea much larger flow table capacity With larger flow tablecapacity the switch will not have to query the controller forflow entries which will reduce the interaction latency to alarge extent (2) New flow table maintaining mechanism liketransferring the flow entry deleting workload from controllerto switch Switch itself can decide which flow entry to deleteand then sync state with controller and during the flowentry deleting process the controllerrsquos intervention is notneeded In the widely used OpenFlow Switch Specification140 [19] this mechanism has been added as an optionalfeature but without any mature implementation so far (3)Routing aggregation Routing aggregation canmatch a groupof flows using one flow entry which will reduce the flowtable consuming significantly comparedwith exactmatch (4)Inference attack detection Administrators can develop infer-ence attack detecting applications and then perform defenseslike portspeed limiting or network address validation

From the discussion above we can see that there is stilla long road to go before SDNOpenFlow becomes a trulymature and reliable network paradigm There are still urgentand severe issues to solve which have been neglected in thepast Only by solving these security issues and architecturalvulnerabilities can SDNOpenFlow be widely deployed inreal-world commercial datacenters and fully demonstrate itsrevolutionary flexibility and intelligence

7 Related Work

The inference attack proposed in this paper is motivated bythe limited flow table capacity of SDNOpenFlow switchesThe flow table capacity issue has been presented in manyprevious works like [20ndash24] They all point out the limitationof switch flow table memory and potential scalability andsecurity issue However these works do not give furtheranalysis on the inference attack and information leakagecaused by the limited flow table capacity

Kloti et al [25] present potentially problematic issues inSDNOpenFlow including information disclosure throughtiming analysis However this information disclosurerequires disclosing existing flows with side channel attackwhich is hard to perform in real world Compared with theirapproach our inference attack is self-contained and requiresno prior knowledge

Gong et al [26] present a kind of inference attackusing RTT measurement to infer which website the victimis browsing They recover victimsrsquo network traffic patternsbased on the queuing side channel happened at the Internetrouter However the scenario of their work is in the publicInternet while our approach focuses on SDNOpenFlowinfrastructures in cloud computing network Compared withpublic Internet and website inference the inference attackand information leakage in modern data centers are moresensitive and valuable

Shin and Gu [27] demonstrate a novel attack targetingat SDN networks This attack includes fingerprinting SDNnetworks and further flooding the data plane flow table bysending specifically crafted fake flow requests in high speedIn the fingerprinting phase header field change scanning isused to collect the different response time (RTT) for new flowand existing flow The fingerprinting result is then analyzedto estimate if the target network used SDN technology TheRTT measurement and analysis they used in fingerprintingare similar to our approach But they just perform DoSattacks to the SDN network without performing any furtherinformation leakage or network parameter inference

As for flow table overflow defending strategy Shelly etal [28] and Katta et al [29] introduce flow entry cachingmechanism into SDNOpenflow network by inserting atransparent intermediate layer between controller and switchYan et al [9] use CAB to generate wildcard flow entriesdynamically and reactively to handle bursting network trafficKannan and Banerjee [30] present a flow entry compactionalgorithm to saveTCAMflow table spaceThis algorithmusesflow entry tags instead of matching fields as forwarding rulesKim et al [31] develop a new flow entry management schemeto reduce the controller overhead

8 Conclusion

In this paper we have explored the structure of SDNOpenFlow network and some of the possible security issues itbrings After our detailed analysis of the SDNOpenFlow net-work we proposed a novel inference attack model targetingat the SDNOpenFlow network which is the first proposedinference attack model of this kind in the SDNOpenFlowarea This inference attack is introduced by the OpenFlowswitch especially by its limited flow table capacity The infer-ence attack can be done in a completely passive waymaking ithard to detect and defendWe also implemented the inferenceattack framework and examined the efficiency and accuracyof it using network traffic data from different sources Thesimulation results show that the inference attack frameworkcan infer the network parameter (flow table capacity and flowtable usage) with an accuracy of up to 80 or higher We alsoproposed two possible defense strategies for the discovered


vulnerability including routing aggregation algorithm andmultilevel flow table architecture

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The research presented in this paper is supported in partby the National Key Research and Development Program ofChina (no 2016YFB0800100) the Fund of China NationalAeronautical Radio Electronics Research Institute (PM-12210-2016-001) the National Natural Science Foundation(61572397 U1766215 U1736205 61502383 61672425 and61702407) and State Grid Corporation of China (DZ71-16-030)

References

[1] W Li W Meng and L F Kwok ldquoA survey on OpenFlow-basedSoftware Defined Networks Security challenges and counter-measuresrdquo Journal of Network and Computer Applications vol68 pp 126ndash139 2016

[2] M Brooks and B Yang ldquoA Man-in-the-Middle attack againstOpenDayLight SDN controllerrdquo in Proceedings of the 4thAnnual Conference on Research in Information TechnologyAssociation for Computing Machinery Chicago IL USASeptember 2015

[3] P Porras S Shin V Yegneswaran M Fong M Tyson and GGu ldquoA security enforcement kernel for OpenFlow networksrdquoin Proceedings of the 1st ACM International Workshop on HotTopics in Software Defined Networks HotSDN 2012 pp 121ndash126 Association for Computing Machinery Helsinki FinlandAugust 2012

[4] N Gude T Koponen and J Pettit ldquoNOX towards an operatingsystem for networksrdquoACM SIGCOMMComputer Communica-tion Review vol 38 no 3 pp 105ndash110 2008

[5] A Khurshid W Zhou M Caesar and P B Godfrey ldquoVeriflowVerifying network-wide invariants in real timerdquo in Proceedingsof the Annual Conference of the ACM Special Interest Group onData Communication on the Applications Technologies Archi-tectures and Protocols for Computer Communication ACMSIGCOMM 2012 pp 467ndash472 Finland August 2012

[6] G Zhao L Huang Z Yu H Xu and P Wang ldquoOn the effectof flow table size and controller capacity on SDN networkthroughputrdquo in Proceedings of the 2017 IEEE InternationalConference on Communications (ICC) pp 1ndash6 Paris FranceMay 2017

[7] A RoyH Zengy J BaggayG Porter andAC Snoeren ldquoInsidethe social networkrsquos (Datacenter) networkrdquo in Proceedings of theACM Conference on Special Interest Group on Data Communi-cation SIGCOMM 2015 pp 123ndash137 UK August 2015

[8] N Shelly E J Jackson T Koponen N McKeown and JRajahalme ldquoFlow caching for high entropy packet fieldsrdquo inProceedings of the 3rd ACM SIGCOMM 2014 Workshop on HotTopics in Software Defined Networking HotSDN 2014 pp 151ndash156 Chicago Illinois USA August 2014

[9] B Yan Y Xu H Xing K Xi and H J Chao ldquoCAB A reactivewildcard rule caching system for software-defined networksrdquo inProceedings of the 3rd ACM SIGCOMM 2014 Workshop on Hot

Topics in Software Defined Networking HotSDN 2014 pp 163ndash168 Chicago Illinois USA August 2014

[10] Katta Naga Jennifer Rexford and David Walker ldquoInfinitecacheflow in software-defined networksrdquo Princeton School ofEngineering and Applied Science 2013

[11] Yanwen Wang Hainan Chen Hainan Chen and Lei ShuldquoAn energy-efficient SDN based sleep scheduling algorithm forWSNsrdquo Journal of Network and Computer Applications vol 59pp 39ndash45 2016 httpdxdoiorg101016jjnca201505002

[12] S-N Yang S-W Ho Y-B Lin and C-H Gan ldquoA multi-RATbandwidth aggregation mechanism with software-defined net-workingrdquo Journal ofNetwork andComputerApplications vol 61pp 189ndash198 2016 httpdxdoiorg101016jjnca201511003

[13] M Dehghan L Massoulie D Towsley D Menasche andY C Tay ldquoA utility optimization approach to network cachedesignrdquo in Proceedings of the 35th Annual IEEE InternationalConference on Computer Communications IEEE INFOCOM2016 San Francisco CA USA April 2016

[14] ldquoMininetrdquo httpmininetorg[15] ldquoPOX Controllerrdquo httpwwwnoxrepoorgpoxabout-pox[16] ldquolibnet-devrdquo httpsgithubcomsam-githublibnet[17] ldquolibpcaprdquo httpwwwtcpdumporg[18] X Zhao Y Liu L Wang and B Zhang ldquoOn the aggregatability

of router forwarding tablesrdquo in Proceedings of IEEE INFOCOM2010 Institute of Electrical and Electronics Engineers SanDiego CA USA March 2010

[19] ldquoOpenFlow Switch Specification 140rdquo httpswwwopennet-workingorgimagesstoriesdownloadssdn-resourcesonf-spec-ificationsopenflowopenflow-spec-v140pdf

[20] S Sezer S Scott-Hayward P Chouhan et al ldquoAre we readyfor SDN Implementation challenges for software-defined net-worksrdquo IEEE Communications Magazine vol 51 no 7 pp 36ndash43 2013

[21] D Kreutz F M V Ramos P E Verissimo C E RothenbergS Azodolmolky and S Uhlig ldquoSoftware-defined networking acomprehensive surveyrdquo Proceedings of the IEEE vol 103 no 1pp 14ndash76 2015

[22] S Scott-Hayward G OrsquoCallaghan and S Sezer ldquoSDN securityA surveyrdquo in Proceedings of the 2013 Workshop on SoftwareDefined Networks for Future Networks and Services SDN4FNS2013 Trento Italy November 2013

[23] A Akhunzada E Ahmed A Gani M K Khan M Imran andS Guizani ldquoSecuring software defined networks Taxonomyrequirements and open issuesrdquo IEEE Communications Maga-zine vol 53 no 4 pp 36ndash44 2015

[24] M Tsugawa A Matsunaga and J A B Fortes ldquoCloud comput-ing securityWhat changes with software-defined networkingrdquoSecure Cloud Computing pp 77ndash93 2014

[25] R Kloti V Kotronis and P Smith ldquoOpenFlow A securityanalysisrdquo in Proceedings of the 2013 21st IEEE International Con-ference on Network Protocols ICNP 2013 Institute of ElectricalandElectronics EngineersGoettingenGermanyOctober 2013

[26] X Gong N Borisov N Kiyavash and N Schear ldquoWebsiteDetection Using Remote Traffic Analysisrdquo in Privacy EnhancingTechnologies vol 7384 of Lecture Notes in Computer Science pp58ndash78 Springer Berlin Heidelberg 2012

[27] S Shin and G Gu ldquoAttacking software-defined networks afirst feasibility studyrdquo in Proceedings of the 2nd ACM SIG-COMMWorkshop onHot Topics in SoftwareDefinedNetworking(HotSDN rsquo13) pp 165-166 Association for Computing Machin-ery Hong Kong China August 2013


[28] N Shelly E J Jackson T Koponen N McKeown and JRajahalme ldquoFlow caching for high entropy packet fieldsrdquo ACMSIGCOMMComputer CommunicationReview vol 44 no 4 pp663ndash668 2014

[29] N Katta O Alipourfard J Rexford and D Walker ldquoInfiniteCacheFlow in software-defined networksrdquo in Proceedings of the3rd ACM SIGCOMM 2014 Workshop on Hot Topics in SoftwareDefined Networking HotSDN 2014 pp 175ndash180 Association forComputing Machinery Chicago Illinois USA August 2014

[30] K Kannan and S Banerjee ldquoCompact TCAM Flow entrycompaction in TCAM for power aware SDNrdquo in Proceedings ofthe 14th International Conference on Distributed Computing andNetworking vol 7730 of Lecture Notes in Computer Science pp439ndash444 Springer Mumbai India 2013

[31] E-D Kim S-I Lee Y Choi M-K Shin and H-J KimldquoA flow entry management scheme for reducing controlleroverheadrdquo in Proceedings of the 16th International Conference onAdvanced Communication Technology Content Centric NetworkInnovation ICACT 2014 pp 754ndash757 Institute of Electrical andElectronics Engineers Pyeongchang South Korea February2014

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


with traditional networks Particularly this vulnerability canbe extremely severe in SDN-based networks where networktraffic from different sources shares the same SDN switchrsquosflow table for example different tenants in a SDN-basedcloud computing network

Specifically most commercial SDNOpenFlow switcheshave limited flow table capacities ranging from hundreds tothousands [6] Such capacity is usually insufficient to handlemillions of flows that are typical for enterprise and data centernetworks [7] Nevertheless the flow table capacity was justconsidered as a potential bottleneck of resource consumingattacks in the past motivating researches on flow cachingsystems like [8ndash10] But according to our analysis the flowtable capacity can lead to inference attack and privacy leakageunder certain circumstances

As a consequence of flow table overflow the SDNcontroller needs to dynamically maintain the flow table byinserting and deleting flow entries The maintaining processtypically includes packet information transferring routingrule calculation and flow entry deployment which leads tomeasurable network performance decrease

Particularly once the flow table is full extra interactionsbetween controller and switch are needed to remove certainexisting flow entries to make room for newly generated flowentries resulting in further network performance decreaseAn attacker can therefore leverage the perceived performancechange to deduce the internal state of the SDN To be morespecific we consider the scenario that an attacker resides ina network that is managed by a SDN The attacker can thenactively generate network traffic triggering the interactionsbetween the controller and switch with respect to flow entryinsertion and deletion The attacker can then measure thechange of the network performance to estimate the internalstate of the SDN including the flow table capacity and flowtable usage We have designed innovative algorithms toexploit this vulnerability and quantify their effectiveness onexploiting this vulnerability based on extensive evaluation

Additionally to mitigate this vulnerability we have pro-posed two possible defense strategies The first strategy isa new routing aggregation algorithm to compress the flowentries so they will consume less flow table spaceThe secondstrategy is building a multilevel flow table architectureMultilevel flow table architecture can implement flow tableswith larger capacities without introducing additional powerassumption or charges

To summarize in this paper we made the followingcontributions

(i) We have identified a novel vulnerability introducedby the limited flow table capacities of SDNOpenFlowswitches and formalized that threat

(ii) We have designed effective algorithms that can suc-cessfully exploit this vulnerability to accurately inferthe internal states of the SDN network including flowtable capacity and flow table usage

(iii) We have performed extensive evaluation to quantifythe effectiveness of proposed algorithms The experi-mental results have demonstrated that the discovered

vulnerability indeed leads to significant security con-cerns our algorithm can infer the network parame-ters with an accuracy of 80 or higher across variousnetwork settings

(iv) We have proposed two possible defense strategiesfor the discovered vulnerability including routingaggregation algorithm to compress the flow entriesand multilevel flow table architecture to implementflow tables with larger capacities

The rest of this paper is organized as follows Section 2gives an overall statement of the inference attack problemSection 3 gives detailed inference algorithms targeting atFIFO and LRU replacement algorithms respectively Sec-tion 4 gives a detailed evaluation of the simulation resultsSection 5 proposes two possible defense methods against thiskind of inference attack Section 6 is a brief discussion aboutour findings and future research Section 7 describes somerelated works in this area Finally Section 8 concludes thispaper

2 Problem Statement

The vulnerability of flow table overflow in SDN potentiallyexists in SDN-based cloud computing network and otherimportant SDN-based networking systems [11 12]

After analyzing current structure and implementation ofSDNOpenFlow its decoupled nature gives us inspiration theinteractions between control plane and data plane will leadto network performance decrease which can be measuredthrough performance parameters like round trip time (RTT)If a flow matches one flow entry the flow will be forwardeddirectly according to the matched entry This process is fastand will cost little timeWhen the flow table is full some flowentry will be removed then the controller has to calculatethe rule and send a new flow entry to the switch and thisprocess is more complex and has more interactions betweencontroller and switch than the previous case which will costmore time

Figure 1 gives an overall flowchart of packet processingin an OpenFlow switch The three rectangular regions sur-rounded by dotted line stand for three possible packet pro-cessing branches respectively When the switch encountersan incoming packet it will parse it and send the parsed packetinto the subsequent processing pipeline

Then as the first step of the pipeline the switch willlook up its flow table to search flow entries matching thepacket When there is a match the switch will directlyforward the packet according to actions associated with thecorresponding flow entry This branch is illustrated in theinnermost rectangle of Figure 1

When there is no corresponding flow entry in the flowtable extra steps will be introduced into the procedureAdditional interactions between the switch and the controllerwill happen to acquire corresponding routing rules includingpacket information transferring routing rule calculation andflow entry deployment The middle rectangle of Figure 1illustrates this process


Packetparsing

Flow table lookup





Match

No match

Not full

Full

Outcoming packet


T3

T2

T1

Pkt1 Pkt1 Pkt1

RTT

Packet sequence

TS1

(a)

Pkt2 PktNPkt3 Pkt4

RTT

Packet sequence

TS3

TS2

(b)








1to the target





2Pkt3 Pkt











3 we can infer








Strategy for FIFO

Strategy for LRU





A

B

C

D





119860119879119861119879119862 and119879







1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873




119865our (119879119862) + 119865other (119879119862) = 119862 (1)


119865our (119879119863) = 119862 (2)



= 119865our (119879119863) minus 119865our (119879119862) (3)





119865our (119879119862) + 119865other (119879119862) + 119864 (119879119860 119879119862) = 119862 (4)


119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863) = 119862 (5)




119862 = 119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863)



119862 = 119865our (119879119863)











1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873



4 Evaluation








50 100Group

8

7

6

5

4

3

2

1

00

RTT

(ms)






43 Timeout







1003816100381610038161003816valuetrue

lowast 100 (9)







Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)


100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021





Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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



Packetparsing

Flow table lookup





Match

No match

Not full

Full

Outcoming packet


T3

T2

T1

Pkt1 Pkt1 Pkt1

RTT

Packet sequence

TS1

(a)

Pkt2 PktNPkt3 Pkt4

RTT

Packet sequence

TS3

TS2

(b)








1to the target





2Pkt3 Pkt











3 we can infer








Strategy for FIFO

Strategy for LRU





A

B

C

D





119860119879119861119879119862 and119879







1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873




119865our (119879119862) + 119865other (119879119862) = 119862 (1)


119865our (119879119863) = 119862 (2)



= 119865our (119879119863) minus 119865our (119879119862) (3)





119865our (119879119862) + 119865other (119879119862) + 119864 (119879119860 119879119862) = 119862 (4)


119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863) = 119862 (5)




119862 = 119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863)



119862 = 119865our (119879119863)











1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873



4 Evaluation








50 100Group

8

7

6

5

4

3

2

1

00

RTT

(ms)






43 Timeout







1003816100381610038161003816valuetrue

lowast 100 (9)







Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)


100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021





Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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





2Pkt3 Pkt











3 we can infer








Strategy for FIFO

Strategy for LRU





A

B

C

D





119860119879119861119879119862 and119879







1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873




119865our (119879119862) + 119865other (119879119862) = 119862 (1)


119865our (119879119863) = 119862 (2)



= 119865our (119879119863) minus 119865our (119879119862) (3)





119865our (119879119862) + 119865other (119879119862) + 119864 (119879119860 119879119862) = 119862 (4)


119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863) = 119862 (5)




119862 = 119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863)



119862 = 119865our (119879119863)











1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873



4 Evaluation








50 100Group

8

7

6

5

4

3

2

1

00

RTT

(ms)






43 Timeout







1003816100381610038161003816valuetrue

lowast 100 (9)







Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)


100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021





Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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




1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873




119865our (119879119862) + 119865other (119879119862) = 119862 (1)


119865our (119879119863) = 119862 (2)



= 119865our (119879119863) minus 119865our (119879119862) (3)





119865our (119879119862) + 119865other (119879119862) + 119864 (119879119860 119879119862) = 119862 (4)


119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863) = 119862 (5)




119862 = 119865our (119879119863) + 119864 (119879119860 119879119862) + 119864 (119879119862 119879119863)



119862 = 119865our (119879119863)











1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873



4 Evaluation








50 100Group

8

7

6

5

4

3

2

1

00

RTT

(ms)






43 Timeout







1003816100381610038161003816valuetrue

lowast 100 (9)







Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)


100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021





Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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






1larr 0

(9) 1198732larr 0


1larr 119873


2larr 119873



4 Evaluation








50 100Group

8

7

6

5

4

3

2

1

00

RTT

(ms)






43 Timeout







1003816100381610038161003816valuetrue

lowast 100 (9)







Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)


100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021





Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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



50 100Group

8

7

6

5

4

3

2

1

00

RTT

(ms)






43 Timeout







1003816100381610038161003816valuetrue

lowast 100 (9)







Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)


100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021





Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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



Hard timeout = 30

Hard timeout = 25

Hard timeout = 20

Hard timeout = 15

Hard timeout = 10

Hard timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Idle timeout = 30

Idle timeout = 25

Idle timeout = 20

Idle timeout = 15

Idle timeout = 10

Idle timeout = 5

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)


100 95

200 192

300 315

400 408

500 486

600 619

700666

800831

900 883

1000973

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 120

200 180

350300

400 422

500 475

600630

700

788 800828

900 880

10001021





Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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



Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(a)

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group


(b)






100 81

200174

300 295

1000

931900

852800 805

700 641

600 595

500 463

400 385

0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group





0

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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

200

400

600

800

1000

Capa

city

10 3 6 5 8 9 4 7 2 1 Group


100 99

200158

300328

400 399

500447

600 595

700752

800 790

900841

1000 978


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

100 120

200 184

300 322

400 378

500 492

600 617

700 723

800

900 895

1000976

809




5 Defense


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge

10080

200 195

300 278

400

500466

600 602

700731

800 783

900 882

1000 976

378


10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000 U

sage

100 107

200163

300 301

400357

500468

600 590

700 694

800 780

900865

1000

935






10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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



10 3 6 5 8 9 4 7 2 1 Group


0

200

400

600

800

1000

Usa

ge100

200168

300251

400346

500

433

600566

700

57

693

800745

900842

1000

935


Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

Capacity = 1000

Capacity = 800

Capacity = 600

Capacity = 400

Capacity = 200

minus10

0

10

20

30

Rela

tive e

rror

minus10

0

10

20

30

Rela

tive e

rror

2 4 6 8 10Group

2 4 6 8 10Group







Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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



Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM


Table0

Table1

Tablem

Executeaction

set

Packetin

Packetout

TCAM

Match

Table0

Table1

Tablen

SRAM

Match

Table miss

Executeaction

set

Packetout







6 Discussion








7 Related Work






8 Conclusion






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







7 Related Work






8 Conclusion






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






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


exploiting the vulnerability of flow table overflow in ...researcharticle exploiting the...

Documents