INTERNET DRAFT Gopal Dommety Category: Standards Track cisco Systems Title: draft-dommety-mobileip-anchor-handoff-00.txt March 2000 Expires October 2000 Local and Indirect Registration for Anchoring Handoffs draft-dommety-mobileip-anchor-handoff-00.txt Status of this Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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. Abstract In wide area deployment, the handoff latencies due to latencies in Mobile IP registrations, delay incurred due to setting up of dynamic keys, and latencies in setting up secure Tunnels could be high. This document proposes enchantments to reduce the latencies involved in such handoffs. It proposes enhancements to facilitate local registration, anchoring, and global indirect registration. 1. Introduction In wide area deployment, the handoff latencies of the current mobileip could be high. In a mobile environment, it is very important to limit the delay experienced in communication when a mobile moves from base station\access point to another. This document proposes enchantments to reduce the latencies involved in a handoff. It proposes enhancements to facilitate local registration, anchoring, and global indirect registration. 1.1 Problem Description Handoff latencies could involve delays due to the following: 1. Message Exchange Between HA and FA: Mobile IP Message traversal from FA to the HA and back. 2. Establishment of Secure Tunnels between FA and HA: In order to secure traffic destined to/generated by a mobile, encryption of data is being considered. Typically, this encryption is will be done by setting up an IP Sec Tunnel using IKE. Latency in performing IKE and creating an IP Sec Tunnel contributes to the latency experianced by the user during handoffs. 3. Establishment of security keys between FA and HA: For the HA and FA to authenticate each other, a shared key is used to compute FA-HA AE (Authentication Extension). Also a shared key (a different or the same as one used for FA-HA AE) might need to be established if IKE with shared Key is being used to establish IP Sec Tunnel. These Keys can be statically configured or dynamically established. If the Keys are established dynamically, these keys have to be established before the handoff can be completed (Keys can be generated using some form of KDC). The key generation involves considerable delays during handoffs. Another alternative is to use PKI authenticating Mobile IP entities or during IKE negotiations, this also introduces considerable delay. These delays also contribute to the latency experianced by the user. It is desirable to reduce or eliminate these latencies during handoffs. In order to reduce or eliminate the above mentioned latencies, this draft proposes Anchoring of tunnels at the old FA (Anchor FA). To facilitate anchoring, this document introduces two types of registrations Local Registration and Indirect Global Registration. These mechanisms can be used to quickly perform a handoff and later perform a global registration if required. 2. Overview 2.1 Network Model The network model being considered is illustrated in Fig 1. +----------------------------------+ +----------------+ | Visited | | Home | | Network | | Network | | | | | | +------+ +-------+ | | +------+ | | | | | | | | | | | | | MN |-------------| FA1 |-------------------------| HA | | | | | | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | +----------------+ | +-------+ | | | FA2 | | | | | | | | | | | +-------+ | +----------------------------------+ Fig 1: Network Model 2.2. Mobile IP Registration (referred to as Global Registration in this draft) The Current Mobile IP registration[1] is illustrate in Fig 2. It is referred to as Global Registration. +----------------------------------+ +----------------+ | Visited | | Home | | Network | | Network | | | | | | +------+ +-------+ | | +------+ | | | | 1 | |************************ | | | | | MN |------------>| FA1 |----------2------------->| HA | | | | |<------------| |<---------3--------------| | | | +------+ 4 +-------+*************************+------+ | | | Secure | | | | Tunnel +----------------+ | +-------+ | | | FA2 | | | | | | | | | | | +-------+ | +----------------------------------+ Fig 2. Global Registration Messages 1,2: Registration Request Messages 3,4: Registration Reply 2.3 Local Registration During the Global Registration process, the MN authenticates to the HA. During this process IPsec tunnel could be established between the HA and FA to secure the users data. It is possible by the use of a KDC or other mechanisims to establish a shared Key between MN-FA. After a successful Global Registration, the FA acts as an AnchorFA for future registrations. If during the global registration a shared-key is established between MN and FA or there exists another mechanisim (e.g. using PKI) for the FA to authenticate the MN, a local registration can be performed when the MN moves within the same domain. Local Registration is authenticated by the AnchorFA as illustrated in Figure 3. On successful registration, a tunnel is established between the AnchorFA and the New Visiting FA to tunnel packets to and from the Mobile. Note that the assumption here is that there is a mechanisim for the AnchorFA to authenticate the MN. This solution mandates a Shared Key between every two FAs in a domain. By performing Local Registration latencies due to components 1, 2 and 3 described in Section 1.1 are avoided. +----------------------------------+ +----------------+ | Visited | | Home | | Network | | Network | | | | | | Anchor | | | | +-------+ | | +------+ | | | |*************************| | | | | FA1 | | | | HA | | | | |*************************| | | | +-------+ | Secure Tunnel | +------+ | | ^ | | | | | 2| 3| | +----------------+ | | V | | +------+ +-------+ | | | | 1 | | | | | MN |------------>| FA2 | | | | |<------------| | | | +------+ 4 +-------+ | +----------------------------------+ Fig 3: Local Registration Messages 1,2: Registration Request Messages 3,4: Registration Reply 2.4 Global Indirect Registration If there does not exist a direct way for the AnchorFA to authenticate the MN (For Example, a Shared Key between the MN and AnchorFA was not established), an Indirect Global Registration as illustrated in Fig 4 can be performed to avoid the latencies due to components 2 and 3 mentioned in Section 1.1. +----------------------------------+ +----------------+ | Visited | | Home | | Network | | Network | | | | | | Anchor | | | | +-------+ | | +------+ | | | |************************ | | | | | FA1 |----------3------------->| HA | | | | |<---------4--------------| | | | +-------+************************ +------+ | | ^ | |Secure Tunnel | | | 2| |5 | +----------------+ | | V | | +------+ +-------+ | | | | 1 | | | | | MN |------------>| FA2 | | | | |<------------| | | | +------+ 6 +-------+ | +----------------------------------+ Fig 4: Global Indirect Registration Messages 1,2,3: Registration Request Messages 4,5,6: Registration Reply 3. Extensions 3.1 Anchor Advertisement Extension This section defines a new extension to the Router Discovery Protocol [2] for use by foreign agents in a domain to advertise the Zone ID to which the FA belongs to. The Zone ID Information is used by Mobile (MN) to determine if it has changed Zones. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reg-Type | Zone ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Anchor Advertisement Extension Type TDB (To be assigned by IANA) Length Length in bytes of this extension, not including the Type and Length bytes. Reg-Type GLOBAL_REG 0x0 LOCAL_REG 0x1 GLOBAL_INDIRECT_REG 0x2 Zone ID A Globally unique value used to identify the Zone. If an FA has a Zone ID in the IRDP message, then it MUST support at least one of local registration or Indirect Global registration. 3.2 Anchor Registration Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reg-Type | Resrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AnchorFA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone ID......... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Anchor Registration Extension Type TDB (To be assigned by IANA). Length Length in bytes of this extension, not including the Type and Length bytes. Reg-Type GLOBAL_REG 0x0 LOCAL_REG 0x1 GLOBAL_INDIRECT_REG 0x2 Resrvd Currently set to 0. To be used for future enhancements. Zone ID A Globally unique value used to identify the Zone. 3.3 Authentication Extensions The procedures described in this document require two new authentication extensions, FA-AnchorFA Authentication Extension and MN-AnchorFA Authentication Extension. Generalized Mobile IP Authentication Extension as defined in [3] is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: The Generalized Mobile IP Authentication Extension Type 36 (not skippable) (see [1]) Subtype a number assigned to identify the kind of endpoints or characteristics of the particular authentication strategy Length 4 plus the number of bytes in the Authenticator; MUST be at least 20. SPI Security Parameters Index Authenticator The variable length Authenticator field In this document, two subtypes are defined: 2 (TDB) FA-AnchorFA Authentication Extension 3 (TD) MN-AnchorFA Authentication Extension 4. Processing Considerations 4.1 Initial Registration The Initial registration when a MN enter a different Zone, it preforms a registration as specified in RFC 2002[1](referred to as Global Registration). Additional in order to perform Local or Indirect registration in the future Foreign Agent CoA option should be used [1]. The MN remembers the FA (to be used as the AnchorFA) and the Zone ID, and the lifetime (also referred to as global registration lifetime) 4.2 Local Registration Local registration is illustrated in Fig 3. This section give the details of processing by the mobile IP entities. 4.2.1 MN processing The MN is allowed to perform a Local Registration if it has previously performed a Global Registration with a FA in the current Zone and global lifetime that was granted has not expired. The MN sends a Mobile IP registration to the FA with the following fields: -Lifetime is set to the lesser of the remaining lifetime of the last global registration and the one advertised by this FA. -Currently only timestamp-based reply protection is supported and timestamp-based replay protection is followed as specified in RFC 2002. -CoA field set to the address of the FA or Collocated CoA and sets the D bit appropriately. Home Agent and Home Address fields are set according to RFC 2002 [1]. -MN-AnchorFA AE (Authentication Extension) is mandatory and is used in place of MN-HA AE. -Anchor Registration Extension is included before the MH-AnchorFA AE. The Reg_Type field is set to LOCAL_REG. Other Fields are set appropriately. 4.2.2 FA processing FA on receipt of the Registration Request from the MN processes the Request as Specified in RFC 2002[1] and additionally: 1. Checks the Zone ID: If it does not match its Zone ID, Registration Reject with error code of INVALID_ZONEID is sent to the Mobile. 2. Check for Unsupported Registration Type Request. If the MN requests a Registration Type not advertised by the FA, a registration reject with UNSUPPORTED_REG_TYPE is sent to the Mobile. 3. For Local Registration FA-AnchorFA AE is Mandatory. It is computed in place of the FA-HA AE. 4. Sends the Registration Message to AnchorFA (instead of HA as in a Global Registration [1] ). On receiving a successful Registration Reply from the AnchorFA, if the MN is using Foreign Agent CoA, the appropriate tunnel is created to the AnchorFA (instead of to HA as in the Global Registration). The FA also updates the lifetime as specified in RFC 2002[1]. In case of a Registration Reject the FA performs processing as specified in RFC 2002[1] and also relays the error codes for INVALID_ZONEID and UNSUPPORTED_REG_TYPE. 4.2.3 AnchorFA processing AnchorFA on receipt of the Registration Request from the FA processes the Request as a HA as specified in RFC 2002[1] and additionally: 1. Checks the Zone ID: If it does not match its Zone ID, Registration Reject with error code of INVALID_ZONEID is sent to the FA. 2. Check for Unsupported Registration Type Request. If the MN requests a Registration Type not supported, a registration reject with UNSUPPORTED_REG_TYPE is sent to the FA. 3. If FA-AnchorFA AE is missing or fails authentication then Registration Reject is sent to the FA with an FA_FAILED_AUTHENTICATION Code. 4. If MN-AnchorFA AE is missing or fails authentication then Registration is Rejected with MN_FAILED_AUTHNETICATION Code. 5. Registration Lifetime requested has to be less than the remaining global registration lifetime, other wise the lifetime is field is updated to the remaining global registration lifetime. 6. If the MN has not previously performed global registration with the AnchorFA with global registered lifetime remaining, the registration is rejected with MN_UNKNOWN error code. On successful registration, the AnchorFA sends a registration reply. The reply is formed similar to how a HA would [1]. Additionally: 1. Anchor Registration Extension is included before the MN-AnchorFA AE. This extension is copied from the Registration Request. 2. Lifetime field is set to be lesser of the the remaining global registration lifetime, the requested value, and a configured value (for providing the option of forcing global registration within a given time). 3. For Registration Reply in a Local Registration, FA-AnchorFA AE is Mandatory. It is computed in place of the FA-HA AE [1]. 4. MN-AnchorFA AE is mandatory and is used in place of MN-HA AE [1]. On successful registration the AnchorFA creates an appropriate tunnel to the CoA and sets up routing such that datagrams that arrive destined to this mobile from HA-AnchorFA tunnel is tunneled to the via the AnchorFA-FA tunnel. If reverse tunneling is set, then the datagrams that come from the FA-AnchorFA tunnel and generated by this mobile (source address of the Mobile) are tunneled to the HA. 4.3 Global Indirect Registration Global Indirect Registration is illustrated in Fig 4. This section give the details of processing by the mobile IP entities. 4.3.1 MN processing The MN is allowed to perform a Global Indirect Registration if it has previously performed a Global Registration with a FA in the current Zone. The registration request considerations are similar to the considerations in the case of Local Registrations. The differences with the Local Registrations are as follows: - Only Foreign Agent CoA option is valid with Global Indirect Registration. and CoA is set to AnchorFA. - MN-HA AE is mandatory - AnchorFA-MN Authentication Extension is optional - Lifetime is chosen a recommended in RFC 2002 [1]. - Both timestamp-based and nonce based reply protection is supported. -Anchor Registration Extension is included before the MN-AnchorFA AE. The Reg_Type field is set to GLOBAL_INDIRECT_REG. 4.3.2 FA processing The processing performed is similar to the processing done during Local Registration. Note that in this case only Foreign Agent CoA option is chosen and the AnchorFA is set as the CoA. In this registration option the also AnchorFA-FA AE is mandatory. 4.3.3 AnchorFA processing AnchorFA on receipt of the Registration Request from the FA processes the Request as a FA would process according to RFC 2002 [1] and additionally: 1. Checks the Zone ID: If it does not match its Zone ID, Registration Reject with error code of INVALID_ZONEID is sent to the FA. 2. Check for Unsupported Registration Type Request. If the MN requests a Registration Type not supported, a registration reject with UNSUPPORTED_REG_TYPE is sent to the FA. 3. If FA-AnchorFA AE is missing or fails authentication then Registration Reject is sent to the FA with an FA_FAILED_AUTHENTICATION Code. 4. MN-AnchorFA AE is optional and if present and fails authentication then Registration is Rejected with MN_FAILED_AUTHNETICATION Code. 5. If the MN has not previously performed global registration with the AnchorFA with global registered lifetime remaining, the registration is rejected with MN_UNKNOWN error code. If the Registration Request is not denied it is sent to the HA with the following: 1. FA-HA AE can be used optionally On receipt of a registration reply. If the registration is rejected the reject is relayed with mandatory AnchorFA-FA AE and optional MN-AnchorFA AE. If registration was accepted by the HA, the Anchor updates the Global Registration lifetime for this mobile and ,sends a registration reply. The reply is relayed to the FA with the following additions: 1. Anchor Registration Extension is included before the FA-AnchorFA AE. This extension is copied from the Registration Request. 2. HA_FA AE in the reply message from the HA if present is authenticated and removed. 3. FA-AnchorFA AE is Mandatory. It is computed in place of the FA-HA AE [1]. 4. MN-AnchorFA AE is optional. On successful registration the AnchorFA creates an appropriate tunnel to the CoA and sets up routing such that datagrams that arrive destined to this mobile from HA-AnchorFA tunnel is tunneled to the via the AnchorFA-FA tunnel. If reverse tunneling is set, then the datagrams that come from the FA-AnchorFA tunnel and generated by this mobile (source address of the Mobile) are tunneled to the HA. 4.3.4 HA processing Does regular HA processing. 5. Error Codes The Following error codes are to be defined: INVALID_ZONEID TBD UNSUPPORTED_REG_TYPE TBD MN_UNKNOWN TBD 6. Intellectual Property Right Notice Cisco may have IPR on material contained in this draft. Upon approval by the IESG of the relevant Internet standards track specification and if any patents issue to Cisco or its subsidiaries with claims that are necessary for practicing this standard, any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. 7. IANA Considerations The Anchor Registration Extension defined in Section 3.2 is Mobile IP registration extension as defined in RFC 2002 [1]. IANA should assign a Type value consistent with this number space. The Mobile IP Anchor Advertisement extension defined in section 3.1 is taken from the numbering space defined for Mobile IP [1] extensions to the ICMP Router Advertisements [2]. The numbers, 36 and 132, for the Generalized Authentication extension The Code values defined in Section 5 are error codes as defined in RFC 2002 [1]. IANA should assign values to these codes consistent with this number space. A new number space is being created for enumerating subtypes of the Generalized Authentication extension [3]. The AnchorFA-FA AE and AnchorFA-MN AE Subtypes are to be taken from this numbering space. 8. Acknowledgments The author would like to thank Kent Leung for his suggestions and helpful discussion. 9. References [1] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [2] S. Deering. ICMP Router Discovery Messages. Request for Comments (Proposed Standard) 1256, Internet Engineering Task Force, September 1991. [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension. draft-ietf-mobileip-challenge-09.txt, Feb 2000. (work in progress). [4] Eva Gustafsson, et. al. Mobile IP Regional Tunnel Management. draft-ietf-mobileip-reg-tunnel-01.txt, August 1999. [5] K. El Malki, et. al. Fast Handoff Method for Real-Time Traffic over Scaleable Mobile IP Networks. draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999. Dommety [Page 4] Internet Draft Author Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Dommety Local and Indirect Registration for Anchoring Handoffs March 2000 Appendix The following enhancements will be considered in the future: 1. Option of Forcing Global Registration Perform Global Registration Immediately Perform Global Registration Next time. 2. Buffering issues during handoffs 3. Simultaneous Bindings at HA and AnchorFA 4. Private addressing: For private addressing GRE with Key has to be used. 5. Authorization from HA for performing Local Registrations 6. Overlapping Zones 7. Time offset enhancement extensions -This gives a hint of the time offset between the FA and the MN to the mobile during global registration. This can be used to successfully register at the AnchorFA for Local Registration. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reservd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Time Difference + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+