Security Evaluation in Software Defined Mobile Network

Security Evaluation in Software Defined Mobile Network

Reihaneh Vafaei ITSecurity II Essay

Stockholm, Sweden 2015

2

Index

Abstract 3

1. Introduction 45

2. Background and related 6

2.1. SoftwareDefined Mobile Networks (SDMN) 79

2.2. MobileFlow Forwarding Engines 10

2.3. MobileFlow Controller 1012

2.4. Mobile Network Applications 1315

3. Security Issues in SDMN 16

3.1. Threat Vectors 1622

4. Proposed Security Scheme 23

4.1. Background 2324

4.1.2 Secure and Dependable Control Platform 2529

4.1.3 Security and Dependability by Design 30

4.2 Security Issues in SDMN Control channels 3132

4.2.1 Proposed secure Control Channel 33

4.2.1.1 SecGW (Security Gateway) 3334

4.2.1.2. SEC Entity (Security Entity) 3435

4.2.1.3. Local SEC Agent (LSA) 35

4.2.1.4. Control Channel 3639

Conclusion 40

References 4143

3

Abstract

The result of the explosive growth in mobile devices has been led to face

significant challenges with bandwidth demands. Deploying of new standard like

4G/LTE which supports a flexible channel bandwidth by providing smaller cells,

however integrating Software Defined Networking (SDN) in the current 4G/

LTE architecture decouples data plane from control plane to see a tendency

toward simplification of new mobile backhaul networks. In fact, it considers

applying SDN principles on a mobile network architecture not only to conduct

data plane into a forwarding plane but also to provide a logically centralized

control plane that maintains the network state and handles the configuration of

network devices. This new mobile network architecture is referred as

SoftwareDefined Mobile Networks (SDMNs) which composites of data plane,

control plane and application. In this paper, we examine new security challenges

of the control channel of SDMNs and introduce a secure channel architecture

based on Host Identity Protocol (HIP). IPsec tunneling and security gateway

(SecGate) are widely used in today’s mobile networks. Moreover, we analyze the

security of proposed architecture to protect the control channel from various IP

(Internet protocol) based attacks.

4

1. Introduction

Due to the growth of the set of network services such as broadbanding

connectivity, VoIP (Voice over IP), video streaming, mobile cloud and virtual

network services, the mobile traffic usage is drastically increasing than wired

Internet traffic. Hence, it is challenging to accommodate the increasing traffic

demand because of the limited radio bandwidth resources and the inflexible

network equipments. Therefore, the next generation of mobile network requires

to utilize the new equipments and technologies in mobile networks to enhance the

performance, flexibility, scalability of telecommunication networks. Thus,

SoftwareDefined Networking is identified as promising technology to reach

goals for mobile network.

Programmability, abstraction and centralized control plane are the most principles

of SDMN [1] but it is vulnerable to new security threats that did not exist

before.For example, SDMN is an interesting part for external attackers and

malicious users which are called misfeasor.

5

SSL (Secure Sockets Layer)/TLSv1 (Transport Layer Security version 1)

sessions is used as a protection for control channel communication that is

proposed by Open Flow as a communication protocol [2] but this protection

mechanism is not enough strong against IP based attacks.

In this essay, the new security challenges of the control channel of SDMNs are

studied and a secure control channel architecture based on Host Identity Protocol

(HIP) is proposed. IPsec tunneling and Security Gateways (SecGWs) are widely

used in today’s mobile networks.The proposed architecture utilized these

technologies to protect the control channel of SDMNs. In this essay, the focus

relies only on the security challenge of the control channel of SDMNs.

The performance penalty of security of proposed architecture and its ability to

protect the control channel from various IP based attacks are analyzed. [2]

Therefore, the SDMN architecture and security issues are explained in section

two and three respectively and the proposed secure control channel is proposed in

section four as well.

6

2. Background and related work

2.1. SoftwareDefined Mobile Networks (SDMN)

The concept of the SoftwareDefined Mobile Network (SDMN) is introduced as

an extension of SDN paradigm to combine mobile network specific

functionalities.The propose of SDN in network is to separate the control plane

and data plane of network devices and to make the centralized controller as the

network intelligence in order to control all the function in the network. Thus, the

data plane comprises of lowend switches and network links among.

Control channel is the communication channel between the controller and data

plane switches. The control protocol is used between the control plane and data

plane for communication is called OpenFlow protocol (OF).

