GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5446

Network Working Group J. Korhonen Request for Comments: 5446 Nokia Siemens Networks Category: Informational U. Nilsson

                                                           TeliaSonera
                                                         February 2009
                 Service Selection for Mobile IPv4

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents (http://trustee.ietf.org/
 license-info) in effect on the date of publication of this document.
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract

 In some Mobile IPv4 deployments, identifying the mobile node or the
 mobility service subscriber is not enough to distinguish among the
 multiple services possibly provisioned to the mobile node.  The
 capability to specify different services in addition to the mobile
 node's identity can be leveraged to provide flexibility for mobility
 service providers to provide multiple services within a single
 mobility service subscription.  This document describes a Service
 Selection extension for Mobile IPv4 that is intended to assist home
 agents to make specific service selections for their mobility service
 subscriptions during the registration procedure.

Korhonen & Nilsson Informational [Page 1] RFC 5446 Service Selection for MIPv4 February 2009

Table of Contents

 1. Introduction ....................................................2
 2. Requirements ....................................................3
 3. Service Selection Extension .....................................3
 4. Processing Considerations .......................................5
    4.1. Mobile Node Considerations .................................5
    4.2. Home Agent Considerations ..................................5
    4.3. Foreign Agent Considerations ...............................6
 5. Security Considerations .........................................7
 6. IANA Considerations .............................................7
 7. Acknowledgments .................................................7
 8. References ......................................................8
    8.1. Normative References .......................................8
    8.2. Informative References .....................................8

1. Introduction

 Mobile IPv4 [RFC3344] can identify mobile nodes in various ways,
 including home addresses [RFC3344] and Network Access Identifiers
 (NAIs) [RFC4282] [RFC2794].  In some Mobile IPv4 deployments,
 identifying the mobile node (MN) or the mobility service subscriber
 via a Proxy Mobile IPv4 client [LEUNG] (hereafter, the mobile node
 and the Proxy Mobile IPv4 client are used interchangeably) is not
 enough to distinguish among the multiple services possibly
 provisioned to the mobile node.
 The capability to specify different services in addition to the
 mobile node's identity can be leveraged to provide flexibility for
 mobility service providers to provide multiple services within the
 same mobility service subscription.  For example:
 o  Provide an enterprise data access for which the mobility service
    provider hosts connectivity and mobility services on behalf of the
    enterprise.
 o  Provide access to service domains that are otherwise not
    accessible from public networks because of some mobility service
    providers' business reasons.
 o  Provide simultaneous access to different service domains that are
    separated based on policies of the mobility service provider.
 o  Enable easier policy assignment for mobility service providers
    based on the subscribed services.

Korhonen & Nilsson Informational [Page 2] RFC 5446 Service Selection for MIPv4 February 2009

 This document describes a Service Selection extension for Mobile IPv4
 that is intended to assist home agents to make specific service
 selections for their mobility service subscriptions during the
 registration procedure.  A Mobile IPv6-equivalent Service Selection
 Mobility Option has been described in [RFC5149].  The service
 selection may affect home agent routing decisions, Home Address
 assignment policies, firewall settings, and security policies.  When
 the service selection is used, every Registration Request must
 contain the Service Selection extension.  The Service Selection
 extension from the Registration Request may be echoed back in the
 Registration Reply.
 In absence of a specifically indicated service, the home agent must
 act as if the default service, plain Internet access, had been
 requested.  There is no absolute requirement that this default
 service would be allowed to all subscribers, but it is highly
 recommended in order to avoid having normal subscribers employ
 operator-specific configuration values in order to get basic service.
 Some of the potential use cases were listed earlier in this section.
 The general aim is better manageability of services and service
 provisioning, from both operators' and service providers' points of
 view.  However, it should be understood that there are potential
 deployment possibilities where selecting a certain service may
 restrict simultaneous access to other services from a user point of
 view (e.g., a "walled garden").  For example, services may be located
 in different administrative domains or external customer networks
 that practice excessive filtering of inbound and outbound traffic.

2. Requirements

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

3. Service Selection Extension

 At most one Service Selection extension MAY be included in any Mobile
 IPv4 Registration Request message.  When the service selection is
 used, the Service Selection extension MUST be included in every
 Registration Request message.  In absence of a specifically indicated
 service in the Registration Request for the initial registration or
 re-registration, the home agent MUST act as if the default service,
 such as plain Internet access, had been requested.  The Service
 Selection extension MUST be placed in the Registration Request
 message as follows:

