idnits 2.17.1 draft-korhonen-mip6-service-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 396. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 20, 2007) is 5972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. '5') (Obsoleted by RFC 7542) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-07 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility for IPv6 (MIP6) J. Korhonen 3 Internet-Draft U. Nilsson 4 Intended status: Informational TeliaSonera 5 Expires: June 22, 2008 V. Devarapalli 6 Azaire 7 December 20, 2007 9 Service Selection for Mobile IPv6 10 draft-korhonen-mip6-service-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 any 26 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 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 22, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 In some Mobile IPv6 deployments identifying the mobile node or the 44 mobility service subscriber is not enough to distinguish between 45 multiple services possibly provisioned to the said mobile node and 46 its mobility service subscription. A capability to specify different 47 services in addition to the mobile node identity can be leveraged to 48 provide flexibility for mobility service providers on provisioning 49 multiple services to one mobility service subscription. This 50 document describes a Service Selection Mobility Option for both 51 conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to 52 assist home agents to make a specific service selection for the 53 mobility service subscription during the binding registration 54 procedure. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Service Selection Mobility Option . . . . . . . . . . . . . . 4 61 4. Processing Considerations . . . . . . . . . . . . . . . . . . 5 62 4.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 5 63 4.2. Home Agent Considerations . . . . . . . . . . . . . . . . 6 64 4.3. Correspondent Node Considerations . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Intellectual Property and Copyright Statements . . . . . . . . . . 10 74 1. Introduction 76 Mobile IPv6 [1] can identify mobile nodes in various ways, including 77 home addresses [1], Network Access Identifiers (NAIs) [5][6], and 78 credentials suitable for IKEv2 [7]. In some Mobile IPv6 deployments 79 identifying the mobile node or the mobility service subscriber via a 80 Proxy Mobile IPv6 client [8] (hereafter the mobile node and the Proxy 81 Mobile IPv6 client are used interchangeably) is not enough to 82 distinguish between multiple services possibly provisioned to the 83 said mobile node and its mobility service subscription. 85 The capability to specify different services in addition to the 86 mobile node identity can be leveraged to provide flexibility for 87 mobility service providers to provide multiple services within the 88 same mobility service subscription. For example: 90 o Provide an enterprise data access for which the mobility service 91 provider hosts connectivity and mobility services on behalf of the 92 enterprise. 94 o Provide access to service domains that are otherwise not 95 accessible from public networks because of some mobility service 96 provider's business reasons. 98 o Provide simultaneous access to different service domains that are 99 separated based on policies of the mobility service provider. 101 o Enable easier policy and quality of service assignment for 102 mobility service providers based on the subscribed services. 104 o In absence of a specifically indicated service the home agent MUST 105 act as if the default service, plain Internet access had been 106 requested. There is no absolute requirement that this default 107 service be allowed to all subscribers, but it is highly 108 RECOMMENDED in order to avoid having normal subscribers employ 109 operator-specific configuration values in order to get basic 110 service. 112 This document describes a Service Selection Mobility Option for 113 Mobile IPv6 that is intended to assist home agents to make specific 114 service selections for the mobility service subscription during the 115 binding registration procedure. The service selection may affect 116 home agent routing decisions, Home Address or Home Network Prefix 117 assignment policies, firewall settings, and security policies. The 118 Service Selection option should be used in every Binding Update that 119 makes a new registration to the home agent. 121 Some of the potential use-cases were listed earlier in this section. 123 The general aim is better manageability of services and service 124 provisioning from both operators and service providers point of view. 125 However, it should be understood that there are potential deployment 126 possibilities where selecting a certain service may restricts 127 simultaneous access to other services from an user point of view. 128 For example, services may be located in different administrative 129 domains or external customer networks that practice excessive 130 filtering of inbound and outbound traffic. 132 2. Requirements 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [2]. 138 3. Service Selection Mobility Option 140 At most one Service Selection mobility option MAY be included in any 141 Binding Update message. If the Binding Update message includes any 142 authorization related options (such as the Binding Authorization Data 143 option [1]) or authentication related options (such as the Mobility 144 Message Authentication option [9]), then the Service Selection option 145 MUST appear before any mobility message authorization or 146 authentication related options. 148 The service selection option SHOULD NOT be send to a correspondent 149 node. The mobile node cannot assume that the correspondent node has 150 any knowledge about a specific service selection made between the 151 mobile node and the home agent. 153 The Service Selection option has no alignment requirement as such. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type = TBD | Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Identifier... 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Service Selection Mobility Option 165 o Type: 8-bit identifier set to TBD (to be defined by IANA) of the 166 type of the skipable mobility option. 168 o Length: 8-bit unsigned integer, representing the length of the 169 Service Selection mobility option in octets, excluding the Option 170 Type and Option Length fields. Value of zero (0) is not allowed. 172 o Identifier: A variable length encoded service identifier string 173 used to identify the requested service. The identifier string 174 length is between 1 to 255 octets. This specification allows 175 international identifier strings that are based on the use of 176 Unicode characters, encoded as UTF-8 [3] and formatted using 177 Normalization Form KC (NFKC) as specified in [4]. 179 'ims', 'voip' and 'voip.companyxyz.example.com' are valid examples 180 of Service Selection option Identifiers. At minimum the 181 Identifier MUST be unique among the home agents the mobile node is 182 authorized to register to. 184 4. Processing Considerations 186 4.1. Mobile Node Considerations 188 A mobile node or a Proxy Mobile IPv6 client MAY include at most one 189 Service Selection mobility option into a Binding Update message. The 190 option is used to identify the service to be associated with the 191 binding registration and SHOULD only be included into the initial 192 Binding Update message sent to a home agent. If the mobile node 193 wishes to change the selected service, it is RECOMMENDED that the 194 mobile node de-register the existing binding with the home agent 195 before proceeding with a binding registration for a different 196 service. The provisioning of the service identifiers to the mobile 197 node or to the Proxy Mobile IPv6 client is out of scope of this 198 specification. 200 The placement of the Service Selection option is as follows: when 201 present this option MUST appear after the MN-NAI option, if the MN- 202 NAI option is present, and before any authorization and 203 authentication related options. The Service Selection option can be 204 used with any mobile node identification method such as a home 205 address, a MN-NAI and credentials suitable for IKEv2. 207 If the mobile node receives a Binding Acknowledgement with a Status 208 Code set to SERVICE_AUTHORIZATION_FAILED and the mobile node has an 209 existing binding with the Home Address or the Home Network Prefix 210 used in the failed Binding Update message, the mobile node MUST 211 delete the existing binding. If there is no existing binding the 212 mobile node proceeds as with any failed initial binding registration. 214 4.2. Home Agent Considerations 216 Upon receiving a Bind Update message with a Service Selection option 217 the home agent authenticates and authorizes the mobile node. If the 218 home agent supports the Service Selection it MUST also verify that 219 the mobile node is authorized for the service it included in the 220 Service Selection option. The services the mobile node is authorized 221 for SHOULD be part of the general mobile node subscription profile. 222 If the mobile node is not authorized for the service the home agent 223 MUST deny the registration and send a Binding Acknowledgement with a 224 Status Code set to SERVICE_AUTHORIZATION_FAILED (error code TBD). 226 The Service Selection option is used to assist the authorization and 227 identifies a specific service that is to be authorized. The Service 228 Selection option MAY also affect the Home Address or the Home Network 229 Prefix allocation when for example used with the MN-NAI option. For 230 example, for the same NAI there MAY be different Home Addresses or 231 Home Network Prefixes depending on the identified service. 232 Furthermore, the Service Selection option MAY also affect the routing 233 of the outbound IP packets in the home agent depending on the 234 selected service. The home agent MAY also apply different policy or 235 quality of service treatment to traffic flows based on the selected 236 service. 238 If the newly arrived Binding Update message with a Service Selection 239 option indicates a change in the selected service, then the home 240 agent MUST re-authorize the mobile node. Depending on the home agent 241 policies, the services policies, Home Address or Home Network Prefix 242 allocation policies and the subscription policies the home agent may 243 or may not be able to authorize the mobile node to the new service. 244 For example the existing service and the new service could require 245 different Home Network Prefixes. If the authorization fails then the 246 home agent MUST deny the registration, delete any binding with the 247 existing Home Address or Home Network Prefix and send a Binding 248 Acknowledgement with a Status Code set to 249 SERVICE_AUTHORIZATION_FAILED (error code TBD). 251 4.3. Correspondent Node Considerations 253 Unless the correspondent node and the home agent share the same 254 knowledge about mobility services the Service Selection option is 255 more or less useless information to the correspondent node. The 256 correspondent node SHOULD silently ignore the Service Selection 257 option in this case. 259 There are deployment cases where the home agent and a correspondent 260 node, for example, belong to the same administrative domain. In this 261 case it is possible that the correspondent node share the same 262 knowledge of the services as the home agent. Therefore, the 263 correspondent node is, for example, able to provide service based 264 traffic handling to mobile nodes. 266 5. Security Considerations 268 The protection for the Service Selection mobility option depends on 269 the service that is being identified and eventually selected. If the 270 service selection information should not be revealed on the wire, 271 Binding Updates and Binding Acknowledgements should use Encapsulating 272 Security Payload (ESP) [10] in transport mode with a non-null 273 encryption transform to provide message confidentiality. 275 6. IANA Considerations 277 A new Mobile IPv6 Mobility Option type is required for the following 278 new mobility option described in Section 3: 280 Service Selection Mobility Option is set to TBD 282 A new Mobile IPv6 registration denied by home agent Status Code is 283 required. The Status Code must be allocated from the range 128-255: 285 SERVICE_AUTHORIZATION_FAILED is set to TBD 287 7. Acknowledgements 289 Jouni korhonen would like to thank TEKES MERCoNe project for 290 providing funding to work on this document. The authors would like 291 to thank Jari Arkko for his thorough review. 293 8. References 295 8.1. Normative References 297 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 298 IPv6", RFC 3775, June 2004. 300 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 301 Levels", BCP 14, RFC 2119, March 1997. 303 [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 304 STD 63, RFC 3629, November 2003. 306 [4] Davis, M. and M. Durst, "Unicode Standard Annex #15; Unicode 307 Normalization Forms", Unicode 5.0.0, October 2006. 309 8.2. Informative References 311 [5] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 312 Access Identifier", RFC 4282, December 2005. 314 [6] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 315 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 316 RFC 4283, November 2005. 318 [7] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 319 IKEv2 and the Revised IPsec Architecture", RFC 4877, 320 April 2007. 322 [8] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 323 B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07 324 (work in progress), November 2007. 326 [9] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 327 "Authentication Protocol for Mobile IPv6", RFC 4285, 328 January 2006. 330 [10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 331 December 2005. 333 Authors' Addresses 335 Jouni Korhonen 336 TeliaSonera Corporation 337 P.O.Box 970 338 FIN-00051 Sonera 339 Finland 341 Email: jouni.korhonen@teliasonera.com 342 Ulf Nilsson 343 TeliaSonera Corporation 344 Marbackagatan 11 345 S-123 86 Farsta 346 Sweden 348 Email: ulf.s.nilsson@teliasonera.com 350 Vijay Devarapalli 351 Azaire Networks 352 4800 Great America Pkwy 353 Santa Clara, CA 95054 354 USA 356 Email: vijay.devarapalli@azairenet.com 358 Full Copyright Statement 360 Copyright (C) The IETF Trust (2007). 362 This document is subject to the rights, licenses and restrictions 363 contained in BCP 78, and except as set forth therein, the authors 364 retain all their rights. 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 369 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 370 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 371 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Intellectual Property 376 The IETF takes no position regarding the validity or scope of any 377 Intellectual Property Rights or other rights that might be claimed to 378 pertain to the implementation or use of the technology described in 379 this document or the extent to which any license under such rights 380 might or might not be available; nor does it represent that it has 381 made any independent effort to identify any such rights. Information 382 on the procedures with respect to rights in RFC documents can be 383 found in BCP 78 and BCP 79. 385 Copies of IPR disclosures made to the IETF Secretariat and any 386 assurances of licenses to be made available, or the result of an 387 attempt made to obtain a general license or permission for the use of 388 such proprietary rights by implementers or users of this 389 specification can be obtained from the IETF on-line IPR repository at 390 http://www.ietf.org/ipr. 392 The IETF invites any interested party to bring to its attention any 393 copyrights, patents or patent applications, or other proprietary 394 rights that may cover technology that may be required to implement 395 this standard. Please address the information to the IETF at 396 ietf-ipr@ietf.org. 398 Acknowledgment 400 Funding for the RFC Editor function is provided by the IETF 401 Administrative Support Activity (IASA).