A Flow-Based Authentication Handover Mechanism for Multi-Domain SDN Mobility Environment

Ke Ding, Xiulei Wang＊, Guomin Zhang, Zhen Wang, Ming Chen

PLA University of Science & Technology, Nanjing 210007, China

* The corresponding author, email: xiuleiwang1988@126.com

I. INTRODUCTION

Authentication, which is in charge of proving the authenticity of mobility entity to some central authority, is an important part of security handover mechanism. The long handover delay and high computation cost are two important issues to be solved in current authentication handover mechanisms [1]. In current mechanisms, an entity need to re-authenticate after the handover, which will inevitably disrupt the communication process. This will degrade the performance of the applications.Therefore, how to design a secure and efficient handover authentication mechanism in multi-domain mobile network is still a challenging task [2] [3] [4] [5], which mainly contains two parts.

Firstly, in order to keep the communication undisrupted, the handover delay must be short.For instance, to reduce the impact of the bursting packet-loss caused by handover, the related agencies of IEEE have proposed a 50-ms limit on handover time, in which the authentication module should ideally take no more than 20ms. However, most of existing handover authentication protocols incur high communication and computation costs [1]. Secondly,security and privacy are serious concerns for the authentication process. In contrast, all existing handover authentication protocols are subjected to many security attacks. In most of the current handover authentication schemes,it is commonly assumed that APs are trustworthy and would keep users’ privacy-related information confidential. However, since such information is extremely sensitive and coveted by many companies, which may abuse privacy rules for profits, such assumptions may not be valid. According to the analysis above, most of existing handover authentication protocols fail to provide appropriate security and efficient guarantees.

The emergence of Software-Defined Network (SDN) [21] [22] technique makes it possible to solve these two issues of the handover authentication in a new perspective. Literature[3] and [4] have investigated applying SDN in the handover scheme and the authentication mechanisms in a single SDN domain. Experimental results in literature [3] [4] and [23]have proven that SDN can greatly improve the efficiency and security in a single control domain. However, under multi-domain SDN environments, the authentication handover mechanisms are still lack of efficiency.

In this paper, an authentication handover mechanism under multi-SDN domain (AHMMD) is introduced. The key point of AHMMD is that the controller can actively transferred the identity information of the mobile entity to neighbor controllers, which can noticeably reduce the delay while reducing the other costs.The handover protocols and algorithms are designed to support AHMMD mechanism and a prototype system is implemented.

The remainder of this paper is organized as follows. The basic idea and modeling of AHMMD are given in section 2. Section 3 describes the handover protocol of AHMMD and section 4 gives the key algorithm of the handover time prediction. In section 5, the performance is evaluated. Finally, the conclusions are provided in section 6.

In this paper, an authentication handover process for multi-domain SDN environment is presented and analyzed. Based on the programmable SDN wireless network architecture, an efficient secure SDN multi-domain authentication handover mechanism AHMMD is proposed.

II. THE DESIGN OF AHMMD MECHANISM

2.1 The basic idea of AHMMD

According to the communication scenario of multi-domain SDN networks described in [6][7] [8], the communication process of AHMMD includes 4 phases.

1. Controller Authentication Phase

When a SDN network joins the Internet, the controller of the domain must immediately authenticate with the controllers of the neighbor SDN networks.

2. Mobile Host Authentication Phase

When a mobile host communicates with other hosts in a network, it should first associate and authenticate itself with the controller (also named as home controller) by the host-controller authentication protocol. Once they have authenticated with each other, the home controller will allocate the related communication resources for the host. At the same time, the home controller will dispatch the authentication and flow attribute information of the mobile host to the neighbor controllers through the secure communication channel established in the controller authentication phase.

3. Inter-domain Routing Phase

When a mobile host enters a visited domain, the visited controller does not need to authenticate the host again since the host’s home controller has already dispatched the identity and flow information to the visited controller in the host authentication phase.Therefore, the visited controller can directly use this information to establish the communication path with the host.

4. Revocation Phase

When a mobile host wants to terminate the communication, the current associated controller will revoke its related resources and distribute the revocation announce message to the neighbor domains, which indicate the neighbor controller to remove the mobile host authentication information dispatched before.

