idnits 2.17.1 draft-ietf-netext-rfc5149bis-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5213, updated by this document, for RFC5378 checks: 2007-04-12) -- 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 (August 2, 2012) is 4283 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NFKC' == Outdated reference: A later version (-06) exists of draft-gundavelli-v6ops-community-wifi-svcs-04 -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network-Based Mobility Extensions J. Korhonen 3 (Netext) Nokia Siemens Networks 4 Internet-Draft U. Nilsson 5 Obsoletes: 5149 (if approved) TeliaSonera 6 Updates: 5213 (if approved) V. Devarapalli 7 Intended status: Standards Track August 2, 2012 8 Expires: February 3, 2013 10 Service Selection for Mobile IPv6 and Proxy Mobile IPv6 11 draft-ietf-netext-rfc5149bis-02.txt 13 Abstract 15 In some Mobile IPv6 deployments, identifying the mobile node or the 16 mobility service subscriber is not enough to distinguish between 17 multiple services possibly provisioned to the mobile node and its 18 mobility service subscription. A capability to specify different 19 services in addition to the mobile node identity can be leveraged to 20 provide flexibility for mobility service providers on provisioning 21 multiple services to one mobility service subscription. This 22 document describes a Service Selection Mobility Option for both 23 conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to 24 assist home agents and local mobility agents to make a specific 25 service selection for the mobility service subscription during the 26 binding registration procedure. This specification updates RFC5213 27 and obsoletes RFC5149. 29 Requirements 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 3, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Service Selection Mobility Option . . . . . . . . . . . . . . 5 70 3. Processing Considerations . . . . . . . . . . . . . . . . . . 6 71 3.1. Binding Cache Entry Lookup Considerations . . . . . . . . 6 72 3.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 7 73 3.3. Home Agent and Local Mobility Agent Considerations . . . . 7 74 3.4. Correspondent Node Considerations . . . . . . . . . . . . 8 75 4. Configuration Objects . . . . . . . . . . . . . . . . . . . . 9 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.1. Normative references . . . . . . . . . . . . . . . . . . . 10 80 7.2. Informative references . . . . . . . . . . . . . . . . . . 10 81 Appendix A. Changes from RFC5149 . . . . . . . . . . . . . . . . 11 82 A.1. Service Selection option in a PBA . . . . . . . . . . . . 11 83 A.2. Service Selection Identifier encoding . . . . . . . . . . 11 84 A.3. Using Service Selection as a BCE lookup key . . . . . . . 11 85 A.4. Addition of a new Status Code . . . . . . . . . . . . . . 11 86 A.5. Change of the document category from Informational to 87 Standards Track . . . . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 Mobile IPv6 [RFC6275] can identify mobile nodes in various ways, 93 including home addresses, Network Access Identifiers (NAIs) 94 [RFC4282][RFC4283], and credentials suitable for the Internet Key 95 Exchange Protocol version 2 (IKEv2) [RFC4877]. Proxy Mobile IPv6 96 [RFC5213] uses Home Network Prefix (HNP) and/or Mobile Node 97 Identifier [RFC4283]. In some Mobile IPv6 deployments, identifying 98 the mobile node or the mobility service subscriber via a Proxy Mobile 99 IPv6 client [RFC5213] (hereafter, the mobile node and the Proxy 100 Mobile IPv6 client are used interchangeably) is not enough to 101 distinguish between multiple services possibly provisioned to the 102 mobile node . 104 The capability to specify different services in addition to the 105 mobile node identity can be leveraged to provide flexibility for 106 mobility service providers to provide multiple services within the 107 same mobility service subscription. For example: 109 o Provide an enterprise data access for which the mobility service 110 provider hosts connectivity and mobility services on behalf of the 111 enterprise. 113 o Provide access to service domains that are otherwise not 114 accessible from public networks because of some mobility service 115 provider's business reasons. 117 o Provide simultaneous access to different service domains that are 118 separated based on policies of the mobility service provider. 120 o Enable easier policy and quality of service assignment for 121 mobility service providers based on the subscribed services. 123 o In the absence of a specifically indicated service, the home agent 124 MUST act as if the default service, plain Internet access, had 125 been requested. There is no absolute requirement that this 126 default service be allowed to all subscribers, but it is highly 127 RECOMMENDED in order to avoid having normal subscribers employ 128 operator-specific configuration values in order to get basic 129 service. 131 This document describes a Service Selection Mobility Option for 132 (Proxy) Mobile IPv6 that is intended to assist home agents or local 133 mobility agents to make specific service selections for the mobility 134 service subscription during the binding registration procedure. The 135 service selection may affect home agent or local mobility agent 136 routing decisions, Home Address or Home Network Prefix assignment 137 policies, firewall settings, charging and security policies among 138 others. The Service Selection option should be used in every (Proxy) 139 Binding Update or Acknowledgement message. 141 Some of the potential use-cases were listed earlier in this section. 142 The general aim is better manageability of services and service 143 provisioning from the point of view of both operators and service 144 providers. However, it should be understood that there are potential 145 deployment possibilities where selecting a certain service may 146 restrict simultaneous access to other services from a user's point of 147 view. For example, services may be located in different 148 administrative domains or external customer networks that practice 149 excessive filtering of inbound and outbound traffic. 151 There are existing deployments using the Service Selection option. 152 3GPP PMIPv6-based Evolved Packet Core (EPC) [RFC6459] deployments use 153 the Service Selection option to carry the Access Point Name (APN) 154 [TS.23003]. Recently, service provider Wi-Fi services over 155 residential architectures [I-D.gundavelli-v6ops-community-wifi-svcs] 156 that intend to integrate into e.g., 3GPP EPC using PMIPv6, need 157 Service Selection option again to carry the APN information for 158 identifying a particular routing domain. 160 2. Service Selection Mobility Option 162 At most one Service Selection Mobility option SHOULD be included in 163 any (Proxy) Binding Update message. If and only if the (Proxy) 164 Binding Update message included the Service Selection Option, then 165 the corresponding (Proxy) Binding Acknowledgement message SHOULD also 166 contain the Service Selection option with the service name in the 167 Identifier. 169 If the (Proxy) Binding Update message includes any authorization- 170 related options (such as the Binding Authorization Data option 171 [RFC6275]) or authentication related options (such as the Mobility 172 Message Authentication option [RFC4285]), then the Service Selection 173 option MUST appear before any mobility message authorization- or 174 authentication-related options. 176 The Service Selection option SHOULD NOT be sent to a correspondent 177 node. The mobile node cannot assume that the correspondent node has 178 any knowledge about a specific service selection made between the 179 mobile node and the home agent. 181 The Service Selection option has no alignment requirement as such. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type = 20 | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Identifier... ~ 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: Service Selection Mobility Option 193 o Type: 8-bit identifier set to 20 of the type of the skipable 194 mobility option. 196 o Length: 8-bit unsigned integer, representing the length of the 197 Service Selection Mobility Option in octets, excluding the Option 198 Type and Option Length fields. A value of zero (0) is not 199 allowed. 201 o Identifier: A variable-length encoded service identifier string 202 used to identify the requested service. The identifier string 203 length is between 1 and 255 octets. This specification allows 204 international identifier strings that are based on the use of 205 Unicode characters, encoded as UTF-8 [RFC3269], and formatted 206 using Normalization Form KC (NFKC) as specified in [NFKC]. 208 Alternatively, based on the local configuration, the identifier 209 string can be encoded using the domain name style encoding 210 described in Section 3.1 of [RFC1035]. However, the terminating 211 length of zero octet (i.e. the '\0' octet) is not included into 212 the encoded identifier since the option length implicitly tells 213 when the identifier string ends [TS.23003]. The selection of the 214 encoding is controlled by the ServiceSelectionMobilityOptionFormat 215 configuration object, see Section 4. 217 'ims', 'voip', and 'voip.companyxyz.example.com' are valid 218 examples of Service Selection option Identifiers. At minimum, the 219 Identifier MUST be unique among the home agents to which the 220 mobile node is authorized to register. 222 3. Processing Considerations 224 3.1. Binding Cache Entry Lookup Considerations 226 Section 5.4.1 of [RFC5213] describes various Binding Cache Entry 227 (BCE) lookup variations in the local mobility agent. Some existing 228 Proxy Mobile IPv6 deployments have added the Service Selection option 229 as one of the used BCE lookup keys. This implies that the Service 230 Selection option SHOULD be included in all Proxy Binding Update 231 messages, especially when the Home Network Prefix is not readily 232 available. 234 3.2. Mobile Node Considerations 236 A mobile node or a Proxy Mobile IPv6 client MAY include, at most, one 237 Service Selection Mobility Option into a (Proxy) Binding Update 238 message. The option is used to identify the service to be associated 239 with the binding registration and SHOULD only be included into the 240 initial Binding Update message sent to a home agent. If the mobile 241 node wishes to change the selected service, it is RECOMMENDED that 242 the mobile node de-register the existing binding with the home agent 243 before proceeding with a binding registration for a different 244 service. The provisioning of the service identifiers to the mobile 245 node or to the Proxy Mobile IPv6 client is out of the scope of this 246 specification. 248 The placement of the Service Selection option is as follows: when 249 present, this option MUST appear after the Mobile Node-Network Access 250 Identifier (MN-NAI) option, if the MN-NAI option is present, and 251 before any authorization- and authentication-related options. The 252 Service Selection option can be used with any mobile node 253 identification method such as a home address, an MN-NAI, and 254 credentials suitable for IKEv2. 256 If the mobile node receives a (Proxy) Binding Acknowledgement with a 257 Status Code set to SERVICE_AUTHORIZATION_FAILED and the mobile node 258 has an existing binding with the Home Address or the Home Network 259 Prefix used in the failed (Proxy) Binding Update message, the mobile 260 node MUST delete the existing binding. If there is no existing 261 binding, the mobile node proceeds as with any failed initial binding 262 registration. 264 If the mobile node receives a (Proxy) Binding Acknowledgement with a 265 Status Code set to MISSING_OR_UNKNOWN_SERVICE the mobile node 266 proceeds as with any failed initial binding registration. The mobile 267 node SHOULD log the event as it is usually an indication of a 268 configuration error. 270 3.3. Home Agent and Local Mobility Agent Considerations 272 Upon receiving a (Proxy) Binding Update message with a Service 273 Selection option, the home agent or the local mobility agent 274 authenticates and authorizes the mobile node. If the home agent or 275 the local mobility anchor supports the Service Selection and the 276 Service Selection is required by the local policy, the home agent or 277 the local mobility anchor MUST also verify that the mobile node is 278 authorized for the service it included in the Service Selection 279 option. The services the mobile node is authorized for SHOULD be 280 part of the general mobile node subscription profile. If the mobile 281 node is not authorized for the service, the home agent or the local 282 mobility agent MUST deny the registration and send a (Proxy) Binding 283 Acknowledgement with a Status Code set to 284 SERVICE_AUTHORIZATION_FAILED (151). If the (Proxy) Binding Update 285 does not contain the Service Selection option or the indicated 286 service is unknown, the home agent or the local mobility agent SHOULD 287 deny the registration and send a (Proxy) Binding Acknowledgement with 288 a Status Code set to MISSING_OR_UNKNOWN_SERVICE (TBD). 290 If binding registration was successful in the home agent or the local 291 mobility agent, then the (Proxy) Binding Acknowledgement SHOULD 292 contain the Service Selection option with the service name in the 293 Identifier. 295 The Service Selection option is used to assist the authorization and 296 identifies a specific service that is to be authorized. The Service 297 Selection option MAY also affect the Home Address or the Home Network 298 Prefix allocation when, for example, used with the MN-NAI option. 299 For example, for the same NAI there MAY be different Home Addresses 300 or Home Network Prefixes depending on the identified service. 301 Furthermore, the Service Selection option MAY also affect the routing 302 of the outbound IP packets in the home agent or the local mobility 303 agent depending on the selected service. The home agent MAY also 304 apply different policy or quality of service treatment to traffic 305 flows based on the selected service. 307 If the newly arrived (Proxy) Binding Update message with a Service 308 Selection option indicates a change in the selected service, then the 309 home agent MUST re-authorize the mobile node. Depending on the home 310 agent or the local mobility agent policies, the services policies, 311 Home Address or Home Network Prefix allocation policies, and the 312 subscription policies, the home agent may or may not be able to 313 authorize the mobile node to the new service. For example, the 314 existing service and the new service could require different Home 315 Network Prefixes. If the authorization fails, then the home agent or 316 the local mobility agent MUST deny the registration, delete any 317 binding with the existing Home Address or Home Network Prefix, and 318 send a (Proxy) Binding Acknowledgement with a Status Code set to 319 SERVICE_AUTHORIZATION_FAILED (151). 321 3.4. Correspondent Node Considerations 323 Unless the correspondent node and the home agent share the same 324 knowledge about mobility services, the Service Selection option is 325 more or less useless information to the correspondent node. The 326 correspondent node SHOULD silently ignore the Service Selection 327 option in this case. 329 There are deployment cases where the home agent and a correspondent 330 node, for example, belong to the same administrative domain. In this 331 case, it is possible that the correspondent node shares the same 332 knowledge of the services as the home agent. Therefore, the 333 correspondent node is, for example, able to provide service-based 334 traffic handling to mobile nodes. 336 4. Configuration Objects 338 This specification defines one configuration object that controls the 339 encoding of the service identifier string. 341 ServiceSelectionMobilityOptionFormat 343 This configuration object is available in both a MAG and in a LMA. 344 When set to 'label', the PMIPv6 node encodes the service 345 identifier string using [RFC1035] domain name encoding. When set 346 to 'dotted', the PMIPv6 node encodes the service identifier string 347 as any UTF-8 string. 349 5. Security Considerations 351 The protection for the Service Selection Mobility Option depends on 352 the service that is being identified and eventually selected. If the 353 service selection information should not be revealed on the wire, 354 (Proxy) Binding Updates and (Proxy) Binding Acknowledgements should 355 use Encapsulating Security Payload (ESP) [RFC4303] in transport mode 356 with a non-null encryption transform to provide message 357 confidentiality. 359 6. IANA Considerations 361 A Mobile IPv6 Mobility Option type has been assigned for the 362 following new mobility option from [RFC6275] "Mobility Options" 363 registry. The mobility option is defined in Section 2: 365 Service Selection Mobility Option is set to 20 367 A Mobile IPv6 registration denied by home agent Status Code has been 368 assigned. The Status Code was allocated from the range 128-255: 370 SERVICE_AUTHORIZATION_FAILED is set to 151 371 MISSING_OR_UNKNOWN_SERVICE is set to TBD 373 7. References 375 7.1. Normative references 377 [NFKC] Davis, M. and M. Durst, "Unicode Standard Annex #15; 378 Unicode Normalization Forms", Unicode 5.0.0, October 2006. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 384 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 386 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 387 in IPv6", RFC 6275, July 2011. 389 7.2. Informative references 391 [I-D.gundavelli-v6ops-community-wifi-svcs] 392 Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, 393 "Service Provider Wi-Fi Services Over Residential 394 Architectures", 395 draft-gundavelli-v6ops-community-wifi-svcs-04 (work in 396 progress), April 2012. 398 [RFC1035] Mockapetris, P., "Domain names - implementation and 399 specification", STD 13, RFC 1035, November 1987. 401 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 402 Reliable Multicast Transport (RMT) Building Blocks and 403 Protocol Instantiation documents", RFC 3269, April 2002. 405 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 406 Network Access Identifier", RFC 4282, December 2005. 408 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 409 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 410 (MIPv6)", RFC 4283, November 2005. 412 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 413 Chowdhury, "Authentication Protocol for Mobile IPv6", 414 RFC 4285, January 2006. 416 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 417 RFC 4303, December 2005. 419 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 420 IKEv2 and the Revised IPsec Architecture", RFC 4877, 421 April 2007. 423 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 424 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 425 Partnership Project (3GPP) Evolved Packet System (EPS)", 426 RFC 6459, January 2012. 428 [TS.23003] 429 3GPP, "Numbering, addressing and identification", 3GPP 430 TS 23.003 10.2.0, June 2011. 432 Appendix A. Changes from RFC5149 434 A.1. Service Selection option in a PBA 436 3GPP EPC PMIPv6-based interfaces echo the Service Selection option 437 always back in Proxy Binding Acknowledgements. This is clarified 438 from the RFC5149, which did not say anything about the Service 439 Selection option in Proxy Binding Acknowledgement messages. 441 A.2. Service Selection Identifier encoding 443 3GPP EPC decided to encode their Service Selection Identifiers using 444 the [RFC1035] domain name style encoding [TS.23003]. Implementations 445 has to take this into account when they intend to interoperate with 446 3GPP EPC. 448 A.3. Using Service Selection as a BCE lookup key 450 3GPP EPC use the Service Selection option as one of the BCE lookup 451 keys. This is additional to RFC5213 defined set of BCE lookup keys. 453 A.4. Addition of a new Status Code 455 RFC5149 did not make a difference between a service authorization 456 failure (SERVICE_AUTHORIZATION_FAILED) and a service not being 457 provisioned in a home agent/local mobility agent or otherwise unknown 458 (MISSING_OR_UNKNOWN_SERVICE). 460 A.5. Change of the document category from Informational to Standards 461 Track 463 RFC5149 has implementations by multiple vendors and there are several 464 deployments. Furthermore, RFC5149 is not specific to 3GPP networks 465 anymore. 467 Authors' Addresses 469 Jouni Korhonen 470 Nokia Siemens Networks 471 Linnoitustie 6 472 FIN-02600 Espoo 473 Finland 475 Email: jouni.nospam@gmail.com 477 Ulf Nilsson 478 TeliaSonera Corporation 479 Marbackagatan 11 480 S-123 86 Farsta 481 SWEDEN 483 Email: ulf.s.nilsson@teliasonera.com 485 Vijay Devarapalli 487 Email: dvijay@gmail.com