Security for Future Software Defined Mobile Networks

Security for Future Software Defined Mobile Networks Madhusanka Liyanage∗, Ijaz Ahmad, Mika Ylianttila University of Oulu, Oulu, Finland

Jesus Llorente Santos, Raimo Kantola Aalto University, Espoo, Finland

Oscar Lopez Perez, Mikel Uriarte Itzazelaia Nextel S.A., Zamudio, Spain

Edgardo Montes de Oca Montimage, Paris, France

Asier Valtierra Innovalia Association, Bilbao, Spain

Carlos Jimenez Eneo Technologia S.L, Bilbao, Spain

Abstract—5G constitutes the next revolution in mobile communications. It is expected to deliver ultra-fast, ultra-reliable network access supporting a massive increase of data traffic and connected nodes. Different technologies are emerging to address the requirements of future mobile networks, such as Software Defined Networking (SDN), Network Function Virtualization (NFV) and cloud computing concepts. In this paper, we introduce the security challenges these new technologies are facing, inherent to the new telecommunication paradigm. We also present a multitier approach to secure Software Defined Mobile Network (SDMN) by tackling security at different levels to protect the network itself and its users. First, we secure the communication channels between network elements by leveraging Host Identity Protocol (HIP) and IPSec tunnelling. Then, we restrict the unwanted access to the mobile backhaul network with policy based communications. It also protects the backhaul devices from source address spoofing and Denial of Service (DoS) attacks. Finally, we leverage Software Defined Monitoring (SDM) and data collection to detect, prevent and react to security threats.

introduction of centralized controllers, programmability, NFV, the separation of the control and data planes, the introduction of new network functions and even the introduction of new stakeholders such as Mobile Virtual network Operators (MVNO) will all have impact on how security needs to be assured and managed in future telecommunication networks.

Index Terms—SDN, NFV, Security, Mobile Networks, Monitoring

The proposed security architecture presents a multitier approach to tackle security at different levels by protecting the network itself and its users. First, we secure the communication channels between network elements by leveraging Host Identity Protocol (HIP) and IPSec tunnelling. Then, we restrict the unwanted access to the backhual network with policy based communications. It also protects the network from source address spoofing and DoS attacks. We leverage Software Defined Monitoring (SDM) and data collection to detect security threats and react to them. We also synchronize network security with the network traffic management to reduce the performance penalty due to the proposed architecture. Finally, we implement the components of proposed architecture in a testbed and analyze the performance under different scenarios.

I. I NTRODUCTION The evolution of mobile telecommunication networks is accompanied by new demands for the performance, portability, elasticity and energy efficiency of network functions. Software Defined Mobile Network (SDMN) architecture integrates Software Defined Networking (SDN), Network Function Virtualization (NFV) and cloud computing principles to telecommunication networks. The target of SDMN architecture is to innovate and develop new network concepts for meeting the future requirements of the evolving mobile networks. SDN aims at decoupling the network control and data planes. The network control and intelligence of SDNs are logically centralized and the underlying network infrastructure is abstracted from the control functions. NFV offers a new way to design, deploy and manage networking services. NFV allows decoupling the network functions from proprietary hardware appliances, so that they can run in software. However, the *Corresponding author. Email: [email protected]

In this article, we discuss the usability of existing fault management and network security solutions of legacy telecommunication networks to protract SDMNs. Moreover, new opportunities, challenges and vulnerabilities of SDMNs are being investigated. Based on these findings, we present a novel security architecture for SDMNs. The proposed security architecture not only solves the security issues which are introduced by SDN, NFV and cloud computing concepts, but also solves the security limitation in legacy telecommunication networks.

This paper is organized as follows; Section II describes SDMN architecture, generalized SDMN security challenges and existing security solutions. Section III presents the proposed security architecture. Section IV contains the testbed implementation and experiment results. Section V contains the discussion. Finally, Section VI concludes article and presents future research directions.

II. BACKGROUND A. SDMN Architecture SDMN architecture combines the concepts of SDN, NFV and cloud computing to design a programmable, flexible and flow centric mobile network. It offers various benefits such as centralized controlling, improved flexibility, efficient segmentation, automatic network management, granular network control, reduction of operational and equipment cost of backhaul devices, on-demand provision and resource scaling [1]. Therefore, SDMN is considered as the latest innovation in the telecommunication domain [2] [3]. Figure 1 illustrates the consolidated SDMN architecture.

TABLE I: Summery of security threats in SDMN architecture SDMN Layer

Application

Type of Threat

Threat Reason and Description

Lack of authentication and authorization Fraudulent rules insertion

Possible huge number of (third-party) apps Malicious applications generated false flow rules Lack of binding mechanisms for apps

Access control and accountability

Control

DoS, DDoS attack, Controller hijacking or compromise Unauthorized controller access Scalability or availability

Data

Fraudulent flow rules Flooding attacks Controller and DP switch masquerading

Ctrl-Data Int

TCP-Level attacks Man-in-the middle attack

