Securing the Control Channel of Software-DefinedMobile Networks

Madhusanka Liyanage1, Mika Ylianttila2, Andrei Gurtov31,2 Centre for Wireless Communication (CWC), University of Oulu, Finland

3 Helsinki Institute for Information Technology (HIIT), Finland and ITMO University, Russia.Email: 1madhusanka@ee.oulu.fi,2mika.ylianttila@oulu.fi,3gurtov@hiit.fi

Abstract—Software-Defined Mobile Networks (SDMNs) arebecoming popular as the next generation of telecommunicationnetworks due to the enhanced performance, flexibility andscalability. In this paper, we study the new security challengesof the control channel of SDMNs and propose a novel securecontrol channel architecture based on Host Identity Protocol(HIP). IPsec tunneling and security gateways are widely usedin today’s mobile networks. The proposed architecture utilizedthese technologies to protect the control channel of SDMNs.Weimplement the proposed architecture in a testbed and analyze thesecurity features. Moreover, we measure the performance penaltyof security of proposed architecture and analyze its ability toprotect the control channel from various IP (Internet Protocol)based attacks.

I. I NTRODUCTION

The next generation of mobile networks will support arich set of network services such as VoIP (Voice over IP),video streaming, broadband connectivity, mobile cloud andvirtual network services. Hence, the mobile traffic usage isdrastically increasing than wired Internet traffic. However, itis challenging to accommodate the increasing traffic demanddue the limited radio bandwidth resources and the inflexiblenetwork equipments. Therefore, it is required to utilize newequipments and technologies in mobile networks to enhancethe performance, flexibility and scalability of telecommunica-tion networks. On these grounds, Software-Defined Network-ing (SDN) and Network Function Virtualization (NFV) areidentified as promising technologies to achieve above goalsformobile networks. SDMN offers key features such as the logi-cally centralized intelligence, programmability and abstraction[1]. However, SDMNs are vulnerable to new security threatsthat did not exist before or were harder to exploit. For instance,the centralization of the network intelligence and controllingin a SDMN is an attractive honey-pot for external attackersand malicious users.

In [2], authors specified the various threat vectors of SDN.However, we focus only on the security challenge of thecontrol channel of SDMNs in this paper. Moreover, the recentresearch articles proposed new security mechanisms to protectthe controller and the control plane from various securitythreats [3] [4] [5]. However, none of these security mecha-nisms solves the security issues in the control channel. Onthe other hand, OpenFlow (OF) specifications proposed to useSSL (Secure Sockets Layer)/TLSv1 (Transport Layer Securityversion 1) sessions to protect control channel communication

[6]. However, SSL/TLSv1 based communication is not strongenough to protect the control channel from IP based attacks.On the other hand, a use case of Host Identity Protocol (HIP)to support SDN switch mobility is presented in [7]. Here,authors studied only the mobility aspects and they did notconsider any security threats, issues and attacks in the SDMNcontrol channel.

• Our Contribution

In this paper, we study the new security challenges ofthe control channel of SDMNs and propose a novel securecontrol channel architecture based on Host Identity Protocol(HIP). IPsec tunneling and Security Gateways (SecGWs) arewidely used in today’s mobile networks. A recent surveyreveals that 44% of mobile operators are using SecGWs basedsecurity mechanisms in their backhaul networks [8]. Theproposed architecture utilized these technologies to protectthe control channel of SDMNs. We implement the proposedarchitecture in a testbed and analyze the security features.Moreover, we measure the performance penalty of securityof proposed architecture and analyze its ability to protectthecontrol channel from various IP based attacks.

The rest of the paper is organized as follows. The SDMNarchitecture and its security issues are explained in Section II.The proposed secure control channel architecture is presentedin Section III. We describe our experiment testbed and presentits results in Section IV. Section V and VI respectively containthe discussion and conclusions of the paper.

II. BACKGROUND

A. Software-Defined Mobile Network (SDMN)

