A Protocol for Secure Seamless Handover - CiteSeerX
A. R. Prasad, H. Wang: A Protocol for Secure Seamless Handover, in Proc. of The 2004 International Conference on Security and Management (SAM'04), Las Vegas, USA, June 21-24, 2004.
A Protocol for Secure Seamless Handover Anand R. Prasad and Hu Wang DoCoMo Comm. Labs Europe GmbH Munich, Germany Email: {prasad |wang}@docomolab-euro.com
Abstract This paper proposes a secure seamless handover protocol for heterogeneous networks and technologies. The proposed protocol also works for inter-domain handover; where a domain represents an administrative domain. Message sequence of the proposed protocol is given in the paper for different trust relations that can exist between the involved domains. Decision method for handover and methods for context transfer are also proposed in the paper.
1. Introduction A variety of radio access technologies will constitute the Beyond 3G (B3G) mobile communication systems underneath a common IP layer. B3G has three characteristics (see Figure 1), (1) Variety of access technologies and their networks will work together (heterogeneity) (2) Different administrative domains (in rest of the paper administrative domain will be referred to as domain) will exist. Where an administrative domain is an autonomous network infrastructure; it can constitute of various access technologies and their networks. (3) There will be mobility of users between different access technologies of same or different domains. One of the requirements of B3G is to provide a seamless handover across different access technologies and domains without compromising the security. The seamless handover requirement should be fulfilled even though each access technology and network has its own security solution and each domain can have its own security policies and services that it provides. There is on-going work in the field of Vertical Handover (VHO) [1-14], i.e., handover between different access technologies. The IETF WG Seamoby is working on seamless mobility [4-6] at IP layer and is not looking at the issues of different trust relations. IEEE 802.11f recommendation discusses context transfer [7] that can support fast handover
but the solution is only for Wireless Local Area Networks (WLANs) and for intra-domain scenario. Wi-Fi Alliance, [8], has prepared a recommendation for inter-domain roaming, i.e., the connection is not alive when the user moves from one domain to other. IETF ROAMOPS WG had proposed similar solutions in 1996, [9]. In IEEE 802 Handoff ECSG, [10-11], work was presented on context transfer but not on seamless handover mechanism using context parameters. Study in this group is still in its infancy. 3GPP, [12-13], is working on WLAN interworking but a solution for seamless handover is not yet discussed. Some research work is going on in the field of context transfer for fast handover and creation of trust but currently no complete solution exists in the open literature that fulfills the seamless handover requirement of B3G [1-3,14]. The problem of seamless handover basically means fast handover such that the user does not perceive any change in service quality. Context parameters must be transferred between the participating networks so as to provide fast handover with seamless service continuity and methods should be deployed to do it securely [2,5-7,11,14]. Also the Trust relationship between administrative domains User mobility between administrative domains Adm. Domain 1
Administrative Domain 2
IP as a common layer to all technologies, administrative domains and users
IP Layer
WLAN
FWA
An administrative domain constitutes of different access technologies and their networks
WWAN
Various access technologies providing different services
Coverage increase with technology type Interworking between technologies/networks User mobility between technology/networks
Figure 1 Beyond 3G scenario.
trust relation between the involved domains should be taken in account [2]. As per this paper the involved domains are: (1) the Serving Network (SN), where the user is now, (2) the Target Network (TN), where the user can move to and (3) the Service Provider (SP) network. For the handover to take place, it is necessary that the SN and the TN have trust relations with the SP. Trust should also exist between the user and the the TN; this can be achieved by providing methods for fast mutual authentication. This paper proposes a protocol for secure and seamless handover. The protocol proposed in this paper takes in account the heterogeneity in radio access technologies, different domains and their trust relations. The protocol is divided in four phases: trust, discovery, decision and commencement. A decision method based on several parameters and different context transfer methods are discussed in this paper. Note that the proposal presented in this paper is a generic one and gives a framework on methods to perform secure seamless handover. Further study should be done to apply the proposed protocol on different technologies, performance study and optimization should also be performed. The paper is organized as follows: In Section 2 an introduction is given to handover, context parameters are also explained and requirements are given for secure seamless handover. The seamless handover protocol is proposed in Section 3. Section 4 studies fulfillment of the requirements and the paper is concluded in Section 5.
2. Handover, Context and Requirements This section explains handover mechanisms, context parameters and proposes requirements for secure seamless handover.
2.1.
Handover
Handover is a basic mobile network capability for dynamic support of terminal migration, while handover management is a process of initiating and ensuring a seamless and lossless handover of a mobile terminal from one wireless Access Point (AP) or Base Station (BS) to another. Handover procedures involve a set of protocols to notify all related entities of a particular connection of which it has been executed. A discussion of handover can be found in [3]. For heterogeneous networks, handover
can be classified in horizontal and vertical ones. Handover can take place within a domain, i.e., intradomain handover or between different domains, i.e., inter-domain handover. An example of inter-domain VHO is the one between a 3G network and a WLAN where 3G is owned by a Mobile Network Operator (MNO) and WLAN is owned by a Wireless Internet Service Provider (WISP).
2.2.
Context Parameters
There can be different types of context parameters, e.g., security parameters or QoS parameters like Bit Error Rate (BER), Signal to Interference Ratio (SIR) or even required Mean Opinion Score (MOS). Security context is used to support trust relation in distributed networks and to provide communication security. The contents of security context include authentication state, authorization results, cryptographic (session) keys and algorithms. Usually security context is negotiated when creating a communication association and shared by two or more parties. When creating a new security context, authenticity and integrity of the information must be ensured and confidentiality of some or all of the information is typically required [2,14].
2.3.
Proposed Requirements
Proposed requirements for secure seamless handover are: (i) ease of access to applications from all locations with required security and acceptable QoS at all times, (ii) handover must not compromise security of involved networks and terminal, as a whole it should not compromise security of B3G systems, (iii) unified billing, (iv) minimal effect on overall performance and resource of network and device, (v) no user intervention, while also allowing users to configure which networks they would like to use, (vi) fast mutual authentication, (vii) using priority to transfer security context for seamless service, (viii) handover decision should consider the security requirement of user and service.
3. Proposed Seamless Handover Protocol The proposed protocol goes through four phases: trust, discovery, decision and commencement. Creation of trust on-the-fly is not discussed in this paper and discovery of TN is based on standard procedures [3]. The novelty of the proposed protocol is in the decision method and parameters used and in
SN
TN
SN
TN
Trust type 1
Trust type 2
SP
SP
SN
3.3.
SP
SP
TN
Trust type 3
SN
TN
Trust type 4
Delegated trust Context transfer
Figure 2 Possible trust relations between SN, TN and SP and context transfer.
the commencement phase. This section discusses the four phases of the proposed protocol.
3.1.
Trust
This section discusses the trust relation required to perform seamless handover. Note that trust creation on-the-fly is not proposed in this paper. Trust relation is normally created beforehand mostly by owners of two domains signing contract but trust could also be created on-the-fly, e.g., by Public Key Infrastructure (PKI). For seamless handover there must be trust relation among SN, TN and SP. There are three possible trust relations: SN, TN and SP have prior trust relation (Trust type 1). SN has trust relation with TN and SP but TN and SP do not have trust relation (Trust type 2); in this case it is possible that SN can delegate trust between TN and SP. TN and SN do not have prior trust relation (Trust type 3); it is possible for SP to delegate trust between TN and SN. Same as Trust type 3 except that SP could transfer the context parameters from SN to TN (Trust type 4). These trust types are also depicted in Figure 2.
3.2.
Discovery
Discovery of TNs (there can be more then one) can happen by the device having 2 or more active radio interfaces, active either simultaneously or periodically, or through announcement of TNs by the SN which can be in the form of a beacon or a specific message giving detailed information of the TN. The SN (for example, another or the same access technology of SN) can also be part of the TN. A device can also discover a TN.
Decision
After TN is discovered, decision can take place. For the purpose of decision certain measurements must be done, either continuously or periodically. In this section measurement parameters, decision parameters and decision procedure are proposed. 3.3.1. Measurement So as to perform optimum handover decision it is proposed to measure the following parameters: Location of a device; this can give the information about the networks a device can access. Speed of the device; gives the time within which a device will pass through the coverage area of a SN and a TN. Direction of motion; gives information of the TNs the device will come in contact with and the coverage area of the TN that the device will first approach. The three parameters (location, speed and direction) together give an estimate of the time duration within which a device might leave the SN or even TN based on this information a handover might or might not be performed. Example: If the device is moving very fast a handover to WLAN networks will make no sense because normally WLAN coverage is very small and the device might leave the network very soon or it is also possible that the device direction is such that it might only stay in TN for a very short period. The estimate of time duration can also be seen as available time for context transfer. Network latency gives the information on delay in transfer of context. Based on delay and available time it is possible to derive the extent to which context can be transferred, i.e., if time is not enough context might be transferred partially. Signal quality should also be measured. This can be a combination of packet error rate and signal strength. If possible to measure, the perceived service quality would be the best criteria for handover. 3.3.2. Decision Parameters It is proposed that decision should be made on measured data discussed above and on the following parameters: Device capability, if the device only has capability for voice then handover from cellular to WLAN should not be performed. Type of service, it is possible that a TN cannot provide the service a device is accessing
Start measurement and decision: Device or network
A: Device or SN part of decision
1. Check network latency 2. Check location 3. Check device speed 4. Check direction of motion 5. Check signal quality
Mobile stays long enough in TN?
Yes No
Signal and/or service quality good enough? No
No
Device capable for new network?
Yes Yes Network latency low enough?
No
B
No Handover
Yes
A
B: device or TN part of decision
A
Yes
Yes
Perform handover with all Context Transfer
Perform handover. Send quick/ partial context such that context reaches TN on time for handover/ before signal loss
TN can provide the service?
Yes
TN has resources for the service?
No
Yes
TN can maintain SLA?
Yes
TN can provide service cheaper (same quality) or better?
No Handover
Figure 3 Measurement and decision.
TN resources and Service Level Agreement (SLA), will give the information if a TN has the resources to provide the required service and if it can fulfill the SLA. Map information, e.g., an automobile with Global Positioning System (GPS) where the user has put the route he/she plans to take, could also be used for better planning of handover networks 3.3.3. Basic Decision As basic decision procedure it is proposed that the handover must take place if the device approaches the border of the network. When there is overlay situation, the network that gives best service quality (including cost) must be chosen. The handover is performed only if: (1) the device is capable of handover, (2) the TN fulfills all the criteria, (3) the TN is ready to accept the device
based on trust relation and subscription and (4) measurement values show that handover can happen. 3.3.4. Handover Decision Mechanism A flowchart of the proposed decision mechanism is given in Figure 3 and the message sequence is given in Figure 4. Parameters based on which handover should be performed are discussed below. Depending on the type of system being considered, the propose handover of decision can be made by the device, the SN or the TN. As discussed in Section 3.3.1 the device or the SN should measure the speed, the location and the direction of the device. This gives an estimate of the available time for context transfer and an estimate of time within which a device will pass through a TN. If the length of stay of a device within a TN is not long enough then handover should not be performed. Further if the signal quality and the service quality are deteriorating fast then handover must be performed at once. Network latency together with available time will give the extent of context that can be transferred. The capability of the device and TN must be checked and compared either by the device or the SN; it is possible that the device does not have the required air interface in which case handover should not be performed. The TN should check if it has enough resources to provide the service. TN should also check if it can maintain the SLA, this check can also be performed by SN. In overlay situation the cost of service should also be checked. Once decision has been taken to perform handover then context parameters are sent to the TN. It is possible that not all context parameters can be sent. The amount of context parameters to be transferred will depend on the urgency of handover (service and signal quality), location, speed and direction and network latency.
3.4.
Commencement
Once decision of handover has been made, context parameter transfer can take place which will be followed by actual handover and commencement of communication in the TN. In this section the proposed commencement process and message sequence charts are given. For each handover following steps occur: (1) context parameters are transferred before handover and (2) the SP is informed about handover as SP should know where to send data. So as to decrease signaling, this step can also be combined with the
step where normal communication is resumed. The message sequence is given in Figure 5. Mutual authentication is performed between the TN and the device so as to prevent, for example, rogue network, intruder to network and session hijacking during handover. As authentication can be time consuming, fast mutual authentication information is created by the SN and passed to the TN; it is also possible that this information is created by the TN Serving Network (SN)
Device
Target Network (TN)
Service Provider (SP)
and is passed via the SN to the device. This step is done during decision phase, see Figure 4. 3.4.1. Context Transfer Methods There are two proposed methods of deciding the context to be transferred: (1) decide independent and dependent context based on domains, access technology and network and (2) give priority to context based on a policy. A combination of these two methods can also be used. Serving Network (SN)
Device
Decision: Trust 1
Target Network (TN)
Decision: Trust 2
2a. Performs decision if device based.
2a. Performs decision if device based.
2b. Request handover (decision if device based)
2b. Request handover (decision if device based)
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based. If SN, TN and SP know about trust relationship this step is not required.
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based.
3. Check TN trust with SP and inform handover initiation
3. Check TN trust with SP and inform handover initiation 4. NACK trust
4. ACK trust 5. Request handover
5. Create trust between TN and SP
6. Check trust. Make decision. Create mutual auth. Parameters.
5'. NACK (reason)
6. Request handover
7. ACK (required info) or NACK (reason) E.g. for IEEE 802.11 this might include information like SSID, WEP key etc.
7'. NACK (reason)
7. Check trust. Make decision. Create mutual auth. Parameters. 8. ACK (required info) or NACK (reason)
E.g. for IEEE 802.11 this might include information like SSID, WEP key etc.
8'. NACK (reason)
Serving Network (SN)
Device
Service Provider (SP)
Target Network (TN)
Service Provider (SP)
Serving Network (SN)
Device
Decision: Trust 3
Target Network (TN)
Service Provider (SP)
Decision: Trust 4
2a. Performs decision if device based.
2a. Performs decision if device based.
2b. Request handover (decision if device based)
2b. Request handover (decision if device based)
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based.
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based.
3. Check TN trust with SP and inform handover initiation
3. Check TN trust with SP and inform handover initiation 4. Inform handover
4. Create trust between SN and TN
5. Check trust. Make decision. Create mutual auth. Parameters.
5. Request handover 6. Check trust. Make decision. Create mutual auth. Parameters.
6. ACK (required info) or NACK (reason)
7. ACK (required info) or NACK (reason) 7'. NACK (reason)
7. ACK (required info) or NACK (reason) E.g. for IEEE 802.11 this might include information like SSID, WEP key etc.
7'. NACK (reason)
Figure 4 Decision phase message sequence for the four trust types.
Device
Serving Network (SN)
Target Network (TN)
Service Provider (SP)
Commencement: Trust 1, 2, 3 This is for mutual auth. if it is done by TN then no need to do it here
8. Create security parameters if required 9. Context and new security parameters transfer
4. Fulfillment of Requirements
10. ACK 11. ACK handover (required info + new security parameters) 12. Mutual authentication
13. Handover inform 14. ACK handover
Resume normal communication
Device
Serving Network (SN)
Target Network (TN)
Service Provider (SP)
Commencement: Trust 4 This is for mutual auth. if it is done by TN then no need to do it here
Priority should be given to a context or a set of context (a context set is context parameters that are dependent of each other) based on their effect on seamless handover. Priority policy should be used for giving prioritization; this can be based on the service type, SLA, the TN and the access technology being used, the domains or other parameters.
8. Create security parameters if required
9. Context and new security parameters transfer 10. Context and new security parameters transfer 11. ACK 12. ACK context reception 13. ACK handover (required info + new security parameters) 14. Mutual authentication
15. Handover inform 16. ACK handover
Resume normal communication
Figure 5 The commencement phase.
Independent context should be chosen based on the kind of access technology, network and domain e.g. security related context parameters in 3G mobile communication systems cannot be entirely used in IEEE 802.11 WLAN systems. Further if it is the same domain then any type of context transfer should not be an issue but in case of handover between different domains security policy might prevent certain context parameters from being transferred.
In this section the extent of fulfillment of requirements, given in Section 2.3, by the proposed protocol is discussed. (i) The proposed protocol fulfills the first requirement as that is the main purpose of defining the proposed protocol. It does mean that interworking of the proposed protocol with the security and AAA mechanisms in use is required. Such interworking mechanism will be technology/network/domain dependent and is a part of future study. (ii) Security measures must be taken when transferring context, off-the-shelf techniques can be used for this purpose. The protocol recommends creation of mutual authentication parameters for quick handover. Thus combined with off-the-shelf techniques this requirement can be met. (iii) With the provision of mutual authentication and trust relation between the networks it will be possible to provide unified billing. (iv) The overall effect on performance should be studied in depth. During implementation certain messages can be combined so as to give an even better performance. (v) With the temporary security parameters and mutual authentication information being given to the device and with the transfer of context parameters between the networks user intervention is not required. Thus, this requirement is also met by the proposed protocol. (vi) Mutual authentication parameters are given to the device and the TN which allows both fast handover and mutual authentication between the device and TN. (vii) A method of context transfer is also proposed in the paper, depending on the policy of prioritization and choice of independent context parameters the most important security parameters will be transferred. (viii) The handover does consider SLA which includes the security requirement of the user and the service.
5. Conclusions This paper proposes a secure seamless handover protocol for inter-domain and inter-technology handover. Message sequence of the protocol is
discussed in the paper. The paper also proposes decision methods and context transfer methods. Security requirements for seamless handover are also proposed in the paper. The extent of fulfilment of these requirements by the proposed protocol is also studied in the paper. It is quite understandable that currently few features of the proposed protocol cannot be optimally used but in future such seamless handover protocols will be of prime importance. The proposed protocol will depend on technology thus the ideas presented in the paper should be considered as a framework. Detail study on application of the protocol for different technologies should be done together with optimization of parameters. Further study should be done in this field while taking in account the possible services future mobile communications systems can provide and those desired by the users.
References [1] M. Stemm, and R. H. Katz, “Vertical Handoffs in Wireless Overlay Networks”, ACM Mobile Networks and Applications (MONET), vol.3, No.4, pp.335-350, 1998. [2] P. Nikander, and L. Metso, “Policy and trust in open multi-operator networks”, Proceedings of IFIP SmartNet 2000, pp.419–436, Vienna, Austria, Kluwer Academic Publishers, September 2000. [3] K. Pahlavan, P. Krishnamurthy, A. Hatami, M. Ylianttila, J. P. Makela, R. Pichna, and J. Vallström, “Handoff in hybrid mobile data networks”, IEEE Personal Communications, vol. 7, issue 2, pp.34–37, April 2000.
[4] IETF Seamoby WG: http://www.ietf.org/html.charters/seamobycharter.html. [5] J. Kempf (ed.), “Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network”, RFC3374, September 2002. [6] J. Loughney (ed.), M. Nakhjiri, C. Perkins, and R. Koodli, “Context Transfer Protocol”, draft-ietfseamoby-ctp-01.txt, March 2003. [7] IEEE 802.11f, “Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation”, P802.11f, January 2003. [8] WISPr, Best Current Practices for Wireless Internet Service Provider (WISP) Roaming, February 2003, v1.0, Wi-Fi Alliance. [9] Roaming Operations (ROAMOPS), http://www.ietf.org/proceedings/97dec/97dec-final79.htm. [10] IEEE 802 Handoff ECSG, http://www.ieee802.org/handoff/. [11] B. Aboba, and T. Moore, “A Model for Context Transfer in IEEE 802”, Internet Draft, expired, draftaboba-802-context-02.txt, April, 2002. [12] 3GPP TS 23.234, “3GPP system to Wireless Local Area Network (WLAN) Interworking; System Description”, v.1.3.0, January 2003. [13] 3GPP TS 22.129, “Handover Requirements between UTRAN and GERAN or other Radio Systems”, v.5.2.0, June 2002. [14] H.Wang and A.R. Prasad, “Security Context Transfer in Vertical Handover”, PIMRC 2003, Sept. 7-12, Beijing, China.
A Protocol for Secure Seamless Handover Anand R. Prasad and Hu Wang DoCoMo Comm. Labs Europe GmbH Munich, Germany Email: {prasad |wang}@docomolab-euro.com
Abstract This paper proposes a secure seamless handover protocol for heterogeneous networks and technologies. The proposed protocol also works for inter-domain handover; where a domain represents an administrative domain. Message sequence of the proposed protocol is given in the paper for different trust relations that can exist between the involved domains. Decision method for handover and methods for context transfer are also proposed in the paper.
1. Introduction A variety of radio access technologies will constitute the Beyond 3G (B3G) mobile communication systems underneath a common IP layer. B3G has three characteristics (see Figure 1), (1) Variety of access technologies and their networks will work together (heterogeneity) (2) Different administrative domains (in rest of the paper administrative domain will be referred to as domain) will exist. Where an administrative domain is an autonomous network infrastructure; it can constitute of various access technologies and their networks. (3) There will be mobility of users between different access technologies of same or different domains. One of the requirements of B3G is to provide a seamless handover across different access technologies and domains without compromising the security. The seamless handover requirement should be fulfilled even though each access technology and network has its own security solution and each domain can have its own security policies and services that it provides. There is on-going work in the field of Vertical Handover (VHO) [1-14], i.e., handover between different access technologies. The IETF WG Seamoby is working on seamless mobility [4-6] at IP layer and is not looking at the issues of different trust relations. IEEE 802.11f recommendation discusses context transfer [7] that can support fast handover
but the solution is only for Wireless Local Area Networks (WLANs) and for intra-domain scenario. Wi-Fi Alliance, [8], has prepared a recommendation for inter-domain roaming, i.e., the connection is not alive when the user moves from one domain to other. IETF ROAMOPS WG had proposed similar solutions in 1996, [9]. In IEEE 802 Handoff ECSG, [10-11], work was presented on context transfer but not on seamless handover mechanism using context parameters. Study in this group is still in its infancy. 3GPP, [12-13], is working on WLAN interworking but a solution for seamless handover is not yet discussed. Some research work is going on in the field of context transfer for fast handover and creation of trust but currently no complete solution exists in the open literature that fulfills the seamless handover requirement of B3G [1-3,14]. The problem of seamless handover basically means fast handover such that the user does not perceive any change in service quality. Context parameters must be transferred between the participating networks so as to provide fast handover with seamless service continuity and methods should be deployed to do it securely [2,5-7,11,14]. Also the Trust relationship between administrative domains User mobility between administrative domains Adm. Domain 1
Administrative Domain 2
IP as a common layer to all technologies, administrative domains and users
IP Layer
WLAN
FWA
An administrative domain constitutes of different access technologies and their networks
WWAN
Various access technologies providing different services
Coverage increase with technology type Interworking between technologies/networks User mobility between technology/networks
Figure 1 Beyond 3G scenario.
trust relation between the involved domains should be taken in account [2]. As per this paper the involved domains are: (1) the Serving Network (SN), where the user is now, (2) the Target Network (TN), where the user can move to and (3) the Service Provider (SP) network. For the handover to take place, it is necessary that the SN and the TN have trust relations with the SP. Trust should also exist between the user and the the TN; this can be achieved by providing methods for fast mutual authentication. This paper proposes a protocol for secure and seamless handover. The protocol proposed in this paper takes in account the heterogeneity in radio access technologies, different domains and their trust relations. The protocol is divided in four phases: trust, discovery, decision and commencement. A decision method based on several parameters and different context transfer methods are discussed in this paper. Note that the proposal presented in this paper is a generic one and gives a framework on methods to perform secure seamless handover. Further study should be done to apply the proposed protocol on different technologies, performance study and optimization should also be performed. The paper is organized as follows: In Section 2 an introduction is given to handover, context parameters are also explained and requirements are given for secure seamless handover. The seamless handover protocol is proposed in Section 3. Section 4 studies fulfillment of the requirements and the paper is concluded in Section 5.
2. Handover, Context and Requirements This section explains handover mechanisms, context parameters and proposes requirements for secure seamless handover.
2.1.
Handover
Handover is a basic mobile network capability for dynamic support of terminal migration, while handover management is a process of initiating and ensuring a seamless and lossless handover of a mobile terminal from one wireless Access Point (AP) or Base Station (BS) to another. Handover procedures involve a set of protocols to notify all related entities of a particular connection of which it has been executed. A discussion of handover can be found in [3]. For heterogeneous networks, handover
can be classified in horizontal and vertical ones. Handover can take place within a domain, i.e., intradomain handover or between different domains, i.e., inter-domain handover. An example of inter-domain VHO is the one between a 3G network and a WLAN where 3G is owned by a Mobile Network Operator (MNO) and WLAN is owned by a Wireless Internet Service Provider (WISP).
2.2.
Context Parameters
There can be different types of context parameters, e.g., security parameters or QoS parameters like Bit Error Rate (BER), Signal to Interference Ratio (SIR) or even required Mean Opinion Score (MOS). Security context is used to support trust relation in distributed networks and to provide communication security. The contents of security context include authentication state, authorization results, cryptographic (session) keys and algorithms. Usually security context is negotiated when creating a communication association and shared by two or more parties. When creating a new security context, authenticity and integrity of the information must be ensured and confidentiality of some or all of the information is typically required [2,14].
2.3.
Proposed Requirements
Proposed requirements for secure seamless handover are: (i) ease of access to applications from all locations with required security and acceptable QoS at all times, (ii) handover must not compromise security of involved networks and terminal, as a whole it should not compromise security of B3G systems, (iii) unified billing, (iv) minimal effect on overall performance and resource of network and device, (v) no user intervention, while also allowing users to configure which networks they would like to use, (vi) fast mutual authentication, (vii) using priority to transfer security context for seamless service, (viii) handover decision should consider the security requirement of user and service.
3. Proposed Seamless Handover Protocol The proposed protocol goes through four phases: trust, discovery, decision and commencement. Creation of trust on-the-fly is not discussed in this paper and discovery of TN is based on standard procedures [3]. The novelty of the proposed protocol is in the decision method and parameters used and in
SN
TN
SN
TN
Trust type 1
Trust type 2
SP
SP
SN
3.3.
SP
SP
TN
Trust type 3
SN
TN
Trust type 4
Delegated trust Context transfer
Figure 2 Possible trust relations between SN, TN and SP and context transfer.
the commencement phase. This section discusses the four phases of the proposed protocol.
3.1.
Trust
This section discusses the trust relation required to perform seamless handover. Note that trust creation on-the-fly is not proposed in this paper. Trust relation is normally created beforehand mostly by owners of two domains signing contract but trust could also be created on-the-fly, e.g., by Public Key Infrastructure (PKI). For seamless handover there must be trust relation among SN, TN and SP. There are three possible trust relations: SN, TN and SP have prior trust relation (Trust type 1). SN has trust relation with TN and SP but TN and SP do not have trust relation (Trust type 2); in this case it is possible that SN can delegate trust between TN and SP. TN and SN do not have prior trust relation (Trust type 3); it is possible for SP to delegate trust between TN and SN. Same as Trust type 3 except that SP could transfer the context parameters from SN to TN (Trust type 4). These trust types are also depicted in Figure 2.
3.2.
Discovery
Discovery of TNs (there can be more then one) can happen by the device having 2 or more active radio interfaces, active either simultaneously or periodically, or through announcement of TNs by the SN which can be in the form of a beacon or a specific message giving detailed information of the TN. The SN (for example, another or the same access technology of SN) can also be part of the TN. A device can also discover a TN.
Decision
After TN is discovered, decision can take place. For the purpose of decision certain measurements must be done, either continuously or periodically. In this section measurement parameters, decision parameters and decision procedure are proposed. 3.3.1. Measurement So as to perform optimum handover decision it is proposed to measure the following parameters: Location of a device; this can give the information about the networks a device can access. Speed of the device; gives the time within which a device will pass through the coverage area of a SN and a TN. Direction of motion; gives information of the TNs the device will come in contact with and the coverage area of the TN that the device will first approach. The three parameters (location, speed and direction) together give an estimate of the time duration within which a device might leave the SN or even TN based on this information a handover might or might not be performed. Example: If the device is moving very fast a handover to WLAN networks will make no sense because normally WLAN coverage is very small and the device might leave the network very soon or it is also possible that the device direction is such that it might only stay in TN for a very short period. The estimate of time duration can also be seen as available time for context transfer. Network latency gives the information on delay in transfer of context. Based on delay and available time it is possible to derive the extent to which context can be transferred, i.e., if time is not enough context might be transferred partially. Signal quality should also be measured. This can be a combination of packet error rate and signal strength. If possible to measure, the perceived service quality would be the best criteria for handover. 3.3.2. Decision Parameters It is proposed that decision should be made on measured data discussed above and on the following parameters: Device capability, if the device only has capability for voice then handover from cellular to WLAN should not be performed. Type of service, it is possible that a TN cannot provide the service a device is accessing
Start measurement and decision: Device or network
A: Device or SN part of decision
1. Check network latency 2. Check location 3. Check device speed 4. Check direction of motion 5. Check signal quality
Mobile stays long enough in TN?
Yes No
Signal and/or service quality good enough? No
No
Device capable for new network?
Yes Yes Network latency low enough?
No
B
No Handover
Yes
A
B: device or TN part of decision
A
Yes
Yes
Perform handover with all Context Transfer
Perform handover. Send quick/ partial context such that context reaches TN on time for handover/ before signal loss
TN can provide the service?
Yes
TN has resources for the service?
No
Yes
TN can maintain SLA?
Yes
TN can provide service cheaper (same quality) or better?
No Handover
Figure 3 Measurement and decision.
TN resources and Service Level Agreement (SLA), will give the information if a TN has the resources to provide the required service and if it can fulfill the SLA. Map information, e.g., an automobile with Global Positioning System (GPS) where the user has put the route he/she plans to take, could also be used for better planning of handover networks 3.3.3. Basic Decision As basic decision procedure it is proposed that the handover must take place if the device approaches the border of the network. When there is overlay situation, the network that gives best service quality (including cost) must be chosen. The handover is performed only if: (1) the device is capable of handover, (2) the TN fulfills all the criteria, (3) the TN is ready to accept the device
based on trust relation and subscription and (4) measurement values show that handover can happen. 3.3.4. Handover Decision Mechanism A flowchart of the proposed decision mechanism is given in Figure 3 and the message sequence is given in Figure 4. Parameters based on which handover should be performed are discussed below. Depending on the type of system being considered, the propose handover of decision can be made by the device, the SN or the TN. As discussed in Section 3.3.1 the device or the SN should measure the speed, the location and the direction of the device. This gives an estimate of the available time for context transfer and an estimate of time within which a device will pass through a TN. If the length of stay of a device within a TN is not long enough then handover should not be performed. Further if the signal quality and the service quality are deteriorating fast then handover must be performed at once. Network latency together with available time will give the extent of context that can be transferred. The capability of the device and TN must be checked and compared either by the device or the SN; it is possible that the device does not have the required air interface in which case handover should not be performed. The TN should check if it has enough resources to provide the service. TN should also check if it can maintain the SLA, this check can also be performed by SN. In overlay situation the cost of service should also be checked. Once decision has been taken to perform handover then context parameters are sent to the TN. It is possible that not all context parameters can be sent. The amount of context parameters to be transferred will depend on the urgency of handover (service and signal quality), location, speed and direction and network latency.
3.4.
Commencement
Once decision of handover has been made, context parameter transfer can take place which will be followed by actual handover and commencement of communication in the TN. In this section the proposed commencement process and message sequence charts are given. For each handover following steps occur: (1) context parameters are transferred before handover and (2) the SP is informed about handover as SP should know where to send data. So as to decrease signaling, this step can also be combined with the
step where normal communication is resumed. The message sequence is given in Figure 5. Mutual authentication is performed between the TN and the device so as to prevent, for example, rogue network, intruder to network and session hijacking during handover. As authentication can be time consuming, fast mutual authentication information is created by the SN and passed to the TN; it is also possible that this information is created by the TN Serving Network (SN)
Device
Target Network (TN)
Service Provider (SP)
and is passed via the SN to the device. This step is done during decision phase, see Figure 4. 3.4.1. Context Transfer Methods There are two proposed methods of deciding the context to be transferred: (1) decide independent and dependent context based on domains, access technology and network and (2) give priority to context based on a policy. A combination of these two methods can also be used. Serving Network (SN)
Device
Decision: Trust 1
Target Network (TN)
Decision: Trust 2
2a. Performs decision if device based.
2a. Performs decision if device based.
2b. Request handover (decision if device based)
2b. Request handover (decision if device based)
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based. If SN, TN and SP know about trust relationship this step is not required.
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based.
3. Check TN trust with SP and inform handover initiation
3. Check TN trust with SP and inform handover initiation 4. NACK trust
4. ACK trust 5. Request handover
5. Create trust between TN and SP
6. Check trust. Make decision. Create mutual auth. Parameters.
5'. NACK (reason)
6. Request handover
7. ACK (required info) or NACK (reason) E.g. for IEEE 802.11 this might include information like SSID, WEP key etc.
7'. NACK (reason)
7. Check trust. Make decision. Create mutual auth. Parameters. 8. ACK (required info) or NACK (reason)
E.g. for IEEE 802.11 this might include information like SSID, WEP key etc.
8'. NACK (reason)
Serving Network (SN)
Device
Service Provider (SP)
Target Network (TN)
Service Provider (SP)
Serving Network (SN)
Device
Decision: Trust 3
Target Network (TN)
Service Provider (SP)
Decision: Trust 4
2a. Performs decision if device based.
2a. Performs decision if device based.
2b. Request handover (decision if device based)
2b. Request handover (decision if device based)
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based.
2c. Check trust relationship with TN. Make decision if not done by device/or if decision is network based.
3. Check TN trust with SP and inform handover initiation
3. Check TN trust with SP and inform handover initiation 4. Inform handover
4. Create trust between SN and TN
5. Check trust. Make decision. Create mutual auth. Parameters.
5. Request handover 6. Check trust. Make decision. Create mutual auth. Parameters.
6. ACK (required info) or NACK (reason)
7. ACK (required info) or NACK (reason) 7'. NACK (reason)
7. ACK (required info) or NACK (reason) E.g. for IEEE 802.11 this might include information like SSID, WEP key etc.
7'. NACK (reason)
Figure 4 Decision phase message sequence for the four trust types.
Device
Serving Network (SN)
Target Network (TN)
Service Provider (SP)
Commencement: Trust 1, 2, 3 This is for mutual auth. if it is done by TN then no need to do it here
8. Create security parameters if required 9. Context and new security parameters transfer
4. Fulfillment of Requirements
10. ACK 11. ACK handover (required info + new security parameters) 12. Mutual authentication
13. Handover inform 14. ACK handover
Resume normal communication
Device
Serving Network (SN)
Target Network (TN)
Service Provider (SP)
Commencement: Trust 4 This is for mutual auth. if it is done by TN then no need to do it here
Priority should be given to a context or a set of context (a context set is context parameters that are dependent of each other) based on their effect on seamless handover. Priority policy should be used for giving prioritization; this can be based on the service type, SLA, the TN and the access technology being used, the domains or other parameters.
8. Create security parameters if required
9. Context and new security parameters transfer 10. Context and new security parameters transfer 11. ACK 12. ACK context reception 13. ACK handover (required info + new security parameters) 14. Mutual authentication
15. Handover inform 16. ACK handover
Resume normal communication
Figure 5 The commencement phase.
Independent context should be chosen based on the kind of access technology, network and domain e.g. security related context parameters in 3G mobile communication systems cannot be entirely used in IEEE 802.11 WLAN systems. Further if it is the same domain then any type of context transfer should not be an issue but in case of handover between different domains security policy might prevent certain context parameters from being transferred.
In this section the extent of fulfillment of requirements, given in Section 2.3, by the proposed protocol is discussed. (i) The proposed protocol fulfills the first requirement as that is the main purpose of defining the proposed protocol. It does mean that interworking of the proposed protocol with the security and AAA mechanisms in use is required. Such interworking mechanism will be technology/network/domain dependent and is a part of future study. (ii) Security measures must be taken when transferring context, off-the-shelf techniques can be used for this purpose. The protocol recommends creation of mutual authentication parameters for quick handover. Thus combined with off-the-shelf techniques this requirement can be met. (iii) With the provision of mutual authentication and trust relation between the networks it will be possible to provide unified billing. (iv) The overall effect on performance should be studied in depth. During implementation certain messages can be combined so as to give an even better performance. (v) With the temporary security parameters and mutual authentication information being given to the device and with the transfer of context parameters between the networks user intervention is not required. Thus, this requirement is also met by the proposed protocol. (vi) Mutual authentication parameters are given to the device and the TN which allows both fast handover and mutual authentication between the device and TN. (vii) A method of context transfer is also proposed in the paper, depending on the policy of prioritization and choice of independent context parameters the most important security parameters will be transferred. (viii) The handover does consider SLA which includes the security requirement of the user and the service.
5. Conclusions This paper proposes a secure seamless handover protocol for inter-domain and inter-technology handover. Message sequence of the protocol is
discussed in the paper. The paper also proposes decision methods and context transfer methods. Security requirements for seamless handover are also proposed in the paper. The extent of fulfilment of these requirements by the proposed protocol is also studied in the paper. It is quite understandable that currently few features of the proposed protocol cannot be optimally used but in future such seamless handover protocols will be of prime importance. The proposed protocol will depend on technology thus the ideas presented in the paper should be considered as a framework. Detail study on application of the protocol for different technologies should be done together with optimization of parameters. Further study should be done in this field while taking in account the possible services future mobile communications systems can provide and those desired by the users.
References [1] M. Stemm, and R. H. Katz, “Vertical Handoffs in Wireless Overlay Networks”, ACM Mobile Networks and Applications (MONET), vol.3, No.4, pp.335-350, 1998. [2] P. Nikander, and L. Metso, “Policy and trust in open multi-operator networks”, Proceedings of IFIP SmartNet 2000, pp.419–436, Vienna, Austria, Kluwer Academic Publishers, September 2000. [3] K. Pahlavan, P. Krishnamurthy, A. Hatami, M. Ylianttila, J. P. Makela, R. Pichna, and J. Vallström, “Handoff in hybrid mobile data networks”, IEEE Personal Communications, vol. 7, issue 2, pp.34–37, April 2000.
[4] IETF Seamoby WG: http://www.ietf.org/html.charters/seamobycharter.html. [5] J. Kempf (ed.), “Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network”, RFC3374, September 2002. [6] J. Loughney (ed.), M. Nakhjiri, C. Perkins, and R. Koodli, “Context Transfer Protocol”, draft-ietfseamoby-ctp-01.txt, March 2003. [7] IEEE 802.11f, “Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation”, P802.11f, January 2003. [8] WISPr, Best Current Practices for Wireless Internet Service Provider (WISP) Roaming, February 2003, v1.0, Wi-Fi Alliance. [9] Roaming Operations (ROAMOPS), http://www.ietf.org/proceedings/97dec/97dec-final79.htm. [10] IEEE 802 Handoff ECSG, http://www.ieee802.org/handoff/. [11] B. Aboba, and T. Moore, “A Model for Context Transfer in IEEE 802”, Internet Draft, expired, draftaboba-802-context-02.txt, April, 2002. [12] 3GPP TS 23.234, “3GPP system to Wireless Local Area Network (WLAN) Interworking; System Description”, v.1.3.0, January 2003. [13] 3GPP TS 22.129, “Handover Requirements between UTRAN and GERAN or other Radio Systems”, v.5.2.0, June 2002. [14] H.Wang and A.R. Prasad, “Security Context Transfer in Vertical Handover”, PIMRC 2003, Sept. 7-12, Beijing, China.
