idnits 2.17.1 draft-korhonen-mip4-service-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 (January 9, 2009) is 5586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Korhonen 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational U. Nilsson 5 Expires: July 13, 2009 TeliaSonera 6 January 9, 2009 8 Service Selection for Mobile IPv4 9 draft-korhonen-mip4-service-08.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 13, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 In some Mobile IPv4 deployments identifying the mobile node or the 49 mobility service subscriber is not enough to distinguish between 50 multiple services possibly provisioned to the said mobile node and 51 its mobility service subscription. A capability to specify different 52 services in addition to the mobile node identity can be leveraged to 53 provide flexibility for mobility service providers to provide 54 multiple services within a single mobility service subscription. 55 This document describes a Service Selection Extension for Mobile IPv4 56 that is intended to assist home agents to make specific service 57 selections for the mobility service subscription during the 58 registration procedure. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Service Selection Extension . . . . . . . . . . . . . . . . . . 4 65 4. Processing Considerations . . . . . . . . . . . . . . . . . . . 5 66 4.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 6 67 4.2. Home Agent Considerations . . . . . . . . . . . . . . . . . 6 68 4.3. Foreign Agent Considerations . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 Mobile IPv4 [RFC3344] can identify mobile nodes in various ways, 80 including home addresses [RFC3344] and Network Access Identifiers 81 (NAI) [RFC4282][RFC2794]. In some Mobile IPv4 deployments 82 identifying the mobile node or the mobility service subscriber via a 83 Proxy Mobile IPv4 client [I-D.leung-mip4-proxy-mode] (hereafter the 84 mobile node and the Proxy Mobile IPv4 client are used 85 interchangeably) is not enough to distinguish between multiple 86 services possibly provisioned to the said mobile node and its 87 mobility service subscription. 89 The capability to specify different services in addition to the 90 mobile node identity can be leveraged to provide flexibility for 91 mobility service providers to provide multiple services within the 92 same mobility service subscription. For example: 94 o Provide an enterprise data access for which the mobility service 95 provider hosts connectivity and mobility services on behalf of the 96 enterprise. 98 o Provide access to service domains that are otherwise not 99 accessible from public networks because of some mobility service 100 provider's business reasons. 102 o Provide simultaneous access to different service domains that are 103 separated based on policies of the mobility service provider. 105 o Enable easier policy assignment for mobility service providers 106 based on the subscribed services. 108 This document describes a Service Selection Extension for Mobile IPv4 109 that is intended to assist home agents to make specific service 110 selections for the mobility service subscription during the 111 registration procedure. Mobile IPv6 equivalent Service Selection 112 Mobility Option has been described in [RFC5149]. The service 113 selection may affect home agent routing decisions, Home Address 114 assignment policies, firewall settings, and security policies. When 115 the service selection is used every Registration Request must contain 116 the Service Selection extension. The Service Selection extension 117 from the Registration Request may be echoed back in the Registration 118 Reply. 120 In absence of a specifically indicated service the home agent must 121 act as if the default service, plain Internet access had been 122 requested. There is no absolute requirement that this default 123 service would be allowed to all subscribers, but it is highly 124 recommended in order to avoid having normal subscribers employ 125 operator-specific configuration values in order to get basic service. 127 Some of the potential use-cases were listed earlier in this section. 128 The general aim is better manageability of services and service 129 provisioning from both operators and service providers point of view. 130 However, it should be understood that there are potential deployment 131 possibilities where selecting a certain service may restrict 132 simultaneous access to other services from an user point of view 133 (e.g., a "walled garden"). For example, services may be located in 134 different administrative domains or external customer networks that 135 practice excessive filtering of inbound and outbound traffic. 137 2. Requirements 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Service Selection Extension 145 At most one Service Selection extension MAY be included in any Mobile 146 IPv4 Registration Request message. When the service selection is 147 used, the Service Selection extension MUST be included in every 148 Registration Request message. In absence of a specifically indicated 149 service in the Registration Request for the initial registration or 150 re-registration, the home agent MUST act as if the default service, 151 such as plain Internet access had been requested. The Service 152 Selection extension MUST be placed in the Registration Request 153 message as follows: 155 o When present the extension MUST appear after the MN-NAI extension, 156 if the MN-NAI is also present in the message 158 o If the extension was added by the mobile node to a Registration 159 Request it MUST appear prior to any authentication-enabling 160 extensions [RFC3344][RFC4721] 162 o In the event the foreign agent adds the Service Selection 163 extension to a Registration Request, the extension MUST appear 164 prior to any Foreign-Home authentication-enabling extensions 165 [RFC3344] 167 The Home Agent MAY echo the received Service Selection extension 168 option back in a Mobile IPv4 Registration Reply message. The echoed 169 Service Selection extension MUST be an unchanged copy of the Service 170 Selection extension received in the corresponding Registration 171 Request message. The Service Selection extension MUST be placed in 172 the Registration Reply message as follows: 174 o If the extension was originally added by the mobile node to a 175 Registration Request it MUST appear in the Registration Reply 176 prior any authentication-enabling extensions [RFC3344][RFC4721] 178 o If the foreign agent added the Service Selection extension to a 179 Registration Request, the extension MUST appear in the 180 Registration Reply prior to any Foreign-Home authentication- 181 enabling extensions [RFC3344] 183 The Service Selection extension has the following format: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type = TBD1 | Length | Identifier... ~ 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Service Selection Extension 193 o Type: 8-bit identifier set to TBD1 (to be defined by IANA) of the 194 type of this skippable extension. 196 o Length: 8-bit unsigned integer, representing the length of the 197 Service Selection Extension in octets, excluding the Type and 198 Length fields. A value of zero (0) is not allowed. 200 o Identifier: A variable-length encoded service identifier string 201 used to identify the requested service. The identifier string 202 length is between 1 and 255 octets. This specification allows 203 international identifier strings that are based on the use of 204 Unicode characters, encoded as UTF-8 [RFC3629], and formatted 205 using Normalization Form KC (NFKC) as specified in [NFKC]. 207 'ims', 'voip' and 'voip.companyxyz.example.com' are valid examples 208 of Service Selection extension Identifiers. At minimum the 209 Identifier MUST be unique among the home agents the mobile node is 210 authorized to register to. 212 4. Processing Considerations 213 4.1. Mobile Node Considerations 215 A mobile node or its proxy representative MAY include the Service 216 Selection extension into any Registration Request message. The 217 Service Selection extension can be used with any mobile node 218 identification method. The extension is used to identify the service 219 to be associated with the mobility session and if the service 220 selection is used, the Service Selection extension MUST be included 221 into every Registration Request message sent to a home agent. If the 222 mobile node wishes to change the selected service, it is RECOMMENDED 223 that the mobile node de-register the existing binding with the home 224 agent before proceeding with a binding registration for a different 225 service. The provisioning of the service identifiers to the mobile 226 node or its proxy representative is out of scope of this 227 specification. 229 If the mobile node receives a Registration Reply message with a Code 230 set to SERVICE_AUTHORIZATION_FAILED and the mobile node has an 231 existing binding with the Home Address used in the failed 232 Registration Request message, the mobile node MUST delete the 233 existing binding. If there is no existing binding the mobile node 234 proceeds as with any failed initial registration. 236 4.2. Home Agent Considerations 238 Upon receiving the Service Selection extension the home agent 239 authenticates and authorizes the mobile node. If the home agent 240 supports the Service Selection it MUST also verify that the mobile 241 node is authorized to the service identified by the Service Selection 242 extension. The services the mobile node is authorized to SHOULD be 243 part of the general mobile node subscription data. If the mobile 244 node is not authorized to the service, or the home agent does not 245 recognize the identified service, the home agent MUST deny the 246 registration and send a Registration Reply with a Code 247 SERVICE_AUTHORIZATION_FAILED (error code TBD2). 249 The Service Selection extension is used to assist the mobile node 250 authorization phase and identifies a specific service that is to be 251 authorized. The Service Selection extension MAY also affect the Home 252 Address allocation when for example used with the MN-NAI extension. 253 For example, for the same NAI there MAY be different Home Addresses 254 depending on the identified service. Furthermore, the Service 255 Selection extension MAY also affect the routing of the outbound IP 256 packets in the home agent depending on the selected service. The 257 home agent MAY also apply different policy or quality of service 258 treatment to traffic flows based on the selected service. 260 If the newly arrived Registration Request message with a Service 261 Selection extension indicates a change in the selected service, then 262 the home agent MUST re-authorize the mobile node. The absence of the 263 Service Selection extension MUST be treated as a request for the 264 default service, which may also cause the re-authorization of the 265 mobile node. Depending on the home agent policies, the services 266 policies, Home Address allocation policies and the subscription 267 policies the home agent may or may not be able to authorize the 268 mobile node to the new service. For example the existing service and 269 the new service could require different Home Addresses. If the 270 authorization fails then the home agent MUST deny the registration, 271 delete any binding with the existing Home Address and send a 272 Registration Reply with a Code set to SERVICE_AUTHORIZATION_FAILED 273 (error code TBD2). 275 Depending on the local home agent policy, the home agent MAY echo 276 back the Service Selection extension in the corresponding 277 Registration Reply message towards the mobile node or the foreign 278 agent. The home agent MUST NOT change the content of the echoed 279 Service Selection extension. 281 4.3. Foreign Agent Considerations 283 A foreign agent MUST skip the Service Selection extension if the 284 Registration Request already contains the Service Selection 285 extension. If the Registration Request does not contain the Service 286 Selection extension the foreign agent MAY add the Service Selection 287 extension to the Registration Request message. How the foreign agent 288 learns the service the mobile nodes needs to authorize to is outside 289 of scope of this document. 291 In the case a foreign agent added the Service Selection extension to 292 the Registration Request on behalf of the mobile node, it MUST verify 293 whether the corresponding Registration Reply message from a home 294 agent also contains an echoed Service Selection extension. If the 295 received Registration Reply message contains the echoed Service 296 Selection extension, the foreign agent MUST NOT include the extension 297 to the Registration Reply message that gets forwarded to the mobile 298 node. 300 5. Security Considerations 302 The protection for the Service Selection extension depends on the 303 service that is being identified and eventually selected. If the 304 service selection information should not be revealed on the wire it 305 should be protected in a manner similar to Registration Requests and 306 Registration Replies. The Service Selection extension is protected 307 by the same authentication enabling extension as the rest of the 308 Registration Request message. 310 The home agent MUST verify that the mobile node is authorized to the 311 service included in the Service Selection extension. The Service 312 Selection extension authorization is part of the normal mobile node 313 registration and authentication procedure. Both registration 314 authentication and service authorization MUST succeed before the 315 mobile node is allowed to register to the home agent. 317 6. IANA Considerations 319 A new Mobile IPv4 skippable Extension type is required for the 320 following new Extension described in Section 3. The Extension type 321 must be from the 'skippable Extension' range (128-255): 323 Service Selection Extension is set to TBD1 325 A new Mobile IPv4 registration denied by home agent error code is 326 required. The error code must be allocated from the 'Error Codes 327 from the Home Agent' range (128-192): 329 SERVICE_AUTHORIZATION_FAILED is set to TBD2 331 7. Acknowledgements 333 The authors would like to thank Henrik Levkowetz, Kent Leung, Spencer 334 Dawkins and Jari Arkko for their comments. Jouni Korhonen also 335 acknowledges TeliaSonera and TEKES MERCoNe project where most of the 336 work was conducted. 338 8. References 340 8.1. Normative References 342 [NFKC] Davis, M. and M. Durst, "Unicode Standard Annex #15; 343 Unicode Normalization Forms", Unicode 5.0.0, October 2006. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 349 August 2002. 351 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 352 10646", STD 63, RFC 3629, November 2003. 354 8.2. Informative References 356 [I-D.leung-mip4-proxy-mode] 357 Leung, K., "WiMAX Forum/3GPP2 Proxy Mobile IPv4", 358 draft-leung-mip4-proxy-mode-10 (work in progress), 359 December 2008. 361 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 362 Identifier Extension for IPv4", RFC 2794, March 2000. 364 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 365 Network Access Identifier", RFC 4282, December 2005. 367 [RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 368 Challenge/Response Extensions (Revised)", RFC 4721, 369 January 2007. 371 [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 372 Selection for Mobile IPv6", RFC 5149, February 2008. 374 Authors' Addresses 376 Jouni Korhonen 377 Nokia Siemens Networks 378 Linnoitustie 6 379 FIN-02600 Espoo 380 FINLAND 382 Email: jouni.nospam@gmail.com 384 Ulf Nilsson 385 TeliaSonera Corporation 386 Marbackagatan 11 387 S-123 86 Farsta 388 SWEDEN 390 Email: ulf.s.nilsson@teliasonera.com