OF protocol is the widely used control protocol in SDN domain [3] and we use it

as the reference protocol for our analysis.

SDN explicitly separate the control and data planes in much better way rather

than 3GPP evolved Packet Core (EPC).

Moreover, SDN has triggered significant interest in network function

virtualization (NFV), as indicated by the latest developments in standardization

organizations such as the Internet Engineering Task Force (IETF) and European

Telecommunications Standards Institute (ETSI)[4].

7

SDMN architecture is now directing the current mobile network to a flowcentric

model that applies inexpensive hardware and logically centralized controller.

The aim of implementing SDN in mobile network is to provide maximum

flexibility, scalability and programmability to carrier without commanding any

changes in user equipment (UE). Therefore, in this way, operators can innovate

inside their domain without depending on either overthe top (OTT) service

provides or UE vendors to support their innovations.

Figure 1 illustrates the central elements of SDMN with a new split that

distinguish mobile network control from all user plane elements.This way the

user plane, the Mobile Flow forwarding engine (MFFE) becomes simple, stable

and high performing while the control plane (i.e., Mobile Forwarding control

(MFC) and mobile network applications) can be implemented in a logically

centralized manner.

8

Fig 1: Software Defined Mobile Networking

Forwarding in the MFFE can be fully defined in software, while the control

software can flexibly steer user traffic to different service enablers (e.g.,deep

packet inspection[DPI],video caching and optimization) that can be distributed

throughout the mobile network as shown in Fig 1.

9

Thus, a new layer based on a logically centralized MobileFlow controller can

drive forwarding. MFFEs apply network virtualization that are suitable for multi

tenant mobile networks and can support security related network functions.

Figure 1 also depicts the OF alone is not enough for implementing a carrier

grade network user plane. Thus, the SDMN is distinguished its architecture from

OpenFlowbased network, as MFFEs are not switch level equipment but instead

MFFEs supports carriersgarde functionality such as network layer tunneling and

flexible charging.

Hence, the MobileFlow architecture interacts with Evolved Packet Core network

elements easily. Thus, as the figure 1 is depicted that at the control plane, the

mobile network applications running on the top of the mobileFlow control which

can function as an as an MME or the gateway control part of a physical box

(indicated as GWC) and can interoperate with other heritage such as MMEs,

SGWs or PGWs which are using the well established 3GPPdefined interfaces

shown in fig1.

In the user plane, the MFFE can be interconnected with the legacy EPC elements

with a common IP/Ethernet transport network.where the control messages can be

transmitted via the MFFE in an inband manner or or via dedicated outofband

network.[4]

10

2.2. MobileFlow Forwarding Engines

MFFEs include standard mobile network tunnel processing capabilities and with

the support of an MFC it can integrated with legacy EPC equipment and it may

also include key functionality of wireless access node such as radio interface to

manage radio bearers.

Each MFFE communicates with am MFC through a lightweight protocol that

implement MobileFlow control interface (Smf). MFFEs use the flow rules

received from MFC to encapsulate/decapsulate user traffic and/or forward

packets to the transport network.

2.3. MobileFlow Controller

The Mobile controller has three interfaces which are southbound , horizontal and

northbound interface.The southbound interface of the Mobileflow control (MFC)

controls MFFE operation and the functional blocks corresponds to three

interfaces.

Figure 2 in MFC illustrates its main functional blocks: the mobile network

function, the mobile network abstraction and the functional blocks corresponding

to three interfaces.

11

Figure 2: MobileFlow controller.

The horizontal interface is used for communication with other MFCs and can be

employed for intra and trusted interdomain cooperation with other MobileFlow

controllers. Operators with very large infrastructure typically segment their

network according to administrative, regulatory, technical, or other reasons.[1]

12

Finally, the fast network service and application development are facilitated by

the northbound interface.

The corresponding functional block in MFC includes topology autodiscovery,

resource view , network resource monitoring and network resource virtualization

and in addition the network functions block include tunnel processing, mobility

anchoring, routing and charging among others.

A essential part of the SDN is the feasibility of extending current and new

functionality through programmatic APIs and SDMN is compatible with

advances in the Open Flowbased ecosystem.

The figure 2 also illustrates the open interfaces and associated APIs introduced by

the SDMN. It must be mentioned that the SDMN controller does not have an

explicit interface to infrastructure but this infrastructure can be handled by

