summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5446.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5446.txt')
-rw-r--r--doc/rfc/rfc5446.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5446.txt b/doc/rfc/rfc5446.txt
new file mode 100644
index 0000000..1d16297
--- /dev/null
+++ b/doc/rfc/rfc5446.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+