Mipshop Working Group Youngsong Mun Internet-Draft Seonggeun Ryu Expires: May, 2008 Soongsil University Jaehoon Nah Seungwon Sohn ETRI November, 2007 An Enhanced Mobile IPv6 Handover for Roaming between Administrative Domains Based on AAA draft-mun-mipshop-emipv6-aaa-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract When Mobile IPv6 (MIPv6) is deployed in commercial network, a mobile node needs AAA services for authentication, authorization and accounting. MIPv6, however, does not provide any mean to authenticate mobile nodes that are roaming in different domains, although visited S. Ryu, et al. Expires May, 2008 [Page 1] Internet-Draft Enhanced Handover between Domains November 2007 networks will need to check whether access of mobile nodes should be authorized or not. Hence schemes which support both AAA services and mobility have been emerged. These schemes enable access of the mobile node to be authorized by visited networks through AAA as well as to perform a home registration during AAA procedure. However, they introduce lots of signal messages and long handover latency during handover, since Route Optimization mode for MIPv6 is performed using Return Routability procedure. Especially, the long handover latency is a critical problem in real-time communication such as voice over IP (VoIP). To solve these problems, we propose an optimized scheme which performs Route Optimization mode using the AAA infrastructure between the home agent and a correspondent node instead of Return Routability procedure. Table of Contents 1. Introduction.....................................................3 2. Terminology......................................................4 3. Background Information...........................................5 3.1. Mobile IPv6................................................5 3.2. MIPv6 with AAA.............................................6 3.2.1 Francis Dupont's Scheme..............................7 3.2.2 Reen-Cheng Wang's Scheme.............................8 4. Proposed Protocol Details........................................9 4.1. Problem Description........................................9 4.2. An Optimized Scheme for Route Optimization Mode............9 5. Message Formats.................................................11 6. Security Considerations.........................................11 7. Conclusions.....................................................11 8. References......................................................12 9. Authors' Addresses..............................................13 S. Ryu, et al. Expires May, 2008 [Page 2] Internet-Draft Enhanced Handover between Domains November 2007 1. Introduction Mobile devices like laptops and PDAs are improved and wireless/mobile communications and networking are propagated widely. Then mobile users for real-time communication such as voice over IP (VoIP) have increased. Also, authentication, authorization and accounting (AAA) services are required for the users, since the mobile users may move between administrative domains. Mobile IPv6 (MIPv6) [1] which supports mobility of a mobile node (MN) in IPv6 networks has been standardized by Internet Engineering Task Forces (IETF). When MIPv6 is deployed in commercial network, MNs need AAA services. AAA and MIPv6 are operated independently. Hence schemes which integrate these protocols have been emerged [2]-[4]. In these schemes, when an MN moves between administrative domains, it is authenticated by AAA and its mobility is supported by MIPv6. Also, these schemes enable the MN to establish a security association between the MN and its home agent (HA), or to perform a home registration during AAA authentication procedure. However, these schemes introduce lots of signal messages and long handover latency during the handover, because Route Optimization mode for MIPv6 is performed by using Return Routability procedure. Return Routability procedure consists of Home of Test Init (HoTI) / Home of Test (HoT) and Care-of Test Init (CoTI) / Care-of Test (CoT) messages. To solve these problems, we propose an optimized scheme for Route Optimization mode by using the AAA infrastructure between the HA and a correspondent node (CN) instead of Return Routability procedure. When the MN performs AAA procedure, it embeds a home Binding Update (BU) message and the CN's information (address and the Network Access Identifier (NAI) [5]) in a request message of AAA procedure. The BU message and the CN's information are delivered to the HA through AAA procedure. After the HA performs the home binding update, it creates a BU message to the CN for Route Optimization mode. The HA then sends the BU message to the CN via the AAA infrastructure between itself and the CN. The proposed scheme can reduce signal messages and handover latency during the handover, because Return Routability procedure for Route Optimization mode is not performed. The proposed scheme also can get a security benefit for Route Optimization mode, since it uses the AAA infrastructure which is secured by IPsec [6] and TLS [7]. S. Ryu, et al. Expires May, 2008 [Page 3] Internet-Draft Enhanced Handover between Domains November 2007 2. Terminology This document borrows all of the terminology from Mobile IPv6 [1] and AAA for Mobile MIPv6 [3]. Attendant: AAA entity which is the local AAA system entry point and the local address provider/registry. Term from [8]. AAA client: attendant. AAA home server (AAAH): AAA server of the home network. AAA local server (AAAL): AAA server of the local network. AVP (Attribute Value Pair): AAA (element of) payload. Binding: home address/care-of address association for a mobile node on a mobility aware IPv6 node. Care-of address (CoA): temporary address used by a mobile node. The care-of address is allocated or registered by a local entity which is assumed for simplicity in this document to be the same than the attendant. Home address (HoA): fixed address used by a mobile node. The home address belongs to the home network and is in general well known by the mobile node even if the protocol described here supports home address allocation. Home agent (HA): router on the home network which forwards traffic at the destination of the home address to the mobile node. Mobile Node (MN): node using mobile IPv6 mechanisms. Correspondent Node (CN) A IPv6 host communicating with MN. Network Access Identifier (NAI): [5] mobile user identifier which is compatible with user_FQDN identities of IKE. We assume NAI can be used to identify any entity involved here even if some of them are nodes and not users. Security Association (SA): a security connection which affords security services to some traffic between peers. This notion is shared between IPsec, ISAKMP and AAA over different forms. S. Ryu, et al. Expires May, 2008 [Page 4] Internet-Draft Enhanced Handover between Domains November 2007 Access Router (AR) The MN's default router. Handover A process of terminating existing connectivity and obtaining new IP connectivity. 3. Background Information 3.1. Mobile IPv6 MIPv6 protocol enables an MN to keep connections to an HA and a CN, although the MN changes a point of attachment to network. In MIPv6 the MN has two addresses of a home address (HoA) and a care-of address (CoA). The HoA is generated in a home network, which never be changed although the MN enters another network, and hence the HA and the CN identify the MN as the HoA. The CoA is generated in a visited network whenever it moves, and represents a current location. MIPv6 protocol binds the CoA to the HoA. In MIPv6 the MN uses Route Optimization mode consisting of Return Routability procedure and a binding update to the CN to communicate with the CN directly. Return Routability procedure consists of HoTI/ HoT and CoTI/CoT message, and through this procedure a key between the MN and the CN is generated, and then a BU message to the CN is authenticated by the generated key. Figure 1 shows Route Optimization mode of MIPv6. In Fig. 1, HoTI message is sent to the CN through the HA, and CoTI message is sent to the CN directly. The CN then processes these messages respectively and sends response messages to the sender. That is, the CN sends HoT and CoTI messages to the MN as a result of processing HoTI and CoTI messages, respectively. When the MN receives HoT and CoT messages, it generates a binding management key (Kbm) using keygen tokens in HoT and CoT messages. Then the MN sends the BU message to CN to inform its new CoA, and the BU message is authenticated by the Kbm. After updating binding information in the CN, the MN and the CN can communicate directly. As a result, Route Optimization mode is completed. S. Ryu, et al. Expires May, 2008 [Page 5] Internet-Draft Enhanced Handover between Domains November 2007 MN HA CN | | | \ MIPv6 |---Binding Update-->| | \ Reg. | | | / phase |<--Binding Ack.-----| | / | | | / |-Home of Test Init->|------------------->| \ / |-Care-of Test Init---------------------->| \ RR | | | | | MIPv6 proc.\ |<-------------------|<---Home of Test----| | RO mode \ |<------------------------Care-of Test----| | | | | / |---Binding Update----------------------->| / | | | Fig. 1. Mobile IPv6 Route Optimization mode Whenever the MN moves between networks, a process for mobility support is required and is called a handover. The handover consists of a movement detection, an address configuration, a home binding update, Return Routability procedure, and a binding update to the CN [1]. The MN cannot communicate with the CN during the handover. 3.2. MIPv6 with AAA When MIPv6 is deployed in commercial networks, the MN needs AAA [8] services to allow it to access to any service provided by an administrative domain different from its home domain. AAA supports authentication and authorization for the MN and collects MN's accounting information [9]. AAA is a distributed security model which consists of distributed clients and central servers. In AAA, all of connections between entities are secured by IPsec and additionally by TLS. Figure 2 shows the architecture of MIPv6 with AAA. In Fig. 2, the paths between the AAAL and the AAAH are secured by IPsec and additionally TLS. It is similar to the paths between the AAAH and the HA and the paths between the AAAL and the AAA Attendant. The local network is a network where the MN currently resides. The AAA Attendant may be implemented at the AR. S. Ryu, et al. Expires May, 2008 [Page 6] Internet-Draft Enhanced Handover between Domains November 2007 +--------+ "AAA network" +--------+ | AAAL |<------------------->| AAAH | | server | | server | +--------+ +--------+ ^ ^ | | v v +-----------+ +---------+ | AAA | | Home | | Attendant | | Agent | +-----------+ +---------+ ^ | v +--------+ | Mobile | | Node | +--------+ Fig. 2. AAA Schema In Fig. 2, AAAH is an AAA server of the MN\u2019s home network, AAAL is an AAA server of the local network, and AAA Attendant is AAA entity which is local AAA system entry point and the local address provider/ registry [3]. When the MN moves into a foreign domain, it needs authorization to attach to the foreign domain. Hence AAA plays a role to enable the MN to get access in the foreign domain. After getting the access permission to the foreign domain through AAA, MIPv6 is performed to support mobility. These two protocols are performed in order, so both signal overhead and handover latency are increased. Schemes which integrate two protocols have studied to solve these problems. In this draft, we describe two schemes to combine MIPv6 and AAA. We also focus on the message flow of two schemes. Hence we do not discuss AAA protocol or the message types. 3.2.1. Francis Dupont's Scheme In Dupont\u2019s draft [3], the author describes a solution that allows the AAA infrastructure to authenticate/authorize an MN, and to create credentials for securing subsequent AAA exchanges and MIPv6 registration messages. The original idea is that the MN is allowed to dynamically establish a security association pair with its HA during AAA exchanges using AAA infrastructure as a trusted third party [3]. S. Ryu, et al. Expires May, 2008 [Page 7] Internet-Draft Enhanced Handover between Domains November 2007 In this draft we focus on the message flow for Dupont\u2019s scheme, and it is shown in Fig. 3. MN Attendant AAAL AAAH HA | | | | | |---Attendant-->| | | | | Request |-AA-MN-Request>| | | | | |-AA-MN-Request>| | | | | |-AA-HA-Request>| | | | | | | | | |<-AA-HA-Answer-| | | |<-AA-MN-Answer-| | | |<-AA-MN-Answer-| | | |<--Attendant---| | | | | Reply | | | | | | | | | |---Binding Update--------------------------------------------->| | | | | | |<------------------------------------Binding Acknowledgement---| | | | | | Fig. 3. The message flow for Dupont's scheme In Fig. 3 procedures of AAA and MIPv6 are performed when the MN moves a foreign network. The MN performs AAA procedure to get access to the network and then it performs MIPv6 procedure to support its mobility. These procedures are performed sequentially. After registration to the HA, the MN sets up Route Optimization mode to communicate directly with CNs. 3.2.2. Reen-Cheng Wang's Scheme In Wang\u2019s paper [2], the author proposes a mechanism combining MIPv6 and AAA which are performed in a common procedure. Figure 4 shows the message flow for Wang\u2019s scheme when the MN moves into a foreign network. In Fig. 4 MIP Reg. Req. is Mobile IPv6 Registration Request message which requests AAA authentication and Mobile IPv6 registration, and MIP Reg. Reply is Mobile IPv6 Registration Reply message which replies the result of the request message. S. Ryu, et al. Expires May, 2008 [Page 8] Internet-Draft Enhanced Handover between Domains November 2007 MN Attendant AAAL AAAH HA | | | | | |-MIP Reg.Req.->| | | | | |--Access Req.->| | | | | |-MIP Reg.Req.->| | | | | |-MIP Reg.Req.->| | | | | | | | | |<---MIP Reg.---| | | |<---MIP Reg.---| Reply | | |<-Access Reply-| Reply | | |<---MIP Reg.---| | | | | Reply | | | | | | | | | Fig. 4. The message flow for Wang's scheme When the MN moves into a foreign network and receives the router advertisement, it will send a registration request to the attendant. The attendant will forward the message to the AAAH server via AAAL server to check the user\u2019s identity. After the AAAH server checks the user\u2019s identity, it will send a MIP registration message to the HA. The HA will send a registration reply message to the AAAH server, which waits for the AAA message. After the message from the HA is received, the AAA server will forward the result to the attendant. The attendant will send the registration reply message to the MN. After the registration to the HA, the MN uses Route Optimization mode to communicate directly with CNs. 4. Proposed Protocol Details 4.1. Problem Description Wang's scheme among the existing schemes can optimize a handover, since the AAA infrastructure can be used to support mobility procedures and to optimize authentication, authorization and mobility in a common procedure. However Wang's scheme must also perform Return Routability procedure for Route Optimization mode. Hence, handover latency is long and signaling overhead is large, due to many signal messages used in Return Routability procedure. 4.2. An Optimized Scheme for Route Optimization Mode To solve problems mentioned above, we propose an optimized scheme for Route Optimization mode by using the AAA infrastructure between the HA and a CN instead of Return Routability procedure. When the MN S. Ryu, et al. Expires May, 2008 [Page 9] Internet-Draft Enhanced Handover between Domains November 2007 requests AAA authentication, it embeds a home BU message and the CN's information (address and NAI) in a request message of AAA procedure. When the HA receives the BU message and CN's information via the AAA infrastructure, it performs the home binding update and creates a BU message to the CN. The HA then sends the BU message to the CN via the AAA infrastructure between itself and the CN. For the proposed scheme, we assume the followings. The CN is being supported by AAA. When the MN sends the request message to an AAA Attendant, the CN's address and NAI are embedded in the message. The MN can know the CN's NAI using an appropriate manner in advance. The HA can create a registration message to the CN, substituting the MN. MN Attendant AAAL AAAH HA CN's AAAH CN | | | | | | | |MIP Reg.->| | | | | | | Request |--Access->| | | | | | | Request |MIP Reg.->| | | | | | | Request |MIP Reg.->| | | | | | | Request | | | | | | | | | | | | | |<---------| | | | | | |---MIP Reg. to CN--->|--------->| | | | | | | | | | | |<-MIP Reg.| | | | | |<-MIP Reg.| Reply | | | | |<-Access--| Reply | | | | |<-MIP Reg.| Reply | | | | | | Reply | | | | | | | | | | | | | Fig. 5. The message flow for the proposed scheme Figure 5 shows message flows of the proposed scheme. Whole procedure for the proposed scheme is similar to Wang\u2019s scheme except a procedure for setting up Route Optimization mode. When receiving the MIPv6 registration request message from AAAH, the HA processes the message and creates a response message. The HA then creates a BU message for the CN with the MN's CoA as the source IP address, the CN's address as the destination IP address, and the MN's HoA as the home address option. The HA then sends an AAA request message including a BU to CN's NAI to register the MN\u2019s new location. Upon receipt of the AAA message, the CN processes the message, and then BCE for the MN is updated. Finally, Route Optimization mode is completed and the MN and the CN can communicate directly. S. Ryu, et al. Expires May, 2008 [Page 10] Internet-Draft Enhanced Handover between Domains November 2007 The proposed scheme does not need Return Routability procedure for Route Optimization mode, because the mode is completed via the AAA infrastructure. Therefore, the proposed scheme can reduce handover latency and signaling overhead. 5. Message Formats To be defined. 6. Security Considerations In this draft, AAA infrastrucure are secured by IPsec and TLS. Hence, it is assumed that messages exchanging in AAA infrastructure are secured. However, obviously a deep security review is needed. 7. Conclusions MIPv6 protocol does not provide any specific support for mobility passing through different administrative domains, and hence it limits the applicability of MIPv6 in a large scale commercial deployment. For MIPv6 to be deployed in commercial networks there has to be AAA support for the protocol. Wang's scheme provides a solution for MIPv6 and AAA interworking. It also can support a fast handover, since it enables an MN to establish a security association between the MN and an HA, and to perform a home binding update through AAA procedure. However, Wang's scheme introduces a lot of signal messages and long handover latency during the handover, since Route Optimization mode is performed using Return Routability procedure. To solve this problem, we propose an optimized scheme for Route Optimization mode that the HA performs the binding update for a CN by using the AAA infrastructure between the HA and the CN instead of Return Routability procedure. The proposed scheme can reduce handover latency and signaling overhead during the handover, because Return Routability procedure for Route Optimization mode is not performed. The proposed scheme also can get a security benefit, since it uses the AAA infrastructure which is secured by IPsec and TLS. Since the proposed scheme causes shorter handover latency than the existing schemes, it may be suitable to support real-time communication such as VoIP. Fast Handover for Mobile IPv6 (FMIPv6) [10] and Hierarchical MIPv6 (HMIPv6) [11] have been standardized in IETF. FMIPv6 is an enhanced handover scheme for MIPv6, as portions of layer 3 handover are performed layer 2 handover. HMIPv6 reduces location updates, since mobility is managed locally. Therefore, the proposed scheme can be S. Ryu, et al. Expires May, 2008 [Page 11] Internet-Draft Enhanced Handover between Domains November 2007 considered to be used in FMIPv6 or HMIPv6, since these mechanisms have enhanced MIPv6. 8. References [1] D. Johnson, C. E. Perkins, and J. Arkko, "Mobility Support in IPv6", Request for Comments (Proposed Standard) 3775, Internet Engineering Task Force, June 2004. [2] R. C. Wang, R. Y. Chen, and Han-Chieh Chao, "AAA architecture for Mobile IPv6 based on WLAN," Int. J. Network Mgmt, Volume 14, Issue 5 September 2004, pp.305-313. [3] F. Dupont, M. Laurent-Maknavicius, and J. Bournelle, "AAA for mobile IPv6," IETF Draft draft-dupont-mipv6-aaa-01.txt, May 2002. [4] F. Le, B. Patil, C. Perkins, and C. Faccin, "Diameter Mobile IPv6 Application," IETF Draft draft-le-aaa-diameter-mobileipv6- 04.txt, May 2005. [5] B. Aboba and M. Beadles, "The Network Access Identifier," IETF RFC2486, January 1999. [6] S. Kent and K. Seo, "Security Architecture for the Internet Protocol," IETF RFC4301, December 2005. [7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright, "Transport Layer Security (TLS) Extensions," IETF RFC3546, June 2003. [8] C. de. Laat, G. Gross, L. Gommans, J. Vollbrecht, and D. Spence, "Generic AAA Architecture," IETF RFC2903, August 2000. [9] S. Glass, T. Hiller, S. Jacobs, and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements," IETF RFC2977, October 2000. [10] R. Koodli, (editor), "Fast Handovers for Mobile IPv6", Request for Comments (Experimental) 4068, Internet Engineering Task Force, July 2005. [11] H. Soliman, C. Catelluccia, K. Malki, L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Request for Comments (Experimental) 4140, Internet Engineering Task Force, August 2005. S. Ryu, et al. Expires May, 2008 [Page 12] Internet-Draft Enhanced Handover between Domains November 2007 9. Authors' Addresses Youngsong Mun, Professor Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-820-0676 Fax: +82-2-822-2236 E-mail: mun@ssu.ac.kr Seonggeun Ryu Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-812-0689 Fax: +82-2-822-2236 E-mail: sgryu@sunny.ssu.ac.kr Jaehoon Nah Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-6749 Fax: +82-42-860-5611 E-mail: jhnah@etri.re.kr Seungwon Sohn Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-5072 Fax: +82-42-860-5611 E-mail: swsohn@etri.re.kr S. Ryu, et al. Expires May, 2008 [Page 13] Internet-Draft Enhanced Handover between Domains November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). S. Ryu, et al. Expires May, 2008 [Page 14]