INTERNET DRAFT Kent Leung Category: Cisco Systems Title: draft-subbarao-mobileip-bindingid-00.txt Madhavi Subbarao Expires May 2000 Cisco Systems Mobile IP Binding Identifier Extension draft-subbarao-mobileip-bindingid-00.txt Status of this Memo This document is an Internet Draft and is in full compliance 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. Internet Drafts 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 A Network Access Identifier can be added to a Mobile IP Registration Request to identify a user and allow for the assignment of a dynamic home address. However, users may want to open several simultaneous sessions using the same NAI from the same or different devices and obtain a unique IP address for each session. The Mobile IP Binding Identifier Extension defined in this draft can be used to distinguish registration requests belonging to these various sessions. 1. Introduction A Mobile IP Registration Request may carry a Network Access Identifier (NAI) [1,2] that serves to identify the user requesting access to the network. The NAI is used to establish the necessary security assocation with the HA or AAA server. With the abundance of mobile devices, a given user may want to open multiple, simultaneous Mobile IP sessions/services from the same or different devices. Moreover, the user may desire to obtain and use a dynamic home address on each device. For these situations a finer level of abstraction is needed to distinguish the registration requests pertaining to the different sessions. An obvious approach is to use a different NAI for each device or service and obtain a one-to-one mapping between an NAI and dynamically allocated home address. A separate security association entry would need to be established for each NAI (the security associations may be the same). However, a NAI is considered a way to identify and authenticate a user, not a device or service. A user should be able to gain access into a network based on authentication through a single NAI, regardless of the device through which access is requested. A consequential disadvantage to the multiple NAI approach is in accounting. A network administrator or service provider would need to manage accounts and security associations for the multiple NAIs established for one user, which is not a trivial task. Moreover, an operator may be willing to only distribute one NAI per user. It is more natural to authenticate and account for a user based on a single NAI, and distinguish between the various devices or Mobile IP sessions that a user may use by a different means. Thus, an operator may simply maintain a single database for security keys and billing accounts. This document proposes a Mobile IP Binding Identifier Extension to Mobile IP that can accomplish this goal. When it is included in each Registration Request sent by a Mobile Node (MN), a user can have multiple active Mobile IP sessions/services, each with a different dynamically assigned Home Address, while using the same NAI and Home Agent (HA). For example, currently in a cdma2000 network, multiple registrations for the same NAI using different static addresses is specified [7]. (The MN must be configured with different static addresses, and a registration is indexed by the combination of NAI and static address.) The Mobile IP Binding Identifier would allow for multiple registrations for the same NAI using dynamic address allocation. Moreover, the Mobile IP Binding Identifier provides a mechanism to uniquely map the dynamically allocated IP address to a dynamic Domain Name Server (DNS). The Mobile IP Binding Identifier is independent of the dynamic address allocation method, i.e., 2. Mobile IP Binding Identifier Extension The Mobile IP Binding Identifier extension MAY be attached to the registration request and reply. It is defined 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 | Length |A|H| Sub-Type | rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile IP Binding ID... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Not Skippable (TBD) Length Length in bytes of this extension, not including the Type and Length bytes. Sub-Type Appropriate bit is set to identify the Mobile IP Binding ID type. 'A' bit is set to indicate an ASCII string. 'H' bit is set to indicate HEX notation. Remaining bits MUST be set to zero and may be defined in the future. rsv Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception. Mobile IP Binding ID The Mobile IP Binding ID field is one or more octets that identifies the session/service that the mobile node is registering. There are no restrictions on the contents of the Mobile IP Binding ID field. For example, it MAY contain ASCII character strings or HEX notation. The Mobile IP Binding ID should not be NULL or CR/LF terminated. The size is determined from the Length field. It is suggested that the Mobile IP Binding ID not simply index the NAI but be globally unique, e.g., concatenation of NAI-Binding Number. This removes the dependence of the Mobile IP Binding ID on the NAI extension for interpretation. 3. Mobile Node Considerations The Mobile IP Binding Identifier Extension contains a value that distinguishes the Registration Request as belonging to a particular service for a given MN. The MN should choose a suitable value for this field at the beginning of a session. Thus, if a MN uses the Mobile IP Binding Identifier Extension in its Registration Request to establish a mobility binding, then the MN MUST continue using that Mobile IP Binding ID for any subsequent Registration Requests pertaining to that session. If the MN sets the Home Address field to zero, it is requesting that the HA assign an address and return it in the Home Address field of the Registration Reply. If the MN includes a nonzero value in the Home Address field, it MUST use an address that was previously (dynamically or statically) allocated to the same Mobile IP Binding ID. When registering the first device or service, the MN may include only a Mobile IP NAI extension, since it may not anticipate any future registrations for different devices or services. When the MN wishes to register another device or service, it SHOULD include the Mobile IP Binding Identifier extension. Note that the MN MUST ensure that the Mobile IP Binding ID is unique. The first device registration will be identified by just the NAI, while any subsequent registrations for other devices or services will be identified by NAI-Mobile IP Binding ID. When the Mobile IP Binding Identifier Extension is present in the Registration Request it MUST appear in the Registration Request before both the Mobile-Home Authentication extension and Mobile-Foreign Authentication extension, if present. 4. Foreign Agent Considerations If the Home Address is zero in the Registration Request, and the Mobile IP Binding Identifier Extension is present, the foreign agent MUST use the NAI provided by the NAI extension [1] and the Mobile IP Binding ID provided by the Mobile IP Binding Identifier Extension to index its pending registration request records. If the foreign agent cannot manage pending registration request records in this way, it MUST return Registration Reply with Code NONZERO_HOMEADDR_REQD [1]. If the mobile node includes the Mobile IP Binding Identifier Extension in its Registration Request, then the corresponding Registration Reply from the Home Agent MUST include the same Mobile IP Binding Identifier Extension. If not the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_BINDING_ID (see section 6). 5. Home Agent Considerations If the mobile node includes the Mobile IP Binding Identifier Extension in its Registration Request, then the corresponding Registration Reply from the home agent MUST also include the same Mobile IP Binding Identifier Extension. If the Registration Request received by the HA has a Home Address field set to zero, the HA will attempt to allocate an IP address for the MN in the home domain and return it in the Home Address field of the Registration Reply. The HA may use various method to allocation an address, for example, from a local pool of addresses, via a AAA server, or via a DHCP server. The Mobile IP Binding Identifier extension is compatible with recently proposed drafts for allocating an address for a Mobile IP client via a DHCP server [4][5] (with client ID for the DHCP server based on NAI and Mobile IP Binding ID). For networks that use an existing AAA architecture or local pool, the Mobile IP Binding ID provides a transparent solution. 6. Error Values The following table contains the Error Code [3] to be returned in the Registration Reply, the value for the Code, and the Section in which it is first mentioned. Error Name Value Section ---------- ------ -------- MISSING_BINDING_ID TBD 4 7. IANA Considerations The Mobile IP Binding Identifier Extension defined in Section 2 is a Mobile IP registration extension as defined in RFC 2002 [3]. IANA should assign a Type value consistent with this number space. The Code value defined in Section 6 is an error code as defined in RFC 2002 [3]. IANA should assign a value to this code consistent with this number space. 8. Security Considerations Mobile IP registration messages are authenticated, and the authentication verified by the recipient. The Mobile IP Binding Identifier Extension is always covered by at least a Mobile-Home Authentication Extension. 9. IPv6 Considerations As with the NAI extension for Mobile IP [1], support for Mobile IP Binding ID based registration in IPv6 is outside the scope of this document. Any of the methods suggested there for creating an attendant function in the visited network could also make use of a Mobile IP Binding ID extension to support multiple, simultaneous sessions/services. 10. Acknowledgements Thanks to Mohamed Khalil for his participation in early drafts of this document. 11. Intellectual Property Statement 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. 12. References [1] P. Calhoun and C. Perkins, Mobile IP Network Access Identifier Extension, Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip-mn-nai-07.txt, Work in progress, January 2000. [2] B. Aboba and M. Beadles, The Network Access Identifier. RFC 2486, Internet Engineering Task Force, January 1999. [3] C. Perkins, IP Mobility Support for IPv4, revised, Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip-rfc2002-bis-01.txt, Work in progress, January 2000. [4] S. Glass, Mobile IP Agents as DHCP Proxies, Internet Draft, Internet Engineering Task Force. draft-glass-mobileip-agent-dhcp-proxy-00.txt, Work in progress, June 2000. [5] S. Thuel, et al, Dynamic Home Addressing in Mobile IP using Transient Tunnels, Internet Draft, draft-thuel-mobileip-tt-00.txt, Work in progress, June 2000. [6] R. Droms, Dynamic Host Configuration Protocol, RFC 2131, March 1997. [7] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000. Author's Addresses Questions about this memo can be directed to: Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA email: kleung@cisco.com phone: +1 408 526 5030 fax: +1 408 526 4952 Madhavi Subbarao Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 USA email: msubbara@cisco.com phone: +1 919 392 8387 Expires May 2000