App-Ctrl Int.

Illegal controller access, policy manipulation and fraudulent rule insertion

Visible nature of Ctrl-plane

No compelling mechanisms for enforcing access ctrl on backhaul devices. Centralized intelligence Lack of intelligence Limited capacity of flow tables. Lack of strong authentication TLS is susceptible to TCP level attacks. Optional use of TLS and complexity in configuration of TLS Limited secure APIs, lack of binding mechanisms b/w Apps and controller.

Fig. 1: The consolidated SDMN architecture In SDMNs, the legacy mobile network control functions, i.e., MME (Mobility Management Entity), HSS (Home Subscriber Server), PCRF (Policy and Charging Rules Function) and the control planes of S/P-GW (Serving/Packet Gateway) run on the mobile network cloud as SDN applications and enforce the desired function by means of SDN technology. With this approach, the user plane is composed only by strategically located SDN capable switches and devices [4]. B. Security Threats in SDMN The separation of the planes, aggregating the control functionality to a centralized system and running the control functions in a cloud open up new security challenges in SDMNs. For instance, the communication channels between the isolated planes can be targeted to masquerade one plane for attacking the other. The control plane is more vulnerable to security attacks, especially to DoS and DDoS (Distributed DoS) attacks, because of its visible eventually centralized nature and can become a single point of failure. Since the networking paradigm in SDMN is converging towards software-based networking, operational malfunctioning or malicious software can compromise the whole network by providing access to the control plane [5]. Some of the known security challenges in SDMN are summarized in Table I. C. Related Work Nonetheless, with the logically centralized control plane, SDN can also enhance network security by enabling global visibility of the network state where a conflict can be easily

resolved from a centralized monitoring device. The logically centralized architecture supports highly reactive security monitoring, analysis and response systems to facilitate network forensics, security policy alteration and security service insertion [6]. For network forensics, SDN facilitates quick and adaptive threat identification through a cycle of harvesting intelligence from the network to analyse network security, update security policies and reprogram the network accordingly. Henceforth, the benefits of centralized control for secure cloud computing are presented in [7] while the ease of deploying new security services is demonstrated in [8] that implements MPLS (Multiprotocol Label Switching) VPNs (Virtual Private Networks) in OpenFlow networks. Similarly, the use of SDN for improving anomaly detection systems in small and home networks is demonstrated in [24]. OpenSafe [25] using ALARMS (A Language for Arbitrary Route Management for Security) to manage the routing of traffic through network monitoring devices is an example of economical deployment of security monitoring systems in SDN. Software-defIned Middlebox PoLicy Enforcement (SIMPLE) [26] is another example of deploying security middle-boxes without requiring modifications in middle-boxes or the SDN architecture. Table II contains the proposed security mechanism for general SDN networks. The above security solutions are proposed to secure the general SDN networks. However, the nature of telecommunication networks is significantly different from general communication networks since they offer high availability and security, carrier grade services for users, contain many

TABLE II: Proposed Security Mechanism for General SDN Networks Security Type

Reference

SDN Layer/Interface

Threat detection and mitigation

[9]

Ctrl, App-Ctrl

App debugging, flow rules inspection

[10]

App, Data

Flow rules verification, Configuration verification

[11] [12]

Ctrl, Data

Flow policy verification, catch bugs in OF programs

[13]

App, Ctrl

App testing and debugging

[14]

App

Conflict resolution, authorization, security audit system

[15]

Ctrl, Data, AppCtrl

DDoS detection, Controller resilience

[16] [17]

Ctrl, Data

Link monitoring

[18]

Data, Ctrl Data

Find contradictions in flow rules, authorize applications

[19]

Ctrl, Data

Controller availability, network monitoring

[20] [21]

Ctrl, Ctrl Data

Access control and dynamic policy enforcement

[22] [23]

Ctrl, Data

control elements, support seamless and high speed mobility, tunnel based communication and support multiple access technologies [27] [28]. Therefore, SDMN requires special security mechanisms which can support the telecom-specific requirements. The SIGMONA project [29] considers these telecom specific requirements and proposes a consolidated security architecture for SDMN networks [30]. This paper presents the proposed SIGMONA security architecture. III. P ROPOSED S ECURITY A RCHITECTURE Most of the telecom-specific requirements are tightly coupled with control and data planes than the application plane [1] [4]. At the first stage, the proposed security architecture is focused on securing the security issues related to the control plane, data plane and Ctrl-Data interface only. The proposed security architecture for SDMN networks is presented in Figure 2.

