Mobile IP Working Group Pat R. Calhoun INTERNET DRAFT Sun Microsystems, Inc. 25 May 1999 Charles E. Perkins Sun Microsystems, Inc. Mobile IP Network Address Identifier Extension draft-ietf-mobileip-mn-nai-01.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 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. Abstract AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to include the NAI along with the Mobile IP Registration Request. Calhoun, Perkins Expires 25 November 1999 [Page i]
Internet Draft Mobile Node NAI 25 May 1999 1. Introduction AAA servers, such as RADIUS [10] and DIAMETER [3], are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI) [1]. This document specifies the Mobile Node NAI extension to the Mobile IP Registration Request [9] message from the mobile node. Since the NAI is typically used to uniquely identify the mobile node, the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without even having a home address. This draft introduces a new function named the Home Domain Allocation Function (HDAF) that can dynamically assign a Home Address to the mobile node. A message containing the Mobile Node NAI extension MAY have the Home Address field in the Registration Request set to zero (0) to request that one be assigned. Figure 1 illustrates the Home HDAF, which receives messages from foreign agents (e.g., FA) and assigns a Home Address within the Home Domain. The HDAF does not perform any Mobile IP processing on the Registration Request, but simply forwards the request to a Home Agent (HA) within the network that is able to handle the request. +------+ | | +---+ HA-1 | +------+ +------+ +------+ | | | | | | | | | | +------+ | MN |-------| FA |-------| HDAF +---+ ... | | | | | | | +------+ +------+ +------+ +------+ | | | +---+ HA-n | | | +------+ Figure 1: Home Domain Allocator Function (HDAF) Upon receipt of the Registration Request from the mobile node (MN), FA extracts the NAI and finds the domain name associated with it. FA then finds the HDAF that handles requests for the mobile node's domain. The discovery protocol is outside of the scope of this Calhoun, Perkins Expires 25 November 1999 [Page 1]
Internet Draft Mobile Node NAI 25 May 1999 specification. As an example, however, FA might delegate the duty of finding a HDAF to a local AAA server. The local AAA server may also assist FA in the process of verifying the credentials of the mobile node, using protocols not specified in this document. 2. Mobile Node NAI Extension The Mobile Node NAI extension, shown in figure 2, contains the user and/or host name following the format defined in [1]. When it is present in the Registration Request, the Home Address field MAY be set to zero (0). The Mobile Node NAI extension MUST appear in the Registration Request before both the Mobile-Home Authentication extension and Mobile-Foreign Authentication extension, if present. 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 | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The Mobile Node NAI Extension Type 130 (skippable) [9] Length The length in bytes of the MN-NAI field MN-NAI A string in the NAI format defined in [1]. 3. Foreign Agent Considerations If Home Address is zero in the Registration Request, the foreign agent MUST use the NAI instead in its pending registration request records, along with the Identification field as usual. If the foreign agent cannot manage pending registration request records in this way, it MUST return a Registration Reply with Code indicating UNIQUE_HOMEADDR_REQD (see section 4). If the mobile node includes the Mobile Node NAI extension in its Registration Request, then the Registration Reply from the home agent MUST include the Mobile Node NAI extension. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_NAI (see section 4). The Registration Reply MUST include a nonzero Home Agent address and mobile node's Home Address. If not, the foreign agent SHOULD send Calhoun, Perkins Expires 25 November 1999 [Page 2]
Internet Draft Mobile Node NAI 25 May 1999 the Registration Reply to the mobile node, changing the Code to the value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see section 4). 4. Error Values Each entry in 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 ---------------------- ----- ------------------- UNIQUE_HOMEADDR_REQD 96 3 MISSING_NAI 97 3 MISSING_HOME_AGENT 98 3 MISSING_HOMEADDR 99 3 5. IANA Considerations The number for the Mobile Node NAI extension is taken from the numbering space defined for Mobile IP registration extensions defined in RFC 2002 [9] as extended in RFC 2356 [6]. The numbering for the extension also SHOULD NOT conflict with values specified in the Internet Draft for Route Optimization [8]. The Code values specified for errors, listed in section 4, MUST NOT conflict with any other code values listed in RFC 2002, RFC 2344 [5], or RFC 2356 [6]. They are to be taken from the space of error values conventionally associated with rejection by the foreign agent (i.e., 64-127). 6. Security Considerations Mobile IP registration messages are authenticated, and the authentication verified by the recipient. This proposal does not prohibit the mobile node from sending its NAI in the clear over the network, but that is not expected to be a security issue. 7. IPv6 considerations For mobile nodes using IPv6, there are no commonly deployed mechanisms by which a mobile node may present its credentials, such as there are with IPv4. Nevertheless, a mobile node using IPv6 mobility [4] may wish to specify the domain in which their credentials may be checked, by using a NAI just as this specification proposes for IPv4. In the case of IPv6, however, there is no foreign Calhoun, Perkins Expires 25 November 1999 [Page 3]
Internet Draft Mobile Node NAI 25 May 1999 agent in place to manage the connectivity of the mobile node, and thus to manage the verification of the credentials offered by the mobile node. To identify the HDAF that has the expected relationship with the mobile node, the NAI would have to be forwarded to a local AAA by the local agent involved with configuring the care-of address of the mobile node. This agent can either be a router sending out Router Advertisements [7], or a DHCPv6 [2] server. In the former case, the router could signal its ability to handle the NAI by attaching a new extension to the Router Advertisement. In the latter case, for managed links, the mobile node would include an NAI extension in its DHCP Solicitation message. The NAI extension and appropriate authentication would also be required on the subsequent DHCP Request sent by the mobile node to the DHCP Server selected on the basis of received DHCP Advertisements. Once a care-of address on the foreign network has been obtained, the mobile node can use regular MIPv6. 8. Acknowledgements The authors would like to thank Gabriel Montenegro and Vipul Gupta for their useful discussions. References [1] B. Aboba and M. Beadles. RFC 2486: The Network Access Identifier, January 1999. Status: PROPOSED STANDARD. [2] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-14.txt, February 1999. (work in progress). [3] P. Calhoun and A. Rubens. DIAMETER Base Protocol. draft-calhoun-diameter-07.txt, November 1998. (work in progress). [4] D. Johnson and C. Perkins. Mobility Support in IPv6. draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in progress). [5] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 1998. [6] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for Mobile IP. RFC 2356, June 1998. Calhoun, Perkins Expires 25 November 1999 [Page 4]
Internet Draft Mobile Node NAI 25 May 1999 [7] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor discovery for IP Version 6 (IPv6), December 1998. Status: DRAFT STANDARD. [8] Charles E. Perkins and David B. Johnson. Route Optimization in Mobile-IP. draft-ietf-mobileip-optim-07.txt, November 1997. (work in progress). [9] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [10] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authentication Dial In User Service (RADIUS). RFC 2138, April 1997. Addresses The working group can be contacted via the current chairs: Erik Nordmark Basavaraj Patil Sun Microsystems, Inc. Nortel Networks Inc. 17 Network Circle 2201 Lakeside Blvd. Menlo Park, California 94025 Richardson, TX. 75082-4399 USA USA Phone: +1 650 786-5166 +1 972-684-1489 Fax: +1 650 786-5896 E-mail: nordmark@sun.com bpatil@nortelnetworks.com Questions about this memo can be directed to: Charles E. Perkins Pat R. Calhoun Sun Microsystems Laboratories Sun Microsystems Laboratories 15 Network Circle 15 Network Circle Menlo Park, California 94025 Menlo Park, California 94025 USA USA Phone: +1-650 786-6464 Phone: +1 650-786-7733 EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com Fax: +1 650 786-6445 Calhoun, Perkins Expires 25 November 1999 [Page 5]
