Mipshop Working Group Youngsong Mun Internet-Draft Teail Shin Expires: January, 2008 Soongsil University June, 2007 Using Return Routability for Authentication of Fast Handovers in Mobile IPv6 draft-mun-mipshop-err-mipv6-00.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 June 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract IETF published Fast Handovers in Mobile IPv6 (FMIPv6) for efficient mobility management. FMIPv6 has no solutions to protect binding update messages. Previous researches have mainly concentrated on using AAA, public certificates or cryptographic algorithms for T. Shin, et al. Expires January, 2008 [Page 1] Internet-Draft Extended Return Routablity July 2006 authentication of FMIPv6. However the approaches need a particular infrastructure or heavy processing cost to authenticate binding updates in FMIPv6. Extended Return Routability provides authentication for FMIPv6 without infrastructure and costly cryptographic algorithms. Also it can be used for various existing handover protocol in MIPv6 network. Table of Contents 1. Introduction.....................................................3 2. Terminology......................................................4 3. Background.......................................................5 3.1. FMIPv6.....................................................5 3.2. Return Routability.........................................6 4. Extended Return Routablity.......................................8 5. Message Formats.................................................11 6. Conclusions.....................................................11 7. References......................................................12 8. Authors' Addresses..............................................13 T. Shin, et al. Expires January, 2008 [Page 2] Internet-Draft Enhanced Handover between Domains December 2006 1. Introduction The Internet Engineering Task Force(IETF) standardized Mobile IPv6[1] for the mobility management. Mobile IPv6(MIPv6) is an IP-layer mobility protocol for a Mobile Node (MN) to maintain connectivity to the Internet during its handover from one Access Router to another. The basic idea in MIPv6 is to allow a Home Agent (HA) to work as a stationary proxy for an MN. Whenever an MN is away from its home network, the HA intercepts packets destined to MN's home of address and forwards the packets by tunneling them to MN's care-of address. The transport layer uses the HoA as a stationary identifier for the MN. Because a handover procedure in MIPv6 involves movement detection, IP address configuration, and location update, the handover latencies affect real-time applications. Hence, MIPSHOP Working Group in IETF published Fast Handovers in MIPv6 to reduce the handover latencies. However, current FMIPv6 does not consider authenticating Fast Binding Updates (FBUs) between an MN and a previous access router (PAR). By the FBU message, PAR learns a binding between Previous CoA (PCoA) and New CoA (NCoA). This binding is used to modify the handling of outgoing and incoming packets. The binding may lead to security risks. An attacker may use a malicious BU to hijack or redirect existing connections. Other researches for FMIPv6 involve a trusted online server (e.g. AAA) or public key infrastructure (PKI). Authentication needs to work between any MN and any AR. There does not currently exist any infrastructure that could be used for such global authentication. Also the approaches which use asymmetric cryptosystem need heavy processing cost. Therefore, we use the extended Return Routability to provide authen-tication for FMIPv6 without infrastructure and heavy processing cost. T. Shin, et al. Expires January, 2008 [Page 3] Internet-Draft Enhanced Handover between Domains December 2006 2. Terminology This document borrows all of the terminology from Mobile IPv6 [1] and FMIPv6 [2]. binding Home address/care-of address association for a mobile node on a mobility aware IPv6 node. care-of address (CoA) A 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 A 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) A Router on the home network which forwards traffic at the destination of the home address to the mobile node. mobile node (MN) A node using mobile IPv6 mechanisms. correspondent node (CN) A peer node communicating with MN. return routability procedure The return routability procedure authorizes registrations by the use of a cryptographic token exchange. access router (AR) A default router of a mobile node. previous access router (PAR) The MN's default router prior to its handover. T. Shin, et al. Expires January, 2008 [Page 4] Internet-Draft Enhanced Handover between Domains December 2006 new access router (NAR) The MN's default router subsequent to its handover. handover A process of terminating existing connectivity and obtaining new IP connectivity. 3. Backgound 3.1. FMIPv6 MN PAR NAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------| | | | | |------FBU----------->|--------HI--------->| | |<------HAck---------| | <--FBack---|--FBack---> | | | | disconnect forward | | packets===============>| | | | | | | connect | | | | | |--------- FNA --------------------------->| |<=================================== deliver packets | | Figure 1: "Predictive" Fast Handover FMIPv6 reduces handover latency. In MIPv6, if an MN moves in new subnet, the MN should perform movement detection and address configuration and location update. It is called handover latency. In contrast to MIPv6, FMIPv6 finishes movement detection and address configuration for an NCoA in advance of handover. Also, FMIPv6 uses a tunnel to retain connectivity before location update. Therefore FMIP recovers communication fast without latency resulted from movement detection, address con-figuration and location update. T. Shin, et al. Expires January, 2008 [Page 5] Internet-Draft Enhanced Handover between Domains December 2006 Figure 1 shows FMIPv6 procedure. FMIPv6 is Make-Before-Break protocol. If radio signal strength from an Access Point (AP) is week, link layer triggers a Link-Going-Down event. Receiving the event, the MN sends a RtSolPr including a scanned AP-ID. The PAR finds an appropriate NAR by the AP-ID and sends a PrRtAdv including the prefix and the address of the NAR. After receiving the PrRtAdv, the MN performs auto-configuration to generate an NCoA by the prefix of NAR. Then the MN sends a FBU to start a substantial hand-over. The PAR and the NAR verify the NCoA by exchanging a HI and a Hack and establish a tunnel between the PCoA and the NCoA. When the MN finishes link switching, the MN sends a FNA for announcing its attachment to the NAR. The NAR delivers packets buffered during disruption. Hence, the MN can recover connectivity before the MN finishes location update to the HA. However, there are vulnerabilities in FMIPv6 because the current version of FMIPv6 does not specify authentication for the FBU. If an attacker uses a malicious FBU, packets meant for one address could be stolen or redirected to some unsuspecting node. Therefore, The PAR must verify that the FBU arrive from a node that legitimately owns the CoA. 3.2. Return Routability MN HA CN | | | Home Test Init (HoTI) | | |------------------------->|------------------------->| | | | | Care-of Test Init (CoTI) | |---------------------------------------------------->| | | | | Home Test (HoT) | |<-------------------------|<-------------------------| | | | | Care-of Test (CoT) | |<----------------------------------------------------| | | Figure 2: Return Routability MIPv6 requires tunneling through a HA to communicate with a CN, it leads to longer paths and degraded performance. This tunneling is called triangular routing.[1] To alleviate the performance penalty, MIPv6 includes Route Optimization (RO). For RO an MN sends a BU to a CN for registering the binding between a HoA and a CoA in binding cache of the CN. After RO, the CN can forward packets to the CoA directly. T. Shin, et al. Expires January, 2008 [Page 6] Internet-Draft Enhanced Handover between Domains December 2006 Return Routability (RR) is the protocol to authenticate a BU of RO. RR is based on the idea that a node should be able to verify the existence of a node which is able to respond to packets sent to a given address. Successful RR implies that there is indeed a node at the given address. RR consists of a HoA test and a CoA test. The protocol flow is depicted in Fig. 2. The MN sends a HoTI and a CoTI simultaneously to start a HoA test and a CoA test. The CN replies to both of the messages independently by sending a HoT and a CoT. The HoT has a nonce index and a home keygen token. A Home keygen token is generated by a Kcn, known only by the CN. A CoT has a nonce index and a care-of keygen token. A care-of keygen token is generated by a Kcn. A home keygen token and a care-of keygen token are calculated as follows home keygen token := First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1))) The home keygen token received by the MN is used for proving that the MN is in-deed at the HoA. And care-of keygen token received by the MN is used for proving that the MN is indeed at the CoA. Each nonce index allows the CN to easily find the nonce which was used during generating keygen token. The MN which has a home keygen token and a care-of keygen token can create a binding management key (Kbm) to verify that the MN stays at the HoA and CoA concurrently. Kbm = SHA1 (home keygen token | care-of keygen token) The tunnel between the MN and the HA is protected by IPsec (ESP), which makes it impossible for the outsiders to learn the contents of a HoT. Therefore RR is secure from a malicious attack. T. Shin, et al. Expires January, 2008 [Page 7] Internet-Draft Enhanced Handover between Domains December 2006 4. Extended Return Routability RR is the protocol designed to authenticate BUs in RO. If RR is used for FMIPv6 straightforwardly, there is a problem. An attacker who stays in the same subnet of a target host can initiate RR with his HoA`and target's CoA. The attacker normally receives a home keygen token and sniffs a care-of keygen token of the target. Hence the attacker can generate a valid Kbm. The FBU with only the Kbm can not be used to authorize to change the destination of packet from PCoA to NCoA. RR can not guarantee address ownership of a CoA perfectly. A Kbm of RR only al-lows a CN to change the path of traffic destined to a MN from a HoA to a CoA. However, FMIPv6 needs to change the path of traffic from PCoA to NCoA. Therefore we propose a mechanism that RR can guarantee address ownership of a CoA. To do this, we define the new type of RR and modify the binding cache of the CN. MN HA PAR |--Home Test Init---->|--------------------->| | | | |--Care of Test Init------------------------>| | | | |<--------------------|<----------Home Test--| | | | |<-----------------------------Care of Test--| | | | |------Binding Update----------------------->| | | | Figure 3: Extended Return Routability In extended Return Routability, once an MN newly moves in a subnet, the MN should start the Extended Return Routability (ERR) immediately. Fig. 3 shows ERR. It looks like the procedure of RR. However, when the MN finishes ERR, the MN sends a BU which has an E-flag. If the PAR receives the BU, the PAR does not start route optimization. The BU has a Message Authentication Code (MAC) singed by Kbm. If the MAC is valid and the requested CoA in the BU does not exist in the binding cache, the PAR registers the unique binding of CoA and HoA in binding cache. This binding is de-noted by CoA-HoA. Then, the PAR sends a binding acknowledgement (BA) to indicate successful registration. T. Shin, et al. Expires January, 2008 [Page 8] Internet-Draft Enhanced Handover between Domains December 2006 MN HA PAR NAR | | | | |--HoTI----->|------------>| | |--CoTI------------------->| | |<-----------|<-------HoT--| | |<--------------------CoT--| | | | | |----------BU------------->| | | | | | | | |------RtSolPr------------>| | |<-----PrRtAdv-------------| | | | | |------FBU---------------->|--------------HI--------->| | |<------------HAck---------| | <--FBack---|--FBack---> | | | | disconnect forward | | packets====================>| | | | | | | connect | | | | | |--------- FNA -------------------------------------->| |<============================================ deliver packets | | Figure 4: FMIPv6 using extended return routability This CoA-HoA binding assure that the MN retain the ownership of the CoA. Because the PAR does not permit to register the CoA-HoA` binding if the CoA-HoA binding already exists in the binding cache. Only the MN which has the address ownership of the HoA can updates and deletes the existing CoA-HoA binding. Therefore, with the Kbm and the CoA-HoA binding, the PAR authenticates the FBU in FMIPv6. Figure 4 is the example in which FMIPv6 uses ERR to Authenticate the FBU. The FBU has the MAC signed by Kbm. When the PAR receives the FBU, the PAR verifies the MAC and the CoA-HoA binding in its binding cache. If the verification is correctly finished, the PAR keeps performing remaining processes. ERR always should be performed prior to FMIPv6. Usually, there must be a long interval until the MN which finishes ERR performs a handover. However, if the MN moves from one subnet to another frequently, ERR may leads to degrade performance of FMIPv6. There are two scinerios in terms of performnce. T. Shin, et al. Expires January, 2008 [Page 9] Internet-Draft Enhanced Handover between Domains December 2006 First scenario is normal ERR in which the MN has to procure home keygen token and care-of keygen token. Second scenario is optimized ERR in which the MN that already obtains home keygen token of a next attachment point needs only a care-of keygen token. As shown in Figure 4, ERR is made up of the period of procuring home keygen token , the period of procuring care-of keygen token and the period of sending a BU to register the CoA-HoA. The HoTI and the CoTI start simultaneously and independently. Hence the processing time of the last finished test is considered total latency . Generally the time to get a home keygen token is longer than the time to get a care-of keygen token. If the home keygen token of a next attachment point is obtained in advance, the latency resulted from ERR significantly reduced. This mode of ERR is called the optimized ERR. T. Shin, et al. Expires January, 2008 [Page 10] Internet-Draft Enhanced Handover between Domains December 2006 5. Message Formats To be defined. 6. Conclusions Most of the IPv6 handover protocols in IETF are designed without considering au-thentication between a mobile node and its serving node. Previous works on the authentication for handover protocol in IPv6 have mainly concentrated on studies using AAA, public certificates or cryptographic algorithms. However the approaches does not provide a generic authentication mechanism since the approaches need a particular infrastructure or a heavy processing cost to setup secure associations for handovers. Therefore, we extend the Return Routability so that our scheme could be a generic authentication mechanism for various IPv6 handover protocol without pre-configured infrastructure and heavy cryptosystem. Extended Return Routability does not introduce a new entity for authentication, because it only uses fundamental entities for MIPv6. And it does not introduce a new cryptosystem. In addition, as shown in the previous section, our scheme has acceptable latency and overhead. Especially, the optimized ERR has little latency and cost. We recommend to use the optimized ERR as long as an MN is able to know its serving node for handovers in advance. T. Shin, et al. Expires January, 2008 [Page 11] Internet-Draft Enhanced Handover between Domains December 2006 7. 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. Koodli, (editor), "Fast Handovers for Mobile IPv6", Request for Comments (Experimental) 4068, Internet Engineering Task Force, July 2005. [3] P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", Request for Comments 4225, December 2005. [4] J. Arkko, C. Vogt, W. Haddad, "Enhanced Route Optimization for Mobile IPv6" Request for Comments 4866, Internet Engineering Task Force, May 2007. [5] C. Vogt, J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", Request for Comments 4651, Internet Engineering Task Force, February 2007. [6] S. Kent and K. Seo, "Security Architecture for the Internet Protocol," IETF RFC4301, December 2005. [7] James Kempf, Rajeev Koodli, "Distributing a Symmetric FMIPv6 Handover Key using SEND", draft-ietf-mipshop-handover-key-00 work in progress, February, 2007 [8] Bao, F., Deng, R. and J. Zhou, "Improvement of Return Routability Protocol", draft-qiu-mip6-rr-improvement-00, March 8, 2005 [9] S. Glass, T. Hiller, S. Jacobs, and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements," IETF RFC2977, October 2000. [10] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", IETF RFC 2460, December 1998 [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. T. Shin, et al. Expires January, 2008 [Page 12] Internet-Draft Enhanced Handover between Domains December 2006 8. 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@computing.ssu.ac.kr Teail Shin 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: nulls@sunny.soongsil.ac.kr Intellectual Property Statement 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 IETF's procedures with respect to rights in IETF Documents can T. Shin, et al. Expires January, 2008 [Page 13] Internet-Draft Enhanced Handover between Domains December 2006 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity 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. 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. T. Shin, et al. Expires January, 2008 [Page 14]