MobileFlow applications and the SDMN northbound interface, for example, can

be used by MobileFlow applications to implement different network

functionality. The MobileFlow stratum can be engaged in managing user traffic

selectively depending on several criteria. [1]

13

2.4. Mobile Network Applications

By using SDMN northbound interface, the Mobile network application can be

deployed and in this figure 3 shows that two models.

Figure 3: MobileFlow application models.

The first model adopts a network function virtualization approach in which a

MobileFlow application enforced the control part functionality of each of the EPS

elements (e.g., eNodeBC, SGWC, PGWC, S/PGWC, and GGSNC).This

model features a 1:1 mapping between the virtual gateway and MFFE via the

MobileFlow controller. In other words, an EPC virtual topology is constructed in

the MobileFlow stratum.

14

The second model which is shown in Fig 3 adopts mapping one all mobile

applications and several MFFEs. The application uses the SDMN northbound

interface to access the resource topology from MobileFlow controller.In addition,

it shows that the traffic paths and operations within the MFFE topology based on

the network abstraction obtained from the MFC.

For example, we can develop a virtual EPC gateway which aggregates

functionality by factoring in that is currently distributed between several network

elements, thus optimizing control signaling, while incorporating various

SDMNbased service enablers, as shown in Fig 3.[2]

Fig 4: The SDMN Architecture

15

The figure 4 shows that the control communication between data plane and

control plane is over control channel.

SDMN offers different advantages such as centralized controlling, improved

flexibility, efficient segmentation, automatic network management , granular

network control ,reduction of operation and equipment cost backhual devices,

ondemand provision and resource scaling.Thus, SDMN is considered as the

latest changes in the telecommunication in order to simplify the network as

possible.

16

3. Security Issues in SDMN

3.1. THREAT VECTORS

In softwaredefined mobile network (SDMN), there are two weaknesses that are

used as an attractive places for malicious users and a source of headeches for less

prepared network operators. one is the ability to control the network by means of

software that is always subject to bugs and a source of other vulnerabilities and

other one is the centralization of the network intelligence in the controller.

Therefore, anyone has an access to the servers can potentially control the entire

network[1,5].

In this section , we potentially claims that the SDMN is properly designed and

deployed, we believe this new network environment will definitely present a

quantum leap in network architecting, not only in functionality but also in

resilience.

This figure 5 shows the main SDN threat vector

Threat vector 1:

Forged or faked traffic flows which can be used to attack switches and controllers

nonmalicious devices or by malicious user can trigger this threat and an attacker

can uses network elements such as switches,servers or personal computers to

launch DoS attack against OpenFlow switches and controller resources.

18

A simple authentication mechanism could mitigate the problem but the attacker

can use the same authenticated ports and MAc address to inject authorized by

assuming the control of an application server that stores the details of many users.

Possible solution:

The use of intrusion detection systems could help to identify abnormal flows.

This could be coupled with mechanisms for dynamic control of switch behavior

such as rate bounds for control plane requests.

Threat vector 2:

another attack is that to attack on switches vulnerabilities since one single switch

could be used to drop or slow down packets in the networks or ot can be used to

overload the controller or neighboring switches.

Possible solution : the use of software mechanisms such as automatic trust

management solutions for software components [1] that is a possible reducing

factor. The mechanisms to monitor and detect abnormal behavior of network

devices can also be valuable to defeat this kind of threats.

Threat vector 3:

Other attack that can be used to generate DoS attack or data theft is an attack on

control plane communication. Although, TLS/SSL are used as a security

community, it does not guarantee secure communication due to the various

19

weakness of TLS/SSL communications and Its major anchor of trust and the PKI

infrastructure[7]. Because of the compromised certificate Authority and

controller device link and vulnerable application and libraries , the security of

those communications are compromised.For instance, there are many manin

themiddle vulnerable implementations of SSL being used in worldwide critical

systems [8].Moreover, there is no assure trust between controller and switches in

TLS/SSL model. Once an attacker gains access to control plane, because of the

the numbers of switches under its control , it can launch DDoS attacks. This lack

of trust guarantees could even enable the creation of a virtual black hole network

(e.g., by using OpenFlowbased slicing techniques [9]) allowing data leakage

while the normal production traffic flows.

Possible solutions: The using multiple trustanchor certification authorities (e.g.,

one per subdomain or per controller instance) is a possibility. Another is

