1

Remote IP Access - Stage 2 Architecture proposal for adoption

Peerapol Tinnakornsrisuphap (peerapol@qualcomm.com), QualcommAnand Palanigounder (apg@qualcomm.com), Qualcomm

Jun Wang (jwang@qualcomm.com), Qualcomm

Douglas Knisely (dknisely@airvana.com), Airvana

Rajesh Bhalla (rabhalla@zteusa.com ), ZTE

Mar 30th, 2009Notice ©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 X50-20090216-017

• 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

HRPDFemto

AT

SeGW – Femto APIPsec tunnel

PDSN

A10

Server

HomeRouter(NAT)

PublicInternet

AT-FGW tunnel

Operator’sCore

Macro AN

Femto SecurityGateway

AAAAAA messages

Femto Gateway actsas VPN gatewayfor IPsec tunnel with AT

FGW forwards any packets received from AT to Femto AP IPsec tunnel

AT authentication is perfomed with Home AAA using IKEv2 EAP-AKA or IKEv2 PSK (reusing existing AT’s IP subscription credentials)

Femto is DHCP server from which FGW will request a local IP address and assign it to the AT as part of IKEv2

FGW forwards selected packets from Femto AP to AT (e.g., based on target address)

Femto Gateway needs to be reachable via AT’s macro IP address

NOTE: The AT can use any available IP connectivity for Remote IP Access

5

Packet from AT in macro network to Home

HRPDFemto

AT

Femto Security Gateway – Femto AP

IPsec tunnel

Macro IP 10.10.x.zHome (VPN) IP 192.163.a.b

SRC = 192.163.a.bDST = 192.163.a.c

Outer SRC IP = 10.10.x.zOuter DST IP = FGW address

PDSN

A10

Server

HomeRouter(NAT)

PublicInternet

Server private IP 192.163.a.c

Femto private IP 192.163.a.aIPsec (FGW-FAP) 10.10.x.y

AT-Femto tunnel

Operator’sCore

Inner SRC IP = 192.163.a.bInner DST IP = 192.163.a.c

Macro AN

Femto SecurityGateway

Inner SRC IP = 192.163.a.bInner DST IP = 192.163.a.c

FGW-FAP IPsec header

6

Packet from Home to AT in macro network

HRPDFemto

AT

Femto Security Gateway – Femto AP

IPsec tunnel

Macro IP 10.10.x.zHome (VPN) IP 192.163.a.b

SRC = 192.163.a.cDST = 192.163.a.b

Outer SRC IP = FGW IP addressOuter DST IP = 10.10.x.z

PDSN

A10

Server

HomeRouter(NAT)

PublicInternet

Server private IP 192.163.a.c

Femto private IP 192.163.a.aIPsec (FGW-FAP) 10.10.x.y

AT-Femto tunnel

Operator’sCore

Inner SRC IP = 192.163.a.cInner DST IP = 192.163.a.b

Macro AN

Femto SecurityGateway

Inner SRC IP = 192.163.a.cInner DST IP = 192.163.a.b

FGW-Femto AP IPsec tunnelheader

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., username.femto@realm, where the “username” is the username part

of the AT’s regular IP service NAI– 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., username.femto.FEID@realm

– If there are multiple remote IP network realms (e.g., enterprise scenario), the AT realm is indicated

• E.g., username.femto.ATrealm@realm

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