Netext Working Group Rajeev. Koodli Internet-Draft Cisco Systems Intended status: Standards Track Jouni. Korhonen Expires: September 3, 2012 Nokia Siemens Networks March 2, 2012 Multi-access Indicator for Mobility draft-koodli-netext-multiaccess-indicator-03.txt Abstract When a Mobile Node attaches to the mobile network using multiple access networks, it is important for the Mobile Network Gateway to know whether the Mobile Node is capable of simultaneous multi-access, so that the former can distribute the traffic flows using the most appropriate interface. This document defines a new EAP attribute which can be used for such an indication to the Mobile Network Gateway. The document also reserves a new MIP6-Feature-Vector flag. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 3, 2012. Copyright Notice Copyright (c) 2012 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 Koodli & Korhonen Expires September 3, 2012 [Page 1] Internet-Draft Multi-access Indicator for Mobility March 2012 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 5 4.1. MN_MULTIACCESS Capability Flag . . . . . . . . . . . . . . 5 4.2. AT_MA_IND EAP Attribute . . . . . . . . . . . . . . . . . . 6 4.3. AT_MA_STATUS EAP Attribute . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Koodli & Korhonen Expires September 3, 2012 [Page 2] Internet-Draft Multi-access Indicator for Mobility March 2012 1. Introduction With multi-access, a Mobile Node (MN) may be simultaneously attached to a mobile network via multiple access technologies or just be multi-homed. For instance, in the 3GPP architecture [3gpp-4g-2], a MN may be attached to the same Mobile Network Gateway (MNG), called the PGW, via 4G cellular LTE technology as well as the Wireless LAN (WiFi) technology. Such simultaneous access provides opportunity to distribute traffic based on the most appropriate access for the type of traffic in question as well as policy triggers such as the Time Of the Day. In order to accomplish this flow distribution or flow mobility, the MNG needs to know that the MN's attachment is for multi-access (and not handover) purposes and that the MN has the necessary host abstractions to support prefix sharing across access interfaces. This document defines an attribute to be used during the EAP-AKA authentication process so that the 3GPP AAA server understands the MN's capabilities. Subsequently, the 3GPP AAA server provides the MN's capabilities in a Diameter message, enabling the MNG to make the policy decisions to perform flow mobility. 2. 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 [RFC2119]. 3. Protocol Overview In the 3GPP architecture [3gpp-4g-2], two types of "non-3GPP" accesses are supported. In the trusted access model, the access network is considered trustworthy by the 3GPP network operator. An example of a trusted network is another cellular network such as CDMA or WiMAX, but may also include broadband wireline network with WiFi access such as a residential access network operated by the 3GPP cellular service provider. In the untrusted access model, the 3GPP service provider does not possess a trust relationship with the non- 3GPP access provider. An example includes WiFi hot spot access. In the trusted access model, the MN communicates with an Access Network Gateway (ANG). In the untrusted access model, the MN communicates with a secure tunnel (e.g., IPsec) termination node called ePDG. In both the trusted and untrusted access models, the MN performs EAP-AKA [RFC4187] or EAP-AKA' [RFC5448] authentication. In the trusted access model, the EAP-AKA messages are transported from the MN to the ANG over a protocol specific to the access network. In the untrusted access model, the EAP-AKA messages are transported from Koodli & Korhonen Expires September 3, 2012 [Page 3] Internet-Draft Multi-access Indicator for Mobility March 2012 the MN to the ePDG over IKEv2 [RFC5996]. Both the ANG and the ePDG communicate with the (3GPP) AAA server using Diameter. This is shown in Figure 1, which we explain further below. The security architecture itself is described in [3gpp-33.402]. MN ANG/ePDG AAA MNG (PGW) | | | | 1) |---- EAP ------->|--- AAA[EAP] -->| | | | | | 2) |<--- EAP --------|<--- AAA[EAP] --| | | | | | 3) | |----------------|---- PBU ---------->| | | | | 4) | | |<----- AAA ---------| | | | | 5) | | |------ AAA -------->| | | | | 6) | |<---------------|----- PBA ----------| | | | | Figure 1: Authentication and Registration 1. The MN attaches to the non-3GPP access network The MN performs EAP-AKA or EAP-AKA' authentication. The EAP messages are sent over IKEv2 when the MN is connected using untrusted access. As a part of the EAP-AKA procedure, the MN responds with EAP- Response/AKA-Challenge message. In this message, the MN includes a new attribute AT_MA_IND which indicates that the MN's attachment is for multi-access purposes, and that the MN supports the necessary abstraction (Logical Interface) for flow mobility. The ANG/ePDG forwards the EAP message to the AAA server using the Diameter EAP application protocol message Diameter EAP Request (DER) message specified in [RFC4072]. 2. The 3GPP AAA server verifies through subscription records at the Home Subscriber Server (HSS) that the the MN is allowed to use flow mobility. Subsequently, the AAA server provides the result in a new EAP attribute AT_MA_STATUS in the existing EAP-Request/ AKA-Notification message (which is used for indicating the IP Mobility Selection mode [3gpp-24.302]). The EAP message is sent using the Diameter EAP Answer (DEA) message to the ANG/ePDG, which forwards the EAP message to the MN. Koodli & Korhonen Expires September 3, 2012 [Page 4] Internet-Draft Multi-access Indicator for Mobility March 2012 3. The ANG/ePDG sends the PMIP6 PBU message. 4. The MNG contacts the AAA server to update the MNG's address for the MN's connection. The MNG includes the MIP6-Feature-Vector AVP with the MN_MULTIACCESS flag set in the AAA request to indicate that multi-access is allowed and supported by the MNG. 5. The AAA server provides the MN's multi-access indication and Logical Interface capability in a MN_MULTIACCESS lag in the MIP6- Feature-Vector AVP [RFC5447]. 6. The MNG now understands that the MN is capable of flow mobility. It provides a prefix in the PBA accordingly. For instance, it may provide a new prefix as well as one or more of the already- assigned prefixes in the PBA. The ANG/ePDG MUST be able to provide forwarding support for the prefixes provided in the PBA, regardless of the type of attachment indicated in the PBU message. If the AAA server determines that the UE is not permitted for multi- access flow mobility through the MNG, it does not include the MN_MULTIACCESS flag in the MIP6-Feature-Vector AVP. The absence of the flag is an indication to the MNG that flow mobility is disabled in the subscription. If the AAA server does not understand the AT_MN_IND attribute, it silently discards the attribute, and hence does not send the AT_MA_STATUS attribute back in the EAP-Request/ AKA-Notification message. It also does not provide the MIP6-Feature- Vector to the MNG. 4. Protocol Extensions Two extensions to existing protocols are defined in this specification. First, a new RFC 5447 MIP6-Feature-Vector AVP capability flag is defined. Second, two new EAP attributes AT_MA_IND and AT_MA_STATUS are defined. 4.1. MN_MULTIACCESS Capability Flag The MIP6-Feature-Vector AVP [RFC5447] capability flag MN_MULTIACCESS (TBD by IANA) is used by the requesting Diameter node to indicate that it supports multi-access functionality and the feature is also allowed by its policy. The Diameter server uses the flag to authorize the use of multi-access functionality. The absence of the MN_MULTIACCESS feature flags indicates that either the multi-access feature is not supported/understood or prohibited by Koodli & Korhonen Expires September 3, 2012 [Page 5] Internet-Draft Multi-access Indicator for Mobility March 2012 a local policy. 4.2. AT_MA_IND EAP Attribute The skippable AT_MA_IND EAP attribute is included in EAP-Response/ AKA-Challenge message and indicates to the EAP authenticator that the EAP peer (i.e., the mobile node) supports multi-access functionality and this attachment is for multi-access purposes. The attribute is illustrated in Figure 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_MA_IND | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: AT_MA_IND EAP Attribute 4.3. AT_MA_STATUS EAP Attribute The non-skippable AT_MA_STATUS EAP attribute is included in EAP- Request/AKA-Notification or EAP-Request/EAP-Success messages. Due to alignment with [3gpp-24.302] EAP usage this specification only gives examples of cases where EAP-Request/AKA-Notification is used. The attribute indicates to the EAP peer (i.e., the mobile node) that the EAP authenticator supports multi-access functionality and provides the result of the multi-access functionality negotiation. The attribute is illustrated in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_MA_STATUS | Length = 1 | Result Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: AT_MA_STATUS EAP Attribute Following Result Codes are defined by this specification: 0 The multi-access functionality was accepted. 128 The multi-access functionality was rejected by a local policy. 5. IANA Considerations This document defines a new flag (TBD by IANA) for the MIP6-Feature- Vector AVP in RFC 5447, which needs IANA assignment. This document Koodli & Korhonen Expires September 3, 2012 [Page 6] Internet-Draft Multi-access Indicator for Mobility March 2012 defines two new EAP attributes: the skippable AT_MA_IND (TBD by IANA) and the non-skippable AT_MA_STATUS (TBD by IANA). Both attributes need IANA assignment. IANA is also requested to establish a new registry for the AT_MA_STATUS Result Codes. Values between 0-127 are for success codes and values between 128-255 are for error code. The initial values for this registry are listed in Section 4.3. New values for the registry MUST follow the Specification Required [RFC5226]. 6. Security Considerations This documents defines a new EAP attribute to extend the capability of EAP-AKA protocol as specified in Section 8.2 of RFC 4187 [RFC4187]. This attribute is passed from the MN to the AAA server. The document does not specify any new messages or options to the EAP- AKA protocol. 7. Acknowledgement Thanks to Aeneas-Dodd Noble for flow mobility discussions. 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. [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009. [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", Koodli & Korhonen Expires September 3, 2012 [Page 7] Internet-Draft Multi-access Indicator for Mobility March 2012 RFC 5448, May 2009. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 8.2. Informative References [3gpp-24.302] "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP Access Networks, 3GPP TS 24.302 8.7.0, December 2009.", . [3gpp-33.402] "Security aspects of non-3GPP accesses, 3GPP TS 33.402 8.6.0, December 2009.", . [3gpp-4g-2] "Architecture Enhancements for non-3GPP accesses, 3GPP TS 23.402 8.7.0, December 2009.", . [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. Authors' Addresses Rajeev Koodli Cisco Systems USA Email: rkoodli@cisco.com Jouni Korhonen Nokia Siemens Networks Finland Email: jouni.korhonen@nsn.com Koodli & Korhonen Expires September 3, 2012 [Page 8]