1. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 1 Coexistence of Legacy & RSN STAs in Public WLAN Byoung-Jo “J” Kim AT&T Labs-Research March ‘03, Dallas

2. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 2 Purpose A Twist in Public Access Scenario: Must Support “Simultaneously” –Legacy STAs with WEP off For various reasons, at least for a while –RSN (or WPA) STAs For privacy protection if STAs capable Not a requirement for PWLAN in general: You should assume you’re on your own. But Use it if available: Must do more for customers for their protection, and maybe all hidden from users

3. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 3 Possible Solutions Shares some issues with doc 03-154 by Bernard Aboba, and Also maybe can be considered as a special case of TSN Use Two SSIDs with Two Radios Use Two SSIDs with a Single Radio –Common implementation has Primary SSID in Beacon, others Revealed with Probe Problems: Refer to 03-154 Most importantly: Two SSID may confuse people – “Consumer” service, maybe OK, but not sure Preference toward single SSID Risk to Network is accepted factor of any ISP

4. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 4 Single SSID: Beacon with Privacy off and RSN IE included No problem with Legacy STAs Not Sure How RSN STAs will behave –Not a valid option in Draft 3.1 7.3.1.4 Capability Information field Add the following paragraphs to Clause 7.3.1.4: STAs (including APs) that include the RSN IE in beacons and probe responses shall set the Privacy subfield to 1 in any frame that includes it. –Attempt to associate regardless of Privacy bit, auth via 1x and run RSN? –Don’t even try to associate since Privacy bit is OFF? Possible Solutions: continued

5. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 5 TSN Policy does not cover this case 8.4.3.1 TSN policy selection > If an AP operating within a TSN receives a (Re)association request without an RSN IE, it shall allow communications only if a WEP key has been configured to secure communication. If a WEP key is not installed, the AP shall reject the association request; if a WEP key is configured, the AP may accept the request.

6. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 6 Observations with “one” current HW Setup: Beacon WEP off, Some STAs configured to use 1x authentication/key exchange and Some configured no WEP. All Pre-RSN/WPA –Broadcast unencrypted by AP if non-1x STA present –No-WEP STAs associate and work fine –Some 1x STA models won’t even try to send assoc-req –Most do and associate/authenticate successfully –Some do accept unencrypted broadcast like ARP –Some do not –Some 1x STA broadcast unencrypted but refuse to receive Points toward potentially unpredictable STA behavior –Not a news –Expensive for PWLAN provider –Hope to minimize it as much as possible

7. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 7 Broadcast/Multicast Probably solved at APs for this particular scenario ARP for gateway, DHCP, etc are necessary for service –STA to AP is OK, whether encrypted or not –AP can be smart about whether to encrypt, or not by keeping track of the interactions. –DHCP and gateway under our control –APs may be configured to drop direct communication between STAs in PWLAN, always via an access enforcer, so ARP for other than gateway is useless anyways

8. doc.: IEEE 802.11-03/173r1 Submission Byoung-Jo Kim, AT&T March 2003 Slide 8 Options Make “Beacon/Probe Privacy OFF” with RSN IE” a legitimate mode, a particular mode of TSN? Specify STA behaviors for this Case? –“Attempt RSN operation based on RNS IE only, regardless of WEP bit”? Specify what to do with broadcast/multicast traffic? Or leave it to AP vendors catering to PWLAN providers