securing communication with threshold cryptography across controller replicas

[9] (where the switch will need at least n shares to get a valid controller message).

Additionally, the use of dynamic, automated and assured device association

mechanisms may be considered, in order to guarantee trust between the control

plane and data plane devices.

20

Threat vector 4:

The most severe threats to SDMNs are attacks on vulnerabilities in controllers.

Thus , the entire network could be compromised because of faulty or malicious

controller. Since controllers only provide abstractions that translate into issuing

configuration commands to the underlying infrastructure, a malicious application

can potentially do anything in network. As a result the use of intrusion detection

system may not be enough as it may be hard to find abnormal behavior and more

importantly to lable it as malicious.

Possible solutions:

Several techniques can be used, such as replication (to detect, remove or mask

abnormal behavior), employing diversity (of controllers, protocols, programming

languages, software images, etc.), and recovery (periodically refreshing the

system to a clean and reliable state). It is also important to secure all the sensitive

elements inside the controller (e.g., crypto keys/secrets). Furthermore, security

policies enforcing correct behavior might be mapped onto those techniques,

restricting which interfaces an application can use and what kind of rules it can

generate to program the network (along the lines of securitybased prioritization

[10]).

21

Threat vector 5:

Similar to threat vector 3 , the lack of mechanisms to implement between the

controller and management applications, the ability to establish trusted

relationships between controller and applications is absent.

Possible solution:

To provide the trust for applications during its lifetime, the mechanisms for

autonomic trust management could be used to guarantee that the application.

Threat vector 6:

Attacks on and vulnerabilities in administrative stations which, as it is also

common in traditional networks, are used in SDNs to access the network

controller. These machines are already an exploitable target in current networks,

the difference being that the threat surface as seen from a single compromised

machine increases dramatically in SDMNs. It becomes easy to reprogram the

network from a single location.

Possible solutions: The use of protocols requiring double credential verification

(e.g., requiring the credentials of two different users to access a control server).

22

Threat vector 7:

It could be possible to detect and understand the cause of a detected problem and

proceed to a fast and secure mode recovery since the lack of trusted resources for

forensics and remediation are exist.Therefore, the reliable information from all

components and domains of the network are needed in order to investigate and

establish facts about an incident.Furthermore, this data will only be useful if its

trustworthiness (integrity, authenticity, etc.) can be assured. Similarly,

remediation requires safe and reliable system snapshots to guarantee a fast and

correct recovery of network elements to a known working state.

Possible solutions: Logging and tracing are the common mechanisms in use, and

are needed both in the data and control planes. However, in order to be effective,

they should be indelible (a log that is guaranteed to be immutable and secure).

Furthermore, logs should be stored in remote and secure environments.

23

4. Proposed Security Scheme

4.1. Background

There is no mechanisms are used to assure trusted switch controller in order to

avoid malicious devices in network or detect ,correct or mask faults of systems

components since there is no security and dependability beyond using simple

authenticated communication channels for SDMN controller and also no

techniques are used to assure data integrity and confidentiality in or between

controllers.

Fault and intrusion tolerance are the most key ingredients to guarantee a highly

robust system in a security and dependability perspective.The two main fault

models are crash and Byzantine (a.k.a., arbitrary faults). Crash fault tolerant

services support only kindly failures such as a crashed process, operating system

or machine, being a narrow subset of the arbitrary model. Byzantine fault tolerant

(BFT) systems are capable of tolerating any abnormal behavior, i.e., intentional

or nonintentional faults, while the service keeps its correct operation.

By using state machine replication [11], Faults such as bugs, misconfigurations,

attacks and errors can be masked automatically as they happen.

24

Furthermore, in order to ensure the lastly and unattended operation of the

system, errors can be removed with self healing techniques [12], so that there is

never an excessive number of compromised devices. Both automatic recovery

and perpetual and unattended operation seem to be relevant objectives in the

context of SDNs.

Despite of the Intrusion tolerant architectures [13] are a step in the direction of

this automatic security paradigm and are capable of encouraging properties such

as integrity, confidentiality and availability, the process of faulty or compromised

components due to successful attacks.

In final goal is to improve the overall network resilience [14] that is relied on a

secure and dependable control plane help. A resilient system is one that

selfadapts to the dynamics of environment conditions, e.g., one that performs

selfhealing in the presence of persistent threats and where protection parameters,