Software Defined Mobile Network (SDMN) concept isproposed as an extension of SDN paradigm to incorporatemobile network specific functionalities. SDMN architecture isnow directing the current mobile network to a flow-centricmodel that employs inexpensive hardware and a logicallycentralized controller.

Basically, SDN proposes to separate the control and the dataplanes of network devices. It pushes the network intelligenceto a centralized controller which controls all the functions inthe network. Thus, the data plane consists of low-end switchesand network links among them. The communication channelbetween the controller and data plane switches is called thecontrol channel. The controller communicates with the data

Fig. 1: The SDMN Architecture

plane elements over the control channel by using the controlprotocol (Figure 1). OF protocol is the widely used controlprotocol in SDN domain [6] and we use it as the referenceprotocol for our analysis.

SDMN offers various benefits such as centralized control-ling, improved flexibility, efficient segmentation, automaticnetwork management, granular network control, reduction ofoperation and equipment cost backhaul devices, on-demandprovision and resource scaling [1]. Thus, SDMN is consideredas the latest innovation in the telecommunication domain.

B. Security Issues in SDMN Control channels

SDMNs are now vulnerable to new security threats thatdid not exist before or were harder to exploit [2] in mobilenetworks. These security issues can be originated at varioussections of the network [2]. However, this research is focusonly to identify the security challenges in the control channelof SDMNs.

The main security issue of the control channel is the lack ofIP level security. Existing SDN control channels rely on higherlayer secure mechanism such as TLS/SSL based communica-tion. For instance, OF protocol uses TLS/SSL based controlchannels [6]. However, higher layer secure mechanisms arevulnerable various IP based attacks such as IP spoofing, TCPSYN (Synchronization) DoS (Denial of Service) and TCPreset attacks [2] [9]. Therefore, the higher layer protectionmechanisms are not strong enough to provide a required levelof robustness and security for the control channel.

Moreover, the security level of a TLS/SSL session is de-pending on various factors such as self-signed certificates,Certificate Authority (CA), security applications and libraries.Thus, the security of the TLS/SSL session is strong as thesecurity level of the weakest link among those factors [9]. Onthe other hand, a strong authentication is required betweenthe controller and data plane switches. In absent of strongauthentication mechanism, an intruder who gains access tothe control plane can launch various attacks. For instance,the attacker can inject fake flow requests to overwhelm thecontroller resources and exhaust the flow tables in switches.However, the TLS/SSL model is not sufficient enough toperfume such a strong authentication procedure between con-trollers and switches. For example, TLS/SSL authenticationmechanism is vulnerable to IP spoofing and CompressionRatio Info-leak Made Easy (CRIME) attacks [9].

III. PROPOSEDSECURE CONTROL CHANNEL

We propose a HIP based secure control channel for SDMNsand it is a Bump-in-the-wire security architecture. Therefore,the security architecture is independent of the SDN controlprotocol (e.g. OF protocol).

The proposed secure control channel architecture is pre-sented in Figure 2. There are four changes are proposed tothe existing SDMN architecture. First, distributed SecGWsare utilized to secure the controller from outside network andsolve the single point of failure. Second, new SEC (Security)entity is added as a control entity to control SecGWs and othersecurity related functions in SDMN. Third, a Local SecurityAgent (LSA) application is installed in each data plane switchto handle security related functions in the switch. Fourth,IPsecBEET (Bounded-End-to-End-Tunnel) is used to secure thecontrol channel communication.

Fig. 2: Proposed Secure control Channel Architecture

A. SecGW (Security Gateway)

SecGW is the intermediate device between the controllerand the rest of the network. SecGWs hide the network con-troller from the outside world and reduce the security relatedwork load of the controller. SecGWs are responsible for twofunctions. 1. Establish IPsec tunnels with data plane switches.2. Participate in the authentication and registration proceduresof new switches.

Here, we propose to utilize distributed SecGWs to preventthe single point of failure. Moreover, it is possible to integratevarious security functions such as IDS (Intrusion DetectionSystems), DPI (Deep Packet Inspection) and Firewalls withthese SecGWs for extra protection.