approach with four components. 1) Secure Communication (SC) Component, 2) Policy Based Communication (PBC) Component, 3) Security Management and Monitoring (SMM) Component and 4) Synchronized Network Security and Traffic (Synch) Component. A. Secure Communication (SC) Component The SDMN architecture has two communication channels, i.e. control and data channels. The control channel transports the vital control/signaling data between the control and data planes. The user communication data will be transported via the data channel. The key security issues of SDMN communication channels are the lack of IP level security and lack strong authentication between backhaul devices (See Table I). Existing SDMN communication channels rely on higher layer security mechanisms such as TLS/SSL based communication. For instance, widely used OpenFlow protocol utilizes a TLS/SSL based control channel [31]. However, higher layer security mechanisms do not protect the IP level information. As a result, communication sessions are vulnerable to IP based attacks such as IP spoofing, TCP SYN DoS and TCP reset attacks [32] [6] [33]. Moreover, TLS/SSL authentication mechanism is vulnerable to IP spoofing and Compression Ratio Info-leak Made Easy (CRIME) attacks [6]. Therefore, SDMN architecture requires secure communication mechanisms to prevent these security threats. We propose a HIP (Host Identity Protocol) based secure IPsec tunnelling architecture to secure SDMN communication channels [33]. It establishes secure HIP tunnels between the DP (Data Plane) switches and the controller. The secure HIP tunnel establishment under the proposed SC component is illustrated in Figure 3.

Fig. 3: Secure Communication Channel

Fig. 2: The Proposed Security Architecture for SDMN The proposed security architecture is a multitier security

We proposed three main changes to the existing SDMN architecture. First, distributed SecGWs (Security Gateways) are utilized to secure the controller from outside network and solve the single point of failure. Second, new Security Entity (SecE) is added to control SecGWs and other security functions in SDMN. Third, local Security Agent (LSA) application is installed in each data plane switch to handle security related

functions in the switch. The proposed solution is a bumpin-the-wire mechanism and it will not change the underline control protocol (e.g. Openflow) or user plane communication channels. Table III contains a features comparison of proposed SC component with other security solutions. TABLE III: Comparison of proposed architecture with existing security mechanisms Property

TLS/SSL

IPSec with IKEv2

IPSec with HIP

Proposed Architecture

Vulnerability of mutual authentication mechanism

Medium

Medium Low

Low

DoS attack prevention

No

No

Yes

Yes

Support for seamless mobility of backhaul nodes

No

No

Yes

Yes

Multihomed Support

No

No

Yes

Yes

Centralized Controlling

No

No

No

Yes

Point-to-Multipoint/ Multipoint-to-Multipoint

No

No

No

Yes

Visibility of traffic transportation

No

No

No

Yes

Access Control

No

No

No

Yes

Collaboration with other control entities

No

No

No

Yes

links not exposed to the public Internet for increased security. CES is particularly interesting as it contributes to enhancing the user experience of mobile users mainly in compatibility, CPU consumption and energy saving: a) it is compatible with current protocols and applications; b) does not require explicit signalling to maintain network connections; c) users can make use of a network firewall in the cloud instead of directly in the mobile. We propose CES to introduce policy based communications in the SDMN framework. The CES function runs as an SDN application on top of the SDN controller. CES can retrieve user certificates and policies from different network nodes, such as HSS or PCRF/PCEF. The CES function interacts with the gateway datapath to insert the negotiated flows via the Customer Edge Traversal Protocol (CETP), thus granting user communication end to end. The proposed PBC component is illustrated in Figure 4

B. Policy Based Communication (PBC) Component The current Internet allows any host to send packets to any destination address, which enables malicious hosts to launch DoS attacks against other users. In addition, the possibility of source address spoofing makes it difficult to prevent such attacks and successfully trace the attack back to the originator. Furthermore, the network does its best to deliver packets to their destination, regardless of the interest of the receiver. Therefore, unwanted traffic occurs when the interest of the sender and the receiver are not well aligned [16] [17]. SDMN architecture proposes all-IP based open network architecture which is similar to other IP networks such as Internet [4]. As a result, SDMN backhual network is also vulnerable to above DoS and source address spoofing attacks [5] [34]. Cooperation has been proven as an effective mechanism to curb antisocial behavior in society [35]. We call Best-Effort Communications (BEC) the principle by which a network equally meets the needs of both sender and receiver. Similar principle can be used to mitigate DoS and source address spoofing attacks on SDMNs. Customer Edge Switching (CES) is a disruptive approach to enable policy based communications to mobile nodes. CES enhances traditional firewall mechanisms via cooperative mechanisms to detect and counteract the effect of abusive hosts, denial of service and source address spoofing. CES nodes act as security brokers, aligning the interest of senders and receivers, in order to establish more secure communication between end hosts. These policies include the verification of the sender credentials, from basic reverse DNS (Domain Name Server) lookup to more complex certificate validation, as well as the possibility of utilizing private transit