such as number of replicas, length of keys, etc., can automatically increase in

case of a severe attack.

25

4.1.2 Secure and Dependable Control Platform

The secure and dependable SDN control platform , it proposes in figure in order

to illustrate a simplified view of the architecture need to be implement in mobile

backhaul architecture. In the remainder of this section we briefly introduce and

discuss the several mechanisms which we consider using to address the threat

vectors identified in SDNs.

Figure 2: Secure & Dependable SDN

26

Replication: Due to improve the dependability of the system, replication is one

of the most important techniques. As can be seen in figure 2, our controller is

replicated, with three instances in the example. Besides the replicated controller,

the application should be replicated as well that is shown in figure the application

B also replicated in all controller instances. Replication makes it possible to mask

failures and to isolate malicious or faulty applications and/or controllers.

Moreover, in case of a network partition, application B, with the proper

consistency algorithms, will still be able to program all network switches,

contrary to application A.

Diversity: The diversity is another technique to improve the robustness of secure

and dependable system [15, 16]. Avoiding faults such as software bugs or

vulnerabilities is the basic principle behind this mechanism. The OS diversity

constrains the overall effect of attacks on common vulnerabilities. In SDNs the

same management application could run on different controllers. This can be

simplified by defining a common abstraction for applications (a northbound API)

Selfhealing mechanisms: Proactive and reactive recovery can bring the system

back to a healthy state in under persistent adversary circumstances. Replacing

compromised components, and keep it working virtually forever. It is important

that the replacement be done with new and diverse versions of the

components,When replacing components, whenever possible. In other words, we

27

should explore diversity in the recovery process, strengthening the defense

against attacks targeting specific vulnerabilities in a system.

Dynamic device association: If a switch is associated with a single controller, its

control plane does not tolerate faults. Once the controller fails, the control

operation of the switch fails and the switch will need to associate with another

controller. For this reason, a switch should be able to dynamically associate with

several controllers in a secure way (e.g., by using threshold cryptography to

detect malicious controllers and authentication, which would hinder

maninthemiddle attacks, for instance). A switch associated with different

controllers would be able to automatically tolerate faults (crash or Byzantine,

depending on the configuration). Other advantages include increasing control

plane throughput (several controllers could be used for load balancing) and

reducing control delay [17] by choosing the quickestresponding

controller.Increasing the data plane programmability (near or in the network

switches) would be helpful in this respect. Two approaches could be used for this

purpose. One option would be to use general purpose CPUs inside the switch to

replace some of the traditional functionality of custom ASIC, as in [18]. Another

could be to have a proxy element acting on behalf of the switch. This element

could be easily deployed in a small black box attached to the switch, with a

general purpose microcomputer.

28

Trust between applications and controllers software: This paper is proposed

and demonstrated the feasibility of a model to support autonomic trust

management in componentbased software systems. They use a holistic notion of

trust to allow a trustor to assess the trustworthiness of the trustee by observing its

behavior and measuring it based on quality attributes, such as availability,

reliability, integrity, safety, maintainability, and confidentiality.The proposed

model can also be applied to define, monitor, and ensure the trustworthiness of

relationships among system entities.

Security domains: A very common technique which is used in different types of

systems is isolated security domains.For instance, in operating systems user level

applications are not allowed to access kernel level subsystems. Similarly to

operating systems sandboxes, Chromium uses sandboxes to isolate the rendering

engine from the browser kernel.Thus, most of the attacks will affect only the

rendering engine and not the system kernel. Sandboxing and virtualization are

used as techniques in order to explore Security domains in SDN control

platforms.These techniques enable the design of strong isolation modes, through

well defined interfaces that allow minimal (only restricted and strictly necessary)

set of operations and communication between different domains

29

Secure components: These components are one of the essential building blocks

of a secure and dependable system. Secure elements can be used, for example, to

provide trusted computing bases (TCB) to assure security properties such as

confidentiality. A TCB is a tamperproof device that can be used to store

sensitive security data (e.g., crypto private keys) and execute basic operations on

it. Thus, even if the system is compromised, sensitive data will have its

confidentiality assured.

Fast and reliable software update and patching:. As no software is free from

bugs (or other vulnerabilities), fast and reliable software patching and update is

essential to reduce the window of vulnerabilities. Thus, a control platform should

be deployed with mechanisms to assure a smooth and secure way of doing

updates. Solutions as those proposed in [19] can help in achieving this goal.

