WLAN Offload: Introduction and Authentication

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

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. Simplified WLAN Network Model

10. 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

11. 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

12. Non-Roaming Architecture

13. 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

14. 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

15. 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

16. 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

17. Non-Roaming Architecture

18. 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

19. 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

20. 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

21. Security Architecture

22. 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'

23. 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

24. 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.

25. 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

26. Initial attachment from Untrusted Non-3GPP Access

27. 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

28. 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

29. 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.

30. 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

31. 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

32. 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

33. 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

34. Tunnel full authentication and authorization

35. Tunnel full authentication and authorization(Cont.)

36. 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

37. 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

38. 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

39. 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

40. Initial attachment from Trusted Non-3GPP Access

41. 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

42. Non-3GPP Access Authentication Step 1~10

43. Non-3GPP Access Authentication Step 11~18

44. Non-3GPP Access Authentication Step 19~25

45. 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

46. 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

47. 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.

48. References