In AHMMD, any flow will only be authenticated once in its initiation stage, and in the subsequent roaming process, the authentication information will be dispatched among the controllers. The neighbor controllers will complete the flow authentication in advance according to the dispatched information,which ensures the parallel execution of the authentication and movement. This is completely different from the current mobile authentication protocol which adopted the “mobile and re-authentication” style and can greatly reduce the impact of the authentication phases in the ongoing communication.

2.2 AHMMD model

In order to facilitate the analysis, the model of the AHMMD is described as follows.

1. Assuming that the mobile network MN is composed of n controller domains D_Set ={Di| i = 1, 2… n}, and each control domain Diconsists of a controller Ciand a set of wireless OpenFlow APs controlled by Ci. When Dijoins the MN, the controller Ciwill be authenticated with the neighbor controllers of the MN through the authentication protocol Ctrl-Authen which is designed based on the public key cryptosystem, and the controller set C_Set= {Ci| i = 1, 2… n}.

2. When the mobile host MHiaccesses MN through domain D0, it will be associated with AP0of D0. In the association phase, the home controller C0will create a unique BSSIDiand install LVAPion AP0for MHi[9]. After the association, MHiwill be authenticated with C0through the authentication protocol MNAuthen [10] [11]. C0will assign a unique IP address IPiof home domain for MHi. The identity, IP address and MAC address of the MHiwill be bound to the BSSIDi. Once the user initiates a connection to the destination address IPd, C0will authenticate the flow by the flow authentication protocol. At the same time, C0will determine whether to authorize the service to the user according to the access control policies configured by the network administrator. If the authentication process is passed, C0will establish a communication path Path0(IPi, IPd) and store the Secure Context Information SCIiwhich includes BSSIDi, LVAPi, MACi, IPi, AP0and public key information.

Fig. 1 Working scene of MHi under AHMMD

3. The controller C0will proactively push the message which includes SCIi[6] and Flowito the controller Ciof C_Set0according to the security protocol AuthInfo which is designed based on the symmetric cryptographic mechanism. The controller Ciwill receive the message and establish the communication path for Flowiin advance.

4. When MHiis roaming to a neighbor domain Di, as the controller Cihas already pre-authenticated the authenticity of MHi, Ciwill compute new communication Pathi(IPi,IPd) for the flow. Once the migration of LVAPiis complete, the ongoing flow will not be disrupted.

5. The MHiwill repeat steps 2～4 when it is roaming between adjacent domains. If flowiis terminated in the domain Ds, MHiwill send the revocation message to current service controller Csand the resource allocated to MHiwill be revoked by the Cs. At the same time,Cswill dispatch the revocation message to all neighbor domain controllers to inform them to revoke all resources which are pre-allocated to MHi.

2.3 Example of model

The working scenes of mobile host MHiunder the mechanism of AHMMD is shown in figure 1.

1. When domains D0, D1, D2, …, Dnconsist of a mobile network MN, mutual authentication starts among each domain controller corresponding C0, C1, C2, …, C6through the protocol based on PKI, to form a reliable assembly of controller C Set, which is shown as ellipse coverage in the control surface in figure 1.

2. When the mobile host MHiis connected to the network and has been sensed by controller C0of D0, mutual authentication starts between C0and MHiunder the protocol of MNAuthen. This process is on the basis of PKI which will cost 50ms or more. Once the authentication of network access completes,C0is interrelated with MHiand the communication is set up. While the continuous roaming destination of MHimust be one of the neighbors of D0, C0will initiatively send a notification message encrypted with symmetric key, carrying the information of security background of MHito the assemblage of neighbors via AuthInfo protocol.

3. After the neighbor controller C5receives the authentication information SCIi,it will calculate the communication path for MHiin advance.

4. When the MHiroams to D5and is connected to the wireless devices, communication can be at work directly without any problems of communication interrupted. At the same time, C5continues to announce its authentication information to its neighbor controller.

5. When MHiwants to terminate the communication, it will send a revocation message to the associated controller via AuthInfo protocol. C5will take back the source allocated to it and forward the revocation message to neighbor controller through AuthInfo protocol to clear the authentication information related to MHi.

III. THE DESIGN OF KEY PROTOCOL