30

4.1.3 Security and Dependability by Design

Suppose that we have three repli cated controllers to keep our network in a

healthy state. If one controller is buggy or gets compromised we still have two

potentially correct controllers. This will be true if controllers are designed in

order that they can be easily replicated, are capable of interoperating and

providing support to execute applications across controllers. To achieve these

characteristics, we need common interfaces for controller integration and

interoperation (e.g., three different controllers working together in a same

environment), common northbound APIs, and common replication capabilities.

In addition to this, the switches will also need to be able to dynamically associate

with more than one controller. Finally, if we rely on a single controller make for

replication, bugs and abnormal behaviors have a high probability of affecting all

instances in parallel. In this case, diversity helps improve the robustness of the

system. In summary, by applying these three techniques — replication, diversity,

dynamic switch association — in the design of our system, we are able to

increase its security and dependability from the first hour.

31

4.2 Security Issues in SDMN Control channels

SDMNs are now vulnerable to new security threats that did not exist before or

were harder to exploit [20] in mobile networks. These security issues can be

originated at various sections of the network [20]. However, this research is focus

only to identify the security challenges in the control channel of SDMNs.

The lack of IP level security is the main security issue of the control

channel.Existing SDN control channels rely on higher layer secure mechanism

such as TLS/SSL based communication. For instance, OF protocol uses TLS/SSL

based control channels. However, higher layer secure mechanisms are vulnerable

various IP based attacks such as IP spoofing, TCP SYN (Synchronization) DoS

(Denial of Service) and TCP reset attacks [21].Therefore, the higher layer

protection mechanisms are not strong enough to provide a required level of

robustness and security for the control channel.

Moreover, various factors such as selfsigned certificates, Certificate Authority

(CA), security applications and libraries are used for the security level of a

TLS/SSL session. Thus, the security of the TLS/SSL session is strong as the

security level of the weakest link among those factors [21]. On the other hand, a

strong authentication is required between the controller and data plane switches.

In absence of strong authentication mechanism, an intruder who gains access to

the control plane can launch various attacks. For instance, the attacker can inject

32

fake flow requests to overwhelm the controller resources and exhaust the flow

tables in switches. However, the TLS/SSL model is not sufficient enough to

perfume such a strong authentication procedure between controllers and switches.

For example, TLS/SSL authentication mechanism is vulnerable to IP spoofing

and Compression Ratio Infoleak Made Easy (CRIME) attacks [21].

4.2.1 Proposed secure Control Channel

For SDMNs, HIP (Host Identity Protocol) is proposed based secure control

channel.Therefore, the security architecture is independent of the SDN control

protocol (e.g. OF protocol).

The proposed secure control channel architecture is presented in Figure 2. In

existing SDMN architecture, There are four changes are proposed. First, for

securing the controller from outside network and solving the single point of

failure, the distributed SecGWs are utilize. Second, new SEC (Security) entity is

added as a control entity to control SecGWs and other security related functions

in SDMN. Third, a Local Security Agent (LSA) application is installed in each

data plane switch to handle security related functions in the switch. Fourth, IPsec

BEET (BoundedEndtoEndTunnel) is used to secure the control channel

communication.

33

Fig. : Proposed Secure control Channel Architecture

4.2.1.1 SecGW (Security Gateway)

SecGW is the intermediate device between the controller and the rest of the

network. SecGWs hide the network controller from the outside world and reduce

the security related workload of the controller.Two responsibilities of SecGWs

34

are for two functions. 1. Establish IPsec tunnels with data plane switches. 2.

Participate in the authentication and registration procedures of new

switches.Here, we propose to utilize distributed SecGWs to prevent the single

point of failure. Moreover, it is possible to integrate various security functions

such as IDS (Intrusion Detection Systems), DPI (Deep Packet Inspection) and

Firewalls with these SecGWs for extra protection.

4.2.1.2. SEC Entity (Security Entity)

The SEC entity is a new control entity which controls SecGWs and other security

functions in the network. In the proposed architecture, the SEC entity is used to

authorize the data plane switches (Figure 4). The operator uploads a set of ACLs

(Access Control Lists) to the SEC entity. These ACLs contain the identities of

legitimate data plane switches and the SEC entity authorizes new switches based

on ACLs

35

Moreover, SEC entity retrieves the statistical information from the controller.

Based on this information, the SEC entity can identify the abnormal traffic

