INTERNET DRAFT James Kempf Category: Standards Track Pat R. Calhoun Title: draft-calhoun-mobileip-proactive-fa-01.txt Sun Microsystems, Inc. Date: June 2000 Chandana Pairla University of Illinois Foreign Agent Assisted Hand-off Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. 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 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. Copyright (C) The Internet Society 1999. All Rights Reserved. Abstract The Mobile IP WG has been investigating how its protocol can be used in environments that require fast hand-off, which is especially important for real-time applications such as voice and video. The Calhoun, Kempf expires December 2000 [Page 1] INTERNET DRAFT June 2000 Mobile IP protocol is not currently designed to provide fast hand-off services to Mobile Nodes. This specification proposes extensions to the Mobile IP protocol that may be used by Foreign Agents within a domain in order to setup a Mobile Node's visitor entry, and forward its packets, prior to the formal Mobile IP registration process. Table of Contents 1.0 Introduction 1.1 Requirements language 2.0 Operation 2.1 Foreign Agent Considerations 2.2 Gateway Foreign Agent Considerations 3.0 Mobile Node Hand-Off Request 4.0 Mobile Node Hand-Off Reply 5.0 IANA Considerations 6.0 Security Considerations 7.0 References 8.0 Acknowledgements 9.0 Authors' Addresses 10.0 Full Copyright Statement 1.0 Introduction The Mobile IP WG has been investigating how its protocol can be used in environments that require fast hand-off, which is especially important for real-time applications such as voice and video [2]. This specification provides fast hand-off extensions to the Mobile IP protocol. The Mobile IP protocol [1] currently requires that a Mobile Node listen for, or solicit, advertisements in order to detect that a hand-off is required, which adds significant latency to the hand-off. Mobility agents that advertise frequently do minimize the movement detection delay, but it is questionable whether frequent advertisements are appropriate in low bandwidth networks, such as cellular networks. Calhoun, Kempf expires December 2000 [Page 2] INTERNET DRAFT June 2000 Reg Req +-----+ Reg Req /----------->| oFA |--------------\ | +-----+ | | v +----+ +-----+ Reg Req +----+ | MN | | GFA |<------->| HA | +----+ +-----+ +----+ Figure 1 - Initial Mobile Node Registration The Mobile IP protocol [1] requires that the Mobile Node registers with the Foreign Agent, and subsequently its Home Agent, in order to have its packets delivered. Certain optimizations have been proposed, such as Regional Registration [6] and Anchor Hand-off [7], which reduces the Registration's round trip time (see Figure 1). These proposals allow a Mobile Node's registration message to be processed by a common Mobility Agent in the hierarchy, eliminating the need to contact the Home Agent (see Figure 2). Of course, this optimization is only valid as long as the old and new local Foreign Agents have a common "parent" Foreign Agent in the hierarchy, depicted as Gateway Foreign Agent (GFA) in Figures 1 and 2. +-----+ | oFA | +-----+ +----+ +-----+ +----+ | MN | | GFA | | HA | +----+ +-----+ +----+ | ^ | +-----+ | \----------->| nFA |-------------/ Reg Req +-----+ Reg Req Figure 2 - Registration as a Result of a Hand-off In order for Mobile IP to be a suitable mobility management protocol for multimedia protocols, it is necessary for packets to be delivered to a Mobile Node as soon as it enters a new service area. The added delays of detecting movement, and the registration process, would cause significant and noticeable disruptions to the multimedia stream. Of course, the Mobile Node SHOULD be required to issue a Mobile IP registration in order to continue to receive service. In certain networks, it is possible for Mobile Nodes to receive service from multiple service areas. This is especially important when the Mobile Node is bouncing back and forth between service areas. In such cases, it MAY be necessary for the GFA to forward a Calhoun, Kempf expires December 2000 [Page 3] INTERNET DRAFT June 2000 Mobile Node's packets to ALL Foreign Agents that have registered that they are providing service to the Mobile Node Data +-----+ Data /------------| oFA |<-------------\ | +-----+ | v | +----+ +-----+ Data +----+ | MN | | GFA |<--------| HA | +----+ +-----+ +----+ ^ | | +-----+ | \------------| nFA |<-------------/ Data +-----+ Data Figure 3 - Forwarding the Mobile Node's traffic This proposal, combined with either [6] or [7], will provide a complete fast hand-off solution for Mobile IP. 1.1 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4]. 2.0 Operation When a Foreign Agent detects that a Mobile Node could be serviced by another FA, it issues a Binding Update message to the new FA. The method by which a Foreign Agent determines a Mobile Node's current location and movement patterns MAY be known through an interface with the underlying link layer or a radio specific protocol, and is outside the scope of this document. The Binding Update contains the Mobile Node's home address, Security Association information [8], as well as the identity of the Gateway Foreign Agent (GFA) [6], or the Anchor Foreign Agent (AFA) [7]. Upon receipt of the Binding Update, the new Foreign Agent issues a Hand-off Request to the GFA or the AFA. The Hand-off request is used by the GFA or the AFA to register the new Foreign Agent as also being able to deliver traffic to the Mobile Node. The GFA or AFA MAY forward all packets destined for the Mobile Node through all Foreign Agents that registered service to the MN (see figure 3). Calhoun, Kempf expires December 2000 [Page 4] INTERNET DRAFT June 2000 When the Mobile Node receives the advertisement from the new Foreign Agent, it SHOULD issue a registration request message. The GFA MAY decide to time out the entry created by the Hand-off message if the Mobile Node does not issue a registration within a specific number of seconds, which is indicated in the lifetime field of the Hand-off Reply message. +-----+ | oFA | +-----+ | +----+ | 1. Binding +-----+ +----+ | MN | | Update | GFA | | HA | +----+ | +-----+ +----+ | v ^ 3. Reg| +-----+ 2. Hand-Off Req | Req \----------->| nFA |-----------------/ +-----+ 4. Reg Req Figure 4 - Mobile Node hand-off When the Mobile Node enters the new Foreign Agent's service area, the new FA MAY forward all packets destined for the MN prior to registration. The Mobile Node MAY discard all packets received from an unknown Foreign Agent until an authenticated Registration has been completed. When a Foreign Agent determines that a Mobile Node is no longer in its service area, it SHOULD issue a Hand-off Request, with the lifetime field set to zero, informing the GFA that the Mobile Node is no longer being serviced. In wireless technologies that support Mobile Nodes with dormant mode, this specification does not require that the MN wake up to register when it detects that it has moved to a new service area. In such networks, the new Foreign Agent MUST re-issue a Hand-off Request to the GFA, prior to the expiration of the previous request. This ensures that the GFA has an up to date list of a Mobile Node's location. When data is received by the local Foreign Agent, that is to be delivered to a dormant Mobile Node, it SHOULD send a page to the MN informing it to wake up. 2.1 Foreign Agent Considerations When a Foreign Agent detects that a Mobile Node is moving towards another service area, it issues a Binding Update [5] to the Foreign Calhoun, Kempf expires December 2000 [Page 5] INTERNET DRAFT June 2000 Agent servicing the area. The method by which the Foreign Agent detects the Mobile Node's current location and movement patterns is outside the scope of this document. The Binding Update message MUST include the GFA extension [6], SHOULD include the FA-FA authentication extension [6]. In the event that the local Foreign Agents MUST process the MN-FA authentication extension [1], the Binding Update MUST include the MN-Key-Token [8] extension. Upon receipt of a Binding Update, a Foreign Agent SHOULD issue a Hand-off Request message to the GFA indicated in the Binding Update message. The Foreign Agent SHOULD set the lifetime field to be the interval between router advertisements multiplied by two. Upon receipt of the Hand-off Reply from the GFA, the Foreign Agent SHOULD forward the Mobile Node's packets, unless the radio link is not setup. The Foreign Agent MAY buffer such packets until the radio link is established. In the event that the Mobile Node does not issue a Registration Request prior to the number of seconds that was indicated in the Hand-off Reply's lifetime field, the FA MAY expire the entry, or attempt to re-issue another Hand-off request to the GFA. When a Foreign Agent detects that it is no longer servicing a Mobile Node, it SHOULD issue a Hand-off Request to the GFA with the lifetime field set to zero, indicating a deregistration. If a Hand-off Reply is received from the GFA with the Code field set to DO_NOT_SERVICE_MN (see section 5.0), the Foreign Agent SHOULD NOT provide service to the Mobile Node. This COULD be achieved by refraining from answering any router solicitations. In the event that the interface between the Mobile Node and the Foreign Agent is point-to-point, the Foreign Agent COULD refrain from issuing router advertisements, or close the link layer connection. 2.2 Gateway Foreign Agent Considerations Upon receipt of a Hand-off request, a GFA MUST create a visitor entry indicating the Mobile Node's current point of attachment. In the event that a visitor entry already exists, the GFA SHOULD be able to register multiple local Foreign Agents servicing the Mobile Node. The GFA SHOULD be able to forward packets destined for a Mobile Node to all local Foreign Agents in the visitor entry. When issuing the Hand-off Reply, the GFA SHOULD include the FA-FA authentication extension, and set the lifetime field to the number of seconds that the GFA will expire the visitor entry if no registration request from the Mobile Node is received. Calhoun, Kempf expires December 2000 [Page 6] INTERNET DRAFT June 2000 Upon receipt of a Hand-off Request with the lifetime field set to zero, the GFA MUST remove the local Foreign Agent from the visitor entry. In the event that the GFA does NOT want the local Foreign Agent to provide service to the Mobile Node, the Hand-off Reply is returned with the code set to DO_NOT_SERVICE_MN (see section 5.0). 3.0 Mobile Node Hand-Off Request The Hand-Off Request message is sent by a local Foreign Agent to a GFA or AFA, to inform it that it is servicing a particular Mobile Node. The UDP header is followed by the Mobile IP fields shown below: 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 |M|G| reseved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Foreign Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type TBD (Hand-off Request) M If the 'M' (minimal encapsulation) bit is set, datagrams MAY be tunneled to the mobile node using the minimal encapsulation protocol [10]. G If the 'G' (Generic Record Encapsulation, or GRE) bit is set, datagrams MAY be tunneled to the mobile node using GRE [9]. reserved Reserved bits; sent as zero Lifetime The number of seconds the GFA or AFA SHOULD keep the Calhoun, Kempf expires December 2000 [Page 7] INTERNET DRAFT June 2000 resulting visitor entry active. A value of 0xffff indicates infinity. A value of zero (0) indicates that the GFA MUST remove the New Foreign Agent from the Mobile Node's visitor entry. Home Address The IP address of the mobile node. Home Agent The IP address of the mobile node's home agent. New Foreign Agent The IP address for the new Foreign Agent. Identification A 64-bit number used for matching Hand-Off Requests with Hand-off Replies, and for protecting against replay attacks of Hand-Off messages. See [1] for more information. Extensions The fixed portion of the Hand-off Request is followed by one or more Mobile IP Extensions. The GFA Extension [6] MUST be present in the Hand-off Request. The Generalized Foreign-Foreign Authentication Extension [6] SHOULD be included in the Hand-off Request. 4.0 Mobile Node Hand-Off Reply The Hand-Off Reply is sent by the GFA or AFA as a result of the Hand-Off Request message. The UDP header is followed by the Mobile IP fields shown below: Calhoun, Kempf expires December 2000 [Page 8] INTERNET DRAFT June 2000 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 | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type TBD (Hand-off Reply) Code A value indicating the result of the Hand-Off Request. See [1] for the list of supported codes. Lifetime If the Code field indicates that the hand-off was accepted, the Lifetime field is set to the number of seconds remaining before the entry is considered expired. A value of zero indicates that the local foreign agent has been deregistered. A value of 0xffff indicates infinity. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception. Home Address The IP address of the mobile node. Home Agent The IP address of the mobile node's home agent. Identification A 64-bit number used for matching Hand-Off Requests with Hand-off Replies, and for protecting against replay attacks of Hand-Off messages. The value is based on the Identification field from the Hand-Off Request message from the mobile node, and on the style of replay protection used in the security context between the mobile node and its home agent (defined by the mobility security association between them, and SPI value in the Mobile-Home Authentication Extension). See [1] for more information. Calhoun, Kempf expires December 2000 [Page 9] INTERNET DRAFT June 2000 Extensions The fixed portion of the Hand-Off Reply is followed by one or more of the Extensions. The Generalized FA-FA Authentication Extesion [6] SHOULD be present in all Hand-Off Replies returned by the GFA or AFA. 5.0 Error Values The following table contains the name of Code [9] to be returned in a Registration Reply, the value for the Code, and the section in which the error is first mentioned in this specification. Error Name Value Section of Document ---------------------- ----- ------------------- DO_NOT_SERVICE_MN TBD 2.1 6.0 IANA Considerations This specification introduces two new values in the Mobile IP type field. This value MUST NOT conflict with values specified in [1], or any other Mobile IP extension document. 7.0 Security Considerations Similar to [6] and [7], this specification assumes that the local Foreign Agent, and the GFA (or AFA) inherently trust each other. This MAY be achieved through the use of a long lived security association. This specification introduces a new change to Mobile IP, which is the ability for a Mobile Node to receive packets from a Foreign Agent to which it has not yet registered. In the event that the Mobile Node does not wish to receive packets from unknown Foreign Agents, it MAY drop them. Although this document does not specify how Foreign Agents can identify, or track, Mobile Nodes, it is assumed that the wireless link layer be sufficiently secure in order to correctly identify a Mobile Node. Wireless networks that do not provide such features will be subjected to impersonation attacks, where malicious nodes could cause the Foreign Agents to believe that a Mobile Node has moved to other service areas. 8.0 References Calhoun, Kempf expires December 2000 [Page 10] INTERNET DRAFT June 2000 [1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October 1996. [2] T. Hiller et al. "Cdma2000 Wireless Data Requirements for AAA". draft-hiller-cdma2000-AAA-00.txt (work in progress). October 1999. [3] U. Black. "2nd Generation Wireless Networks". Prentice-Hall. New York. 1999. [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels". BCP 14. RFC 2119. March 1997. [5] C. Perkins and D. Johnson. "Route Optimization in Mobile IP". draft-ietf-mobileip-optim-08.txt (work in progress). Feburary 1999. [6] E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional Registration", draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), March 2000. [7] G. Dommety. "Local and Indirect Registration for Anchoring Hand- offs", draft-dommety-mobileip-anchor-handoff-00.txt (work in progress), March 2000. [8] P. Calhoun, H. Akhtar, E. Qaddoura, N. Asokan, "Foreign Agent Keys Encoded as Opaque Tokens for use in Hand-off Process", draft-calhoun-mobileip-fa-tokens-00.txt (work in progress), March 2000. [9] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). Request for Comments (Informational) 1701, Internet Engineering Task Force, October 1994. [10] C. Perkins. Minimal Encapsulation within IP. Request for Com- ments (Proposed Standard) 2004, Internet Engineering Task Force, October 1996. 9.0 Acknowledgements The authors would like to thank Charles Perkins for his valuable feedback. 10.0 Authors' Addresses Questions about this memo can be directed to: Calhoun, Kempf expires December 2000 [Page 11] INTERNET DRAFT June 2000 James Kempf Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-5890 Fax: 1-650-786-6445 E-mail: james.kempf@eng.sun.com Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pcalhoun@eng.sun.com Chandana Pairla University of Illinois - Urbana Champaign 3315, DCL, 1304, W. Springfield Ave., Urbana, IL 61801 USA Phone: 1-217-244-7117 E-mail: pairla@uiuc.edu 11.0 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights Calhoun, Kempf expires December 2000 [Page 12] INTERNET DRAFT June 2000 defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The lim- ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- CLAIMS 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." Calhoun, Kempf expires December 2000 [Page 13]