Korhonen & Nilsson Informational [Page 3] RFC 5446 Service Selection for MIPv4 February 2009

 o  When present, the extension MUST appear after the MN-NAI
    extension, if the MN-NAI is also present in the message.
 o  If the extension was added by the mobile node to a Registration
    Request, it MUST appear prior to any authentication-enabling
    extensions [RFC3344] [RFC4721].
 o  In the event the foreign agent adds the Service Selection
    extension to a Registration Request, the extension MUST appear
    prior to any Foreign-Home authentication-enabling extensions
    [RFC3344].
 The home agent MAY echo the received Service Selection extension
 option back in a Mobile IPv4 Registration Reply message.  The echoed
 Service Selection extension MUST be an unchanged copy of the Service
 Selection extension received in the corresponding Registration
 Request message.  The Service Selection extension MUST be placed in
 the Registration Reply message as follows:
 o  If the extension was originally added by the mobile node to a
    Registration Request, it MUST appear in the Registration Reply
    prior to any authentication-enabling extensions [RFC3344]
    [RFC4721].
 o  If the foreign agent added the Service Selection extension to a
    Registration Request, the extension MUST appear in the
    Registration Reply prior to any Foreign-Home authentication-
    enabling extensions [RFC3344].
 The Service Selection extension has the following format:
  0                   1                   2                   3
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type = 151   |   Length      | Identifier...                 ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Service Selection Extension
 o  Type: 8-bit identifier set to 151 (the type of this skippable
    extension).
 o  Length: 8-bit unsigned integer, representing the length of the
    Service Selection extension in octets, excluding the Type and
    Length fields.  A value of zero (0) is not allowed.

Korhonen & Nilsson Informational [Page 4] RFC 5446 Service Selection for MIPv4 February 2009

 o  Identifier: A variable-length, encoded service-identifier string
    used to identify the requested service.  The identifier string
    length is between 1 and 255 octets.  This specification allows
    international identifier strings that are based on the use of
    Unicode characters, encoded as UTF-8 [RFC3629] and formatted using
    Normalization Form KC (NFKC) as specified in [NFKC].
    'ims', 'voip', and 'voip.companyxyz.example.com' are valid
    examples of Service Selection extension Identifiers.  At minimum
    the Identifier MUST be unique among the home agents to which the
    mobile node is authorized to register.

4. Processing Considerations

4.1. Mobile Node Considerations

 A mobile node or its proxy representative MAY include the Service
 Selection extension into any Registration Request message.  The
 Service Selection extension can be used with any mobile node
 identification method.  The extension is used to identify the service
 to be associated with the mobility session; if the service selection
 is used, the Service Selection extension MUST be included into every
 Registration Request message sent to a home agent.  If the mobile
 node wishes to change the selected service, it is RECOMMENDED that
 the mobile node de-register the existing binding with the home agent
 before proceeding with a binding registration for a different
 service.  The provisioning of the service identifiers to the mobile
 node or its proxy representative is out of the scope of this
 specification.
 If the mobile node receives a Registration Reply message with a Code
 set to SERVICE_AUTHORIZATION_FAILED and the mobile node has an
 existing binding with the Home Address used in the failed
 Registration Request message, the mobile node MUST delete the
 existing binding.  If there is no existing binding, the mobile node
 proceeds as with any failed initial registration.

4.2. Home Agent Considerations

 Upon receiving the Service Selection extension, the home agent
 authenticates and authorizes the mobile node.  If the home agent
 supports the Service Selection, it MUST also verify that the mobile
 node is authorized to the service identified by the Service Selection
 extension.  The services the mobile node is authorized to SHOULD be
 part of the general mobile node subscription data.  If the mobile
 node is not authorized to the service, or the home agent does not

Korhonen & Nilsson Informational [Page 5] RFC 5446 Service Selection for MIPv4 February 2009

 recognize the identified service, the home agent MUST deny the
 registration and send a Registration Reply with a Code
 SERVICE_AUTHORIZATION_FAILED (error code 151).
 The Service Selection extension is used to assist the mobile node
 authorization phase and identifies a specific service that is to be
 authorized.  The Service Selection extension MAY also affect the Home
 Address allocation when, for example, used with the MN-NAI extension.
 For example, for the same NAI, there MAY be different Home Addresses,
 depending on the identified service.  Furthermore, the Service
 Selection extension MAY also affect the routing of the outbound IP
 packets in the home agent depending on the selected service.  The
 home agent MAY also apply different policy or quality of service
 treatment to traffic flows based on the selected service.
 If the newly arrived Registration Request message with a Service
 Selection extension indicates a change in the selected service, then
 the home agent MUST re-authorize the mobile node.  The absence of the
 Service Selection extension MUST be treated as a request for the
 default service, which may also cause the re-authorization of the
 mobile node.  Depending on the home agent's policies, the services
 policies, the Home Address allocation policies, and the subscription
 policies, the home agent may or may not be able to authorize the
 mobile node to the new service.  For example the existing service and
 the new service could require different Home Addresses.  If the
 authorization fails, then the home agent MUST deny the registration,
 delete any binding with the existing Home Address, and send a
 Registration Reply with a Code set to SERVICE_AUTHORIZATION_FAILED
 (error code 151).
 Depending on the local home agent's policy, the home agent MAY echo
 the Service Selection extension in the corresponding Registration
 Reply message towards the mobile node or the foreign agent.  The home
 agent MUST NOT change the content of the echoed Service Selection
 extension.