B. SEC Entity (Security Entity)

The SEC entity is a new control entity which controlsSecGWs and other security functions in the network. In theproposed architecture, the SEC entity is used to authorize thedata plane switches (Figure 4). The operator uploads a set ofACLs (Access Control Lists) to the SEC entity. These ACLscontain the identities of legitimate data plane switches and theSEC entity authorizes new switches based on ACLs.

Moreover, SEC entity retrieves the statistical informationfrom the controller. Based on this information, the SEC

entity can identify the abnormal traffic behaviors and instructSecGWs to terminate the communication with misbehavingswitches.

C. Local SEC Agent (LSA)

LSA is a security entity which is implemented on theswitch. It is mainly responsible for the secure control channelestablishment with SecGWs.

Fig. 3: The Secure Control Channel

Figure 3 illustrates the secure control channel and theplacement of LSA in the switch. Here, the tradition controlprotocol (e.g. OF protocol) communicates between the Open-Flow logics/APIs (Application Programming Interfaces) inOFswitch and the controller. The proposed security mechanismis invisible to OF protocol.

D. Control Channel

We propose a HIP based secure channel which establishesHIP (IPsec BEET mode) tunnels between SecGWs and dataplane switches. HIP is a novel mobility and security man-agement protocol which is standardized by IETF (InternetEngineering Task Force) [10]. It separates the dual role ofIP address as the locater and the host identity. Each HIPhost has a public/private key and the public key is used asits Host Identity (HI). HIP utilizes a base protocol namedHIP Base Exchange (HIP BEX) to mutually authenticate theend nodes and establish Security Associations (SAs) for anIPsec tunnel between them. HIP BEX contains a strong PKI(Public-Key Infrastructure) based authentication mechanismby utilizing these unique HIs. Moreover, HIP tunnels use theESP (Encapsulating Security Payload) mode. Therefore, thecontrol channel payload is always encrypted.

In proposed architecture, every SDN switch has its ownpublic/private key pair and the public key is used as its HI. Thepublic/private key pair is stored in each SDN switch before theinstallation in the network. The network operator adds HIs oflegitimate switches to ACLs in the SEC entity.

1) Authentication and Registration procedure of Switches:The proposed architecture supports the dynamic addition ofnew data plane switches and automatic establishment of thecontrol channel with them. We propose a novel tunnel estab-lishment procedure has two tasks. First, it authenticates andregisters new date plane switches. Second, it establishes IPsectunnels between the switch and SecGW.

The proposed tunnel establishment procedure has severalstrong security services. The tunnel establishment procedureis initiated by the potential switch. Initially, it mutually au-thenticates the switch and SecGW based on PKI mechanism.Then, the potential switch is authorized by the SEC entitybased on ACLs. Finally, both SecGW and OF switch establishSAs for a HIP tunnel and negotiate keys for traffic encryption.The proposed tunnel establishment procedure is presented inFigure 4 and it is based on existing HIP BEX [10]. We usethe same terminology which was used for original HIP BEXin [10].

Fig. 4: The Tunnel Establishment Procedure

The switch initiates the tunnel establishment procedure bysending an I1 message. It contains only HITs (Host IdentityTag) of OF switch and SecGW. To prevent DoS attacks,SecGW replies the I1 message with a pre-computed R1message without allocating any resources. The main compo-nents of the R1 message are the cryptographic puzzle, D-H(DiffieHellman) key parameters, the public key of SecGW,ESP transforms, HIP transforms, the echo request and thesignature. D-H key parameters are exchanged between twonodes to generate a common symmetric key to encrypt ESPpayload.

