Introduction
Existing mobility management protocols such as Mobile IPv6 (MIPv6) [1] and Proxy Mobile IPv6 (PMIPv6) [2] have been developed with an assumption that a cellular network architecture is centralized. However, the assumption is being changed. The cellular network architecture is being flattened for better performance and scalability, while there are many reports that centralized network architecture and mobility management protocols cause a network bottleneck and present a single point of failure. To address the centralized mobility management protocol issues, the IETF Distributed Mobility Management (DMM) working group was proposed to develop DMM protocols to operate in a distributed network architecture [3] for intelligent 5G wireless networks [4]–[8]. Some of the important ongoing works of the working group include DMM deployment models and architectural considerations, on-demand mobility management, protocol for forward policy configuration, etc.
In DMM, the data plane and the control plane are separated and the data plane is distributed for better performance and scalability over the network architecture. The control plane however can either be distributed (i.e., fully distributed DMM) or centralized (i.e., semi-distributed DMM) for ease of location management [9], [10]. For instance, in [11], a centralized Session Initiation Protocol (SIP) register has been proposed for a DMM environment. However, the SIP register can be duplicated to improve the reliability but it does not give the level of resilience that can be obtained with a fully distributed architecture. There is thus a need to define an architecture fully compatible with DMM. More details about the background and approaches of DMM are available in [9] and [10]. In addition, as a preliminary work [12], we analyzed the performance of a DMM approach called Dynamic Mobility Anchoring (DMA) [13] in comparison with PMIPv6.
Without securing wireless network access, an illegitimate Mobile Node (MN) can access network resources and launch various attacks. Only an authenticated and authorized MN, i.e., legitimate MN, should be able to access the network resources. For instance, only a legitimated MN registers and updates its location during its handover after secure authentication. If no wireless network access security provided, an illegitimate MN can send malicious location update messages on behalf of a legitimate MN or it can redirect or block data packets related to location updates. To address such issues, in this paper, we propose a secure and fault-tolerant mechanism that uses a distributed hash table of access nodes for distributed location management while a ticket-reuse approach is adopted for improving authentication performance. The main contributions of this paper are as follows:
Fault-tolerant and fully distributed location management based on a Chord Distributed Hash Table (DHT).
Analytical model to calculate the average processing (response) time of a location query.
Ticket-reuse approach designed for distributed location management.
Performance analysis results of the proposal that has been compared with TAP-TLS in terms of authentication latency and number of authentication messages.
The remainder of the paper is organized as follows: Section II briefly describes the literature closely related to our work. Section III presents the analytical model to calculate the processing time of a location query and describes the proposed mechanism. Performance analysis is described in Section IV and the results are presented in Section V. The paper is concluded with some remarks in Section VI.
Related Work
A. Mobility Management and Handover Authentication
A distributed and dynamic location management scheme proposed in [14] reduces the signaling traffic and signaling delay as compared to previously developed schemes. The authors proposed the scheme to distribute the signaling burden by dynamically adjusting regional network boundaries depending on the up-to-date mobility and traffic load for each MN.
The idea of using multiple location servers instead of a centralized home location register is not new. Prakash et al. [15] proposed a distributed location management strategy that is based on quorums and dynamic hashing and has the granularity of a Registration Area (RA). The works presented in [16]–[19] have similar ideas. The main aim of the mechanism in [15] was to provide load balancing among location servers in order to reduce location update and query time.
A dynamic location management scheme is described in [20] for the low mobility rate of an MN and a static scheme is presented for the high mobility rate. According to the authors’ claim, the dynamic scheme performs better than the static scheme for high paging cost or when the number of cells in an Location Area (LA) is large.
Sidhu and Singh [21] describe several metrics such as location update cost and paging cost metrics for location management. The schemes are classified into static and dynamic location update schemes. The static schemes are based on the topology of the network whereas the dynamic schemes are based on time, movement or distance. In [22], a simulation environment is described with a claim that, in terms of location management cost, LA based location management using a profile or history-based direction information gives the best performance. In order to reduce the cost of location updates, a dynamic location management approach has been proposed in [23]. However, the approach slightly increases the paging cost compared to the static approach.
DHT based mechanisms have extensively been proposed to solve different problems in wireless networks. An improved handover management mechanism based on a DHT was proposed in [24]. A DHT based distributed localization service for wireless mesh networks is also proposed in [25]. To reduce the packet loss due to IP handovers, a mechanism utilizing the mobile Stream Control Transmission Protocol (mSCTP) for improved transport and a Chord DHT [26] for location management was proposed in [27]. A two-tier Chord DHT for distributed location management was introduced in [28] that uses the nodes with high computation power and stability as location servers.
For DMM, a SIP-based centralized location server was described in an earlier work of Ali-Ahmad et al. [29]. The main objective of the work in [29] was to reduce the number of location update messages that are sent by MNs to the centralized location server. An analytical model was presented to calculate the load of the location updates.
TAP-TLS [30] is a popular authentication scheme that is widely used in existing wireless mobile networks. It performs the full EAP exchange for initial and handover authentications for an MN. As a baseline authentication scheme, TAP-TLS has been deployed and analyzed, but as studied, this scheme does not provide any performance optimization. For instance, when an MN changes its attachment point, the MN must perform the full EAP exchange that causes a long latency so that user’s quality of experience is degraded. To address this kind of problem, studies on performance optimization in handover authentication have been conducted. For instance, the authentication scheme in [31] utilizes a local credential obtained from an Access Router (AR), i.e., Mobile Access Gateway (MAG) of PMIPv6, in initial authentication when an MN performs handover authentication with another AR in a PMIPv6 environment. In [35], Handover Optimized Ticket-based Authentication (HOTA) has been proposed in which an MN performs handover authentication on different access networks securely by reusing credential issued by authentication server in a PMIPv6 environment.
The proposed work is different compared with the distributed and dynamic location management scheme in [14] as the proposed mechanism considers a fixed-size access network area, i.e., the area covered by the AR. In addition, the proposed mechanism introduces a replication strategy for a distributed and secure location management based on a DHT. Our work is also different compared with the previous DHT based mechanisms [24], [25], [27], [28] as the proposed mechanism considers that all ARs have location registers and extends the DHT to provide fault tolerance in location management. Compared with the existing authentication schemes in [31] and [35], the proposed one is developed for DMM and focuses on providing an application level security.
B. Chord DHT
Chord is a protocol and algorithm for a peer-to-peer DHT. The central pillars of the DHT are
Figure 1 illustrates a 6-bit Chord identifier circle having ten nodes and seven data items. It shows that
A 6-bit Chord identifier space in which the dotted lines indicate which nodes host which keys and the black lines represent the fingers of node
Every node maintains a routing table called a finger table pointing to some other nodes on the identifier circle. The finger table has
Secure and Fault-Tolerant Mechanism
In this section, we present the proposed secure and fault-tolerant mechanism. We choose a finger-table based Chord DHT to implement fault-tolerant distributed location management. Chord is preferred because it is a simple and efficient protocol for storing, updating, and retrieving a location binding of an MN in
In the proposed mechanism, every MN is uniquely identified by its ID information, e.g., SIP-like URI such as SIP:MN0@abc.com or permanent IP address of the MN. The mobile network is made of Access Nodes (ANs). In a centralized mobile network, the Location Register (LR) is a standalone entity. We propose to distribute the LR function on every AN. It means that an AN has both AR and LR functions. MNs can access the Internet through the AR of an AN. An IP prefix is associated to that AR. In other words, when an MN is managed by an AN
The data items are the IDs of the MNs and the nodes are the ANs. We map the keys and ANs on a Chord circle using hash values produced from the IDs of MN and network prefixes of ANs. Each MN has a unique ID,
A. Addition/Update of K-V
Pair
We propose a fault-tolerant distributed location server. We achieve the fault-tolerance through a single level of replication for the location bindings of MNs. The chances that both peers (i.e., ANs), maintaining the main and the backup copies of an MN’s location binding, go down simultaneously are close to zero. So, it is reasonable to consider only a single level of replication.
Figure 2 shows a Chord circle having 8 ANs mapped on it. It shows that the backup copy of a K-V pair, maintained on
Fault-tolerance in the distributed location management. The backup copy of K-V pair is accessed in case of failure of the main copy.
1) Addition/Update of Main Copy
On addition/update of the main copy of K-V pair, the pair is assigned to the peer that is the first successor of
Through the currently attached AN, an MN sends the location registration/update to its default LR. The location information that is stored along with the key is the current IP address of the MN. We call this query as a Location Update Query (LUQ).
When a peer receives a location registration/update query from an MN, it checks whether the address space managed by it includes
An MN is connected with its AN (i.e.,
in Figure 3) to register/update its location.AN8 sends MN’s location registration/update request to its LR.AN8 The LR of
calculatesAN8 . The LR ofK=hash(ID_{MN}) checks whether the address space managed by it includesAN8 . The LR does not find{K} . So,{K} checks its finger-table in order to find the closest successor ofAN8 on the Chord circle. As shown in Figure 3, the closest successor to{K} is{K} .AN43 forwards the locations registration/update query toAN8 .AN43 The LR of
finds out thatAN43 is managed by it. So, it stores/updates the location binding information of the MN.{K} Subsequently, the LR of
replies back the registration acknowledgement on the reverse query path to the MN.AN43
The Location Search Query (LSQ) from a CN is handled in the same way as mentioned above. As a result of the LSQ, the CN gets the current IP address of the MN on providing the
2) Addition/Update of the Backup Copy
On addition/update of the backup copy of K-V pair, the pair is assigned to the peer which is the first successor of
B. Analytical Model for Calculating the Processing Time
In this section, we present an analytical model for calculating the average processing time taken by a Location Query (LQ). An LQ can either be a Location Update Query (LUQ) or a Location Search Query (LSQ). Since, each type of query performs the same type of routing steps in the DHT and undergoes similar type of processing so, in the model, we do not differentiate them and consider each of them as an LQ. An LQ can either have a query-miss on an AN or it can have a query-hit on the AN. In case of query-miss, the AN is called an intermediate AN and in case of query-hit, it is called a final AN. The two types of processing at an AN results in a two-queue based query processing system as shown in Figure 4. Each queue of the system is a deterministic queue having its own service rate. Since the processing steps at an AN are always same, an LQ always takes a constant service time for processing while being in service. The symbols that are used in the analytical model are listed in Table 1.
The two-queue based query processing system wherein
We assume that LQ requests arrive at an AN according to a Poisson process. The process results naturally when a reasonably large population of the MNs update their locations independently and a reasonably large population of the CNs search for the locations of the MNs independently. Since there is no practical evidence that the pattern of arrivals of LQ requests on an AN follows any special distribution, but there are strong indications that a cellular network have a large numbers of MNs, the Poisson assumption holds.
Let \begin{equation} \lambda _{LQ} = \lambda _{LSQ}+\lambda _{LUQ} \end{equation}
Let \begin{equation} \lambda = \frac {\lambda _{LQ} N_{MN}}{N_{AN}} \end{equation}
Let \begin{equation} N_{DHT} = \left \lceil{ \frac {N_{AN}}{\log (\log (N_{AN}))} }\right \rceil \end{equation}
Let \begin{equation} W_{i} = \frac {1}{\mu _{i}}+\frac {\rho _{i}}{2\mu _{i}(1-\rho _{i})} \end{equation}
Let \begin{equation} W_{f} = \frac {1}{\mu _{f}}+\frac {\rho _{f}}{2\mu _{f}(1-\rho _{f})} \end{equation}
Let \begin{equation} \Theta = (N_{DHT} \times N_{hops} \times R_{delay}) + (N_{DHT}\times W_{i}) + W_{f} ~ \end{equation}
C. Adding Security
We present Ticket-based Authentication for Location Management (TALM) of the proposal. The authentication process can be divided into two parts. As explained in Section III, we define
Authentication at the time of expiry of the required security credentials (for performing authentication) of an MN or at the first time the MN is switched on (Ticket creation and expiry).
Authentication at the time of an IP handover of an MN in which the MN has to obtain the required security credentials from the previous AR (Ticket collection from the previous AR).
The symbols that are used in TALM are listed in Table 2. We assume that the keys shared between the Authentication Server (AS) and the MN,
1) Ticket Creation and Expiry
Following are the steps of TALM for ticket creation and expiry.
An initial message
is sent from the MN to the AR when the MN has just been switched on and needs to register itself with the AR or MN is creating a new ticket due to the expiry of the previous ticket.(MN_{Reg}) where\begin{equation*}MN -> AR: MN_{Reg}(ID_{MN} || ID_{AR} || N_{MN})\end{equation*} View Source\begin{equation*}MN -> AR: MN_{Reg}(ID_{MN} || ID_{AR} || N_{MN})\end{equation*}
is the nonce generated by the MN.N_{MN} As the AR receives this initial message, it adds its own nonce and creates a message
to be sent to the AS:(MN_{Reg}AS_{Msg}) The AR encrypts this message before sending to the AS using the key it shares with the AS.\begin{align*}&\hspace {-0.7pc}AR -> AS: MN_{Reg}AS_{Msg}(E (K_{AR-AS}, ID_{MN}||\\&\qquad \quad \qquad \qquad \qquad \qquad \qquad ID_{AR}||N_{MN}|| N_{AR}))\end{align*} View Source\begin{align*}&\hspace {-0.7pc}AR -> AS: MN_{Reg}AS_{Msg}(E (K_{AR-AS}, ID_{MN}||\\&\qquad \quad \qquad \qquad \qquad \qquad \qquad ID_{AR}||N_{MN}|| N_{AR}))\end{align*}
The AS generates the following ticket:
This ticket is encrypted using another key\begin{equation*} TK = E(K_{TK},K_{MN-AR}||ID_{MN}||TT)\end{equation*} View Source\begin{equation*} TK = E(K_{TK},K_{MN-AR}||ID_{MN}||TT)\end{equation*}
. Inside this ticket isK_{TK} (that is shared between the MN and AR) and the time TT for which this ticket is valid. The AS wants to transmit theK_{MN-AR} to both the MN and the AR. Since, sending important data such as a key over the network is not safe, we useK_{MN-AR} .K_{TK} Now the AS will send a message
to send(AS_{Res}) to the AR by encrypting it using the key it shares with the AR:K_{MN-AR} The AR will only be able to extract\begin{align*} AS -> AR: AS_{Res}(ID_{MN} || TK || E (K_{MN-AS}, K_{MN-AR} || \\ ID_{AR} || TT || N_{MN}) || E (K_{AR-AS}, K_{TK} || TT ||N_{AR}))\end{align*} View Source\begin{align*} AS -> AR: AS_{Res}(ID_{MN} || TK || E (K_{MN-AS}, K_{MN-AR} || \\ ID_{AR} || TT || N_{MN}) || E (K_{AR-AS}, K_{TK} || TT ||N_{AR}))\end{align*}
part of the message. Once the AR gets\begin{equation*}E(K_{AR-AS}, K_{TK} || TT || N_{AR})\end{equation*} View Source\begin{equation*}E(K_{AR-AS}, K_{TK} || TT || N_{AR})\end{equation*}
, it can decrypt TK and extractK_{TK} (the key it shares with the MN).K_{MN-AR} Now the AR will communicate
to the MN using (RegRes) message:{K} Using its key with the AS, the MN will be able to extract\begin{align*}&\hspace {-0.5pc}AR -> MN: RegRes (ID_{MN} || TK || \\&\qquad \quad \qquad E (K_{MN-AS}, K_{MN-AR} || ID_{AR} || TT || N_{MN}))\end{align*} View Source\begin{align*}&\hspace {-0.5pc}AR -> MN: RegRes (ID_{MN} || TK || \\&\qquad \quad \qquad E (K_{MN-AS}, K_{MN-AR} || ID_{AR} || TT || N_{MN}))\end{align*}
.K_{MN-AR} Now both AR and MN have
and both have knowledge of the ticket’s expiry. A last message (AuthMsg) will be sent by the MN to the AR to authenticate itself along with a location update message.K_{MN-AR} \begin{align*}&\hspace {-1.7pc}MN -> AR: AuthMsg (ID_{AR} || TK || E (K_{MN-AR},\\&\qquad \qquad ID_{MN} || IP-Addr || (N+1)_{MN}))\end{align*} View Source\begin{align*}&\hspace {-1.7pc}MN -> AR: AuthMsg (ID_{AR} || TK || E (K_{MN-AR},\\&\qquad \qquad ID_{MN} || IP-Addr || (N+1)_{MN}))\end{align*}
If the AR successfully decrypts this message, then the MN has successfully authenticated itself. IP-Addr is the current IP address of the MN, which is securely sent. Nonces are used in the messages to prevent man-in-the-middle replay attack. The flow of the messages is shown in Figure 5.
2) Ticket Collection from a Previous AR
Following are the steps of TALM for ticket collection from previous AR.
The MN sends a message
to the nAR (newly attached AR of the MN), which does not know about(nAR_{Reg}) .K_{MN-AR} where\begin{equation*}MN -> nAR: nAR_{Reg}(TK || ID_{MN} || N_{MN}+1)\end{equation*} View Source\begin{equation*}MN -> nAR: nAR_{Reg}(TK || ID_{MN} || N_{MN}+1)\end{equation*}
is a nonce generated by the MN.N_{MN} The nAR receives the message and sends a message
to the pAR (previously attached AR of the MN), which has(MN_{Reg-pAR}) .K_{MN-AR} \begin{align*}&\hspace {-0.5pc}nAR ->pAR: MN_{Reg-pAR} (E (K_{pAR-nAR},\\&\qquad \qquad \qquad \qquad \qquad \qquad \qquad ID_{MN} || N_{MN}+1))\end{align*} View Source\begin{align*}&\hspace {-0.5pc}nAR ->pAR: MN_{Reg-pAR} (E (K_{pAR-nAR},\\&\qquad \qquad \qquad \qquad \qquad \qquad \qquad ID_{MN} || N_{MN}+1))\end{align*}
The pAR sends the message
back to the nAR by adding the information about the time for which the ticket is valid and(MN_{RegRes}) . The pAR encrypts this using the key it shares with the nAR.K_{TK} \begin{align*}&\hspace {-0.5pc}pAR ->nAR: MN_{RegRes} (E (K_{pAR-nAR}, \\&\qquad \qquad \qquad \qquad \qquad \qquad \qquad ID_{MN} || TT || K_{TK}))\end{align*} View Source\begin{align*}&\hspace {-0.5pc}pAR ->nAR: MN_{RegRes} (E (K_{pAR-nAR}, \\&\qquad \qquad \qquad \qquad \qquad \qquad \qquad ID_{MN} || TT || K_{TK}))\end{align*}
The nAR decrypts the message to get the ticket using the key it shares with the pAR. Once, it gets
, it decrypts TK and extractsK_{TK} . The flow of the messages is shown in Figure 6.K_{MN-AR}
In this section, we have proposed a protocol which makes the proposed location management secure. We have illustrated how an MN interacts with an AR and how a ticket is generated by the AS for a user session. We have also illustrated how a ticket can be reused to reduce authentication latency. In the next section, we evaluate the performance of TALM.
Performance Evaluation
In this section, we compare TALM with TAP-TLS. The EAP-TLS based authentication performs EAP exchange between an MN and its AS; there is no concept of ticket reuse in EAP-TLS. Typically a successful TAP-TLS authentication has four steps of authentication process [35]. For the authentication related performance metrics, the simulation program is written in C++ and the simulation time is one year. We also calculate the average LQ processing time using the analytical model. The performance metrics are listed below:
Authentication latency (
): Authentication latency is the latency to create a ticket (by an MN to authenticate itself to the AR for the first time), or renew a ticket when it is expired, or regain a ticket (from previous AR) in case of an IP handover. IP handover occurs when an MN changes its point of network access. The average authentication latency is calculated by dividing the cumulative authentication latency over a period of time by the total number of location update messages in that time period.L_{auth} Number of authentication messages per location update message (
): The number of authentication messages (requiring TALM protocol steps) in a time period is the number of times an MN authenticates itself to an AR in cases of ticket creation, ticket renewal, and ticket collection (from previous AR) in that time period. The number of authentication messages per location update message is calculated by dividing the total number of authentications (performed by an MN) by the total number of location update messages (sent by an MN) within a time period.N_{auth} Average LQ processing time (
): It is the average response time of an LQ.\Theta
A. Calculation of Authentication Latency for TALM
Let nhops be the number of hops between the AR and the AS,
We use the same parameter settings as defined in [35]. We select the value of nhops in the interval [5], [9],
There can be
For MN to AS message transmission, the delay is divided into two parts. First, when a message is sent by an MN to the AR and second, when the message is sent to the AS from an AR. This transmission delay is
Following is the order of messages for a ticket creation:
MN -> AR; 1\,\,hop, 0.02s AR -> AS; n\,\,hops, n\times 0.02s AS -> AR; n\,\,hops, n\times 0.02s AR -> MN; 1\,\,hop,0.02s MN -> AR; 1\,\,hop, 0.02s
As the message transmission delay per hop is
Following is the order of messages for a ticket creation:
MN -> nAR; 1\,\,hop, 0.02s nAR -> pAR; 1\,\,hop, 0.02s pAR -> nAR; 1\,\,hop, 0.02s
The ticket collection time (from the previous AR)
B. Calculation of Authentication Latency for TAP-TLS
The initial authentication delay is the authentication delay when an MN creates or renews (on its expiry) a ticket. As calculated in [35], it is
As calculated in [35], the handover authentication delay in EAP-TLS
C. Calculation of the Average LQ Processing Time
Our choice of the parameter settings are comparable in magnitude with the ones defined in [11], [12], and [35]. We select
In order to compute the values of
The implementation is done on a standard hardware — Intel Core i3 CPU
Results and Discussion
We now present the network topology, the parameter settings, the results of the simulations, and our discussion of the results.
A wrapped-around cellular network topology of 19 hexagonal ANs is used in the simulations as shown in Figure 7.
For the simulations, we choose the AN-Area residence time
A. Average Authentication Latency
We compare the average authentication latency of TALM with that of EAP-TLS. The variable parameter of this experiment is nhops. The results of this experiment are shown in Figure 8. With the increase in nhops, the average authentication latency for both the protocols increases. The results show that TALM performs better than TAP-TLS. We calculate the simulation results of TALM with 95% confidence interval as shown in Figure 8. The percentage reduction in authentication latency by TALM is nearly equal to 99%. This is mainly due to the reuse of the authentication ticket in TALM.
B. Average Number of Authentication Messages
Figure 9 shows the average number of authentication messages per location update as the lifetime of a ticket varies. With the increase in the lifetime of the ticket, the average number of authentication messages per location update decreases. For bigger lifetime of a ticket, an MN faces less number of authentication ticket expiries than the number of the expiries when the lifetime is less.
Figure 10 shows the effect on average number of authentication messages per location update when the velocity of an MN is varied. We can see that the average number of authentication messages increases with the increase in the velocity. This is due to the reason that with the increase in velocity, the MN experiences more IP handovers. Hence, the MN performs more handover authentications and it results in the increase of the average number of authentication messages.
Figure 11 shows the effect on average number of authentication messages per location update when the area of an AN is varied. We observe that the average number of authentication messages decreases with the increase in the AN-Area. This is due to the reason that with the increase in the AN-Area, an MN experiences less IP handovers. Hence, the MN performs less number of handover authentications and it results in the decrease of the average number of authentication messages.
C. Average LQ Processing Time
We vary
Then, we vary
Last but not the least, we vary
Conclusion
In this paper, we have proposed a new mechanism for secure and fault-tolerant operations for DMM. The proposed mechanism utilizes a distributed hash table of access nodes for distributed location management. It is mapping the network prefixes of the access nodes and the location binding information of the MNs on a Chord circle. A replication strategy has been described for the proposed mechanism. The distribution of location server is important as it addresses the limitations and weaknesses of a central location server like single point of failure and attack, traffic bottleneck resulting in long delays in the additions and update of location binding information of MNs, and long response times of location queries that are sent by the CNs. The analytical model that has been used to calculate the average processing (response) time of a location query can help in designing and planning the processing requirements on an AN in future 5G networks.
The proposed mechanism also adopted a ticket-reuse approach called TALM for improving authentication performance while providing secure authentication of MNs. It provides security to the location additions and updates on the wireless link between an MN and its AR. The work is important as it reduces the latency of the authentication process and the number of authentication messages that are sent for a location update message. The results demonstrate significant performance gain of the proposed protocol as compared to a non-ticket based existing wireless authentication protocol, TAP-TLS. In order to replace all centralized components with their distributed counterparts for future 5G networks, it is desirable to have a distributed authentication service for secure handovers.
ACKNOWLEDGEMENTS
The authors are thankful to Prof. Renato Lo Cigno (DISI, University of Trento, Italy) for his guidance related to the analytical modeling part of the manuscript.