behaviors and instruct SecGWs to terminate the communication with

misbehaving switches.

4.2.1.3. Local SEC Agent (LSA)

LSA is a security entity which is implemented on the switch. It is mainly

responsible for the secure control channel establishment with SecGWs. The

secure control channel and the placement of LSA in the switch is illustrated in

Figure 3.Here, the tradition control protocol (e.g. OF protocol) communicates

between the Open Flow logics/APIs (Application Programming Interfaces) in

OF switch and the controller. The proposed security mechanism is invisible to OF

protocol.

36

4.2.1.4. Control Channel

HIP based secure channel is proposed which establishes HIP (IPsec BEET mode)

tunnels between SecGWs and data plane switches.HIP is a novel mobility and

security management protocol which is standardized by IETF (Internet

Engineering Task Force) [22].The dual role of IP address as the locater and the

host identity is separated here. Each HIP host has a public/private key and the

public key is used as its Host Identity (HI). HIP utilizes a base protocol named

HIP Base Exchange (HIP BEX) to mutually authenticate the end nodes and

establish Security Associations (SAs) for an IPsec tunnel between them. HIP

BEX contains a strong PKI (PublicKey Infrastructure) based authentication

mechanism by utilizing these unique HIs. Moreover, HIP tunnels use the ESP

(Encapsulating Security Payload) mode. Therefore, the control channel payload is

always encrypted.

In proposed architecture, every SDN switch has its own public/private key pair

and the public key is used as its HI. The public/private key pair is stored in each

SDN switch before the installation in the network. The network operator adds HIs

of legitimate switches to ACLs in the SEC entity.

37

4.2.1.5Authentication and Registration procedure of Switches:

The proposed architecture supports the dynamic addition of new data plane

switches and automatic establishment of the control channel with them. We

propose a novel tunnel establishment procedure has two tasks. First, it

authenticates and registers new date plane switches. Second, it establishes IPsec

tunnels between the switch and SecGW.

The proposed tunnel establishment procedure has several strong security services.

The tunnel establishment procedure is initiated by the potential switch. Initially, it

mutually authenticates the switch and SecGW based on PKI mechanism. Then,

the potential switch is authorized by the SEC entity based on ACLs. Finally, both

SecGW and OF switch establish SAs for a HIP tunnel and negotiate keys for

traffic encryption. The proposed tunnel establishment procedure is presented in

Figure 4 and it is based on existing HIP BEX [22]. We use the same terminology

which was used for original HIP BEX in [22].

38

Fig. 4: The Tunnel Establishment Procedure

The switch initiates the tunnel establishment procedure by sending an I1 message.

It contains only HITs (Host Identity Tag) of OF switch and SecGW. To prevent

DoS attacks, SecGW replies the I1 message with a precomputed R1 message

without allocating any resources. The main compo nents of the R1 message are

the cryptographic puzzle, DH (DiffieHellman) key parameters, the public key of

SecGW, ESP transforms, HIP transforms, the echo request and the signature.

DH key parameters are exchanged between two nodes to generate a common

symmetric key to encrypt ESP payload.

OF switch sends the I2 message after the arrival of the R1 message. I2 message

contains the solution of the cryptographic puzzle, DH 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 Message Authentication Code)

39

and the signature. Upon the arrival of I2 message, SecGW checks and verifies

three fields namely HMAC, the signature and the solutions of the puzzle. The

puzzle verification is a quite simple since it is a single fast hash computation. If

these fields are verified, SecGW has received a legitimate connection request

from OF switch. Furthermore, SecGW has verified identity of OF switch.

Then, SecGW sends the switch’s credentials to SEC via REQ message. It

contains HI of OF switch, the authentication request, the echo request. Upon the

arrival of REQ, SEC checks the received HI against these ACLs and replies REQ

message with an ACK message. The ACK message contains HI of the switch, the

acknowledgment and the echo reply. A positive acknowledgment is sent for a

request from an authorized OF switch and a negative acknowledgment is sent for

other requests. If it is negative acknowledgment,

40

5. CONCLUSION

This paper is proposed the new network architecture based on the SDN and also

its implementation on mobile backhaul network and it proposed the security

challenges in both SDN architectures and also security challenge of the control

channel of SDMNs and the applicability IPsec tunneling and security gateways

technologies to secure it. Then, we proposed novel secure control channel