Fig. 4: SDN oriented Customer Edge Switching Moreover, the communication with legacy networks is handled by Realm Gateway (RGW), which relies heavily in domain name resolution to grant connectivity. To this regard, we have implemented a number of mechanisms to strengthen the security of the model. Dynamic Service Level Agreement (SLA) and DNS server classifications (white/grey/black lists). DNS resolutions over TCP for trusted DNS servers. An address allocation algorithm is controlled by policy to limit the resources to a certain host, DNS server or a given network. In addition, the development of a new naming scheme to include the intended service contributes not only to security but also to dramatically increase the efficiency of the whole system. The PBC component also includes TCP-Splicing mechanisms to relay user data from guaranteed non spoofed hosts. TCP connection setup is challenged with a cookie, which postpones the allocation of a connection until the response is received. A bot detection scheme helps detect malicious hosts and mitigate DDoS attacks and connection hijacking attempts to the temporarily allocated connections in RGW. The proposed policy based communication Component has several benefits. It constitutes a disruptive approach to the traditional connection establishment by leveraging standard DNS requests as a negotiation trigger. The proposed component can be deployed transparently to end users without changing hosts,

protocols or applications. It also eliminates the utilization of burdensome NAT (Network Address Translation) Traversal mechanisms. With SDN centralized operations, there is more information available that benefits local decision making of the heuristic algorithms. Blocking unwanted traffic from entering the network contributes to a more secure environment, serving as an additional security barrier in a multi-tier approach. C. Security Management and Monitoring (SMM) Component Both in legacy networks as in SDN networks there is a clear need for security monitoring. IT (Information Technology) is challenged with ensuring the health of expanding infrastructures and proper capacity planning. Any degradation of services or downtime can have monumental impact on revenue and quality of experience for end users and customers. As a result there is still a need in SDN environments that security teams will have to handle to align with the business needs and expectations, by means of analyzing data, identifying sources of anomalies, providing reports, and taking feedback to improve. Security information and event management (SIEM) technologies need to be adapted to new SDN environments and will provide on one hand Security information management (SIM), and on the other hand Security event management (SEM) Additionally, there is a large list of threats (See Table I) that SDNs may suffer and tools that will provide visibility and awareness about security measures implemented in SDNs will be an increasing need in the near future. Controls to verify that security measures implemented in SDN, NFV and cloud environments are running as expected could be modeled using the operational security assurance concept [36]. The proposed SMM component focuses on SIEM techniques and an Operational Security Assurance (OSA) monitoring implementation [36]. It enables the possibility to scale and integrate monitoring functions in SDN and virtual environments, deploying virtual sensors. The deployed sensors will retrieve information regarding security monitoring tasks performed throughout the network, concerning, e.g., the availability of monitoring resources, network performance monitoring and traffic mirroring. Virtualized network switches controlled by a centralized software based controller will redirect packets and enable packet forwarding to be analysed by IDS (Intrusion Detection Systems) tools in the sensor side. Moreover, the information collected from each sensor will be consolidated and presented by a security monitoring Graphical User Interface (GUI) in the management server side. Mitigation actions and reactions to anomalous traffic or threats that could affect the network, could be managed from the SMM, taking as input security events, and acting accordingly to reconfigure SDN controller, using REST (REpresentational State Transfer) API (Application Programmable Interface) communication to inject a new flow that drops, isolates or redirects network traffic, providing automated mitigation actions. Different architectural possibilities are studied and proposed in the SIGMONA [29] project where an extension of Open-

Fig. 5: Security Management and Monitoring Component

Flow type interface, SDM-CTRL interface (referred to as SDM CTRL INTERFACE in Figure 5). It allows obtaining the packet and flow data and meta-data needed by the security applications (e.g. the modules referred to as Management / Monitoring / Security, Applications and Network Services) from either the switches or the probes (i.e. agents). On the other hand, the Software Defined Monitoring (SDM) paradigm can refer to very different aspects or levels. For instance, authors present how software can control the hardware resources (e.g. FPGA) for specific monitoring tasks in [37]. The proposed SMM component is responsible for network management, defining SDM concepts for managing the monitoring of networks in order to assess and improve their overall security and performance. Security management and monitoring component proposes to add new modules and interfaces. Figure 5 illustrates the placement of these modules. First, security sensor modules are used as an active or passive monitoring probe for the detection of security and behaviour related information (e.g., security properties and attacks) and mitigation (e.g., filtering). It can be installed on the network elements or in network taps (passive network observation points). Second, SDM CTRL module is a new module or extension of SDN CTRL to allow control of monitoring function (e.g., management of network monitoring appliances, traffic mirroring, traffic load balancing and aggregation); accepts requests from network functions and applications). They interact with the management/monitoring/security functions and act as distributed analysis or decision points for the defined security policies. SDM CTRL INTERFACE is an interface that allows controlling the use of monitoring resources, recuperating traffic or metadata for analysis. It allows performing monitoring requests and obtaining status, so that applications and network functions can send requests for monitoring based information, and monitoring functions can send status and recommendations. Finally, the network

