idnits 2.17.1 draft-ietf-mip6-mn-ident-option-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 241. -- Found old boilerplate from RFC 3978, Section 5.5 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 343. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** An RFC 3978, Section 5.1 paragraph was found, but not on the first page, as required. == 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 2, 2005) is 6808 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) -- Looks like a reference, but probably isn't: '1' on line 231 == Unused Reference: 'RFC2119' is defined on line 252, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Patel 3 Internet-Draft K. Leung 4 Expires: March 6, 2006 Cisco Systems 5 M. Khalil 6 H. Akhtar 7 Nortel Networks 8 K. Chowdhury 9 Starent Networks 10 September 2, 2005 12 Mobile Node Identifier Option for MIPv6 13 draft-ietf-mip6-mn-ident-option-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 6, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 Mobile IPv6 defines a new Mobility header which is used by mobile 47 nodes, correspondent nodes, and home agents in all messaging related 48 to the creation and management of bindings. Mobile IPv6 nodes need 49 the capability to identify themselves using an identity other than 50 the default home IP address. Some examples of identifiers include 51 NAI, FQDN, IMSI, MSISDN, etc. This document defines a new mobility 52 option that can be used by Mobile IPv6 entities to identify 53 themselves in messages containing a mobility header. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Mobile Node Identifier option . . . . . . . . . . . . . . . . 5 60 3.1. MN-NAI mobility option . . . . . . . . . . . . . . . . . . 6 61 3.2. Processing Considerations . . . . . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 4.1. General Considerations . . . . . . . . . . . . . . . . . . 7 64 4.2. MN NAI consideration . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 9 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Intellectual Property and Copyright Statements . . . . . . . . . . 13 72 1. Introduction 74 The base specification of Mobile IPv6 [RFC3775] identifies mobility 75 entities using an IPv6 address. It is essential to have a mechanism 76 wherein mobility entities can be identified using other identifiers 77 (for example, a network access identifier (NAI) [RFC_2486bis], 78 International Mobile Station Identifier (IMSI), an application/ 79 deployment specific opaque identifier etc). 81 The capability to identify a mobility entity via identifiers other 82 than the IPv6 address can be leveraged for performing various 83 functions, eg. 85 o authentication and authorization using an existing AAA 86 (Authentication, Authorization and Accounting) infrastructure or 87 via an HLR/AuC (Home Location Register/Authentication Center), 89 o dynamic allocation of a mobility anchor point, 91 o dynamic allocation of a home address etc. 93 This document defines an option with subtype number which denotes a 94 specific type of identifier. One instance of subtype, the NAI is 95 defined in Section 3.1. It is anticipated that other identifiers 96 will be defined for use in the mobility header in the future. 98 This option SHOULD be used when IKE/IPsec is not used for protecting 99 binding update or binding acknowledgements as specified in [RFC3775]. 100 It is typically used with authentication option [auth_id]. But this 101 option may be used independently. For example, the identifier can 102 provide accounting and billing services. 104 2. Terminology 106 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119. 110 3. Mobile Node Identifier option 112 The Mobile node identifier option is a new optional data field that 113 is carried in the Mobile IPv6 defined messages which includes the 114 mobility header. Various forms of identifiers can be used to 115 identify a MN. Some examples include a Network Access Identifier 116 (NAI) [RFC_2486bis], an opaque identifier applicable to a particular 117 application, etc. The subtype field in the option defines the 118 specific type of identifier. 120 This option can be used in mobility messages containing a mobility 121 header. The subtype field in the option is used to interpret the 122 specific type of identifier. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Option Type | Option Length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Subtype | Identifier ... 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Option Type: 134 MN-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier 135 of the type mobility option. 137 Option Length: 139 8-bit unsigned integer, representing the length in octets of 140 the Subtype and Identifier fields. 142 Subtype: 144 Subtype field defines the specific type of identifier included 145 in the identifier field. 147 Identifier: 149 A variable length identifier of type as specified by the 150 subtype field of this option. 152 This option does not have any alignment requirements. 154 3.1. MN-NAI mobility option 156 The MN-NAI mobility option uses the general format of the Mobile Node 157 Identifier option as defined in Section 3. This option uses the 158 subtype value of 1. The MN-NAI mobility option is used to identify 159 the mobile node. 161 The MN-NAI mobility option uses an identifier of the form user@realm 162 [RFC_2486bis]. This option MUST be implemented by the entities 163 implementing this specification. 165 3.2. Processing Considerations 167 The location of the MN identifier option is as follows: When present, 168 this option MUST appear before any authentication related option in a 169 message containing a mobility header. 171 4. Security Considerations 173 4.1. General Considerations 175 Mobile IPv6 already contains one mechanism for identifying mobile 176 nodes, the Home Address Option [RFC3775]. As a result, the 177 vulnerabilities of the new option defined in this document are 178 similar to those that already exist for Mobile IPv6. In particular, 179 the use of a permanent, stable identifier may compromise the privacy 180 of the user, making it possible to track a particular device or user 181 as it moves through different locations. 183 4.2. MN NAI consideration 185 Since a Mobile Node Identifier option Section 3 reveals the home 186 affiliation of a user, it may assist an attacker in determining the 187 identity of the user, help the attacker in targeting specific 188 victims, or assist in further probing of the username space. 190 These vulnerabilities can be addressed through various mechanisms, 191 such as those discussed below: 193 o Encrypting traffic at link layer such that other users on the same 194 link do not see the identifiers. This mechanism does not help 195 against attackers on the rest of the path between the mobile node 196 and its home agent. 198 o Encrypting the whole packet, such as when using IPsec to protect 199 the communications with the home agent [RFC3776]. 201 o Using an authentication mechanism that enables the use of privacy 202 NAIs [RFC_2486bis] or temporary, changing "pseudonyms" as 203 identifiers. 205 In any case, it should be noted that as the identifier option is only 206 needed on the first registration at the home agent and subsequent 207 registrations can use the home address, the window of privacy 208 vulnerability in this document is reduced as compared to the 209 [RFC3775]. In addition, this document is a part of a solution to 210 allow dynamic home addresses to be used. This is an improvement to 211 privacy as well, and affects both communications with the home agent 212 and the correspondent nodes, both of which have to be told the home 213 address. 215 5. IANA Considerations 217 IANA services are required for this document. The values for new 218 mobility options must be assigned from the Mobile IPv6 [RFC3775] 219 numbering space. 221 The values for Mobility Option types MN-ID-OPTION-TYPE as defined in 222 Section 3 need to be assigned. The suggested value is 7 for the MN- 223 ID-OPTION-TYPE. 225 IANA should record a value for this new mobility option. 227 In addition, IANA needs to create a new namespace for the subtype 228 field of the Mobile Node Identifier Option. The currently allocated 229 values are as follows: 231 NAI (defined in this document) [1] 233 New values for this namespace can be allocated using Standards Action 234 [RFC2434]. 236 6. IPR Disclosure Acknowledgement 238 By submitting this Internet-Draft, each author represents that any 239 applicable patent or other IPR claims of which he or she is aware 240 have been or will be disclosed, and any of which he or she becomes 241 aware will be disclosed, in accordance with Section 6 of BCP 79. 243 7. Acknowledgements 245 The authors would like to thank Basavaraj Patil for his review and 246 suggestions on this draft. Thanks to Jari Arkko for review and 247 suggestions regarding security considerations and various other 248 aspects of the document. 250 8. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 256 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 257 October 1998. 259 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 260 in IPv6", RFC 3775, June 2004. 262 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 263 Protect Mobile IPv6 Signaling Between Mobile Nodes and 264 Home Agents", RFC 3776, June 2004. 266 [RFC_2486bis] 267 Aboba, et. al., B., "The Network Access Identifier", 268 draft-ietf-radext-rfc2486bis-03.txt (work in progress), 269 November 2004. 271 [auth_id] Patel et. al., A., "Authentication Protocol for Mobile 272 IPv6", draft-ietf-mip6-mn-ident-option-04.txt (work in 273 progress), February 2005. 275 Authors' Addresses 277 Alpesh Patel 278 Cisco Systems 279 170 W. Tasman Drive 280 San Jose, CA 95134 281 US 283 Phone: +1 408-853-9580 284 Email: alpesh@cisco.com 286 Kent Leung 287 Cisco Systems 288 170 W. Tasman Drive 289 San Jose, CA 95134 290 US 292 Phone: +1 408-526-5030 293 Email: kleung@cisco.com 295 Mohamed Khalil 296 Nortel Networks 297 2221 Lakeside Blvd. 298 Richardson, TX 75082 299 US 301 Phone: +1 972-685-0574 302 Email: mkhalil@nortel.com 304 Haseeb Akhtar 305 Nortel Networks 306 2221 Lakeside Blvd. 307 Richardson, TX 75082 308 US 310 Phone: +1 972-684-4732 311 Email: haseebak@nortel.com 312 Kuntal Chowdhury 313 Starent Networks 314 30 International Place 315 Tewksbury, MA 01876 316 US 318 Phone: +1 214 550 1416 319 Email: kchowdury@starentnetworks.com 321 Intellectual Property Statement 323 The IETF takes no position regarding the validity or scope of any 324 Intellectual Property Rights or other rights that might be claimed to 325 pertain to the implementation or use of the technology described in 326 this document or the extent to which any license under such rights 327 might or might not be available; nor does it represent that it has 328 made any independent effort to identify any such rights. Information 329 on the procedures with respect to rights in RFC documents can be 330 found in BCP 78 and BCP 79. 332 Copies of IPR disclosures made to the IETF Secretariat and any 333 assurances of licenses to be made available, or the result of an 334 attempt made to obtain a general license or permission for the use of 335 such proprietary rights by implementers or users of this 336 specification can be obtained from the IETF on-line IPR repository at 337 http://www.ietf.org/ipr. 339 The IETF invites any interested party to bring to its attention any 340 copyrights, patents or patent applications, or other proprietary 341 rights that may cover technology that may be required to implement 342 this standard. Please address the information to the IETF at 343 ietf-ipr@ietf.org. 345 Disclaimer of Validity 347 This document and the information contained herein are provided on an 348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 350 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 351 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 352 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 355 Copyright Statement 357 Copyright (C) The Internet Society (2005). This document is subject 358 to the rights, licenses and restrictions contained in BCP 78, and 359 except as set forth therein, the authors retain all their rights. 361 Acknowledgment 363 Funding for the RFC Editor function is currently provided by the 364 Internet Society.