OF switch sends the I2 message after the arrival of the R1message. I2 message contains the solution of the cryptographicpuzzle, D-H key parameters, the public key of OF switch,SPIs (Security Parameter Indexes), ESP transforms, HIP trans-forms of OF switch, the echo reply, HMAC (Hash MessageAuthentication Code) and the signature. Upon the arrival ofI2 message, SecGW checks and verifies three fields namelyHMAC, the signature and the solutions of the puzzle. Thepuzzle verification is a quite simple since it is a single fasthashcomputation. If these fields are verified, SecGW has receiveda legitimate connection request from OF switch. Furthermore,SecGW has verified identity of OF switch.

Then, SecGW sends the switch’s credentials to SEC viaREQ message. It contains HI of OF switch, the authenticationrequest, the echo request. Upon the arrival of REQ, SECchecks the received HI against these ACLs and replies REQmessage with an ACK message. The ACK message containsHI of the switch, the acknowledgment and the echo reply.A positive acknowledgment is sent for a request from anauthorized OF switch and a negative acknowledgment issent for other requests. If it is negative acknowledgment,

SecGW drops the connection request of OF switch. Otherwise,SecGW completes the tunnel establishment by sending the R2message.

IV. I MPLEMENTATION AND NUMERICAL RESULTS

We implement the proposed secure channel architecture andperform several experiments. We measure the performance ofthe proposed secure channel architecture against OF protocol[6] and analyze the protection against common IP basedattacks such as TCP SYN DoS and TCP reset attacks. Figure5 illustrates the setup of the experiment testbed.

Fig. 5: The layout of the experimental testbed

We use three laptops and one Ethernet hub in the testbed. Alaptop with an i5-3210M CPU of 2.5GHz is used as the SDNswitch. A OpenVSwitch version 1.10.0 [11] is installed in thislaptop. Two virtual hosts (Host1 and Host2) are connected viaOpenVSwitch and they run Lubuntu 13.10 Operating System(OS). The second laptop with a L2400 CPU of 1.66GHz worksas the SDN controller. The latest POX controller is installedin the second laptop. Both switch and controller laptops haveUbuntu 12.04 LTS OS. These laptops are connected via D-LINK DSR-250N router. In this experiment, it runs as asimple Ethernet hub. The attacker is connected to the hub. Theattacker laptop also has a L2400 CPU of 1.66GHz and Ubuntu12.04 LTS OS. Finally, we use OpenHIP implementation [12]to implement SecGW and LSA at corresponding laptops.

Here, the POX controller controls OpenVSwitch via Open-Flow version 1.1.0. Furthermore, the OpenFlow version 1.1.0uses TLSv1 to secure the control channel and we use it as ourreference channel.

A. Performance Analysis

1) Connection Establishment Delay:In the first exper-iment, the connection establishment delay between Open-Vswith and the POX controller is measured under differentscenarios. Here, we send a ping request from Host1 to Host2and measure the connection establishment delay.

The experiment results (Figure 6) reveal that the proposedsecure architecture increases the tunnel establishment delay.The extra HIP tunnel establishment between LSA and SecGWincreases the tunnel establishment delay. However, the impactof HIP tunnel establishment delay can be minimized bykeeping the established HIP tunnels for a long period.

0 5 10 15 20 25 30 35 40 45 500

20

40

60

80

100

120

140

160

180

200

Number of the Attempt

Rou

nd T

rip T

ime

(ms)

Without Secure Channel (Only TLSv1)With Secure Channel (TLSv1 + HIP)Without Secure Channel (Average)With Secure Channel (Average)

Fig. 6: The connection establishment delay

2) Flow Table Update Delay:In the second experiment, theflow table update delay for a new packet flow is measured inthe steady state of operation. The HIP tunnel between LSA andSecGW is already established in the steady state of operation.Here, we send a ping request from Host1 to Host2 and measureRound Trip Time (RTT).

0 5 10 15 20 25 30 35 40 45 500

5

10

15

20

25

30

35

40

45

50

Number of the Attempt

Rou

nd T

rip T

ime

(ms)

Without Secure Channel (Only TLSv1)With Secure Channel (TLSv1 + HIP)Without Secure Channel (Average)With Secure Channel (Average)

