May 2006 doc IEEE 802 11 060662 r

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Network Selection Date: 2006 -05 -08 Authors: 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: // ieee 802. 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 <stuart. kerry@philips. com> 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 <patcom@ieee. org>. Submission 1 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Abstract This document describes a complete proposal for the Network Selection Cluster, requirement series R 10 Nx. Submission 2 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 TGu Requirement: Network Selection Cluster • R 10 N 1: 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. • R 10 N 2: The mechanism described in requirement R 10 N 1 must allow a STA that has multiple credentials with an SSPN to select the correct credentials when authenticating with a Local Network. • R 10 N 3: Define functionality to support authentication with multiple SSPNs through a single AP. • R 10 N 4: Define functionality by which a STA can determine which interworking services are available before joining a BSS. Submission 3 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Overview • This presentation presents a reference architecture over which the network selection process operates • A L 2 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 R 10 N 1, R 10 N 2 and R 10 N 4 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. 11 i authentication and encryption is employed during/post association • Network Access Providers incorporate AAA proxy services for authenticating to SSPNs Submission 4 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Reference network NAP NOC Adv. S AAA SSPN #1 Core Network NAP Core Network Tunnel (Bearer + AAA) SSPN #2 NOC Internet Tunn el (A Adv. S AAA AA o nly) SSPN #2 Core Network Hot Spot #1 Submission NAP Network Access Provider NOC Network Operations Center Adv. S Advertisement Server Hot Spot #N 5 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 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) Submission 6 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Reference network NAP NOC Adv. S AAA SSPN #1 Core Network r + AAA NAP Core Network l (Beare Tunne ) SSPN #2 NOC Internet Tunn el (A Adv. S AAA AA o nly) SSPN #2 Core Network Hot Spot #1 Submission Hot Spot #N 7 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Some Observations on the Advertisement 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 L 2 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 Adv. S is required! • • The NAP’s Advertisement server (Adv. S) 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. Submission 8 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Some Observations on the Advertisement System (cont. ) • It is not scalable for the NAP’s Adv. S to be configured with roaming agreements between directly connected SSPNs and their roaming partners; the SSPN’s Adv. S are used for this purpose. • The NAP’s Adv. S would be configured with the IP address and security credentials for SSPN Adv. S with which they need to communicate. The provision of this information would be pursuant to the business agreement between NAP and SSPN. Submission 9 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Some Observations on the AAA 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 Submission 10 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Operation with TGv Virtual APs • If a directly connected SSPN has been configured to have its own VAP, then SSPN’s Adv. S & AAA server could be contacted directly and not via NAP’s Adv. S/AAA proxy services Submission 11 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 L 2 Generic Advertising Service Submission 12 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 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 Submission 13 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 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 Do. S attacks Submission 14 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Generic Advertising Service Proposal • • 802. 11 u capability advertisement included in beacon (small number of bits)—including bit for L 2 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 Submission 15 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Advertisement Request IE Field Size Element ID Uint 8 Length Uint 8 Advertisement Service Uint 8 Advertisement Type Uint 8 Advertisement Identifier Uint 8 * 2 SSPN ID #1 TBD SSPN ID #2 (optional) TBD SSPN ID #N (optional) TBD • Advertisement Type – 0 = Ethertype – 1 = well-known port – 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) • Advertisement Service – 0 = SSPN advertisement – 1 – 255 = reserved Submission 16 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Advertisement Response IE Field Size Element ID Uint 8 Length Uint 8 Status Code Uint 8 Multicast Address Uint 8*6 • 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 L 2 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 Adv. S Submission 17 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Beacon – Start of Network Advertising DTIM Beacon Tx • • B-SNA BC/MC NA DTIM BC/MC 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. , Qo. S 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 Submission 18 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Message Sequence Chart GAS Generic Advertising Service AR Advertisement Request MCA Multicast Address Submission Capability Supp. Pro Supported Protocols 19 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Network Advertising Action Frame Format Octets: • • • Category Action Value Remaining Repetitions AR IE Adv Length Advertise ment 1 1 1 N 2 N Category and Action Value provided on next slide Remaining Repetitions is the number of additional times this advertisement AR IE is included so that, if advantageous, a client can correlate its request The Advertisement will be in the format requested in the AR IE The Adv (advertisement) length specifies the length in octets of the Advertis Submission 20 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Action Frame Details Category Value Name Value Action Field Value See clause Spectrum Management 0 7. 4. 1 Qo. S 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 Submission 21 Action field value Description 0 Advertisement 1 -255 Reserved Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Advantages of approach • Network manages bandwidth consumption OTA and over the WAN and thus minimizes susceptibility to Do. S 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 Submission 22 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 G 1 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. Submission 23 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 G 2 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. Submission 24 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 G 3 Analysis • All proposals must allow APs to serve legacy STAs in addition to STAs that have been upgraded to 11 u. Proposals must describe how this is achieved. – No changes are required to legacy STAs. Submission 25 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Summary • A reference architecture has been described which provides for efficient “division of responsibilities” for network selection • A L 2 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 Submission 26 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Feedback? Submission 27 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Background Submission 28 Dave Stephenson, Cisco Systems, Inc. et al

May 2006 doc. : IEEE 802. 11 -06/0662 r 0 Why not use Open Auth Instead? • In Open Auth scenario, NAP’s Adv. S 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. 11 u amendments required to provide a standardized way for client to receive SSPN advertisements Submission 29 Dave Stephenson, Cisco Systems, Inc. et al