idnits 2.17.1 draft-korhonen-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 (March 12, 2012) is 4421 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-03 -- 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 March 12, 2012 8 Expires: September 13, 2012 10 Service Selection for Mobile IPv6 11 draft-korhonen-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 said mobile node and 18 its 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 September 13, 2012. 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 . . . . . . . . . . . . . . . . 6 73 3.3. Home Agent and Local Mobility Agent Considerations . . . . 7 74 3.4. Correspondent Node Considerations . . . . . . . . . . . . 8 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Normative references . . . . . . . . . . . . . . . . . . . 9 79 6.2. Informative references . . . . . . . . . . . . . . . . . . 10 80 Appendix A. Changes to RFC5149 . . . . . . . . . . . . . . . . . 10 81 A.1. Note #1 . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 A.2. Note #2 . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 A.3. Note #3 . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 A.4. Note #4 . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 Mobile IPv6 [RFC6275] can identify mobile nodes in various ways, 90 including home addresses, Network Access Identifiers (NAIs) 91 [RFC4282][RFC4283], and credentials suitable for the Internet Key 92 Exchange Protocol version 2 (IKEv2) [RFC4877]. Proxy Mobile IPv6 93 [RFC5213] uses Home Network Prefix (HNP) and/or Mobile Node 94 Identifier [RFC4283]. In some Mobile IPv6 deployments, identifying 95 the mobile node or the mobility service subscriber via a Proxy Mobile 96 IPv6 client [RFC5213] (hereafter, the mobile node and the Proxy 97 Mobile IPv6 client are used interchangeably) is not enough to 98 distinguish between multiple services possibly provisioned to the 99 said mobile node and its mobility service subscription. 101 The capability to specify different services in addition to the 102 mobile node identity can be leveraged to provide flexibility for 103 mobility service providers to provide multiple services within the 104 same mobility service subscription. For example: 106 o Provide an enterprise data access for which the mobility service 107 provider hosts connectivity and mobility services on behalf of the 108 enterprise. 110 o Provide access to service domains that are otherwise not 111 accessible from public networks because of some mobility service 112 provider's business reasons. 114 o Provide simultaneous access to different service domains that are 115 separated based on policies of the mobility service provider. 117 o Enable easier policy and quality of service assignment for 118 mobility service providers based on the subscribed services. 120 o In the absence of a specifically indicated service, the home agent 121 MUST act as if the default service, plain Internet access, had 122 been requested. There is no absolute requirement that this 123 default service 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 126 service. 128 This document describes a Service Selection Mobility Option for 129 (Proxy) Mobile IPv6 that is intended to assist home agents or local 130 mobility agents to make specific service selections for the mobility 131 service subscription during the binding registration procedure. The 132 service selection MAY affect home agent or local mobility agent 133 routing decisions, Home Address or Home Network Prefix assignment 134 policies, firewall settings, and security policies. The Service 135 Selection option SHOULD be used in every Binding Update that makes a 136 new registration to the home agent. 138 Some of the potential use-cases were listed earlier in this section. 139 The general aim is better manageability of services and service 140 provisioning from the point of view of both operators and service 141 providers. However, it should be understood that there are potential 142 deployment possibilities where selecting a certain service may 143 restrict simultaneous access to other services from a user's point of 144 view. For example, services may be located in different 145 administrative domains or external customer networks that practice 146 excessive filtering of inbound and outbound traffic. 148 There are existing deployments using the Service Selection option. 149 3GPP PMIPv6-based Evolved Packet Core (EPC) [RFC6459] deployments use 150 the Service Selection option to carry the Access Point Name (APN) 151 [TS.23003]. Recently, service provider Wi-Fi services over 152 residential architectures [I-D.gundavelli-v6ops-community-wifi-svcs] 153 that intend to integrate into e.g., 3GPP EPC using PMIPv6, need 154 Service Selection option again to carry the APN information for 155 identifying a particular routing domain. 157 2. Service Selection Mobility Option 159 At most one Service Selection Mobility option SHOULD be included in 160 any (Proxy) Binding Update message. If and only if the (Proxy) 161 Binding Update message included the Service Selection Option, then 162 the corresponding (Proxy) Binding Acknowledgement message SHOULD also 163 contain the Service Selection option with the service name in the 164 Identifier (see Note #1 in Appendix A.1). 166 If the (Proxy) Binding Update message includes any authorization- 167 related options (such as the Binding Authorization Data option 168 [RFC6275]) or authentication related options (such as the Mobility 169 Message Authentication option [RFC4285]), then the Service Selection 170 option MUST appear before any mobility message authorization- or 171 authentication-related options. 173 The Service Selection option SHOULD NOT be sent to a correspondent 174 node. The mobile node cannot assume that the correspondent node has 175 any knowledge about a specific service selection made between the 176 mobile node and the home agent. 178 The Service Selection option has no alignment requirement as such. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type = 20 | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Identifier... ~ 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1: Service Selection Mobility Option 190 o Type: 8-bit identifier set to 20 of the type of the skipable 191 mobility option. 193 o Length: 8-bit unsigned integer, representing the length of the 194 Service Selection Mobility Option in octets, excluding the Option 195 Type and Option Length fields. A value of zero (0) is not 196 allowed. 198 o Identifier: A variable-length encoded service identifier string 199 used to identify the requested service. The identifier string 200 length is between 1 and 255 octets. This specification allows 201 international identifier strings that are based on the use of 202 Unicode characters, encoded as UTF-8 [RFC3269], and formatted 203 using Normalization Form KC (NFKC) as specified in [NFKC] (see 204 Note #2 in Appendix A.2). 206 'ims', 'voip', and 'voip.companyxyz.example.com' are valid 207 examples of Service Selection option Identifiers. At minimum, the 208 Identifier MUST be unique among the home agents to which the 209 mobile node is authorized to register. 211 3. Processing Considerations 213 3.1. Binding Cache Entry Lookup Considerations 215 Section 5.4.1 of [RFC5213] describes various Binding Cache Entry 216 (BCE) lookup variations in the local mobility agent. Some existing 217 Proxy Mobile IPv6 deployments have added the Service Selection option 218 as one of the used BCE lookup keys (see Note #3 in Appendix A.3). 219 This implies that the Service Selection option SHOULD be included in 220 all Proxy Binding Update messages, especially when the Home Network 221 Prefix is not readily available. 223 3.2. Mobile Node Considerations 225 A mobile node or a Proxy Mobile IPv6 client MAY include, at most, one 226 Service Selection Mobility Option into a (Proxy) Binding Update 227 message. The option is used to identify the service to be associated 228 with the binding registration and SHOULD only be included into the 229 initial Binding Update message sent to a home agent. If the mobile 230 node wishes to change the selected service, it is RECOMMENDED that 231 the mobile node de-register the existing binding with the home agent 232 before proceeding with a binding registration for a different 233 service. The provisioning of the service identifiers to the mobile 234 node or to the Proxy Mobile IPv6 client is out of the scope of this 235 specification. 237 The placement of the Service Selection option is as follows: when 238 present, this option MUST appear after the Mobile Node-Network Access 239 Identifier (MN-NAI) option, if the MN-NAI option is present, and 240 before any authorization- and authentication-related options. The 241 Service Selection option can be used with any mobile node 242 identification method such as a home address, an MN-NAI, and 243 credentials suitable for IKEv2. 245 If the mobile node receives a (Proxy) Binding Acknowledgement with a 246 Status Code set to SERVICE_AUTHORIZATION_FAILED and the mobile node 247 has an existing binding with the Home Address or the Home Network 248 Prefix used in the failed (Proxy) Binding Update message, the mobile 249 node MUST delete the existing binding. If there is no existing 250 binding, the mobile node proceeds as with any failed initial binding 251 registration. 253 If the mobile node receives a (Proxy) Binding Acknowledgement with a 254 Status Code set to MISSING_OR_UNKNOWN_SERVICE the mobile node 255 proceeds as with any failed initial binding registration. The mobile 256 node SHOULD log the event as it is usually an indication of a 257 configuration error. 259 3.3. Home Agent and Local Mobility Agent Considerations 261 Upon receiving a (Proxy) Binding Update message with a Service 262 Selection option, the home agent or the local mobility agent 263 authenticates and authorizes the mobile node. If the home agent or 264 the local mobility anchor supports the Service Selection and the 265 Service Selection is required by the local policy, the home agent or 266 the local mobility anchor MUST also verify that the mobile node is 267 authorized for the service it included in the Service Selection 268 option. The services the mobile node is authorized for SHOULD be 269 part of the general mobile node subscription profile. If the mobile 270 node is not authorized for the service, the home agent or the local 271 mobility agent MUST deny the registration and send a (Proxy) Binding 272 Acknowledgement with a Status Code set to 273 SERVICE_AUTHORIZATION_FAILED (151). If the (Proxy) Binding Update 274 does not contain the Service Selection option or the indicated 275 service is unknown, the home agent or the local mobility agent SHOULD 276 deny the registration and send a (Proxy) Binding Acknowledgement with 277 a Status Code set to MISSING_OR_UNKNOWN_SERVICE (TBD) (see Note #4 in 278 Appendix A.4). 280 If binding registration was successful in the home agent or the local 281 mobility agent, then the (Proxy) Binding Acknowledgement SHOULD 282 contain the Service Selection option with the service name in the 283 Identifier. 285 The Service Selection option is used to assist the authorization and 286 identifies a specific service that is to be authorized. The Service 287 Selection option MAY also affect the Home Address or the Home Network 288 Prefix allocation when, for example, used with the MN-NAI option. 289 For example, for the same NAI there MAY be different Home Addresses 290 or Home Network Prefixes depending on the identified service. 291 Furthermore, the Service Selection option MAY also affect the routing 292 of the outbound IP packets in the home agent or the local mobility 293 agent depending on the selected service. The home agent MAY also 294 apply different policy or quality of service treatment to traffic 295 flows based on the selected service. 297 If the newly arrived (Proxy) Binding Update message with a Service 298 Selection option indicates a change in the selected service, then the 299 home agent MUST re-authorize the mobile node. Depending on the home 300 agent or the local mobility agent policies, the services policies, 301 Home Address or Home Network Prefix allocation policies, and the 302 subscription policies, the home agent may or may not be able to 303 authorize the mobile node to the new service. For example, the 304 existing service and the new service could require different Home 305 Network Prefixes. If the authorization fails, then the home agent or 306 the local mobility agent MUST deny the registration, delete any 307 binding with the existing Home Address or Home Network Prefix, and 308 send a (Proxy) Binding Acknowledgement with a Status Code set to 309 SERVICE_AUTHORIZATION_FAILED (151). 311 3.4. Correspondent Node Considerations 313 Unless the correspondent node and the home agent share the same 314 knowledge about mobility services, the Service Selection option is 315 more or less useless information to the correspondent node. The 316 correspondent node SHOULD silently ignore the Service Selection 317 option in this case. 319 There are deployment cases where the home agent and a correspondent 320 node, for example, belong to the same administrative domain. In this 321 case, it is possible that the correspondent node shares the same 322 knowledge of the services as the home agent. Therefore, the 323 correspondent node is, for example, able to provide service-based 324 traffic handling to mobile nodes. 326 4. Security Considerations 328 The protection for the Service Selection Mobility Option depends on 329 the service that is being identified and eventually selected. If the 330 service selection information should not be revealed on the wire, 331 (Proxy) Binding Updates and (Proxy) Binding Acknowledgements should 332 use Encapsulating Security Payload (ESP) [RFC4303] in transport mode 333 with a non-null encryption transform to provide message 334 confidentiality. 336 5. IANA Considerations 338 A Mobile IPv6 Mobility Option type has been assigned for the 339 following new mobility option from [RFC6275] "Mobility Options" 340 registry. The mobility option is defined in Section 2: 342 Service Selection Mobility Option is set to 20 344 A Mobile IPv6 registration denied by home agent Status Code has been 345 assigned. The Status Code was allocated from the range 128-255: 347 SERVICE_AUTHORIZATION_FAILED is set to 151 348 MISSING_OR_UNKNOWN_SERVICE is set to TBD 350 6. References 352 6.1. Normative references 354 [NFKC] Davis, M. and M. Durst, "Unicode Standard Annex #15; 355 Unicode Normalization Forms", Unicode 5.0.0, October 2006. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 361 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 363 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 364 in IPv6", RFC 6275, July 2011. 366 6.2. Informative references 368 [I-D.gundavelli-v6ops-community-wifi-svcs] 369 Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, 370 "Service Provider Wi-Fi Services Over Residential 371 Architectures", 372 draft-gundavelli-v6ops-community-wifi-svcs-03 (work in 373 progress), March 2012. 375 [RFC1035] Mockapetris, P., "Domain names - implementation and 376 specification", STD 13, RFC 1035, November 1987. 378 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 379 Reliable Multicast Transport (RMT) Building Blocks and 380 Protocol Instantiation documents", RFC 3269, April 2002. 382 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 383 Network Access Identifier", RFC 4282, December 2005. 385 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 386 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 387 (MIPv6)", RFC 4283, November 2005. 389 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 390 Chowdhury, "Authentication Protocol for Mobile IPv6", 391 RFC 4285, January 2006. 393 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 394 RFC 4303, December 2005. 396 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 397 IKEv2 and the Revised IPsec Architecture", RFC 4877, 398 April 2007. 400 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 401 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 402 Partnership Project (3GPP) Evolved Packet System (EPS)", 403 RFC 6459, January 2012. 405 [TS.23003] 406 3GPP, "Numbering, addressing and identification", 3GPP 407 TS 23.003 10.2.0, June 2011. 409 Appendix A. Changes to RFC5149 410 A.1. Note #1 412 3GPP EPC PMIPv6-based interfaces echo the Service Selection option 413 always back in Proxy Binding Acknowledgements. This is clarified 414 from the RFC5149, which did not say anything about the Service 415 Selection option in Proxy Binding Acknowledgement messages. 417 A.2. Note #2 419 3GPP EPC decided to encode their Service Selection Identifiers using 420 the [RFC1035] domain name encoding [TS.23003]. Implementations has 421 to take this into account when they intend to interoperate with 3GPP 422 EPC. 424 A.3. Note #3 426 3GPP EPC use the Service Selection option as one of the BCE lookup 427 keys. This is additional to what RFC5213 originally defined. 429 A.4. Note #4 431 RFC5149 did not make a difference between a service authorization 432 failure (SERVICE_AUTHORIZATION_FAILED) and a service not being 433 provisioned in a home agent/local mobility agent or otherwise unknown 434 (MISSING_OR_UNKNOWN_SERVICE). 436 Authors' Addresses 438 Jouni Korhonen 439 Nokia Siemens Networks 440 Linnoitustie 6 441 FIN-02600 Espoo 442 Finland 444 Email: jouni.nospam@gmail.com 446 Ulf Nilsson 447 TeliaSonera Corporation 448 Marbackagatan 11 449 S-123 86 Farsta 450 SWEDEN 452 Email: ulf.s.nilsson@teliasonera.com 453 Vijay Devarapalli 455 Email: dvijay@gmail.com