3.1 CtrlAuthen protocol

The two adjacent controllers of the MN are authenticated according to the protocol Ctrl-Authen and the shared symmetric key is negotiated at the same time. The authentication process of two adjacent controllers Ciand Cjis shown in figure 2. The Authority Authentication Server (AAS) is responsible for the registration of the network entities and authorization of the services.

Initialization: the entities Ciand Cjshould register their authentication informationandto AAS. The AAS will create the global unique identityand public/private key file for C and C.

ijAll of the information will be stored in AAS.The public key, private key and identity will be distributed to each entity. For a new controller Ci, the AAS will send the identity and public key certificate file of the neighbor control Cjto the Ci.

The process of CtrlAuthen protocol includes 4 steps.

1. Cisends the authentication request to the neighbor controller Cj. Firstly, Ciwill sign theand noncewith its private keyThen the signature andwill be encrypted by the public key Cjand send to Cj.The format of the message is shown in Equation.1.

2. After receiving the message from Ci, Cjwill decrypt the message by its private key and retrieveCjresearches the public key certificate of Cibased onand decrypts the message {hashwill recomputed the hash value based on the pre-distributed authentication message and. The new value will be compared with hashIf matched, Cjwill send the message which is shown in Equation 2 to Ci.

Fig. 2 The ctrlAuthen protocol

3. Cireceives the response message from Cjand retrieves the signature information by its private key. Cirecalculates the hash value byandIf the new hash value is matched with the value in response message,Cigenerates the random numberof symmetric key and encrypts the message with the public key certificate of Cj. The format of the message is shown in Equation 3.

4. Cjdecrypts the session key negotiation message by its own private key and recalculates the signature as the process shown in step 3. If Cjis sure that the message is true, Cjgenerates the session key AK byand sends the message shown in Equation 4 to Ci.

3.2 AuthInfo protocol

The AuthInfo protocol is used to realize the authentication information distribution between the current controller and the neighbor controller. Based on the negotiation symmetric key of CtrlAuthen protocol, the working flow of the AuthInfo protocol is shown in figure 3.1. Cisigns the security authentication message and nonce based on the symmetric key which is negotiated with the neighborhood controller Cj. Then Cjencrypts the signature based on the private key of Ci. The format of message is shown in equation 5.

Fig. 3 The authinfo protocol

2. Cjdecrypts the message based on the public key certificates and sends response to Cias is shown in equation 6.

IV. CORRECTNESS PROOF

David Clark points out that to establish credible relationship among network entities, then transform the credible relationship to credible links, and finally form a credible cyberspace[16], a perfect trust mechanism should be involved into the security network system. Intuitively, the AHMMD mechanism we design has established credible authentication relationship both between entity and controller and between controllers. Meanwhile, the information encryption technology based on cryptography ensures a closed credible space during mobile.However the safety of such credible chains needs to be proved in theory. In this respect,we prove the safety of AHMMD based on methods of logical reasoning identification provided by the literature [17] in this chapter.

4.1 Basic predicates and definition of derivation rules

Supposing that a, b, s are the entity elements in collection of system entity; Kab, Kas, Kbsindividually sign the symmetric key shared by entities, Ka, Kb, Ksare the public keys of entity a, b, s respectively,are private keys corresponded with the public keys, and Na, Nb, Ncare specific description statements.It is also supposed that P, Q, R are entity variables, X, Y are variables of statement, while K is a variable of key. The symbol ‘,’ shows the link relationship between statements. The connection and communication among entities is expressed by the link among a variety of description statements.

4.1.1 Basic predicates

To show the relationship of identification of system entities, the literature [18] abstracts and defines predicates shown in table 1.

4.1.2 Derivation rules

Rule1:Authentic statements. This rule is used for deriving the authenticity of the grouping contents.

For the shared key, the derivation rules is shown in formula (7).

This derivation rule denotes that if P believes the symmetric key K shared with Q, and it receives messages encrypted by K which is sent by Q, P will believe that X is actually sent by Q.

As to the encryption mechanism of asymmetric key and password, two derivations are listed as formula (8), (9).

Rule2: No repeated authentication. This rule is mainly used to detect whether the message is up-to-date, meanwhile, the sender confides to this message still.

Formula (10) indicates that P has reasons to believe that Q trusts X if P believes X to be new and trusts that X has been sent by Q at the same time.

Rule3:Rule of jurisdiction. If P believes that Q has the jurisdiction over X, P will trust any X which is ruled by Q.

Rule4:Rule of whole - part. Under the premise of knowing the key, an entity will see the whole parts of the sentence if it notices some parts.

Rule5:Rule of part – whole. The context of a sentence is regarded as up-to-date if an entity confirms a part of it to be fresh.

Rule6:Rule of Up-to-date-Solvable.

4.2 Proof of safety in AHMMD

In view of above-mentioned definition of predicate and rules of inference, this chapter will prove the safety of AHMMD.

According to the description of entity iden-tification and flow identification process, the construction of this procedure is based on the hypotheses portrayed by the formula (15).

In the formula, eisigns any entity that needs to be identified in controller domainAAS is authentication server; KAASis the public key of authentication server;is the public key of entityare respectively unrepeatable figures of homologous entity. It can be derivate as follows based on the communication process of flows and the hypothesis in formula (15) shown in the bottom at this page:

Formula (16), (17) reveal that the phase of entity authentication guarantees the authentication of the controller to the entity identity,which means

During the phase of key negotiation between entity eiand Ci, we can obtain formula(13), (14) shown in the top at next page:

The inference process of formulas (16),(19) certifies: authentication of identification between controller and access entity can be achieved. At the same time, on the basis of identification, the next step, negotiation on shared key which authentication of flow requires, can be fulfilled. This provides the basis of further flow authentication.

Figure 2 indicates the authentication process among controllers. The design of CtrlAuthen protocol is based on hypothesis shown in formula (20).

We can arrive at the conclusion as formula(21) following relevant rules of derivation.

Without loss of generality, the transmission process of authentication messages portrayed in figure 3 can be abstracted as shown in figure 4.

In figure 4, A, B represent the authentication entity and its associated controller respectively. The communication process is based on the hypothesis indicated in formula (22).

On the basis of basic assumptions and communication process of protocol, we can arrive at the conclusion of formula (23):

The transmission and authentication of mobile terminals can be accomplished based on shared symmetric key negotiated among entities. By implementing the 3 communication protocols mentioned above in the system, the secure closed-loop space against authentication information can be established.

Fig. 4 The authentication of flow

V. HANDOVER SCHEME DESIGN

5.1 Design of handover scheme of flow authentication

To implement the efficient and safe handover of authentication communication among controllers in different domains, this section designs a handover scheme of flow authentication on the basis of inter-domain controller’s cooperative mechanism, which is shown in figure 5. As to arbitrary security management domain Diand Dj,their network management control logic is accomplished by controllers Ciand Cjof the domain. For the authentication mechanism, it is divided into intra-domain authentication mechanism and inter-domain authentication mechanism logically. The south interface of underlying controllers takes charge of handling the flow incidents, topology discovery, information statistics and some other fundamental functions. Authentication information database is responsible for storing entities and some other important messages relevant to flow authentication (examples: entity identifiers, MAC/IP address of mobile terminals, public key certificate of entities, Flow identification information, etc.). Intra-domain authentication applications are in charge of making initial authentication of entity and communication flow into realization.

1. Handover of intra-domain authentication

The intra-domain authentication mechanism based on flow authentication protocol can realize the initial authentication of entity communication flows. It will store current authentication entity and messages relevant to communication flow into database of authentication information. To support seamless switching behavior, wireless AP supporting OpenFlow Protocol designed in literature [9][19] [20] is applied in network infrastructure.In a single SDN domain, controllers can collect statistics of AP traffic load information and signal strength information of arbitrary mobile terminal MHiRSSI, which can be received in the range of intra-domain controlled AP communication. By running seamless handover algorithm, not only LVAP (migration among different AP), but also the realization of authentication handover by security authentication of context and flow information in corresponding terminals can both be implemented.

Fig. 5 Frame of inter-domain authentication

2. Handover of inter-domain authentication

As is indicated in figure 5, inter-domain authentication mechanism is set up on the mechanism of controller collaboration. Inheriting the communication interface of controller collaboration module, it synergistically worked in the form of application agent program with modules relevant to the handover of authentication information. The main function modules of handover of authentication mechanism implemented in this article involve: discovery agent of domain controller, reachability agent,Push-Receive agent of authentication information, Publish-Subscribe System agent and the interface CCoP in charge of South-West Controller CoOperation Protocol. The fundamental functions are described as follows:

? The interface CCoP provides fundamental interface of South-West communication to controller side, which requires all application involving information exchange among controllers should call the communication function of this interface. The basic format of information handover among controllers has been defined in CCoP, on which inter-domain authentication protocol is built.Figure 6 portraits the basic format of CCoP,

? Neighbor controller discovers the agent.This agent mainly takes charge of providing realization mechanism for each domain to establish covered network. At present,the discovery mechanism in the field of controller is mainly consisted of two modes--passive and initiative. Under the mode of passive, every SDN domain of access network must be registered in AAS. AAS provides the controller with the assembly of neighbor controllers which may appear in current network, based on information it provided. Under the mode of initiative,controller discovers assemblage of neighbor controllers actively by running M-LLDP

Protocol and build controller covered net.

? Reachability agent. It ensures the active of current neighbor controllers by sending Hello message to them periodically.

? Push-Receive module of inter-domain authentication information transfers authentication information of mobile terminals and communication flows among various control domains on the basis of seamless handover algorithm. The Push-Receive of inter-domain authentication information is an open problem. Any mechanism that can enhance the efficiency of mobile terminal communication and ensure the usage of network resource can perform verification by deployment.

The module Pub_Sub is responsible for sending measurement and statistical instructions to the neighborhood controller to obtain key decision making information that authentication transmission algorithm requires.Provisional Interconnect device statistics is a primary parameter to seamless authentication handover, however, the current controller of mobile terminal cannot add up the information of device and flow. So command of related information statistics needs to be sent to neighbor by Pub_Sub Module. Simultaneously,neighbor controllers take charge of collecting statistics information of device and wireless signals of mobile terminals and returning to current controllers.

Figure 6 defines the basic format of CCoP protocol.

The type of protocol, which represents the communication protocol packed in Data Body is shown in table 2.

Fig. 6 The format of CCoP protocol

Table II The meaning of CCoP Type

Fig. 7 the AR prediction model

Here, we make a few modifications to M-LLDP, which makes it can not only discover neighbor relationships of multi-domain,but also return related information of neighbor switching devices. This makes sense to current controllers to discover the assemblage of neighbor switching devices and learn the mapping relationship between the current neighbor switching devices and the controller of domain it belongs to.

5.2 The authentication handover algorithm

Along with the security environment for authentication information delivering, fast authentication information distribution is the key problem to ensure the performance of the communication. Based on the neighbor controller set C_Sets{C1, C2, C3… Cn} which is discovered by the current controller Csbased on M-LLDP [12], a fast authentication handover algorithm AHBTTP based on best trigger time prediction is proposed in this section.

In order to minimize the packet loss rate and maximum switch success ratio, the wireless handover problem can be formalized as formula (24).

Ploss(t) denotes the packet loss ratio and Phf(t) denotes the handover failure probability when the host executes the handover operation at time t. This problem is analyzed in [13] and an optimization condition is given as formula.(25).

We define the signal sensitivity as the minimum received signal strength which can be demodulated by the end system. Theandrepresents the signal sensitivity of the APsand APprespectively. The toptrepresents the best handover time. Thdenotes the handover delay of the end system. RSSIs(topt+Th) and RSSIp(topt+ Th) denote the prediction signal strength which is received by APsand APpat topt+ Th. In this paper, the handover time of AHMMD is mainly composed of handover and authentication delivery time, which can be obtained by measurement.

For the current service controller Csof mobile host MHi, the handover AHBTTP algorithm is described in table 3. The set AP_Sets(AP1, AP2, AP3…APn) includes all the APs which is controlled by Csor directly connected with the current domain.

The Prediction step K is discussed in the paper [13]. If the handover predicting value isand the sampling cycle is Tsamp, the value of K can be calculated by formula (27).

The AR [14] prediction model is given as figure 7 and the prediction value is shown as formula (29).

Wopt= {ωopt(0), ωopt(1)… ωopt(p-1)} is the optimum weight coefficient vector of the predictor when the least mean square criterion is adopted.

VI. EVALUATION

In order to evaluate the performance of the system, a prototype of the AHMMD is built which is shown in figure 8.

As shown in figure 8, the prototype is composed of two SDN management domain A, B and core IP networks. Each SDN domain is composed of an OpenFlow switch, an Odin protocol [9] enabled OpenFlow wireless AP and the corresponding controller CAand CB.The AHMMD handover management functions are implemented in the typical network operation system Floodlight [15]. The network entities including controllers, mobile hosts must register on the authority authentication server AAS and AAS will distribute the authentication information to all controllers. The server which locates in the core network runs the typical applications such as Web, E-mail,FTP and Iperf. The CtrlAuthen and AuthInfo protocol is implemented based on the APIs of OpenSSL. All the computers in the prototypes are installed with Intel Core 2 Quad 2.4 GHZ CPU, 2G RAM and Ubuntu 14.04.

Experiments 1: Communication Delay of CtrlAuthen Protocol

The controller CAand CBmust register in AAS separately. The AAS will generate the public/private key file for them and distributes all the files to every registered controller. In order to establish a security overlay control network, CAand CBwill be authenticated through the CtrlAuthen protocol. Now the OpenSSL only has implemented the RSA public key algorithm and the key lengths of RSA are 1024 and 2048 bits. In order to record the authentication, we modified the CtrlAuthen protocol on CA. We measured the delay of the CtrlAuthen protocol when the public key lengths are 1024 and 2048 bits respectively.The measurement was repeated 30 times and the results are shown in figure 9. Suppose that the RSA1024and RSA2048denote the delay of different public key length.

It can be seen from the figure 9 that along with the increase of the length of the public key, the controller authentication time also increases. The delays are 132.15ms for the situation of RSA2048and 81.68ms for RSA1024.

Experiment 2: Communication Delay of AuthInfo Protocol

Based on the experiment 1, we measuredthe communication delay of AuthInfo protocol. There are 2 classical symmetric key encrypt/decrypt algorithm 3DES and AES in the OpenSSL. The key length of 3DES is 192bits and the key length of AES includes 128, 192 and 256bits. We first implemented the 3DES algorithm in AuthInfo and measured the delay of AuthInfo under different message number:1, 10, 100 and 1000. Suppose that the length of the message is 100K bytes. The results are shown in figure 10.

Table III The authentication handover algorithm based on the best trigger time

Fig. 8 The prototype of AHMMD

Fig. 9 The delay of CtrlAuthen protocol under the public length of 1024 and 2048 bits

From figure 10 we can see that the delay of AuthInfo protocol is linearly related to the number of message transmitted. Generally, the amount of the data transmitted between different controllers is less than 1M bytes and the number of the message is less than 10. Figure 10 shows that the delay of AuthInfo is less than 16.5ms under the 3DES algorithm, which meets the design requirements.

In order to evaluate the impact of different symmetric encrypt algorithm to the delay of AuthInfo, we implemented the AuthInfo protocol based on 3DE and AES. The length of AES encrypt key is implemented as 128 bits,192 bits and 256 bits. The amount of each message is set to be 1M bytes. The number of the messages transmitted is set to be 10. The measurement results are shown in figure 11.

Fig. 10 The delay of AuthInfo based on 3DES algorithm for different number of message

Fig. 11 The delay of AuthInfo under different length of symmetric keys

Fig. 12 The delay of AHMMD compared with EAP

It can be seen from the figure 11 that the delay of 3DES is longer than AES. At the same time, we can see that the average processing delay of AuthInfo can be reduced with the increase of the length of the key by comparing the different length of AES key. In general, all the delay of the classical symmetric encryption algorithm is less than 20ms, which can meet the practical application requirements.

Conclusions:From the experiment 1 and experiment 2, we can see that the delay of CtrlAuthen and AuthInfo protocol based on the existing OpenSSL APIs can meet the practical application requirements of the existing system. Under the different length of public key,the maximum delay of the CtrlAuthen is less than 150ms. Under the general controller data traffic, the delay of the AuthenInfo based on different length of symmetric key is less than 20ms, which meets the wireless handover delay requirement.

Experiment 3: The Communication Efficiency of Mobile Host under AHMMD Handover Algorithm

We compared the handover efficient of AHMMD with current mechanisms. Based on the prototype of figure 8, the location of OFAPAand OFAPBare adjusted in order to make the wireless signal coverage area of OFAPAand OFAPBoverlap. The wirelesses signal strength of mobile host MH received by the APs is periodically measured on the controller and the handover algorithm which runs on the controller monitors the change of the RSSI signal.The Ping and Iperf application are running on the mobile host and communicating with the server which runs on the core networks. The mobile host MH completes the identity and flow authentication on its home controller and moves from OFAPAto OFAPBaccording to the predetermined trajectory. The controller runs the authentication handover applications to handle the handover of MH.

The mobile host first moves from OFAPAto OFAPBand then goes back. Based on the measurement result of MH, the delay and throughout of AHMMD are compared with traditional authentication mechanism EAP.

From figure 8 we can see that, in the traditional wireless handover mechanism, MH needs to re-discover and re-associate with AP. In this experiment, this process takes the mean value of 3 seconds. Based on the handover mechanism, the traditional authentication mechanism EAP further increases the delay. By measuring the EAP based on public key (the length of the public key is 1024),the mean value of the delay is about 100ms.Based on the measurement results of figure 12, it is found that in the case of no authentication handover mechanism running, there are two burst of the packet round-trip delay (RTT)when the handover occurs. The delay is about 3.4s and 2.9s, which is larger than the normal RTT.

Fig. 13 The throughput of AHMMD compared with EAP

As the delay of authentication and handover migration is 1s, the handover step, prediction threshold and signal sensitive degree of AHMMD are set to be 10, 0.5 and -70dB separately.Through the measurement results of figure 12, we can see that, as the CAdistributes the authentication information and finishes the migration of the LVAPMHof MH in advance, the RTT of packet has almost no increase.

In addition to the measurement of communication delay, we also measured the throughput of MH. The results are shown in figure 13.From the results, we can see that the communication process will be interrupted and the throughput will become 0 when the handover occurs. After the re-association, the communication will be resumed. In the case of the traditional EAP authentication mechanism, in addition to the handover process, the authentication further increases the handover delay of host. In the case of AHMMD, the throughput of the host is almost not affected by any of the handover process.

Conclusions:Through the measurement result of AHMMD, it can be seen that the handover mechanism based on prediction and pre-authentication can significantly reduce the impact of handover to the performance of communication, which also improves the security of the terminal seamless mobility and communication.

VII. CONCLUSION

In this paper, an authentication handover process for multi-domain SDN environment is presented and analyzed. The general problem of the efficiency and security is illustrated.Based on the programmable SDN wireless network architecture, an efficient secure SDN multi-domain authentication handover mechanism AHMMD is proposed. The general communication process of multi-domain SDN is described and the CtrlAuthen, MNAuthen and AuthInfo protocols are designed. Based on the cooperation communication APIs of the distributed multi-domain control plan, the CtrlAuthen and AuthInfo is implemented. In order to improve the handover efficiency, a SDN multi-domain authentication handover algorithm AHMMD is designed based on the optimal handover trigger time prediction,which ensures the authentication handover and will not affect the communication of host. The experiment results verify the effectiveness and feasibility of AHMMD.

ACKNOWLEDGEMENT

This research was supported in part by the National Natural Science Foundation of China under Grant No. 61402521, Jiangsu Province Natural Science Foundation of China under Grant No. BK20140068.

[1] D. He, C. Chen, S. Chan, et al, “Secure and Efficient Handover Authentication Based on Bilinear pairing Functions,” IEEE Transactions on Wireless Communications, vol. 11, no. 1, 2012,pp. 48-53.

[2] S. Kukliński, Y. Li, KT. Dinh, “Handover Management in SDN-based Mobile Networks,” Proc.GLOBECOM, 2015, pp.194-200.

[3] M. Avula, SG. Lee, SM. Yoo, “Security Framework for Hybrid Wireless Mesh Protocol in Wireless Mesh Networks,” KSII Transactions on Internet and Information System, vol. 8, no. 6, 2014, pp.1982-2004.

[4] D. He, S. Chan, M. Guizani, “Handover Authentication for Mobile Networks: Security and Effi-ciency Aspects,” IEEE Network, 2015, vol. 29, no.3, 2015, pp. 96-103.

[5] CC. Chang, CY. Lee, YC. Chiu, “Enhanced Authentication Scheme with Anonymity for Roaming Service in Global Mobility Networks,” Computer Communications, vol. 32, no. 4, 2009, pp.611-618.

[6] X. Duan, X. Wang, “Authentication Handover and Privacy Protection in 5G HetNets using Software-defined Networking,” IEEE Communications Magazine, Vol. 53, No. 4, 2015. pp. 28-35.

[7] L. Yuhong, W. Haimeng, L. Ming, et al, “Software Defined Networking for Distributed Mobility Management,” Proc. GLOBECOM Workshops,2014, pp. 885-889.

[8] S. Kuklinski, Y. Li, KT. Dinh, “Handover Management in SDN-based Mobile Networks,” Proc.GLOBECOM Workshops, 2015, pp. 194-200.

[9] J. Schulz-Zander, L. Suresh, N. Sarrar, et al, “Programmatic Orchestration of WifiNetworks,”Proc. Usenix Conference on Usenix Technical Conference, 2014, pp.347-358.

[10] DMF. Mattos, LHG. Ferraz. “AuthFlow: Authentication and Access Control Mechanism for Software Defined Networking,” Annals of Telecommunications, vol.71, no. 11-12, 2016, pp. 1-9.

[11] XL. Wang, GM. Zhang, C. Hu, et al, “SDFAC:Software Defined Flow Access Control Mechanism,” Journal of Communications, vol. 36, no.Z1, 2015, pp. 188-196.

[12] K. Pheminus, M. Bouet, J. Leguay, “DISCO: Distributed Multi-domain SDN Controllers,” Proc.Network Operations and Management Symposium, 2014, pp. 1-2.

[13] J. Yan, L. Zhao, J. Li, “A Prediction-Based Handover Trigger Time Selection Strategy in Varying Network Overlapping Environment,” Proc. Vehicular Technology Conference, 2011, pp. 1-5.

[14] JG. Proakis, DG. Manolak, “Digital Signal Processing: Principles, Algorithms and Applications,” Diabetes Care, vol. 25, no. 10, 2002, pp.1802-1806.

[15] Floodlight. Http: //www.projectfloodlight.org/floodlight/.

[16] YH. Li, HM. Wang, M Liu, et al, “Software Defined Networking for Distributed Mobility Management,” Proc. Software defined networking for distributed mobility management, 2013, pp.885-889.

[17] M. Burrows, M. Abadi, R. Needham, “A Logic of Authentication,” ACM SIGOPS Operating Systems Review, vol. 23, no. 5, 1989, pp. 1-13.

[18] V. Jacobson, DK. Smetters, JD. Thornton, et al,“Networking Named Content,” Proc. International Conference on Emerging Networking Experiments and Technologies, 2009, pp. 1-12.

[19] AK. Rangisetti, BH. Bhopabhai, BP. Kumar, et al. “Load-aware Hand-offs in Software Defined Wireless LANs,” Proc. International Conference on Wireless and Mobile Computing, Networking and Communications, 2014, pp. 685-690.

[20] WS. Kim, SH. Chung, CW. Ahn, et al. “Seamless Handover and Performance Anomaly Reduction Schemes Based on OpenFlow Access Point,”Proc. International Conference on Advanced Information Networking and Applications Workshop, 2014, pp. 316-321.

[21] N. Gude, T. Koponen, J. Pettit, et al, “NOX: towards an operating system for networks,” Acm Sigcomm Computer Communication Review, vol.38, no.3, 2008, no. 105-110.

[22] D. Kreutz, FMV. Ramos, P. Esteves-Verissimo, et al, “Software-Defined Networking: A Comprehensive Survey,” Proceedings of the IEEE, vol.103, no. 1, 2014, pp. 10-13.

[23] W. Braun, M. Menth, “Software-Defined Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices,” Future Internet, vol. 6, no. 2, 2014, pp. 302-336.