1 Remote IP Access - Stage 2 Architecture proposal for adoption Peerapol Tinnakornsrisuphap Anand Palanigounder Jun Wang Douglas Knisely Rajesh Bhalla ), Mar 30th, 2009 Notice ©2009. All rights reserved. The contributors grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner’s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner’s standards publication. The contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.

Background Remote IP access: Allow AT to reach local IP network or server in the same domain as the Femto AP even when the AT is not connected over-the-air with the Femto AP We submitted High-level architecture to Feb 3GPP2 meeting in X In this contribution we provide further design details (e.g., architectural assumptions, security etc) for adoption at concept level at this meeting 2

Architectural Assumptions Operator offers Remote IP Access as an add-on service on a subscription basis Capabilities such as DCHP/ARP are available at the Femto AP to support Remote IP Access Femto APs that can be reached by a given AT, configured as part of the AT (subscription) profile at the Home AAA Femto APs can be identified by FEID or by realm (useful for group of femtos in enterprise deployment) User invokes the service on demand at the AT (e.g., by clicking “My Home”) 3

Proposed Architecture 4 Femto Gateway actsas VPN gatewayfor IPsec tunnel with ATFGW forwards any packetsreceived from AT to Femto APIPsec tunnelAT authentication is perfomedwith Home AAA using IKEv2EAP-AKA or IKEv2 PSK (reusingexisting AT’s IP subscriptioncredentials)Femto is DHCP server fromwhich FGW will request a localIP address and assign it to the ATas part of IKEv2FGW forwards selected packetsfrom Femto AP to AT (e.g., basedon target address)Femto Gateway needs to bereachable via AT’s macro IPaddress NOTE: The AT can use any available IP connectivity for Remote IP Access

5 Packet from AT in macro network to Home

6 Packet from Home to AT in macro network

Femto GW discovery by AT 7 Femto GW publicly reachable (e.g., Femto APs) AT must discover & connect to the same FGW that is being used by the FAP at the target network AT assumed to be pre-configured with the FGW that is used by target FAP –Other possible FGW discovery procedures are FFS

AT Authentication using IKEv2 EAP-AKA inside IKEv2 – EAP-AKA between the AT and Home AAA –Used if both the network and the AT support AKA Use IKEv2 in PSK mode –PSK derived by AT & AAA for each IKEv2 session –Root keys for PSK derivation: EMSK, MN-AAA & CHAP SS NAI indicates Remote IP Access service –e.g., where the “username” is the username part of the AT’s regular IP service –If there are multiple FAPs (e.g., two different homes) then the FAP identity can be included by the AT in the NAI e.g., –If there are multiple remote IP network realms (e.g., enterprise scenario), the AT realm is indicated E.g., 8

Auth method selection AT support for EAP or PSK indicated by absence/presence of AUTH payload during IKE_AUTH exchange; method chosen is as follows: –AT must always prefer either EAP-AKA or IKEv2 PSK with EMSK over other PSK modes –If neither of the above two feasibile, then MN-AAA must be preferred before CHAP-SS for PSK derivation This is similar to IKEv2 PSK/EAP authentication adopted by 3GPP2 for MIPv6 enhancement and HRPD-WiMax interworking AAA enforces auth method selection in order to avoid bidding down attacks 9

Authorization For each AT (subscription), AAA maintains FAP(s) that can be accessed as part of the AT subscription profile Based on the received NAI during authentication, the AAA returns one or more FAPs to the FGW –If multiple FAPs are returned, the FGW selects a FEID (e.g., based on availability of IPSec tunnel to the FAP, etc) –AT subscription profile determines whether the user is authorized to use the selected FAP(s) Authorized femto identifier(s) returned to the FGW via AAA message after successful AT authentication 10

Routing at FGW Based on the FEID(s) received from the AAA, the FGW checks to ensure that there is already pre-setup IPSec tunnel to FAP –If no tunnel exists for the authorized FAP, then FGW rejects the request from AT request with appropriate error code using IKEv2 FGW assigns an IPSec IP address to the AT and creates a routing entry bridging AT’s IPSec tunnel with the FAP’s IPSec tunnel 11

Proposal Adopt the proposal 12