Network Working Group JC. Zuniga Internet-Draft M. Perras Intended status: Informational InterDigital Communications, LLC Expires: May 10, 2010 T. Melia Alcatel-Lucent Bell Labs C. Bernardos Universidad Carlos III de Madrid November 06, 2009 Support of Proxy MIP in the context of WiMAX Networks draft-zuniga-netext-wimax-mn-ar-if-00 Abstract This ID documents the support of Proxy MIP in the context of WiMAX networks (WiMAX-to-WiMAX using PMIP). The main goal is to support the Netext working group in the discussions regarding how RFC 5213 [RFC5213] has been deployed by other SDOs. Requirements Language 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 RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 10, 2010. Zuniga, et al. Expires May 10, 2010 [Page 1] Internet-Draft PMIP support in WiMAX November 2009 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Differences between PMIP in WiMAX and IETF specifications . . 5 3.1. New parameters introduced to indicate IP service capability . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Authenticator/NAS function introduced . . . . . . . . . . 6 3.3. In-band protocol security applied between MAG/LMA . . . . 6 4. PMIPv6 support - CSN anchored mobility management . . . . . . 6 4.1. Network attachment . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Network Service Capability Negotiation . . . . . . . . 7 4.1.2. IP address configuration . . . . . . . . . . . . . . . 8 4.2. PMIPv6 connection setup . . . . . . . . . . . . . . . . . 8 4.3. PMIPv6 CSN-anchored mobility handover . . . . . . . . . . 9 4.4. PMIPv6 session termination . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Zuniga, et al. Expires May 10, 2010 [Page 2] Internet-Draft PMIP support in WiMAX November 2009 1. Terminology This document uses the following terminology: A-DPF ASN-GW DPF ASN Access Service Network CSN Connectivity Service Network DPF Data Path Function FA Foreign Agent HA Home Agent LMA Local Mobility Anchor MAG Mobile Access Gateway NAS Network Access Server NSP Network Service Provider 2. Introduction The WiMAX Forum specified the WiMAX Network Architecture. Figure 1 introduces the network reference model that shows several interoperability reference points. Zuniga, et al. Expires May 10, 2010 [Page 3] Internet-Draft PMIP support in WiMAX November 2009 R2 |--------------------------------------------------------------| | R3 | | |-----------------------------------------| | | _______|______ _____________ _____|__|____ | | NAP | | V_NSP | | H_NSP | | | | | | | | +--|--+ | +----------+ | | +---------+ | | +---------+ | | | | | ASN | | | | CSN | | | | CSN | | | MS | R1 | | | | R3 | | | | R5 | | | | | |------| | ASN GW | |-------| | AAA | |------| | AAA | | | | | | | | | | proxy | | | | home | | | | | | FA/MAG | | | | | | | | | | +-----+ | | | | | | | | | | HA/LMA | | | | NAS | | | +---------+ | | +---------+ | | +----------+ | |_____________| |_____________| | | | | | | R4 | | | | | | | +----------+ | | | | ASN | | | | | | | | | | ASN GW | | | | | | | | | | FA/MAG | | | | | | | | | | NAS | | |-----| | +----------+ | | |______________| _.----|-----. ,-'' `--._ / \ ( Internet ) \ / `--. _.--' `----------'' Legend of lines: control plane --------- Figure 1: Network Reference Model with HA in home NSP Figure 1 shows the WiMAX Reference Model. Reference Point R1 consists of the protocols and procedures between MS and ASN as per the air interface specifications. Reference Point R2 consists of protocols and procedures between the MS and CSN associated with Authentication, Services Authorization and IP Host Configuration management. Reference Point R3 consists of the set of Control Plane Zuniga, et al. Expires May 10, 2010 [Page 4] Internet-Draft PMIP support in WiMAX November 2009 protocols between the ASN and the CSN to support AAA, policy enforcement and mobility management capabilities. It also encompasses the Bearer Plane methods (e.g., tunneling) to transfer user data between the ASN and the CSN. Reference Point R4 consists of the set of Control and Bearer Plane protocols originating/ terminating in various functional entities of an ASN that coordinate MS mobility between ASNs and ASN-GWs. Reference Point R5 consists of the set of Control Plane and Bearer Plane protocols for internetworking between the CSN operated by the home NSP and that operated by a visited NSP. In PMIPv6 supported network, in order to provide the IP mobility service connectivity to MS that does not have mobility capability, LMA in CSN will assign a home prefix or an IPv4 MN-HoA to the MS (if not statically allocated from the AAA server). Depending on the network configuration, the home prefix(es) could be assigned by either V-LMA (if VCSN exists) or H-LMA. Authentication, authorization and accounting information as well as policy control are handled by the home NSP over R3 and/or R5 reference points. In the remainder of this document we assume PMIPv6 is the selected mobility management protocol. 3. Differences between PMIP in WiMAX and IETF specifications The WiMAX network architecture is specified in [WMF-T32-002-R010v04 Part 1]. The PMIPv6 protocol support in WiMAX is specified in [WiMAX Forum Network Working Group Proxy MIPv6 support Stage 2]. The main differences between the PMIPv6 protocol specified in [RFC5213] and the PMIPv6 protocol specified by WiMAX Forum are listed here and described in more details in the following sub-sections. These differences are mainly: 1) the introduction of new parameters used to indicate the IP service capability of the ASN and VCSN, 2) the introduction of the Authenticator/NAS function and 3) the in-band protocol security applied by the MAG/LMA to the PBU/PBA. 3.1. New parameters introduced to indicate IP service capability The new parameters named ASN IP Service Capabilities and VCSN IP Service Capabilities are used to indicate the IP service capability of the ASN and VCSN and are introduced in the WiMAX network. It should be noted that these parameters are conveyed from ASN (VCSN) to (H)CSN through AAA request message. Once the MS is successfully authenticated by the HAAA and HCSN has authorized one or more IP Services, the Authorized IP Services and Authorized Anchor Location attributes are passed to ASN through AAA Response message. Zuniga, et al. Expires May 10, 2010 [Page 5] Internet-Draft PMIP support in WiMAX November 2009 These parameters are not specified in the PMIP specifications [RFC5213] 3.2. Authenticator/NAS function introduced The Authenticator/NAS negotiates the PMIPv6 security mode with the HAAA and makes that information available to the MAG. If the negotiated security mode is in-band, then the Authenticator/NAS facilitates authentication and authorization functions with the aim to acquire, store and distribute keys and related security information required for PMIPv6 operation. Authenticator interworks with MAG in the process of establishing the LMA trust relationships and appropriately securing mobility signaling. The Authenticator/NAS functionally is specific to the WiMAX specifications. What is specified in [RFC4285] is only concerning the authentication and AAA server: "The network entities in the Proxy Mobile IPv6 domain, while serving a mobile node, will have access to the mobile node's policy profile and these entities can query this information using RADIUS [RFC2865] or DIAMETER [RFC3588] protocols". 3.3. In-band protocol security applied between MAG/LMA There are two mandatory-to-implement and optional-to-use security modes for PMIP6: One using [RFC4285] (in-band security), and the other not using any PMIP6-specific security but relying on the R3/R5 control plane security (lower-layer security). NSP and NAP decide which mode to operate based on their local policy and the dynamic negotiation during the network access authentication of the MS. MAG learns the negotiated mode from the authenticator in order to generate the PBU and process the PBA accordingly. Proxy MIPv6 [RFC5213] specifies IPsec as a mandatory-to-implement security mechanism. It also specifies that the use of IPsec for protecting a mobile node's data traffic is optional. Additionally, it specifies that other documents may specify alternative for securing Proxy Mobile IPv6 signaling messages. In WiMAX networks, the PMIPv6 signaling messages are secured using the security mode defined in [RFC4285] (use of AE in the PBU/PBA). 4. PMIPv6 support - CSN anchored mobility management As stated before we focus here on the use of PMIPv6. We summarize in the following sections the attachment procedures, PMIPv6 connection setup, CSN-anchored mobility handover and detachment procedures focusing on the PMIPv6 usage and MAG, Authenticator, LMA functions. Zuniga, et al. Expires May 10, 2010 [Page 6] Internet-Draft PMIP support in WiMAX November 2009 4.1. Network attachment CSN anchored mobility management based on PMIPv6 is transparent to the MS. At the time of the network entry, MS undergoes the regular attachment procedures without directly participating in mobility signaling; selects the network, performs the network entry and proceeds by configuring the IP address. For a given MS, the network determines whether to use PMIPv6 or not. 4.1.1. Network Service Capability Negotiation Simple IP, CMIP and PMIP services for IPv4 as well as IPv6 may be simultaneously provided by a network. Such network configuration provides coexistence of Simple IP service and MIP service support on a per user basis. Whether the Simple IP service or PMIP or CMIP service is invoked by the network for a given user will depend on the user profile, network capabilities negotiation between ASN, VCSN and HCSN along with the operator policy. 4.1.1.1. Selection Scheme The Network Service Capability Negotiation and Selection scheme expands the network access authentication and authorization process adding capability to negotiate the appropriate IP service among ASN, VCSN (when exists) and HCSN. Two new RADIUS attributes named ASN IP Service Capability and V-CSN IP Service Capabilities have been defined to indicate IP service capabilities of ASN and VCSN, respectively. These parameters are conveyed from ASN (VCSN) to (H)CSN through AAA request message. Once the MS is successfully authenticated by the HAAA and HCSN has authorized one or more IP Services, the Authorized IP Services and Authorized Anchor Location attributes are passed to ASN through AAA Response message. Depending on the outcome of this capability negotiation, ASN offers only one of authorized Simple IP, PMIP or CMIP services to the mobile. When multiple IP services are authorized it is the ASN network that makes the final decision of whether or not to allow MS request and assign the appropriate IP service support for this MS. 4.1.1.2. Selection Flow During MS authentication phase, the AAA Request message is sent by the ASN to the H-AAA of the MS (may be sent via the AAA Proxy at the VCSN). In particular, ASN includes the ASN IP Service Capabilities attribute in the AAA Request to provide current ASN IP service capability information of this ASN to the HAAA. Zuniga, et al. Expires May 10, 2010 [Page 7] Internet-Draft PMIP support in WiMAX November 2009 After receiving AAA Request message, the VCSN adds VCSN IP Service Capabilities attribute to this message and forward the message to HAAA Server at the HCSN. Once the HAAA Server successfully authenticates and authorizes the MS services, the HAAA returns the AAA Response message to the NAS in ASN via the AAA Proxy at the VCSN. Together with other MS subscriber and IP configuration parameters, the Authorized IP Services (and Visited Authorized IP Services if VCSN anchoring is permitted) attribute are also included in the AAA Response message. The AAA Proxy in VCSN relays this AAA Response message to ASN. The ASN extracts out the Authorized IP Services and Visited Authorized IP Services information, stores them locally and makes it available to use by the appropriate IP service function entities within ASN. Depending on the outcome of the capability negotiation, the ASN selects among the authorized services and offers a single IP service to the MS. 4.1.2. IP address configuration WiMAX network supports both stateless and stateful IPv6 address autoconfiguration methods within the PMIPv6 scope. Depending on the configuration and preferences, MS can try to configure an IPv4 address by DHCPv4, one or more IPv6 addresses by DHCPv6 or stateless address autoconfiguration. If for any reason the network needs to enforce a specific configuration method it must set the particular address configuration flags in the RA messages (ManagedFlag and OtherConfigFlag) to do so. The HNP for the PMIPv6 MN-HoA may be allocated from two sources, the LMA or the AAA server. - Prefix/HoA can be bootstrapped from the dedicated AAA server during the network authentication process. - PMIPv6 LMA assigns the unique/64 IPv6 prefix in response to the PBU message from the AR/MAG (ASN) with Home Prefix option set to ALL_ZERO, when HNP has not been obtained through network authentication. 4.2. PMIPv6 connection setup The network authentication enables the ASN/NAS to negotiate and boostrap the necessary PMIPv6 mobility parameters and network configuration, including the assigned IP address or IPv6 prefix, security related settings, authorized address configuration mode(s), Zuniga, et al. Expires May 10, 2010 [Page 8] Internet-Draft PMIP support in WiMAX November 2009 etc. The PMIPv6 connection setup takes place after the initial network entry and access authentication is completed. The prerequisite for the procedure is the network decision to assign the network-based PMIPv6 service for MS IP session. The mobility binding registration from the AR/MAG can occur at any moment following the access authentication response that brought the required IP capabilities and services authorization from the H/VCSN to the ASN where MS is attaching. The connection setup procedures are differentiated by the address configuration process the MS undergoes. For an IPv6 MS the WiMAX network should provide both stateful and stateless address (auto)configuration modes with per-MS unique prefix assignment, while for IPv4 MS, the DHCPv4 support is needed to distribute the IPv4 MN- HoA to the MS. The MS is not involved in PMIPv6 mobility procedures and only required to perform the common address acquisition and configuration procedure to obtain IP mobility management via PMIPv6. 4.3. PMIPv6 CSN-anchored mobility handover PMIPv6 mobility handover comes as a result of the A-DPF handover and R3 path relocation to the new serving ASN. There are no specific requirements towards the MS for the case of PMIPv6 handover. The new serving ASN(b) SHOULD assure the appropriate link configuration and the same address of the first-hop AR/MAG get consistently advertised to the MS after the HO, to hide the actual change of the attaching link. If not performed during the Idle Mode, the process is preceded by regular ASN-MM procedures where the PMIPv6 MAG remains anchored at the previous serving ASN-GW/ASN(a) until the Push/Pull A-DPF HO is triggered. In course of the process the new ASN-GW/ASN(b) obtains all mobility and security wise session information from the serving ASN(a) and Anchor Authenticator, and is able to register the MS new location at the LMA. Successful PMIPv6 registration from the new MAG (new Proxy CoA) results with a refresh to binding cache at the LMA, extension to MS PMIPv6 session and an update to MS forwarding tunnel now redirected towards the new serving MAG at the ASN(b). In case of idle mode, when the MS has established the data path on the new serving ASN(b), triggered by one of the HO events, the serving ASN(b) may initiate PMIPv6 HO by sending the Anchor_DPF_HO_Trigger message to the anchor ASN(a) for PULL handover mode. The anchor ASN(a) either responds or self-initiates the Zuniga, et al. Expires May 10, 2010 [Page 9] Internet-Draft PMIP support in WiMAX November 2009 handover (PUSH mode) by sending the Anchor_DPF_HO_Req to the serving ASN(b). The message contains the relevant information associated with the specific PMIPv6 session; allocated HNP or IPv4 HoA, LMA IP address, protocol configuration details such as DHCP and security mode (if applicable), etc. The target ASN(b) sends an Anchor_DPF_Relocate_Req message to the anchor Authenticator requesting a PMIP6 HO. If the ongoing PMIPv6 session requires in- band protocol security, the target ASN(b) requests the keying information from the anchor Authenticator needed to protect the forthcoming PMIPv6 signaling exchange with the LMA. In case that target AR/MAG in ASN(b) receives Anchor_DPF_ Relocate_Rsp message from the anchor Authenticator, it triggers PBU/ PBA procedure to register MS new location and create the PMIPv6 tunnel between itself and the LMA. the target ASN(b) updates the anchor Authenticator with new AR/MAG location by sending the Anchor_DPF_Relocate_Ack message with success code. The target ASN(b) also informs the ASN(a) of the PBU registration result by sending an Anchor_DPF_HO_Rsp with an appropriate result code. Target AR/MAG performs the PBU registration procedure following the guidelines specified in [RFC5213] . The PBU MUST contain the MN ID, HNP or IPv6 HoA options, the Access Technology Type (set to value WIMAX), the Handoff Indicator option (set to value of 3) as well as the Link-local Address option (set to value ALL_ZERO, requesting the LMA to provide current in-use AR downlink address). The LMA updates the MS binding cache entry with the new location information storing the new Proxy-CoA address. Upon successfully updating the MS BCE, the LMA establishes PMIPv6 tunnel towards the new AR/MAG together and installs the corresponding forwarding rules, and simultaneously tears down the tunnel towards the previous AR/MAG (old Proxy-CoA). If the AAA indicates in-band protocol security is needed for the ongoing PMIPv6 session (i.e., use of AE in PBA/PBU), the LMA requires and derives the necessary security parameters as to protect the PBA before it is sent to the target AR/MAG. Upon receiving PBA from the LMA indicating registration success, the new AR/MAG in ASN(b) updates its local MS context and mobility binding with the information obtained, creates PMIPv6 transport tunnel towards the LMA and install the needed forwarding rules. 4.4. PMIPv6 session termination MS self-initiates PMIPv6 session termination when detaching from the network with graceful network exit, or simply performing the IP/DHCP release procedure for its IP session. The designated network entities may also initiate the IP session termination if discovering Zuniga, et al. Expires May 10, 2010 [Page 10] Internet-Draft PMIP support in WiMAX November 2009 the MS has detached/lost connectivity, prohibited from continuing the service or for some other operative or administrative reason. The ASN-GW/A-DPF, LMA or the AAA server induce the path deregistration by issuing a corresponding trigger message towards the serving ASN-GW/ ASN. Session termination SHALL follow the common NWG procedures and signaling exchange to achieve R4/R6 (R6 is the interface between the BS and MAG in the ASN) path release, MS state change and accounting stop. If applicable, the network-initiated session termination includes PMIPv6 De-registration at the LMA as well as IP/DHCP release on the MS side. 5. Security Considerations For constructing the PBU and processing PBA response from the LMA, the AR/MAG follows requirements from [RFC5213] on MS attachment and initial binding registration, and receiving the PBA section, with one key difference. Inline with PMIPv6 service authorization results from the Access-Accept, the AR/MAG must apply in-band protocol security to the PBU sent to the LMA. When lower-layer transport security is requested by the HCSN, AR/MAG abandons explicit protection of PMIPv6 control plane. In any case, trust relationship MUST be established between LMA and its corresponding MAGs. When in-band security is enabled (use of AE in the PBU/PBA), the LMA retrieves all necessary keying information from the AAA. Then the PBU includes a valid MAG-LMA derivation in the MN-HA mobility message authentication option [RFC4285]. The received PBU that entails signaling protection in form of valid authentication option MUST be replied a PBA using the same protection mechanism. The PBUs received without embedded signaling protection is processed and acknowledged only if the source MAG is considered trusted and use of AE options is not enforced for that PMIPv6 peer. In case MS handovers from one ASN where R3 security is present to another ASN where it is not present and the target ASN wants to initiate change of PMIPv6 security mode, a re-authentication has to take place in order to change the negotiated security mechanism upon the handover. This change is feasible only to the LMA that supports the change of the security mechanism from in-band to lower-layer, or vice-versa, for the same MS upon an R3 handover. When the negotiated mechanism is the lower-layer security, then the MAG/LMA does not include Mobility Message Authentication Option [RFC4285] in the PBU/PBAs, and MAG/LMA does not drop any incoming PBU/PBA which carries that option. Zuniga, et al. Expires May 10, 2010 [Page 11] Internet-Draft PMIP support in WiMAX November 2009 6. IANA Considerations This document makes no request of IANA. 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 8.2. Informative References [RFC4285] IETF, "Authentication Protocol for Mobile IPv6", January 2006. [WMF-T32-002-R010v04 Part 1] WiMAX Forum Network Architecture, "WiMAX Forum Network Architecture Stage 2 Part 1", Stage 2 R010v04, February 2009. [WiMAX Forum Network Working Group Proxy MIPv6 support Stage 2] WiMAX Forum Network Working Group, "Proxy MIPv6 support", Stage 2 1.0.0, January 2009. Authors' Addresses Juan Carlos Zuniga InterDigital Communications, LLC Email: JuanCarlos.Zuniga@InterDigital.com Michelle Perras InterDigital Communications, LLC Email: Michelle.Perras@InterDigital.com Zuniga, et al. Expires May 10, 2010 [Page 12] Internet-Draft PMIP support in WiMAX November 2009 Telemaco Melia Alcatel-Lucent Bell Labs Email: telemaco.melia@alcatel-lucent.com Carlos J. Bernardos Universidad Carlos III de Madrid Email: cjbc@it.uc3m.es Zuniga, et al. Expires May 10, 2010 [Page 13]