monitoring function is implemented as a virtualization of monitoring function, so that the traffic analysis can be moved to the cloud. The architecture of the devices and controllers can be hierarchically organised or distributed (e.g., with peerto-peer communications between the controllers). D. Synchronized Network Security and Traffic (Synch) Component Network security is an integral part of the network management. SDMN requires a stable and robust security policy deployment. However, a global analysis of policy configuration of all the networked elements is required to avoid conflicts and inconsistency in the security procedures and hence diminish the chances of serious security breaches and network vulnerabilities. As a security concern, a small oversight can lead to a global security problem, such as placing a significant functionality on an unreliable system. In SDMNs, since a logically centralized controller is responsible for controlling and managing the whole network, security lapses compromising the controller definitely affect traffic in the data plane. Therefore, we propose the realization of synchronized network security and traffic forwarding policies. This is achieved by leveraging from the visibility of the network state in the controller; cooperation between traffic management and forwarding policies establishing 3GPP entities and security monitoring devices in the operator cloud; and with the help of the synchronizing entity (Synch) as shown in Figure 2. The Synch module mediates between security monitoring and security management device; as well as between traffic monitoring and management devices to deploy forwarding rules in the data plane which are based on security polices defined in higher layers.

Fig. 6: Synchronized Network Security and Traffic Component As shown in Figure 6, traffic monitoring and security monitoring entities provide real-time information for the Synch module. The traffic monitoring entity maintains a track of changes in flow rules that could occur for example due to mobility. The security monitoring entity checks the previous security techniques that are used for that particular user. If the traffic from that user was previously directed to a DPI (Deep Packet Inspection) system, the security monitoring entity will

inform the Synch module. Henceforth, the Synch module would redirect the traffic from the same user to a DPI system that was used for his previous traffic. In this fashion, the mobility of a node does not hinder in keeping security of the system intact. Similarly if a user had been behind a firewall, he will still be behind a firewall if he changes the point of attachment to the network. IV. T ESTBED I MPLEMENTATIONS AND R ESULTS The components of proposed architecture were implemented in testbeds to analyze their performance. In the first set of experiments, we measured the performance penalty of secure communication component on throughput, jitter and latency. Also, we measured the ability of proposed architecture to protect the communication channels against common IP based attacks such as TCP SYN DoS and TCP reset attacks. The widely utilized OF protocol [38] with TLS/SSL session is used as the reference for control channel. The preliminary testbed components are illustrated in Figure 7.

Fig. 7: The layout of the experimental testbed The preliminary testbed contains two DP switches, an SDN controller and two hubs. The latest POX controller [39] is used as the SDN controller and OpenVswitch (OVS) version 1.10.0 [40] virtual switches are used as DP switches. We also connect two virtual hosts to each OVS. The controller and switches are connected by using two D-LINK DSR-250N routers. We keep out-band control channel for these experiments. The OpenHIP implementation [41] is used to model Security Gateway and LSAs. The IPERF network measurement tool [42] is used to measure the throughput and latency performance. Finally, we connect an attacker to each hub according to the experiment scenarios. A laptop with an i5-3210M CPU of 2.5GHz processor is used as the attacker. Data plane performance under each architecture is presented in table IV. Each experiment has been conducted for 500s and the average values were recorded. The experiment results (Table IV) indicate that proposed secure channel has decreased both TCP and UDP throughput by 2%. Also, it increases the latency by 3% than existing SDMN data channel. The extra layer of encryption is the main reason for the deficient performance of proposed secure channel. However, the performance deficient of encryption

TABLE IV: Data Channel Performance without Attack (Normal Operation)

TABLE VI: Control Channel Performance under TCP DoS Attack

Performance Metric

Existing SDMN Data Channel

Proposed Secure Data Channel

Performance Metric

OpenFlow With TLS/SSL

Proposed Secure Control Channel

TCP Throughput (Mbps)

93.5514

91.8054

135.4165

95.2845

92.3828

Connection Establishment Delay (ms)

58.3224

UDP Throughput (Mbps) Latency (ms)

36.6514

37.6452

−

135.9145

Jitter (ms)

0.34522

0.4651

Connection Establishment Delay under TCP SYN DoS Attack (ms) Flow Table Update Delay (ms)

30.85645

32.1573

Flow Table Update Delay under TCP Reset Attack (ms)

−

32.2472

can be minimized by using IPsec accelerators. Recent Intel processors support IPsec acceleration by using external accelerators and/or using new AES (Advanced Encryption Standard) instruction sets [43]. In the next experiment, we attached a TCP SYN DoS attacker to the data channel (Hub2). Each experiment run for 500s and the attack was performed between 100s - 200s time interval. The average performance of each architecture is presented in Table V. TABLE V: Data Channel Performance under TCP DoS Attack Performance Metric

Existing SDMN Data Channel

Proposed Secure Data Channel

TCP Throughput (Mbps)

72.1945

91.51564

UDP Throughput (Mbps)

74.4656

92.4551

Latency (ms)

548.14854

37.5146

Jitter (ms)

5.1495

0.4301

