doc.: ieee 802.11-06/0662r0 submission may 2006 dave stephenson, cisco systems, inc. et alslide 1...

May 2006

Dave Stephenson, Cisco Systems, Inc. et alSlide 1

doc.: IEEE 802.11-06/0662r0

Submission

Network Selection

Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.

Date: 2006-05-08

Name Company Address Phone email Dave Stephenson Cisco Systems 170 W. Tasman Dr.

San Jose, CA 95134 +1 408 527 7991 [email protected]

Necati Canpolat Intel Corporation 2111 NE 25th Ave. Hillsboro, OR 97124

+1 503 264 8014 [email protected]

Vivek Gupta Intel Corporation 2111 NE 25th Ave. Hillsboro, OR 97124

+1 503 712 1754 [email protected]

Authors:

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Abstract

This document describes a complete proposal for the Network Selection Cluster, requirement series R10Nx.

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

TGu Requirement: Network Selection Cluster

• R10N1: Define functionality by which a STA can determine whether its subscription to an SSPN would allow it to access a particular 802.11 AN before actually joining a BSS within that 802.11 AN. Proposals must describe their consideration of scalability.

• R10N2: The mechanism described in requirement R10N1 must allow a STA that has multiple credentials with an SSPN to select the correct credentials when authenticating with a Local Network.

• R10N3: Define functionality to support authentication with multiple SSPNs through a single AP.

• R10N4: Define functionality by which a STA can determine which interworking services are available before joining a BSS.

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Overview

• This presentation presents a reference architecture over which the network selection process operates

• A L2 generic advertising service is described– Allows STAs to query and receive SSPN advertisements prior to

association

– The actual advertisements are carried via higher layer protocol; thus R10N1, R10N2 and R10N4 are fulfilled by the higher layer protocol

– The definition of the higher layer protocol is outside the scope of 802.11; 802.21 is an example of such a protocol

• Normal 802.11i authentication and encryption is employed during/post association

• Network Access Providers incorporate AAA proxy services for authenticating to SSPNs

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Reference networkAdvS

Hot Spot #1 Hot Spot #N

NAPCore Network

NAP NOC

AAA

NAP Network Access ProviderNOC Network Operations CenterAdvS Advertisement Server

SSPN #2Core Network

AdvS

SSPN #2 NOC

AAA

SSPN #1Core Network

AdvS

SSPN #1 NOC

AAA

InternetTunnel (Bearer + AAA)

Tunnel (AAA only)

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Description of Reference Network• Network access provider (NAP) owns and/or manages APs in

hotspots and is responsible for their configuration– Includes provisioning of vlans on the AP. APs bridging client frames to

the proper vlan ensures packets are sent to the SSPN’s network.• NAP Advertisement Server:

– Provides advertisements for directly connected SSPNs– Advertisements include SSPN name, SSID, ESS Name, ESSID,

interworking services, information on online enrollment, etc.– Proxies advertisements to SSPN advertising servers when client’s query

so indicates• NAP AAA server:

– Authenticates NAP’s customers onto their network– Proxies SSPN’s clients authentication requests to SSPN AAA servers and

routed based on NAI (RFC-4282)– Provides per-client vlan assignment for authenticated clients– Hotspot APs only need to be configured with NAP’s AAA server

information (e.g., IP address, security credentials)

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Reference networkAdvS

Hot Spot #1 Hot Spot #N

NAPCore Network

NAP NOC

AAA

SSPN #2Core Network

AdvS

SSPN #2 NOC

AAA

SSPN #1Core Network

AdvS

SSPN #1 NOC

AAA

InternetTunnel

Tunnel (AAA only)

Tunnel (Bearer + AAA)

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Some Observations on theAdvertisement System

• SSPN advertisements correspond to back-end networks accessible via WLANs and not the WLANs themselves. Thus these advertisements should be provided by a protocol layer higher than L2. L2 involvement should be limited to providing a standardized means for “efficient” access to advertisement servers.

• From TGu discussions, the follow requirements have emerged:– Number of SSPNs supported per hotspot expected to be in the tens (e.g., ~30)– Number of roaming partners per hotspot expected to be in the hundreds (e.g., >50

roaming partners per SSPN)– Conclusion: this level of scale means advertisements are too numerous to be

included in beacon—an AdvS is required!

• The NAP’s Advertisement server (AdvS) can be expected to be configured with network selection information for directly connected SSPNs.

• A directly connected SSPN is defined as one which has a vlan (or tunnel) from their core network to the NAP’s core network.

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Some Observations on theAdvertisement System (cont.)

