idnits 2.17.1 draft-ietf-mip4-aaa-nai-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (December 12, 2003) is 7440 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2486 (ref. '2') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (ref. '5') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3588 (ref. '6') (Obsoleted by RFC 6733) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group F. Johansson 2 Internet-Draft ipUnplugged 3 Expires: June 11, 2004 T. Johansson 4 Bytemobile 5 December 12, 2003 7 Mobile IPv4 Extension for carrying Network Access Identifiers 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on June 11, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 When a mobile node moves between two foreign networks it has to be 39 re-authenticated. If the home network has both multiple 40 Authentication Authorization and Accounting (AAA) servers and Home 41 Agents (HAs) in use, the Home AAA server may not have sufficient 42 information to process the re-authentication correctly (i.e., to 43 ensure that the same HA continues to be used). This document defines 44 a Mobile IP extension that carries identities for the Home AAA and HA 45 servers in the form of Network Access Identifiers (NAIs). The 46 extension allows a Home Agent to pass its identity (and that of the 47 Home AAA server) to the mobile node, which can then pass it on to the 48 local AAA server when changing its point of attachment. This 49 extension may also be used in other situations requiring 50 communication of a NAI between Mobile IP nodes. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements terminology . . . . . . . . . . . . . . . . . . . 3 58 3. NAI Carrying Extension . . . . . . . . . . . . . . . . . . . . 4 59 3.1 Processing of the NAI Carrying Extension . . . . . . . . 5 61 4. HA Identity subtype . . . . . . . . . . . . . . . . . . . . . 5 63 5. AAAH Identity subtype . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 71 Normative References . . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 75 Intellectual Property and Copyright Statements . . . . . . . . 9 77 1. Introduction 79 When building networks one would like to be able to have redundancy. 80 In order to achieve this, one might place multiple AAA servers in one 81 domain. When a mobile node registers via a visited network the 82 authentication will be handled by one of the AAA servers in the home 83 domain. At a later point, when the mobile node moves to another 84 visited domain it again has to be authenticated. However, due to the 85 redundancy offered by the AAA protocol, it can not be guaranteed that 86 the authentication will be handled by the same AAAH server as the 87 previous one, which can result in the new AAAH not knowing which HA 88 the session was assigned to. This document defines a Mobile IP 89 extension which can be used to distribute the information needed to 90 resolve this. 92 Furthermore, the only information that is normally available about 93 the home agent in the registration request is the IP address as 94 defined in RFC 3344 [5]. This may unfortunately not be enough, since 95 some AAA infrastructures (such as Diameter [6]) use realm based 96 routing; such a AAA infrastructure needs to know the FQDN identity of 97 the home agent to be able to correctly handle the assignment of home 98 agent. A reverse DNS lookup would only disclose the identity of the 99 Mobile IP interface for that HA IP address, which may or may not have 100 a one-to-one correspondence with the home agent FQDN identity. This 101 is a reason for the HA to also include its own identity in the 102 registration reply. The MIP v4 extension defined in this document 103 also has a subtype defined by which this may be done. The HA identity 104 can then be included by the mobile node in later registration 105 requests when changing point of attachment. 107 2. Requirements terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [1]. 113 The Mobile IP related terminology described in RFC 3344 [5] is used 114 in this document. In addition, the following terms are used: 116 AAAH 117 One of possible several AAA Servers in the Home Network 119 FQDN 120 Fully Qualified Domain Name. 122 Identity 123 The identity of a node is equal to its FQDN. 125 NAI 126 Network Access Identifier [2]. 128 3. NAI Carrying Extension 130 This section defines the NAI Carrying Extension which may be used in 131 Mobile IP Registration Request and Reply messages, and also in Mobile 132 IP Agent Advertisements [5]. The extension may be used by any node 133 that wants to send identity information in the form of a NAI [4]. 134 This document also defines some subtype numbers which identify the 135 specific type of NAI carried, in Section 4 and Section 5. It is 136 expected that other types of NAI will be defined by other documents 137 in the future. 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | Sub-Type | NAI ... 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Type 147 (Type to be assigned by IANA) (skippable) [5] 149 Length 8-bit unsigned integer. Length of the extension, in octets, 150 excluding the extension Type and the extension Length 151 fields. This field MUST be set to 1 plus the total length 152 of the NAI field. 154 Sub-Type This field describes the particular type NAI which is 155 carried in the NAI field. 157 NAI Contains the NAI [2] in a string format. 159 3.1 Processing of the NAI Carrying Extension 161 When a mobile node or home agent adds a NAI Carrying Extension to a 162 registration message, the extension MUST appear prior to any 163 authentication extensions. 165 In the event the foreign agent adds a NAI Carrying Extension to a 166 registration message, the extension MUST appear prior to any 167 authentication extensions added by the FA. 169 If an HA has appended a NAI Carrying Extension to a Registration 170 Reply to an MN, and does not receive the NAI extension in subsequent 171 Registration Request messages from the MN, the HA can assume that the 172 MN does not understand this NAI extension. In this case, the HA 173 SHOULD NOT append this NAI extension to further Registration Reply 174 messages to the MN. 176 4. HA Identity subtype 178 The HA identity uses subtype 1 of the NAI Carrying Extension. It 179 contains the NAI of the HA in the form hostname@realm. Together the 180 hostname and realm forms the complete FQDN (hostname.realm) of the 181 HA. 183 A Home Agent using this extension MUST provide it in the first 184 Registration Reply sent to a Mobile Node which is not currently 185 registered. The extension only need to be included in subsequent 186 Registration Replies if the same extension is included in 187 Registration Requests received from the same Mobile Node. 189 A mobile node using this extension MUST, if it receives it in a 190 registration reply message, provide it in every subsequent 191 registration request when re-authentication is needed. Failure to 192 re-authenticate, for instance because no AAAH can be reached, will 193 result in termination of the Mobile-IP session. On initiation of a 194 new session a new HA Identity NAI may be provided to the Mobile node, 195 and the requirement above will apply to the newly received NAI. 197 If the mobile node requires a specific home agent and it has the NAI 198 available it MUST provide this extension in its initial registration 199 request. 201 A foreign agent which receives the Home Agent NAI by this extension 202 in a registration request SHOULD include the Home Agent NAI when 203 requesting Mobile Node authentication through the AAA infrastructure 204 if the AAA protocol used can carry the information. 206 5. AAAH Identity subtype 208 The AAAH identity uses subtype 2 of the NAI Carrying Extension. It 209 contains the NAI of the home AAA server in the form hostname@realm. 210 Together the hostname and realm forms the complete FQDN 211 (hostname.realm) of the home AAA server. 213 If there exists several AAA servers in the Home Network, a Home Agent 214 providing AAAH selection support according to this document MUST 215 provide the AAAH identity in the first Registration Reply sent to the 216 Mobile Node. The extension only need to be included in subsequent 217 Registration Replies if the same extension is included in 218 Registration Requests received from the same Mobile Node. 220 A mobile node SHOULD save the latest AAAH Identity received in a 221 registration reply message and SHOULD provide the AAAH Identity in 222 every registration request sent when re-authenticating, for 223 efficiency reasons. Failure to reach the indicated AAAH during 224 re-authentication will result in a new AAAH Identity NAI being 225 returned (which should then be saved and provided in subsequent 226 registration requests). Similarly, failure to re-authenticate, for 227 instance because no AAAH can be reached, will result in termination 228 of the Mobile-IP session; on initiation of a new session a new AAAH 229 Identity NAI may be provided to the Mobile Node for re-use during 230 later re-registrations. 232 A foreign agent which receives the AAAH NAI by this extension in a 233 registration request SHOULD include the AAAH NAI provided when 234 requesting Mobile Node authentication through the AAA infrastructure 235 if the AAA protocol used can carry the information. 237 6. Security Considerations 239 This specification introduces new Mobile IP extensions that are used 240 to carry mobility agent and AAA server identities, in the form of 241 Network Access Identifiers. The Mobile IP messages that carry this 242 extension MUST be authenticated as described in [4], unless other 243 authentication methods have been agreed upon. Therefore, this 244 specification does not lessen the security of Mobile IP messages. 246 It should be noted that the identities sent in the extensions 247 specified herein MAY be sent in the clear over the network. However, 248 the authors do not envision that this information would create any 249 security issues. 251 7. IANA Considerations 253 This document defines one new mobile IP extension, and one new Mobile 254 IP extension sub-type numbering space to be managed by IANA. 256 Section 3 defines a new Mobile IP extension, the Mobile IP NAI 257 Carrying Extension. The type number for this extension is [TBD, 258 assigned by IANA]. This extension introduces a new sub-type 259 numbering space where the values 1 and 2 has been assigned values in 260 this document. Approval of new Mobile IP NAI Carrying Extension 261 sub-type numbers is subject to Expert Review, and a specification is 262 required [3]. 264 The content and format for this extension is not specific to AAA 265 NAIs, so if in the future new NAIs are defined which does not 266 strictly fall within the category of AAA NAIs, they may nevertheless 267 be accommodated within the subtype numbering space defined for the 268 NAI Carrying Extension defined in this document. 270 The NAI Carrying Extension should be assigned a type value from both 271 the IANA number space for Mobile IPv4 skippable extensions, and from 272 the IANA number space for Mobile IPv4 advertisement extensions. 273 Ideally, the numbers assigned from these two numbering spaces should 274 have the same value. 276 8. Acknowledgements 278 Thanks to the original authors of the GNAIE draft, Mohamed M Khalil, 279 Emad Qaddoura, Haseeb Akhtar, Pat R. Calhoun. The original draft was 280 removed from the MIP WG charter when no use was seen for the 281 extension. The original ideas has been reused in this draft. 283 Also thanks to Henrik Levkowetz and Kevin Purser for valuable 284 feedback and help when writing this draft. 286 Normative References 288 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 289 Levels", BCP 14, RFC 2119, March 1997. 291 [2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 292 2486, January 1999. 294 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 295 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 297 [4] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier 298 Extension for IPv4", RFC 2794, March 2000. 300 [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 301 2002. 303 [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 304 "Diameter Base Protocol", RFC 3588, September 2003. 306 Authors' Addresses 308 Fredrik Johansson 309 ipUnplugged AB 310 Arenavagen 23 311 Stockholm S-121 28 312 SWEDEN 314 Phone: +46 8 725 5916 315 EMail: fredrik@ipunplugged.com 317 Tony Johansson 318 Bytemobile Inc 319 2029 Stierlin Court 320 Mountain View, CA 94043 321 USA 323 Phone: +1 650 862 0523 324 EMail: tony.johansson@bytemobile.com 326 Intellectual Property Statement 328 The IETF takes no position regarding the validity or scope of any 329 intellectual property or other rights that might be claimed to 330 pertain to the implementation or use of the technology described in 331 this document or the extent to which any license under such rights 332 might or might not be available; neither does it represent that it 333 has made any effort to identify any such rights. Information on the 334 IETF's procedures with respect to rights in standards-track and 335 standards-related documentation can be found in BCP-11. Copies of 336 claims of rights made available for publication and any assurances of 337 licenses to be made available, or the result of an attempt made to 338 obtain a general license or permission for the use of such 339 proprietary rights by implementors or users of this specification can 340 be obtained from the IETF Secretariat. 342 The IETF invites any interested party to bring to its attention any 343 copyrights, patents or patent applications, or other proprietary 344 rights which may cover technology that may be required to practice 345 this standard. Please address the information to the IETF Executive 346 Director. 348 Full Copyright Statement 350 Copyright (C) The Internet Society (2003). All Rights Reserved. 352 This document and translations of it may be copied and furnished to 353 others, and derivative works that comment on or otherwise explain it 354 or assist in its implementation may be prepared, copied, published 355 and distributed, in whole or in part, without restriction of any 356 kind, provided that the above copyright notice and this paragraph are 357 included on all such copies and derivative works. However, this 358 document itself may not be modified in any way, such as by removing 359 the copyright notice or references to the Internet Society or other 360 Internet organizations, except as needed for the purpose of 361 developing Internet standards in which case the procedures for 362 copyrights defined in the Internet Standards process must be 363 followed, or as required to translate it into languages other than 364 English. 366 The limited permissions granted above are perpetual and will not be 367 revoked by the Internet Society or its successors or assignees. 369 This document and the information contained herein is provided on an 370 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 371 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 372 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 373 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 374 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Acknowledgment 378 Funding for the RFC Editor function is currently provided by the 379 Internet Society.