The experiment results (Table V) indicate that existing SDMN data channel is vulnerable to TCP DoS attacks. Both TCP and UDP throughput of existing SDMN data channel is dropped by 20%. The drop percentage is equivalent to portion of attack duration from total experiment duration. Therefore, it concludes that existing SDMN data channel has effected for the whole duration of DoS attack. Moreover, the latency and jitter of existing SDMN data channel have increased by 14 times than the normal operation. However, the proposed secure channel has similar performance as the normal operation. Thus, proposed secure channel is able to secure the SDMN data channel from DoS attacks. In the next experiment, we attached a TCP SYN DoS and Reset attacker to the control channel (Hub1). We measure dthe connection delay and flow table update delay between DP switch 1 and the controller. Each experiment run for 25 times and the average performance of each architecture is presented in Table VI. The experiment results (Table VI) indicate that the proposed secure channel has significantly increased the connection establishment delay. The extra HIP tunnel establishment between LSA and SecGW has added extra latency. On the other hand, proposed secure channel has increased flow table update delay only by 4% at steady state of operation (i.e. after the connection is established). The extra layer of encryption is the main reason for the deficient performance of the proposed secure channel.

The experiment results (Table VI) also indicate that existing SDMN control channel is vulnerable to TCP DoS and reset attacks. It is not possible to establish a connection with the controller during TCP SYN DoS attack and also not possible to update the flow tables during TCP Reset attack. However, the proposed secure channel has similar performance has no effect from those attacks. Thus, the proposed secure channel is able to secure the SDMN control channel from IP based attacks. In the second set of experiments, we measured the performance of policy based communication component. Here, we performed a set of experiments to measure the performance of the security algorithms devised for CES. The proposed CES component is implemented in Python. Here, we present numerical results related to the CETP connection establishment and the load reduction as a result of DNS server classification and tracking. The testbed comprises CES nodes with several private hosts connected to each one. The CES are connected via public links where we have also allocated some additional attacking hosts to test the algorithms. The architecture follows a control-plane/data-plane split that runs Python code, which affects the performance of the packet processing.

Fig. 8: Delay impact of CETP policy strengthening Figure 8 illustrates the result of using different CETP policies during the setup of 80 connections. The figure reveals how less restrictive policies enjoy a faster connection setup as they require less amount of verifications. Typically, a CETP connection establishment varies between 1-4 round trip times. However, most of this time is the result of slow control/data plane interaction, as the policy processing by CES

is carried out in a few milliseconds. The signaling procedure can be further improved with direct CES to CES control plane communications, then synchronize the negotiated connection to their respective data planes.

scalability in SDMN are highly inter-linked due to the centralized control plane. Hence, control-data plane intelligence trade-off and the dependencies between security architectures and traffic forwarding mechanisms need further investigation in order to minimize delays incurred in traffic forwarding due to varying and multi-purpose security architectures. Similarly, besides HIP, other identity-location separation architectures need to be investigated to enable mobility with security in future wireless networks. VI. C ONCLUSION

Fig. 9: Load reduction in RGW Figure 9 shows the load reduction in RGW to prevent the exhaustion of the address pool on event of DNS flooding attacks. The algorithms dynamically reduce the amount of resources available to grey-listed DNS servers that are not trustworthy to comply with the SLA defined for other trusted sources. This results in higher availability to legitimate hosts even under load conditions. The bot-detection algorithms defined also contribute to the server classification and service offered to them. V. D ISCUSSION The introduction of NFV and SDN technologies will change the dynamics of wireless networks in terms of cost, complexity, and efficiency. There are two theories in terms of security. First, the centralization of network control increases the chance of security lapses from the single point of failure in aspect. Second, SDN can enhance network security due to global visibility of the network state with centralized control. It is highly probable that new vulnerabilities will be introduced alongside the deployment of these technologies. In this paper, we have highlighted the possible security challenges faced by SDMN and presented the security solutions with their preliminary results. The concepts described in this paper secure communication between the separated planes with HIP-based IPSec tunnelling architecture. The security gateways proposed in the architecture hides controller from the outside world and hence mitigates the risks of DoS and DDoS attacks. The access to the network is granted via policy-based communications enforced at the network edges with Customer Edge Switching, which protects the network against inherent Internet vulnerabilities such as address spoofing and DoS attacks. Customer Edge Switching can limit the communication to only authorized hosts with the help of a tool that implements Anything-asa-Service delegations which is based on the policy control techniques. It can also enforce black lists whenever required. Furthermore, SIEM-based security management and real-time sensors-assisted OSA monitoring can enforce network-wide security. However, there are some grey areas in SDMN security which need further investigation. For example, security and

AND

F UTURE W ORKS