• It is not scalable for the NAP’s AdvS to be configured with roaming agreements between directly connected SSPNs and their roaming partners; the SSPN’s AdvS are used for this purpose.

• The NAP’s AdvS would be configured with the IP address and security credentials for SSPN AdvS with which they need to communicate. The provision of this information would be pursuant to the business agreement between NAP and SSPN.

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Some Observations on theAAA System

• Only the NAP’s AAA server can be expected to be configured with AP vlan information in all their hotspots (and not the SSPN’s AAA servers)

• Based on a roaming/business agreement, NAP and SSPNs set up a trust relationship between their AAA servers

• A shared secret exists between client and its subscription AAA server—this shared secret would not be divulged to foreign AAA servers.

• SSPN AAA server provides PMK to Authenticator

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Operation with TGv Virtual APs

• If a directly connected SSPN has been configured to have its own VAP, then SSPN’s AdvS & AAA server could be contacted directly and not via NAP’s AdvS/AAA proxy services

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

L2 Generic Advertising Service

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Handset requirements• Handover between networks must be seamless (no user

intervention)• Handset must work consistently in all networks (home and

visited) so that user experience is the same• Handset must be able to find back-end network starting from

boot-up, even when out-of-range of cellular network– Handset may be located in home network or visited network—so client

needs to receive advertisements from SSPNs and roaming partners• Dual-mode handsets can also get network advertisements

when connected to cellular network; but not all devices will be dual mode

• Standby time needs to be similar to cellular handsets– Clients should be able to receive advertisements at a predictable TSF time– Clients must not be required to be associated to receive network

advertisements– Advertisements must be transmitted in cleartext

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

AP requirements

• 99+% of the time no client will need to receive network advertisement, so …– Advertisements should not use beacons– Clients needing network advertisements should request them and

AP should transmit them only long enough to ensure reception by client

– Expectation is that clients will cache network advertisements for some period of time—reduces need for constant advertisements

• Clients must be able to get advertisements when not associated—so method should not open up security hole nor cause network to be susceptible to DoS attacks

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Generic Advertising Service Proposal• 802.11u capability advertisement included in beacon (small number of

bits)—including bit for L2 generic advertisement service (GAS)• Client requests advertisements by transmitting Probe Request which

includes Advertisement Request IE (AR IE)– Generic request for advertisement; type of advertisement requested signaled by

ethertype field (e.g., 802.21) or well-known port number in IE– The higher-layer protocol provides requested advertising information– AR IE also optionally supports query for specific SSPN or wild cards– Client sets TA to BSSID + locally administered bit (provides location privacy for

“free” when client is “just looking”)– AP transmits normal Probe Response with Advertisement Response IE thereby

confirming receipt; uses normal response delay of several ms; if AP configured to not accept specific query and/or wild packets, it provides error status code in response.

• AP transmits multicast Action Frames containing GAS encapsulated query response

– Action frames transmitted in cleartext– Each advertising frame is transmitted several times to make transmission more

reliable

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Advertisement Request IE

• Advertisement Service– 0 = SSPN advertisement

– 1 – 255 = reserved

• Advertisement Type– 0 = Ethertype– 1 = well-known port– 2 – 255 = reserved

• Advertisement Identifier = value per Advertisement Type

• SSPN ID:– Null: request all SSPNs

supported– Specific value: provide info for

requested SSPN– Wild card (format TBD)

Field Size

Element ID Uint8

Length Uint8

Advertisement Service Uint8

Advertisement Type Uint8

Advertisement Identifier Uint8 * 2

SSPN ID #1 TBD

SSPN ID #2 (optional) TBD

SSPN ID #N (optional) TBD

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Advertisement Response IE

• Status Code– 0 = Successful– 37 = Request has been declined– N = Service not supported– N+1 = wildcard not supported– N+2 = null SSPN field not

supported

• Multicast Address– The L2 multicast DA of the

advertisements to be transmitted by AP in response to the request

– Different multicast addresses may be used so clients can separate cleartext responses from different VAPs or AdvS

Field Size

Element ID Uint8

Length Uint8

Status Code Uint8

Multicast Address Uint8*6

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Beacon – Start of Network Advertising

• Above shows an example of a sequence of beacon transmissions with DTIM interval = 3; broadcast and multicast transmissions commence immediately after the DTIM beacon

• Define B-SNA which is an otherwise normal, non-DTIM beacon that signals the Start of Network Advertising

– B-SNA interval is N×DTIM interval with offset of +1; N is configurable and offset of +1 helps ensure B-SNA beacon doesn’t collide with DTIM beacon