Fig. 7: Flow Table Update Delay

The experiment results (Figure 7) reveals that the perfor-mance penalty of the proposed secure architecture is lesssignificant in the steady state of operation. The extra IPsecencryption increases the flow update delay only by 2.7% (1.07ms). However, this delay can be further minimized by usingIPsec accelerators. High speed IPsec encryption is possible byusing external accelerators and/or using new AES (AdvancedEncryption Standard) instruction sets for processors [13].

B. Protection from IP Based Attacks

1) Impact of TCP SYN DoS Attack:In the third experiment,we attach an external attacker to the hub and he performsTCP SYN flooding attack on the POX controller. The attacker(TCP packet generator) sends TCP SYN packets by changingthe port number and the source IP address (One change perpacket). The controller allocates one port for every success-fully arrived SYN packet. Likewise, the attacker occupies allthe ports (64000 per user) and IP address combinations [14].

Here, we send a ping request from Host1 to Host2 andmeasure the connection establishment delay. The attack is

placed between connection establishment request attempts10to 40. Each experiment runs for 10 times and only averagesare presented in Figure 8.

0 5 10 15 20 25 30 35 40 45 500

15

30

45

60

75

90

105

120

135

150

Number of the Attempt

Con

nect

ion

Est

ablis

hmen

t Del

a (m

s)

Without Secure ChannelWith Secure Channel

Duration of TCP SYN DoS Attack

Fig. 8: Impact of TCP SYN DoS attack

The experiment results (Figure 8) reveals that the proposedarchitecture protects the control channel from TCP SYN DoSattack. However, TLSv1 based OF protocol is vulnerableto TCP SYN DoS attack. It is not possible to establish aconnection between OpenVSwitch and the POX controllerduring TCP SYN DoS attack.

2) Impact of TCP Reset Attack:In the fourth experiment,we attach an external attacker to the hub and he performsTCP reset attack on both the POX controller and the switch.The attacker sends fake TCP packets to both ends to reset theconnection between them. However, the attacker must includecorrect IP addresses, port numbers and a valid sequence num-ber in the fake packet header. Thus, the attacker eavesdropsthe ongoing data and uses the eavesdropped information togenerate convincing fake TCP packets [15].

Here, we a ping request from Host1 to Host2 and measureRTT. In this experiment, the attack is placed between pingattempt 10 to 40. Each experiment runs for 10 times and onlyaverages are presented in Figure 9.

0 5 10 15 20 25 30 35 40 45 500

5

10

15

20

25

30

35

40

45

50

Number of the Attempt

Rou

nd T

rip T

ime

(ms)

Without Secure Channel (Only TLSv1)With Secure Channel (TLSv1 + HIP)

Duration of TCP Reset Attack

Fig. 9: Impact of TCP Reset attack

The experiment results (Figure 9) reveal that the proposedarchitecture protects the control channel from TCP reset attack.However, TLSv1 based OpenFlow protocol is vulnerable toTCP reset attack. It is not possible to update the flow tables

since the attacker always able to terminates the connectionbetween OpenVSwitch and the POX controller by using TCPreset attack.

V. D ISCUSSION

A. Security Analysis

In this section, we analyze the protection of proposedarchitecture against various IP based attacks.

1) Protection against DoS Attacks:In a DoS attack sce-nario, the attacker sends an extensive amount of connectionrequests. If attackers send a series of I1 packets (Figure 4)to perform a DOS attack, SecGW replies with a precomputedR1 packet for each I1 without allocating any resources such asmemory space and server port. Moreover, each R1 contains aprecomputed puzzle and it increases the commitment require-ment of the attacker. SecGW allocates the resources only afterthe arrival of correct solution in I2 message. Therefore, boththe controller and switch are protected from DoS attacks.

2) Protection against Replay Attacks:Replay attacks arepossible at both connection establishment and flow tableupdate phases. Here, the attacker resends the captured packetsto jeopardize the ongoing communication sessions.

