idnits 2.17.1 draft-koodli-netext-multiaccess-indicator-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2012) is 4436 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) == Missing Reference: 'EAP' is mentioned on line 125, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4187 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5448 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext Working Group Rajeev. Koodli 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Jouni. Korhonen 5 Expires: September 3, 2012 Nokia Siemens Networks 6 March 2, 2012 8 Multi-access Indicator for Mobility 9 draft-koodli-netext-multiaccess-indicator-03.txt 11 Abstract 13 When a Mobile Node attaches to the mobile network using multiple 14 access networks, it is important for the Mobile Network Gateway to 15 know whether the Mobile Node is capable of simultaneous multi-access, 16 so that the former can distribute the traffic flows using the most 17 appropriate interface. This document defines a new EAP attribute 18 which can be used for such an indication to the Mobile Network 19 Gateway. The document also reserves a new MIP6-Feature-Vector flag. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 3, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 57 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. MN_MULTIACCESS Capability Flag . . . . . . . . . . . . . . 5 60 4.2. AT_MA_IND EAP Attribute . . . . . . . . . . . . . . . . . . 6 61 4.3. AT_MA_STATUS EAP Attribute . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 With multi-access, a Mobile Node (MN) may be simultaneously attached 73 to a mobile network via multiple access technologies or just be 74 multi-homed. For instance, in the 3GPP architecture [3gpp-4g-2], a 75 MN may be attached to the same Mobile Network Gateway (MNG), called 76 the PGW, via 4G cellular LTE technology as well as the Wireless LAN 77 (WiFi) technology. Such simultaneous access provides opportunity to 78 distribute traffic based on the most appropriate access for the type 79 of traffic in question as well as policy triggers such as the Time Of 80 the Day. In order to accomplish this flow distribution or flow 81 mobility, the MNG needs to know that the MN's attachment is for 82 multi-access (and not handover) purposes and that the MN has the 83 necessary host abstractions to support prefix sharing across access 84 interfaces. This document defines an attribute to be used during the 85 EAP-AKA authentication process so that the 3GPP AAA server 86 understands the MN's capabilities. Subsequently, the 3GPP AAA server 87 provides the MN's capabilities in a Diameter message, enabling the 88 MNG to make the policy decisions to perform flow mobility. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Protocol Overview 98 In the 3GPP architecture [3gpp-4g-2], two types of "non-3GPP" 99 accesses are supported. In the trusted access model, the access 100 network is considered trustworthy by the 3GPP network operator. An 101 example of a trusted network is another cellular network such as CDMA 102 or WiMAX, but may also include broadband wireline network with WiFi 103 access such as a residential access network operated by the 3GPP 104 cellular service provider. In the untrusted access model, the 3GPP 105 service provider does not possess a trust relationship with the non- 106 3GPP access provider. An example includes WiFi hot spot access. 108 In the trusted access model, the MN communicates with an Access 109 Network Gateway (ANG). In the untrusted access model, the MN 110 communicates with a secure tunnel (e.g., IPsec) termination node 111 called ePDG. In both the trusted and untrusted access models, the MN 112 performs EAP-AKA [RFC4187] or EAP-AKA' [RFC5448] authentication. In 113 the trusted access model, the EAP-AKA messages are transported from 114 the MN to the ANG over a protocol specific to the access network. In 115 the untrusted access model, the EAP-AKA messages are transported from 116 the MN to the ePDG over IKEv2 [RFC5996]. Both the ANG and the ePDG 117 communicate with the (3GPP) AAA server using Diameter. This is shown 118 in Figure 1, which we explain further below. The security 119 architecture itself is described in [3gpp-33.402]. 121 MN ANG/ePDG AAA MNG (PGW) 122 | | | | 123 1) |---- EAP ------->|--- AAA[EAP] -->| | 124 | | | | 125 2) |<--- EAP --------|<--- AAA[EAP] --| | 126 | | | | 127 3) | |----------------|---- PBU ---------->| 128 | | | | 129 4) | | |<----- AAA ---------| 130 | | | | 131 5) | | |------ AAA -------->| 132 | | | | 133 6) | |<---------------|----- PBA ----------| 134 | | | | 136 Figure 1: Authentication and Registration 138 1. The MN attaches to the non-3GPP access network 140 The MN performs EAP-AKA or EAP-AKA' authentication. The EAP 141 messages are sent over IKEv2 when the MN is connected using 142 untrusted access. 144 As a part of the EAP-AKA procedure, the MN responds with EAP- 145 Response/AKA-Challenge message. In this message, the MN includes 146 a new attribute AT_MA_IND which indicates that the MN's 147 attachment is for multi-access purposes, and that the MN supports 148 the necessary abstraction (Logical Interface) for flow mobility. 150 The ANG/ePDG forwards the EAP message to the AAA server using the 151 Diameter EAP application protocol message Diameter EAP Request 152 (DER) message specified in [RFC4072]. 154 2. The 3GPP AAA server verifies through subscription records at the 155 Home Subscriber Server (HSS) that the the MN is allowed to use 156 flow mobility. Subsequently, the AAA server provides the result 157 in a new EAP attribute AT_MA_STATUS in the existing EAP-Request/ 158 AKA-Notification message (which is used for indicating the IP 159 Mobility Selection mode [3gpp-24.302]). The EAP message is sent 160 using the Diameter EAP Answer (DEA) message to the ANG/ePDG, 161 which forwards the EAP message to the MN. 163 3. The ANG/ePDG sends the PMIP6 PBU message. 165 4. The MNG contacts the AAA server to update the MNG's address for 166 the MN's connection. The MNG includes the MIP6-Feature-Vector 167 AVP with the MN_MULTIACCESS flag set in the AAA request to 168 indicate that multi-access is allowed and supported by the MNG. 170 5. The AAA server provides the MN's multi-access indication and 171 Logical Interface capability in a MN_MULTIACCESS lag in the MIP6- 172 Feature-Vector AVP [RFC5447]. 174 6. The MNG now understands that the MN is capable of flow mobility. 175 It provides a prefix in the PBA accordingly. For instance, it 176 may provide a new prefix as well as one or more of the already- 177 assigned prefixes in the PBA. 179 The ANG/ePDG MUST be able to provide forwarding support for the 180 prefixes provided in the PBA, regardless of the type of 181 attachment indicated in the PBU message. 183 If the AAA server determines that the UE is not permitted for multi- 184 access flow mobility through the MNG, it does not include the 185 MN_MULTIACCESS flag in the MIP6-Feature-Vector AVP. The absence of 186 the flag is an indication to the MNG that flow mobility is disabled 187 in the subscription. If the AAA server does not understand the 188 AT_MN_IND attribute, it silently discards the attribute, and hence 189 does not send the AT_MA_STATUS attribute back in the EAP-Request/ 190 AKA-Notification message. It also does not provide the MIP6-Feature- 191 Vector to the MNG. 193 4. Protocol Extensions 195 Two extensions to existing protocols are defined in this 196 specification. First, a new RFC 5447 MIP6-Feature-Vector AVP 197 capability flag is defined. Second, two new EAP attributes AT_MA_IND 198 and AT_MA_STATUS are defined. 200 4.1. MN_MULTIACCESS Capability Flag 202 The MIP6-Feature-Vector AVP [RFC5447] capability flag MN_MULTIACCESS 203 (TBD by IANA) is used by the requesting Diameter node to indicate 204 that it supports multi-access functionality and the feature is also 205 allowed by its policy. The Diameter server uses the flag to 206 authorize the use of multi-access functionality. 208 The absence of the MN_MULTIACCESS feature flags indicates that either 209 the multi-access feature is not supported/understood or prohibited by 210 a local policy. 212 4.2. AT_MA_IND EAP Attribute 214 The skippable AT_MA_IND EAP attribute is included in EAP-Response/ 215 AKA-Challenge message and indicates to the EAP authenticator that the 216 EAP peer (i.e., the mobile node) supports multi-access functionality 217 and this attachment is for multi-access purposes. The attribute is 218 illustrated in Figure 2. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |AT_MA_IND | Length = 1 | Reserved | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 2: AT_MA_IND EAP Attribute 228 4.3. AT_MA_STATUS EAP Attribute 230 The non-skippable AT_MA_STATUS EAP attribute is included in EAP- 231 Request/AKA-Notification or EAP-Request/EAP-Success messages. Due to 232 alignment with [3gpp-24.302] EAP usage this specification only gives 233 examples of cases where EAP-Request/AKA-Notification is used. The 234 attribute indicates to the EAP peer (i.e., the mobile node) that the 235 EAP authenticator supports multi-access functionality and provides 236 the result of the multi-access functionality negotiation. The 237 attribute is illustrated in Figure 3. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |AT_MA_STATUS | Length = 1 | Result Code | Reserved | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: AT_MA_STATUS EAP Attribute 247 Following Result Codes are defined by this specification: 249 0 The multi-access functionality was accepted. 251 128 The multi-access functionality was rejected by a local policy. 253 5. IANA Considerations 255 This document defines a new flag (TBD by IANA) for the MIP6-Feature- 256 Vector AVP in RFC 5447, which needs IANA assignment. This document 257 defines two new EAP attributes: the skippable AT_MA_IND (TBD by IANA) 258 and the non-skippable AT_MA_STATUS (TBD by IANA). Both attributes 259 need IANA assignment. 261 IANA is also requested to establish a new registry for the 262 AT_MA_STATUS Result Codes. Values between 0-127 are for success 263 codes and values between 128-255 are for error code. The initial 264 values for this registry are listed in Section 4.3. New values for 265 the registry MUST follow the Specification Required [RFC5226]. 267 6. Security Considerations 269 This documents defines a new EAP attribute to extend the capability 270 of EAP-AKA protocol as specified in Section 8.2 of RFC 4187 271 [RFC4187]. This attribute is passed from the MN to the AAA server. 272 The document does not specify any new messages or options to the EAP- 273 AKA protocol. 275 7. Acknowledgement 277 Thanks to Aeneas-Dodd Noble for flow mobility discussions. 279 8. References 281 8.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 287 Protocol Method for 3rd Generation Authentication and Key 288 Agreement (EAP-AKA)", RFC 4187, January 2006. 290 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 291 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 292 May 2008. 294 [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 295 and K. Chowdhury, "Diameter Mobile IPv6: Support for 296 Network Access Server to Diameter Server Interaction", 297 RFC 5447, February 2009. 299 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 300 Extensible Authentication Protocol Method for 3rd 301 Generation Authentication and Key Agreement (EAP-AKA')", 302 RFC 5448, May 2009. 304 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 305 "Internet Key Exchange Protocol Version 2 (IKEv2)", 306 RFC 5996, September 2010. 308 8.2. Informative References 310 [3gpp-24.302] 311 "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP 312 Access Networks, 3GPP TS 24.302 8.7.0, December 2009.", . 314 [3gpp-33.402] 315 "Security aspects of non-3GPP accesses, 3GPP TS 33.402 316 8.6.0, December 2009.", . 318 [3gpp-4g-2] 319 "Architecture Enhancements for non-3GPP accesses, 3GPP TS 320 23.402 8.7.0, December 2009.", . 322 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 323 Authentication Protocol (EAP) Application", RFC 4072, 324 August 2005. 326 Authors' Addresses 328 Rajeev Koodli 329 Cisco Systems 330 USA 332 Email: rkoodli@cisco.com 334 Jouni Korhonen 335 Nokia Siemens Networks 336 Finland 338 Email: jouni.korhonen@nsn.com