4.3. Foreign Agent Considerations

 A foreign agent MUST skip the Service Selection extension if the
 Registration Request already contains the Service Selection
 extension.  If the Registration Request does not contain the Service
 Selection extension, the foreign agent MAY add the Service Selection
 extension to the Registration Request message.  How the foreign agent
 learns the service that the mobile node needs to authorize is outside
 the scope of this document.

Korhonen & Nilsson Informational [Page 6] RFC 5446 Service Selection for MIPv4 February 2009

 In the case a foreign agent added the Service Selection extension to
 the Registration Request on behalf of the mobile node, it MUST verify
 whether the corresponding Registration Reply message from a home
 agent also contains an echoed Service Selection extension.  If the
 received Registration Reply message contains the echoed Service
 Selection extension, the foreign agent MUST NOT include the extension
 to the Registration Reply message that gets forwarded to the mobile
 node.

5. Security Considerations

 The protection for the Service Selection extension depends on the
 service that is being identified and eventually selected.  If the
 service selection information should not be revealed on the wire, it
 should be protected in a manner similar to Registration Requests and
 Registration Replies.  The Service Selection extension is protected
 by the same authentication-enabling extension as the rest of the
 Registration Request message.
 The home agent MUST verify that the mobile node is authorized to the
 service included in the Service Selection extension.  The Service
 Selection extension authorization is part of the normal mobile node
 registration and authentication procedure.  Both registration
 authentication and service authorization MUST succeed before the
 mobile node is allowed to register to the home agent.

6. IANA Considerations

 A new Mobile IPv4 Extension type has been assigned in the "Extensions
 appearing in Mobile IP control messages" registry for the extension
 described in Section 3.  The Extension type has been allocated from
 the 'skippable' range (128-255):
     Service Selection Extension       is set to 151
 A new Mobile IPv4 error code has been assigned in the "Registration
 denied by the home agent" section of the "Code Values for Mobile IP
 Registration Reply Messages" registry.  The error code has been
 allocated from the 'Error Codes from the Home Agent' range (128-192):
     SERVICE_AUTHORIZATION_FAILED      is set to 151

7. Acknowledgments

 The authors would like to thank Henrik Levkowetz, Kent Leung, Spencer
 Dawkins, and Jari Arkko for their comments.  Jouni Korhonen also
 acknowledges TeliaSonera and the TEKES MERCoNe project, where most of
 the work was conducted.

Korhonen & Nilsson Informational [Page 7] RFC 5446 Service Selection for MIPv4 February 2009

8. References

8.1. Normative References

 [NFKC]     Davis, M. and M. Durst, "Unicode Standard Annex #15;
            Unicode Normalization Forms", Unicode 5.0.0, October 2006.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
            August 2002.
 [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
            10646", STD 63, RFC 3629, November 2003.

8.2. Informative References

 [LEUNG]    Leung, K., "WiMAX Forum/3GPP2 Proxy Mobile IPv4", Work
            in Progress, December 2008.
 [RFC2794]  Calhoun, P. and C. Perkins, "Mobile IP Network Access
            Identifier Extension for IPv4", RFC 2794, March 2000.
 [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
            Network Access Identifier", RFC 4282, December 2005.
 [RFC4721]  Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
            Challenge/Response Extensions (Revised)", RFC 4721,
            January 2007.
 [RFC5149]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
            Selection for Mobile IPv6", RFC 5149, February 2008.

Korhonen & Nilsson Informational [Page 8] RFC 5446 Service Selection for MIPv4 February 2009

Authors' Addresses

 Jouni Korhonen
 Nokia Siemens Networks
 Linnoitustie 6
 FIN-02600 Espoo
 FINLAND
 EMail: jouni.nospam@gmail.com
 Ulf Nilsson
 TeliaSonera Corporation
 Marbackagatan 11
 S-123 86 Farsta
 SWEDEN
 EMail: ulf.s.nilsson@teliasonera.com

Korhonen & Nilsson Informational [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5446.txt · Last modified: 2009/02/09 22:28 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki