助理教授：吳俊興 助教：楊文健 國立高雄大學 資訊工程學系 教育部行動寬頻尖端技術人才培育計畫-小細胞基站聯盟中心 示範課程:行動與無線區網整合 Week #05 WLAN Offload 助理教授：吳俊興 助教：楊文健 國立高雄大學 資訊工程學系

Outline Introduction of WLAN Offload Authentication Initial attachment from Untrusted Non-3GPP Access Initial attachment from Trusted Non-3GPP Access

Introduction Increasing need for offloading solutions is caused by the explosion of Internet data traffic, especially the growing portion of traffic going through mobile networks This has been enabled by smartphone devices possessing Wi-Fi capabilities together with large screens and different Internet applications, from browsers to video and audio streaming applications In addition to smart phones, laptops with 3G access capabilities are also seen as a major source of mobile data traffic https://en.wikipedia.org/wiki/Mobile_data_offloading

Mobile Data Offloading Mobile data offloading, is the use of complementary network technologies for delivering data originally targeted for cellular networks Offloading reduces the amount of data being carried on the cellular bands, freeing bandwidth for other users It is also used in situations where local cell reception may be poor, allowing the user to connect via wired services with better connectivity https://en.wikipedia.org/wiki/Mobile_data_offloading

The Main Complementary Network Technologies The main complementary network technologies used for mobile data offloading are Wi-Fi, femtocell and Integrated Mobile Broadcast Rules triggering the mobile offloading action can be set by either an end-user (mobile subscriber) or an operator End users do data offloading for data service cost control and the availability of higher bandwidth It is predicted that mobile data offloading will become a new industry segment due to the surge of mobile data traffic https://en.wikipedia.org/wiki/Mobile_data_offloading

Provide Mobile Network Access WLAN access may be used by mobile operators to provide mobile network access It allows an end-user to use their mobile device’s WLAN access interface and a “connection manager” client to route traffic back into the mobile network operator’s packet core network © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

WLAN Service The mobile operator role involves both user plane routing and control plane functions including backend support for the Authentication, Authorization and Accounting (AAA) chain to provide access control and billing for WLAN service In this case the end-user’s device is assigned an IP address by the mobile operator and any requirement for legal interception of user traffic would fall on the mobile operator © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

Primary Offload Technologies Wi-Fi and femtocell technologies are the primary offload technologies used by the industry In addition, WiMax and terrestrial networks (LAN) are also candidates for offloading of 3G mobile data Femtocells use standard cellular radio technologies, thus any mobile device is capable of participating in the data offloading process, though some modification is needed to accommodate the different backhaul connection https://en.wikipedia.org/wiki/Mobile_data_offloading

Simplified WLAN Network Model 23.402 Figure 4.1: Simplified WLAN Network Model. The shaded area refers to WLAN 3GPP IP Access functionality

Non-3GPP accesses Non-3GPP access includes access from for instance Wi-Fi, WiMAX, fixed and CDMA networks The Mobility mechanisms supported between 3GPP and non- 3GPP accesses within an operator and its roaming partner's network would depend upon operator choice The EPS supports the use of non-3GPP IP access networks to access the EPC 24.302 https://www.aptilo.com/solutions/mobile-data-offloading/3gpp-wifi-access/

Trusted/Untrusted non-3GPP Access Non-3GPP accesses can be split into two categories: the "trusted" ones and the "untrusted" The biggest difference between trusted access and untrusted access would be the requirement of authentication requirement 3GPP does not specify which non-3GPP technologies should be considered trusted or untrusted This decision is made by the operator 24.302 http://www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core

Non-Roaming Architecture 23.402 Figure 4.2.2-1: Non-Roaming Architecture within EPS using S5, S2a, S2b

The S2a interface Network Based Mobility uses S2a interface for Trusted access to EPC This interface is based on the Proxy Mobile IPv6 (PMIPv6) protocol The difference is that the PMIPv6 protocol does not require any changes on the user equipment. The wireless access gateway (WAG) in the trusted non-3GPP IP access network provides the mobile IP functions transparently for the client © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

The S2a interface(Cont.) It creates the tunnel, requests the IP address from the P-GW, and then assigns this address to the Wi-Fi connection In this way, the user equipment is assigned an IP address that is part of the P-GW pool, but it does not see the address as virtual but as a physical address directly on the Wi-Fi interface Allowing usage of Wi-Fi as a trusted non-3GPP access to EPC enables a connection to the EPC in deployments where the existing S2b and S2c solutions for untrusted non-3GPP access are not necessary © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

The S2b interface S2b interface for Un-Trusted access to EPC This interface is based on the Proxy Mobile IPv6 (PMIPv6) protocol This S2b interface is similar to the S5/S8 interface between a SGW and a P-GW © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

The S2b interface(Cont.) To maintain trust, the UE has to establish a dedicated “Virtual Private Network (VPN) access” This comprises of establishing an IPSec tunnel(s) to a secure gateway operated by a Mobile operator (called ePDG) that provides access to the EPC These IPSec tunnels are set-up based on 3GPP requirements. IKE parameters are used to carry 3GPP information such as the APN For each UE, there is one such IPSec tunnel per PDN connection, the UE wants to have over Non-Trusted Non- 3GPP Access to EPC © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

Non-Roaming Architecture 23.402 Figure 4.2.2-2: Non-Roaming Architecture within EPS using S5, S2c

The S2c interface Client/Host-Based Mobility uses S2c interface S2c relies on DSMIPv6 mobility signaling The access network needs to allocate Care-Of-Address to the UE, and the High Availability (HA) must be reachable from the access network for the UE © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

The S2c interface(Cont.) The S2c interface is based on the Dual-Stack Mobile IP Version 6 (DSMIPv6) protocol and requires user equipment to support it DSMIPv6 creates a tunneled connection between the user equipment and the P-GW, which is used to forward all traffic to and from the user equipment The P-GW is responsible for assigning a virtual IP address to the tunnel during the setup process. This IP address is from the same IP pool that is used for LTE sessions Because all traffic to and from the user equipment is sent through the tunnel, the P-GW has complete visibility of the user traffic © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

The S2c Interface Access to EPC Access to EPC with Host Based Mobility: in this scenario, the UE establishes DSMIPv6 connectivity to the EPC mobility anchor (i.e. the P-GW) transparently over Wi-Fi Together with DSMIPv6 support in the UE, this requires the support of an IPsec Security Association between the UE and the P-GW in order to protect the Mobile IP signalling between the UE and the P-GW © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Integration of Cellular and Wi-Fi Networks September 2013

Security Architecture 33.402 Figure 4.1-1: Security Architecture of Non-3GPP Access and 3GPP EPS

Authentication Access authentication for non-3GPP access in EPS shall be based on EAP-AKA (RFC 4187 [7]) or on EAP-AKA' (RFC 5448 [23]) It follows from the preceding sentence in particular that access authentication for non-3GPP access in EPS using EAP-SIM is not allowed The EAP server for EAP-AKA and EAP-AKA' shall be the 3GPP AAA server residing in the EPC The UE and 3GPP AAA server shall implement both EAP- AKA and EAP-AKA' 33.402

3GPP-Based Access Authentication The non-3GPP access networks, which are trusted, can be pre-configured in the UE Additionally, during 3GPP-based access authentication the UE may receive an indication whether the non-3GPP IP access is trusted or not If such an indication is sent it shall be sent by the 3GPP AAA server as part of an EAP-AKA or EAP-AKA' request If no such indication is received by the UE, and there is no pre-configured information in the UE, the UE shall consider the non-3GPP IP access as untrusted 33.402

Access Authentication Mechanisms EAP-SIM, EAP-AKA and EAP-AKA’ are Wi-Fi access authentication mechanisms that make use of (U)SIM credentials EAP-SIM is the EAP based mechanism defined for authentication based on SIM credentials EAP-AKA is an improvement on EAP-SIM and is based on USIM symmetric keys allowing for mutual authentication, integrity protection and replay protection EAP-AKA’ is a minor revision to EAP-AKA method with a new key derivation function. 33.402

Access Authentication Mechanisms(Cont.) It should be noted that while all three of these mechanisms make use of (U)SIM credentials, based on existing 3GPP specifications only the EAP-AKA and EAP-AKA’ methods can provide access to the EPC via non-3GPP accesses It is therefore recommended that both EAP-AKA and EAP- AKA’ be supported for authentication purposes in an integrated network environment All of these methods require support of IEEE 802.1x 33.402

Initial attachment from Untrusted Non-3GPP Access 23.402 Figure 7.3-1: Initial attachment from Untrusted Non-3GPP IP Access with DSMIPv6

Attachment-Step 1 The Figure illustrates the attachment as defined by 3GPP The Access authenticate between UE and the 3GPP EPC After the authentication, UE is configured with Local IP Address from the access network domain This address is used for sending all IKEv2, RFC 5996 [9] messages and as the source address on the outer header of the IPsec tunnel between the UE and the ePDG © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

Attachment-Step 2~4 The IKEv2 tunnel establishment procedure is started by the UE The ePDG IP address to which the UE needs to form IPsec tunnel is discovered via DNS The ePDG sends the final IKEv2 message with the assigned IP address in IKEv2 Configuration payloads IPsec Tunnel between the UE and ePDG is now setup © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

Attachment-Step 5 A security association is established between UE and PDN GW to secure the DS-MIPv6 messages between UE and PDN GW During this step an IPv6 home network prefix is assigned by the PDN GW to the UE as defined in RFC 5026 [40] After the IPv6 home network prefix is assigned, UE constructs a home address from it via auto-configuration. © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

Attachment-Step 6 The UE sends the Binding Update (IP Addresses (HoA, CoA)) message to the PDN GW The UE may request an IPv4 Home Address in this step The UE shall inform the PDN GW that the whole home prefix shall be moved © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

Attachment-Step 7 The PDN GW executes a IP‑CAN Session Establishment Procedure with the PCRF The message from the PDG GW includes at least the HoA and the CoA The message may also include a permanent UE identity and an APN string The PCRF decides on the PCC rules and Event Triggers and provisions them to the PDN GW © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

Attachment-Finally Step The PDN GW processes the binding update and creates a binding cache entry for the UE. The PDN GW allocates an IPv4 home address for the UE if requested by the UE in step 5 The PDN GW then sends a Binding Ack to the UE, including the IPv4 home address allocated for the UE The IP Connectivity is now setup © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

Authentication and Key Agreement for Untrusted Access For untrusted access, UE and the ePDG shall perform mutual authentication during the IPsec tunnel establishment between the UE and the ePDG (SWu reference point) In addition, before the IPsec tunnel establishment between the UE and the ePDG can be performed, the UE needs to obtain IP connectivity across the access network, which may require an access authentication, which is independent of the EAP-AKA authentication run in conjunction with the IPsec tunnel establishment 33.402 6.4 Authentication and key agreement for untrusted access This procedure is specified in clause 8 of the present document.

Tunnel full authentication and authorization 33.402 Figure 8.2.2-1: Tunnel full authentication and authorization

Tunnel full authentication and authorization(Cont.) 33.402 Figure 8.2.2-1: Tunnel full authentication and authorization

The First Message The UE sends the user identity (in the IDi payload) and the APN information (in the IDr payload) in this first message of the IKE_AUTH phase, and begins negotiation of child security associations The UE shall send the configuration payload (CFG_REQUEST) within the IKE_AUTH request message to obtain an IPv4 and/or IPV6 home IP Address and/or a Home Agent Address 33.402 6.4 Authentication and key agreement for untrusted access This procedure is specified in clause 8 of the present document.

Authentication and Authorization Request message The ePDG sends the Authentication and Authorization Request message to the 3GPP AAA Server, containing the user identity and APN The 3GPP AAA server shall identify based on the realm part of the NAI that combined authentication and authorization is being performed for tunnel establishment with an ePDG which allows only EAP-AKA 33.402 6.4 Authentication and key agreement for untrusted access This procedure is specified in clause 8 of the present document.

Authentication Successful The 3GPP AAA Server initiates the authentication challenge The user identity is not requested again When all checks are successful, the 3GPP AAA Server sends the final Authentication and Authorization Answer (with a result code indicating success) including the relevant service authorization information, an EAP success and the key material to the ePDG 33.402 6.4 Authentication and key agreement for untrusted access This procedure is specified in clause 8 of the present document.

UE is Authenticated The ePDG checks the correctness of the AUTH received from the UE At this point the UE is authenticated In case S2b is used, PMIP signalling between ePDG and PDN GW can now start 33.402 6.4 Authentication and key agreement for untrusted access This procedure is specified in clause 8 of the present document.

Initial attachment from Trusted Non-3GPP Access 23.402 Figure 6.3-1: Initial attachment from Trusted Non-3GPP IP Access with DSMIPv6

Attachment The Figure illustrates the attachment as defined by 3GPP Phase A represents attachment to the Wi-Fi network In phase B, the DSMIPv6 tunnel is opened to the P-GW In phase C, the session is signaled as the active one and also illustrated is the establishment of policies for the session using the PCRF © 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

Non-3GPP Access Authentication Step 1~10 33.402 6.2 Authentication and key agreement for trusted access Figure 6.2-1: Non-3GPP Access Authentication

Non-3GPP Access Authentication Step 11~18 33.402 Figure 6.2-1: Non-3GPP Access Authentication

Non-3GPP Access Authentication Step 19~25 33.402 Figure 6.2-1: Non-3GPP Access Authentication

Non-3GPP Access Authentication EAP-AKA' as defined in RFC 5448 [23] shall be used for mutual authentication and key agreement A connection is established between the UE and the trusted non-3GPP access network, using a procedure specific to the non-3GPP access network An AAA interface (STa) with a 3GPP AAA server to support UE authentication as well as to retrieve user Authorization data Diameter referral can also be applied to find the AAA server 33402 Figure 6.2-1: Non-3GPP Access Authentication

Non-3GPP Access Authentication(Cont.) The HSS shall check if there is a 3GPP AAA Server already registered to serve for this subscriber In case the HSS detects that another 3GPP AAA Server has already registered for this subscriber, it shall provide the current 3GPP AAA Server with the previously registered 3GPP AAA Server address The authentication signalling is then routed to the previously registered 3GPP AAA Server with Diameter-specific mechanisms e.g., the current 3GPP AAA Server transfers the previously registered 3GPP AAA Server address to the 3GPP AAA proxy or the AAA entity in the trusted non-3GPP access network, or the current 3GPP AAA Server acts as a AAA proxy and forwards the authentication message to the previously registered 3GPP AAA Server 33402 Figure 6.2-1: Non-3GPP Access Authentication

Authentication Failed The authentication process may fail at any moment, for example because of unsuccessful checking of MACs or no response from the UE after a network request In that case, the EAP AKA' process will be terminated as specified in RFC 5448 [23] and an indication shall be sent to HSS. 33402

References