March 2003

Slide 1

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

Coexistence of Legacy & RSN STAs in Public WLAN

Byoung-Jo “J” Kim

AT&T Labs-Research

March ‘03, Dallas

March 2003

Slide 2

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

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

March 2003

Slide 3

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

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

March 2003

Slide 4

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

• 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.17.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

March 2003

Slide 5

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

TSN Policy does not cover this case

• 8.4.3.1 TSN policy selection

<<snip snip>>

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.

March 2003

Slide 6

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

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

March 2003

Slide 7

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

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

March 2003

Slide 8

doc.: IEEE 802.11-03/173r1

Submission Byoung-Jo Kim, AT&T

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