architecture based on IPsec tunnels and security gateways. The proposed

architecture provides various advantages such as reducing the security related

overhead on the controller and control entities, solving the single point of failure

issue of the controller, increasing the flexibility of security mechanism, enhanced

authentication mechanism, encrypted control traffic delivery and protecting the

control channel from IP based attacks.

Moreover, we analyze the security and the performance of proposed architecture

in a testbed. The experiments reveal that proposed architecture protects the

control channel against various IP based attacks such as DoS, reset, spoofing,

replay and eavesdropping attacks. However, there is a performance penalty of

security due to extra the IPsec tunnel establishment. This drawback can be

minimized by using security specific hardware and keeping the established

tunnels for a longer period. In future, we will focus on securing the data plane of

SDMNs by using IPsec tunneling and security gateway technologies.

41

References

1. Kostas Pentikousis, Yan Wang, and Weihua Hu, Huawei Technologies , MobileFlow,Toward

SoftwareDefined Mobile Networks

2. Madhusanka Liyanage , Mika Ylianttila , Andrei Gurtov,Securing the Control Channel of

SoftwareDefined Mobile Networks

3. 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.

4.James F. Kurose,University of Massachusetts, Amhers,Keith W. Ross Polytechnic Institute of

NYU ,computer Network

5.Thomas Magedanz Anastasius Gavras Huu Thanh Nguyen Jeffry S. Chase (Eds.). Testbeds and

Research Infrastructure

6.Z. Yan and C. Prehofer. “Autonomic Trust Manage ment for a ComponentBased Software

System”. In: IEEE Trans. on Dep. and Sec. Computing 8.6 (2011).

7.M. Georgiev et al. “The most dangerous code in the world: validating SSL certificates in

nonbrowser soft ware”. In: ACM CCS. 2012

42

8.R. Sherwood et al. FlowVisor: A Network Virtualiza tion Layer. Tech. rep. Deutsche Telekom

Inc. R&D Lab, Stanford University, Nicira Networks, 2009.

9.Y. G. Desmedt. “Threshold cryptography”. In: Euro pean Transactions on

Telecommunications 5.4 (1994).

10.R. Sherwood et al. FlowVisor: A Network Virtualiza tion Layer. Tech. rep. Deutsche

Telekom Inc. R&D Lab, Stanford University, Nicira Networks, 2009.

11.F. B. Schneider. “Implementing faulttolerant services using the state machine approach: a

tutorial”. In: ACM Comput. Surv. 22.4 (Dec. 1990).

12.P. Sousa et al. “Highly Available IntrusionTolerant Services with ProactiveReactive

Recovery”. In: IEEE Trans. Parallel Distrib. Syst. 21.4 (2010).

13.P. Verissimo et al. “Intrusiontolerant middleware: the road to automatic security”. In: IEEE

Security & Pri vacy 4.4 (2006).

14.J. Korniak. “The GMPLS Controlled Optical Networks as Industry Communication

Platform”. In: IEEE Trans. on Industrial Informatics 7.4 (2011).

15. S. Neti, A. Somayaji, and M. E. Locasto. “Software diversity: Security, Entropy and Game

Theory”. In: 7th USENIX HotSec. 2012.

43

16.M. Garcia et al. “Analysis of operating system diver sity for intrusion tolerance”. In:

Software: Practice and Experience (2013).

17. B. Heller, R. Sherwood, and N. McKeown. “The con troller placement problem”. In:

HotSDN. ACM, 2012.

18. J. C. Mogul and P. Congdon. “Hey, you darned coun ters!: get off my ASIC!” In: HotSDN.

ACM, 2012

19. J. H. Perkins et al. “Automatically patching errors in deployed software”. In: ACM SIGOPS

SOSP. 2009.

20.D. Kreutz, F. Ramos, and P. Verissimo, “Towards secure and depend able softwaredefined

networks,” in Proceedings of the second ACM SIGCOMM workshop on Hot topics in software

defined networking.

21. C. Meyer and J. Schwenk, “Lessons Learned From Previous SSL/TLS AttacksA Brief

Chronology Of Attacks And Weaknesses,” IACR Cryp tology ePrint Archive, vol. 2013, p. 49,

2013.

22. A. Gurtov, Host Identity Protocol (HIP): Towards the Secure Mobile Internet. Wiley, 2008.

Security Evaluation in Software Defined Mobile Network

Documents