This paper investigated security challenges in SDMN to design novel security architectures. On one hand, SDMN concepts will enhance network security with global visibility of the network state, centralized control and softwarization of network functions. On the other hand, the same attributes introduce new vulnerabilities inherent to software, Internetbased systems, and the addition of new components. In this paper, we presented some advantages and disadvantages, the security threats, challenges and state of the art on implementing security in SDMN. We argue that it is very important to consider security, when relying in SDN and NFV concepts. The implementation of different security methods has been done using as example the architecture for SDMN. We have presented four components of proposed security architecture: (1) secure communication channels by proposing HIP to secure the control and data channels; (2) policy based communications to mitigate source address spoofing and denial of service attacks, enabling network communications between end hosts only if the policy negotiated between the edge nodes has been successful, effectively tackling unwanted traffic from entering the network; (3) security management and monitoring where on the one hand security mechanisms implemented should be monitored, and on the other hand security threats can be detected and isolated using DPI and traffic monitoring techniques; and finally (4) synchronized network security with the network traffic, where traffic monitoring and security monitoring will provide real time information for a synchronization module to deploy forwarding rules in the data plane based on security policies. We analyzed the applicability of these components in realworld testbeds. We demonstrated the possibility of proposed security architecture to prevent IP based attacks on SDMNs. However, the integration of these new systems with the existing production environments still has to be examined in detail. The next phase of this research will focus on analyzing these requirements and defining the guidelines for the integration of security components into the SDMN architecture. ACKNOWLEDGMENT This work has been performed in the framework of the CELTIC project CP2012 SIGMONA. R EFERENCES [1] K. Pentikousis, Y. Wang, and W. Hu, “Mobileflow: Toward softwaredefined mobile networks,” Communications Magazine, IEEE, vol. 51, no. 7, 2013.

[2] H. Hawilo, A. Shami, M. Mirahmadi, and R. Asal, “NFV: State of the Art, Challenges and Implementation in Next Generation Mobile Networks (vEPC),” arXiv preprint arXiv:1409.4149, 2014. [3] M. Liyanage, M. Ylianttila, and A. Gurtov, Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. Wiley, 2015. [4] J. Costa-Requena, V. F. Guasch, and et. al., “SDN and NFV Integration in Generalized Mobile Network Architecture,” in European Conference on Networks and Communications (EUCNC), Paris, France. IEEE, 2015. [5] A. Y. Ding, J. Crowcroft, S. Tarkoma, and H. Flinck, “Software defined networking for security enhancement in wireless mobile networks,” Computer Networks, vol. 66, pp. 94–101, 2014. [6] C. Meyer and J. Schwenk, “Lessons Learned From Previous SSL/TLS Attacks-A Brief Chronology Of Attacks And Weaknesses.” IACR Cryptology ePrint Archive, vol. 2013, p. 49, 2013. [7] F. Hao, T. Lakshman, S. Mukherjee, and H. Song, “Secure cloud computing with a virtualized network infrastructure.” USENIX Association, 2010. [8] A. R. Sharafat, S. Das, G. Parulkar, and N. McKeown, “Mpls-te and mpls vpns with openflow,” in ACM SIGCOMM Computer Communication Review, vol. 41, no. 4. ACM, 2011, pp. 452–453. [9] S. Shin, P. A. Porras, V. Yegneswaran, M. W. Fong, G. Gu, and M. Tyson, “FRESCO: Modular Composable Security Services for Software-Defined Networks.” in NDSS, 2013. [10] R. Beckett, X. K. Zou, S. Zhang, S. Malik, J. Rexford, and D. Walker, “An assertion language for debugging SDN applications,” in Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, ser. HotSDN, vol. 14, 2014, pp. 91–96. [11] A. Khurshid, W. Zhou, M. Caesar, and P. Godfrey, “Veriflow: verifying network-wide invariants in real time,” ACM SIGCOMM Computer Communication Review, vol. 42, no. 4, pp. 467–472, 2012. [12] E. Al-Shaer and S. Al-Haj, “FlowChecker: Configuration analysis and verification of federated OpenFlow infrastructures,” in Proceedings of the 3rd ACM workshop on Assurable and usable security configuration. ACM, 2010, pp. 37–44. [13] S. Son, S. Shin, V. Yegneswaran, P. Porras, and G. Gu, “Model checking invariant security properties in OpenFlow,” in Communications (ICC), 2013 IEEE International Conference on. IEEE, 2013, pp. 1974–1979. [14] M. Canini, D. Kostic, J. Rexford, and D. Venzano, “Automating the testing of OpenFlow applications,” in Proceedings of the 1st International Workshop on Rigorous Protocol Engineering (WRiPE), no. EPFLCONF-167777, 2011. [15] Security-enhanced floodlight. [Online]. Available: http://www. sdncentral.com/education/toward-secure-sdn-controllayer/,2013/10/ [16] R. Braga, E. Mota, and A. Passito, “Lightweight DDoS flooding attack detection using NOX/OpenFlow,” in Local Computer Networks (LCN), 2010 IEEE 35th Conference on. IEEE, 2010, pp. 408–415. [17] P. Fonseca, R. Bennesby, E. Mota, and A. Passito, “A replication component for resilient OpenFlow-based networking,” in Network Operations and Management Symposium (NOMS), 2012 IEEE. IEEE, 2012, pp. 933–939. [18] J. Kempf, E. Bellagamba, A. Kern, D. Jocha, A. Tak´acs, and P. Skoldstrom, “Scalable fault management for OpenFlow,” in Communications (ICC), 2012 IEEE International Conference on. IEEE, 2012, pp. 6606– 6610. [19] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu, “A security enforcement kernel for OpenFlow networks,” in Proceedings of the first workshop on Hot topics in software defined networks. ACM, 2012, pp. 121–126. [20] K. Phemius, M. Bouet, and J. Leguay, “Disco: Distributed multi-domain sdn controllers,” in Network Operations and Management Symposium (NOMS), 2014 IEEE. IEEE, 2014, pp. 1–4. [21] Y. Zhang, N. Beheshti, and M. Tatipamula, “On resilience of splitarchitecture networks,” in Global Telecommunications Conference (GLOBECOM 2011), 2011 IEEE. IEEE, 2011, pp. 1–6.