– Typical value of N produces B-SNA every 1-2 seconds– Immediately after B-SNA, network advertising frames begin; but unlike BC/MC after

DTIM, these can have other intervening unicast frames (e.g., QoS frames) thereby minimizing jitter

– Beacon contains B-SNA count and data buffered bit so that client can predict TSF time when network advertisements will start and whether any advertisements will be sent after the B-SNA beacon

– B-SNA also includes a configured “Time to Suspend” field which is the amount of time in TUs that an AP will schedule NA frames for transmission after the TBTT for B-SNA. After expiry of this time, no more NA frames will be transmitted until the next B-SNA

– Network Advertising (NA) frames transmitted in cleartext, multicast action frames– MORE data bit set in multicast action frames to indicate if additional advertising frames

are queued

DTIM DTIM DTIMB-SNA

Beacon Tx

BC/MC BC/MC BC/MCNA

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Message Sequence Chart

GAS Generic Advertising ServiceAR Advertisement RequestMCA Multicast Address

Beacon (TGu + GAS Cap & Supp.Pro)

Advertisement Query

Probe Request (AR IE)

B-SNA, MC(Query Response)

Probe Response (Status, AR IE, MCA)

Advertisement Response

NAP AdvSAPClientSSPN AdvS

Advertisement Query

Advertisement Response

MC(Query Response)

MC(Query Response)

Cap CapabilitySupp.Pro Supported Protocols

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Network Advertising Action Frame Format

Category Action Value

Remaining Repetitions

AR IE AdvLength

Advertisement

Octets: 1 1 1 N 2 N

• Category and Action Value provided on next slide

• Remaining Repetitions is the number of additional times this advertisement will be transmitted

• AR IE is included so that, if advantageous, a client can correlate its request to this response

• The Advertisement will be in the format requested in the AR IE

• The Adv (advertisement) length specifies the length in octets of the Advertisement

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Action Frame Details

Name Value See clause

Spectrum Management

0 7.4.1

QoS 1 7.4.2

DLS 2 7.4.3

Block Ack 3 7.4.4

Reserved 4 -

Radio Measurement 5 7.4.5

Generic Advertising Service

6

Action field value Description

0 Advertisement

1-255 Reserved

Category Value Action Field Value

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Advantages of approach

• Network manages bandwidth consumption OTA and over the WAN and thus minimizes susceptibility to DoS attack

• AP can rate limit Probe Requests if needed

• Un-associated client never gets its frames passed into network

• Fewer steps required on part of the client—therefore more battery efficient

• Client does not need IP address

• Client maintains location privacy while un-associated

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

G1 Analysis

• All proposals (whichever requirements they address) shall describe how they minimize battery consumption for mobile devices. – This proposal minimizes effect on battery consumption by

providing a predictable time when network advertisements are transmitted by the AP. Thus, client can stay in power-save mode while waiting for same.

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

G2 Analysis

• All proposals (whichever requirements they address) shall describe the security impact of the functions they propose. – This proposal has minimal security impact as network

advertisements are multicast in cleartext to un-associated clients. Since clients can request these advertisements via Probe Request, AP should provide capability to rate-limit advertising responses.

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

G3 Analysis

• All proposals must allow APs to serve legacy STAs in addition to STAs that have been upgraded to 11u. Proposals must describe how this is achieved.– No changes are required to legacy STAs.

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Summary

• A reference architecture has been described which provides for efficient “division of responsibilities” for network selection

• A L2 generic advertising service employing active query has been described

• The mechanism is scalable, provides efficient usage of the wireless medium, is secure and battery efficient for handsets

• Actual advertisements are carried out by a higher-layer protocol which need not (and should not) be constrained by the 802.11 link layer

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Feedback?

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Background

May 2006


doc.: IEEE 802.11-06/0662r0

Submission

Why not use Open Auth Instead?

• In Open Auth scenario, NAP’s AdvS would be reachable in a walled garden

• Advantages of Open Auth:– No changes required to 802.11 protocol (thus less overall complexity)– Unicast transmissions offer greater reliability– More flexible (changes to advertisement services need not affect 802.11

protocol)• Dis-advantages:

– In the case of TGv VAPs, two BSSIDs needed for each directly connected SSPN: one BSSID for bearer traffic and one BSSID for network discovery/selection—therefore approach doesn’t scale well

• Unless we add no-encryption and open-authentication capability to RSN• Even if Open Auth was used, there would still be some albeit

simple 802.11u amendments required to provide a standardized way for client to receive SSPN advertisements

doc.: ieee 802.11-06/0662r0 submission may 2006 dave stephenson, cisco systems, inc. et alslide 1...

Documents