idnits 2.17.1 draft-ietf-mobileip-mn-nai-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 68: '...de-NAI extension MAY have the Home Add...' RFC 2119 keyword, line 89: '...the Mobile-Node-NAI extension MAY have...' RFC 2119 keyword, line 91: '... Such a registration MUST be forwarded...' RFC 2119 keyword, line 120: '...m the Home Agent MUST include the Mobi...' RFC 2119 keyword, line 121: '...gistration Reply MUST include a nonzer...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-14 == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1970 (ref. '4') (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 2461 (ref. '5') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2002 (ref. '6') (Obsoleted by RFC 3220) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Pat R. Calhoun 3 INTERNET DRAFT Sun Microsystems, Inc. 4 25 February 1999 Charles E. Perkins 5 Sun Microsystems, Inc. 7 Mobile IP Network Address Identifier Extension 8 draft-ietf-mobileip-mn-nai-00.txt 10 Status of This Memo 12 This document is a submission by the mobile-ip Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@smallworks.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 AAA servers, such as RADIUS and DIAMETER, are in use within the 40 Internet today to provide authentication and authorization services 41 for dial-up computers. We propose that such services are equally 42 valuable for mobile nodes using Mobile IP when the nodes are 43 attempting to connect to foreign domains with AAA servers. Such 44 AAA servers typically identify clients by using the Network Access 45 Identifier (NAI). We propose that the NAI be allowed for use with 46 Mobile IP when the mobile node issues a Registration Request. 48 1. Introduction 50 AAA servers, such as RADIUS and DIAMETER, are in use within the 51 Internet today to provide authentication and authorization services 52 for dial-up computers. We propose that such services are equally 53 valuable for mobile nodes using Mobile IP when the nodes are 54 attempting to connect to foreign domains with AAA servers. Such 55 AAA servers typically identify clients by using the Network Access 56 Identifier (NAI). We propose that the NAI be allowed for use with 57 Mobile IP when the mobile node issues a Registration Request. This 58 draft specifies the Mobile-Node-NAI Extension to the Mobile IP 59 Registration Request message from the Mobile Node. 61 Since the NAI is typically used to identify the mobile node, the 62 mobile node's home address is not always necessary to provide that 63 function. Thus, it is possible for a mobile node to authenticate 64 itself, and be authorized for connection to the foreign domain, 65 without even having a home address. This draft introduces new entity 66 named the Home Domain Allocation Agency (HDAA) that can dynamically 67 assign a Home Address to the Mobile Node. A message containing the 68 Mobile-Node-NAI extension MAY have the Home Address field in the 69 Registration Request set to zero (0) to request that one be assigned. 71 In the figure 1, we introduce the Home Domain Allocator Agency 72 (HDAA), which receives messages from Foreign Agents and assigns a 73 Home Address, and possibly a Home Agent, within the Home Domain. The 74 HDAA does not perform any Mobile IP processing on the Registration 75 Request, but simply forwards the request to a Home Agent within the 76 network that is able to handle the request. 78 Mobile IP [6] defines a method for a Mobile Node to be assigned 79 a Home Agent dynamically through the use of a limited broadcast 80 message. However, most corporate networks do not allow such packets 81 to traverse their firewall. The use of the limited broadcast ensured 82 that the Home Agent assigned to the Mobile Node resided on a specific 83 subnet, therefore it was not necessary to assign a dynamic IP 84 Address to the Mobile Node. With the Mobile-Node-NAI extension, we 85 propose that the the HDAA may also assign a dynamic Home Agent to the 86 Mobile Node. This alternative mechanism avoids the use of limited 87 broadcast. 89 A Registration Request with the Mobile-Node-NAI extension MAY have 90 the Home Agent field set to zero (0) to request that a home agent 91 be dynamically assigned. Such a registration MUST be forwarded 92 to an HDAA, which is able to assign the Home Address. The domain 93 portion of the NAI [1] is used to identify the Mobile Node's Home 94 Domain, and thus to identify the HDAA which is the destination of the 95 Registration Request. The DIAMETER Mobile IP extension [3] defines a 96 method of resolving the Home Agent allocator, but this document will 97 refer to a generic method for full generality. 99 +------+ 100 | | 101 +---+ HA-1 | 102 +------+ +------+ +------+ | | | 103 | | | | | | | +------+ 104 | MN |-------| FA |-------| HDAA +---+ ... 105 | | | | | | | +------+ 106 +------+ +------+ +------+ | | | 107 +---+ HA-n | 108 | | 109 +------+ 111 Figure 1: Home Domain Allocator Agency (HDAA) 113 Upon receipt of the Registration Request, the Foreign Agent extracts 114 the Mobile Node's NAI and finds the domain name associated with it. 115 The Foreign Agent then finds the HDAA that handles requests for the 116 Mobile Node's domain. The discovery protocol is outside of the 117 scope of this specification. As an example, however, the FA might 118 typically delegate the duty of finding a HDAA to a local AAA server. 120 The Registration Reply from the Home Agent MUST include the Mobile- 121 Node-NAI extension. The Registration Reply MUST include a nonzero 122 Home Agent address and Mobile Node's Home Address. 124 2. Mobile-Node-NAI Extension 126 The Mobile-Node-NAI Extension contains the user and/or host name 127 following the format defined in [1]. The NAI is used to identify a 128 user or host and can be used to find a HDAA within the requestor's 129 home domain. 131 When present in the Registration Request, the Home Agent and Home 132 Address fields MAY be set to zero (0). Since the foreign agent 133 cannot use the Home Address in the reply to identify the Mobile Node, 134 it MUST use the NAI instead in its pending registration request 135 records. If the foreign agent cannot manage pending registration 136 request records in this way, it MUST return a Registration Reply with 137 status 77 (unexpected extension). 139 The Mobile-Node-NAI Extension, shown in figure 2, MUST appear before 140 the Foreign-Home Authentication Extension. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Type | Length | MN-NAI ... 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 2: The Mobile-Node-NAI Extension 150 Type TDB 152 Length 154 Mobile-Node-NAI Contains the username or host name in the format 155 defined in [1]. 157 3. Security Considerations 159 This document assumes that the Mobile IP messages are authenticated 160 using a method defined by the Mobile IP protocol. This proposal does 161 require that the Mobile Node's NAI be sent in the clear over the 162 network, but that is not expected to be a security issue. 164 4. IPv6 considerations 166 For mobile nodes using IPv6, there are no commonly deployed 167 mechanisms by which a mobile node may verify credentials, such 168 as there are with IPv4. Nevertheless, it may be the case that 169 mobile nodes using IPv6 mobility would like to specify the domain 170 in which their credentials may be checked, by using a NAI just 171 as this specification proposes for IPv4. In the case of IPv6, 172 however, there is no foreign agent in place to forward the mobile 173 node's binding update, and thus to manage the verification of the 174 credentials offered by the mobile node. In order for the NAI to 175 serve the purpose of identifying the home AAA that has the expected 176 relationship with the mobile node, the NAI would have to be forwarded 177 to a local AAA by the local agent involved with configuring the 178 care-of address of the mobile node. 180 This local agent can be identified as either the router sending out 181 Router Advertisements [5] for use by the mobile node with stateless 182 address autoconfiguration, or as an appropriate DHCPv6 [2] server. 183 In the former case, the ability to handle the NAI would be signaled 184 by the router in question by attaching a new extension to the Router 185 Advertisement. In the latter case, for managed links, the mobile 186 node would include an NAI extension to the DHCP Solicitation for use 187 by the DHCP server. The NAI extension would also be required on the 188 subsequent DHCP Request unicast by the mobile node to the DHCP Server 189 selected on the basis of received DHCP Advertisements. 191 5. Acknowledgements 193 The authors would like to thank Gabriel Montenegro and Vipul Gupta 194 for their useful discussions. 196 References 198 [1] B. Aboba and M. A. Beadles. The network access identifier. 199 draft-ietf-roamops-nai-12.txt, November 1998. (work in 200 progress). 202 [2] J. Bound and C. Perkins. Dynamic Host Configuration Protocol 203 for IPv6. draft-ietf-dhc-dhcpv6-14.txt, June 1998. (work in 204 progress). 206 [3] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. 207 draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in 208 progress). 210 [4] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 211 IP version 6 (IPv6). RFC 1970, August 1996. 213 [5] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor 214 discovery for IP Version 6 (IPv6), December 1998. Obsoletes 215 RFC1970 [4]. Status: DRAFT STANDARD. 217 [6] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 218 1996. 220 Chairs' Addresses 222 The working group can be contacted via the current chairs: 224 Jim Solomon Erik Nordmark 225 Redback Networks, Inc. Sun Microsystems, Inc. 226 1301 E. Algonquin Road 17 Network Circle 227 Schaumburg, IL 60196 Menlo Park, California 94025 228 USA USA 230 Phone: +1-847-576-2753 Phone: +1 650 786-5166 231 Fax: Fax: +1 650 786-5896 232 E-mail: solomon@redbacknetworks.com E-mail: nordmark@sun.com 234 Author's Addresses 236 Questions about this memo can be directed to: 238 Pat R. Calhoun Charles E. Perkins 239 Sun Microsystems Laboratories Sun Microsystems Laboratories 240 15 Network Circle 15 Network Circle 241 Menlo Park, CA 94025 Menlo Park, CA 94025 242 USA USA 244 Phone: +1-650-786-7733 Phone: +1 650 786-6464 245 EMail: pat.calhoun@sun.com EMail: cperkins@eng.sun.com 246 Fax: +1 650 786-6445