The proposed architecture uses the following mechanismsagainst replay attacks during the connection establishmentphase. Virtue of the stateless response to I1 messages with pre-calculated R1 messages is used to protect responders againstattacker’s replays of I1 messages. A monotonically increasing“R1 generation counter” which is included in R1, is used toprotect the initiator from R1 replays. Again, responders areprotected against attacker’s replays of I2 messages by usingthe puzzle mechanism and optional use of opaque data. Finally,a monotonically increasing “R2 generation counter” is usedtoprotect the initiator from R2 replays.

IPsec ESP mode for the data communication is used flowtable update phases. IPsec ESP mode utilizes sequence num-bers to protect the messages against the replay attacks. Thus,the attacker’s replays of an IPSec encrypted packet will berejected due to sequence number mismatches at end users.

3) Protection against IP Spoofing Attacks:The preliminarymethod of preventing IP spoofing attacks is to stop theunauthorized access to the backhaul network. The proposedarchitecture uses strong user authentication mechanisms basedon public key authentication. Proposed mutual authenticationmechanism uses Host Identity (A cryptographic key) to provethe identity of the node. Thus, mutual authentication mecha-nism is capable to verifying the identity of the entity behindthe IP address and it prevents IP spoofing attacks.

4) Protection against Eavesdropping Attacks:Attackerseavesdrop the ongoing communication channels and use thegathered information to perform various attacks such as IPspoofing, TCP reset and replay attacks. However, proposedarchitecture uses HIP tunnels (IPsec BEET) in ESP mode forthe data communication. Thus, the original IP headers, TCPheaders and payload are always encrypted. It prevents possibleeavesdropping attacks.

B. Benefits of proposed architecture

1) SecGW (Security Gateway):The present LTE archi-tectures highly utilize SecGWs in different sections of thetransport network [16]. The utilization of SecGWs in SDMNcontrol channel provides various advantages. First, the controlchannel security mechanism is independent of the controller. Itallows upgrading or changing the security mechanism withoutchanging the controller and vice versa. Second, the controllermust use security specific hardware such as firewalls, IPsecaccelerators, IDS to support high speed security functions.However, the integration of such hardware to the controllerincreases the complexity and cost of the controller. Theproposed architecture separates the security functions form thecontroller. It is allowed to develop low cost controllers andhigh performing security devices.

2) Distributed SecGW:There are three main reasons toutilize a distributed SecGW mechanism. First, it avoids thesingle point of failure. Second, the distributed SecGWs splitthe control plane in to different independent slices. Thedifferent OF switches in backhaul network face a different setof security threats and they require different types of securitymechanism. By separating the control plane, it is possible toimplement extra security mechanisms for such highly vulner-able devices such as gateway switches to the Internet. Third,the security related functions use higher processing powerthanother network application. The distributed security mechanismdistributes the security workload among SecGWs.

3) SEC Entity (Security Entity):The use of a separatesecurity entity is highly recommended for the SDMN archi-tecture. First, it reduces the security related overhead onothercontrol entities in the controller. Second, it logically centralizesthe security mechanisms. Thus, SEC entity can optimizethe security functions. Third, the security is independentofother controlling entities in the SDMN. Thus, the securitymechanism can be upgraded without changing the operationof other entities and vice versa.

C. Limitations of proposed architecture

The proposed architecture is not able to prevent volumebased DoS attacks such as UDP (User Datagram Protocol)floods, ICMP (Internet Control Message Protocol) floods andother spoofed-packet floods. In volume based DoS attacks, theattackers send excessive amount of junk traffic to overloadthe network bandwidth. Volume based DoS attacks can beprevented by implementing firewalls, ingress filtering andenforcing rate bounds [17]. Thus, we recommend to implementthem in the control channel.

VI. CONCLUSION

We studied new security challenge of the control channelof SDMNs and the applicability IPsec tunneling and securitygateways technologies to secure it. Then, we proposed novelsecure control channel architecture based on IPsec tunnelsandsecurity gateways. The proposed architecture provides variousadvantages such as reducing the security related overhead onthe controller and control entities, solving the single point