[22] A. K. Nayak, A. Reimers, N. Feamster, and R. Clark, “Resonance: dynamic access control for enterprise networks,” in Proceedings of the 1st ACM workshop on Research on enterprise networking. ACM, 2009, pp. 11–18. [23] H. Hu, W. Han, G.-J. Ahn, and Z. Zhao, “FLOWGUARD: building robust firewalls for software-defined networks,” in Proceedings of the third workshop on Hot topics in software defined networking. ACM, 2014, pp. 97–102. [24] S. A. Mehdi, J. Khalid, and S. A. Khayam, “Revisiting traffic anomaly detection using software defined networking,” in Recent Advances in Intrusion Detection. Springer, 2011, pp. 161–180. [25] J. R. Ballard, I. Rae, and A. Akella, “Extensible and scalable network monitoring using opensafe,” Proc. INM/WREN, 2010. [26] Z. A. Qazi, C.-C. Tu, L. Chiang, R. Miao, V. Sekar, and M. Yu, “SIMPLE-fying middlebox policy enforcement using SDN,” in ACM SIGCOMM Computer Communication Review, vol. 43, no. 4. ACM, 2013, pp. 27–38. [27] M. Liyanage and A. Gurtov, “Secured VPN Models for LTE Backhaul Networks,” in Vehicular Technology Conference (VTC Fall), 2012 IEEE. IEEE, 2012, pp. 1–5. [28] M. Liyanage, M. Ylianttila, and A. Gurtov, “A Case Study on Security Issues in LTE Backhaul and Core Networks,” Case Studies in Secure Computing: Achievements and Trends, p. 167, 2014. [29] SDN Concept in Generalized Mobile Network Architectures (SIGMONA) project. [Online]. Available: http://www.sigmona.org/ [30] J. Costa-Requena, J. L. Santos, V. F. Guasch, K. Ahokas, G. Premsankar, S. Luukkainen, I. Ahmed, M. Liyanage, M. Ylianttila, O. L. Prez, M. U. Itzazelaia, and E. M. de Oca, “SDN and NFV Integration in Generalized Mobile Network Architecture,” in European Conference on Networks and Communications (EUCNC). IEEE, 2015, pp. 1–5. [31] M. McBride, M. Cohn, S. Deshpande, M. Kaushik, M. Mathews, and S. Nathan, “SDN Security Considerations in the Data Center,” Open Networking Foundation-ONF SOLUTION BRIEF, 2013. [32] D. Kreutz, F. Ramos, and P. Verissimo, “Towards secure and dependable software-defined networks,” in Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. ACM, 2013, pp. 55–60. [33] M. Liyanage, M. Ylianttila, and A. Gurtov, “Securing the control channel of software-defined mobile networks,” in A World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2014 IEEE 15th International Symposium on. IEEE, 2014, pp. 1–6. [34] M. Liyanage, A. Gurtov, and M. Ylianttila, “IP-Based Virtual Private Network Implementations in Future Cellular Networks,” Handbook of Research on Progressive Trends in Wireless Communications and Networking, p. 44, 2014. [35] R. Axelrod, “The evolution of cooperation: revised edition,” Basic books, vol. 185, p. 186, 2006. [36] ETSI TR 187 023 V1.1.1 (2012-03). [Online]. Available: http://www.etsi.org/deliver/etsi tr/187000 187099/187023/01.01. 01 60/tr 187023v010101p.pdf [37] L. Kekely, V. Pus, and J. Korenek, “Software defined monitoring of application protocols,” in INFOCOM, 2014 Proceedings IEEE. IEEE, 2014, pp. 1725–1733. [38] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: enabling innovation in campus networks,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008. [39] About POX. [Online]. Available: http://www.noxrepo.org/pox/ about-pox/ [40] Open vSwitch: An Open Virtual Switch. [Online]. Available: \url{http://openvswitch.org/} [41] “The OpenHIP project,” http://www.openhip.org/. [42] Iperf. [Online]. Available: http://iperf.sourceforge.net/ [43] “Carrier Cloud Telecoms - Exploring the Challenges of Deploying Virtualisation and SDN in Telecom Networks,” Intel Cooperation, Tech. Rep., 2013.