1. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 1 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, 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 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.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2006-05-08 Authors:

2. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 2 Abstract This document describes a complete proposal for the Network Selection Cluster, requirement series R10Nx.

3. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 3 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.

4. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 4 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

5. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 5 Reference network AdvS Hot Spot #1 Hot Spot #N NAP Core Network NAP NOC AAA NAPNetwork Access Provider NOCNetwork Operations Center AdvSAdvertisement Server SSPN #2 Core Network AdvS SSPN #2 NOC AAA SSPN #1 Core Network AdvS SSPN #1 NOC AAA Internet Tunnel (Bearer + AAA) Tunnel (AAA only)

6. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 6 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)

7. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 7 Reference network AdvS Hot Spot #1 Hot Spot #N NAP Core Network NAP NOC AAA SSPN #2 Core Network AdvS SSPN #2 NOC AAA SSPN #1 Core Network AdvS SSPN #1 NOC AAA Internet Tunnel Tunnel (AAA only) Tunnel (Bearer + AAA)

8. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 8 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 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.

9. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 9 Some Observations on the Advertisement 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.

10. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 10 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

11. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 11 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

12. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 12 L2 Generic Advertising Service

13. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 13 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

14. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 14 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

15. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 15 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

16. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 16 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) FieldSize Element IDUint8 LengthUint8 Advertisement ServiceUint8 Advertisement TypeUint8 Advertisement IdentifierUint8 * 2 SSPN ID #1TBD SSPN ID #2 (optional)TBD SSPN ID #N (optional)TBD

17. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 17 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 FieldSize Element IDUint8 LengthUint8 Status CodeUint8 Multicast AddressUint8*6

18. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 18 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 B-SNA Beacon Tx BC/MC NA

19. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 19 Message Sequence Chart GASGeneric Advertising Service ARAdvertisement Request MCAMulticast Address CapCapability Supp.ProSupported Protocols

20. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 20 Network Advertising Action Frame Format CategoryAction Value Remaining Repetitions AR IEAdv Length Advertise ment Octets:111N2N 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

21. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 21 Action Frame Details NameValueSee clause Spectrum Management 07.4.1 QoS17.4.2 DLS27.4.3 Block Ack37.4.4 Reserved4- Radio Measurement57.4.5 Generic Advertising Service 6 Action field valueDescription 0Advertisement 1-255Reserved Category Value Action Field Value

22. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 22 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

23. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 23 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.

24. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 24 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.

25. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 25 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.

26. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 26 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

27. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 27 Feedback?

28. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 28 Background

29. doc.: IEEE 802.11-06/0662r0 Submission May 2006 Dave Stephenson, Cisco Systems, Inc. et alSlide 29 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