of failure issue of the controller, increasing the flexibilityof security mechanism, enhanced authentication mechanism,encrypted control traffic delivery and protecting the controlchannel from IP based attacks.

Moreover, we analyze the security and the performance ofproposed architecture in a testbed. The experiments revealthat proposed architecture protects the control channel againstvarious IP based attacks such as DoS, reset, spoofing, replayand eavesdropping attacks. However, there is a performancepenalty of security due to extra the IPsec tunnel establishment.This drawback can be minimized by using security specifichardware and keeping the established tunnels for a longerperiod. In future, we will focus on securing the data planeof SDMNs by using IPsec tunneling and security gatewaytechnologies.

ACKNOWLEDGMENT

This work has been performed in the framework of theCELTIC CP2012 project SIGMONA.

REFERENCES

[1] C. Kolias, S. Ahlawat, C. Ashtonet al., “OpenFlow-Enabled Mobileand Wireless Networks,”White Paper, Open Network Foundation,September 2013.

[2] D. Kreutz, F. Ramos, and P. Verissimo, “Towards secure and depend-able software-defined networks,” inProceedings of the second ACMSIGCOMM workshop on Hot topics in software defined networking.ACM, 2013, pp. 55–60.

[3] S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, and M. Tyson,“Fresco: Modular composable security services for software-definednetworks,” Internet Society NDSS, 2013.

[4] S. Gutz, A. Story, C. Schlesinger, and N. Foster, “Splendid isolation: Aslice abstraction for software-defined networks,” inProceedings of thefirst workshop on Hot topics in software defined networks. ACM, 2012,pp. 79–84.

[5] G. Yao, J. Bi, and P. Xiao, “Source address validation solution withOpenFlow/NOX architecture,” inProceedings of 19th IEEE Interna-tional Conference on Network Protocols (ICNP), 2011. IEEE, 2011,pp. 7–12.

[6] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,J. Rexford, S. Shenker, and J. Turner, “OpenFlow: enabling innovation incampus networks,”ACM SIGCOMM Computer Communication Review,vol. 38, no. 2, pp. 69–74, 2008.

[7] S. Namal, I. Ahmad, A. Gurtov, and M. Ylianttila, “Enabling securemobility with openflow,” in Proceedings of IEEE SDN for FutureNetworks and Services (SDN4FNS), 2013. IEEE, 2013, pp. 1–5.

[8] “Worldwide Infrastructure Security Report (WISR) 2012,” Survey Re-port, Arbor Networks, 2013.

[9] C. Meyer and J. Schwenk, “Lessons Learned From Previous SSL/TLSAttacks-A Brief Chronology Of Attacks And Weaknesses,”IACR Cryp-tology ePrint Archive, vol. 2013, p. 49, 2013.

[10] A. Gurtov, Host Identity Protocol (HIP): Towards the Secure MobileInternet. Wiley, 2008.

[11] “Open vSwitch: An Open Virtual Switch,” http://openvswitch.org/.[12] “The OpenHIP project,” http://www.openhip.org/.[13] “Carrier Cloud Telecoms - Exploring the Challenges of Deploying

Virtualisation and SDN in Telecom Networks,” Intel Cooperation, Tech.Rep., 2013.

[14] W. Eddy, “TCP SYN flooding attacks and common mitigations,” RFC4987, 2007.

[15] P. A. Watson, “Slipping in the Window: TCP Reset attacks,” Tech. Rep.,2004.

[16] M. Liyanage and A. Gurtov, “Secured VPN Models for LTE Back-haul Networks,” in Proc. of 76th Vehicular Technology Conference(VTC2012-Fall). IEEE, 2012.

[17] R. K. Chang, “Defending against flooding-based distributed denial-of-service attacks: A tutorial,”Communications Magazine, IEEE, vol. 40,no. 10, pp. 42–51, 2002.