80 likes | 210 Views
Coexistence of Legacy & RSN STAs in Public WLAN. Byoung-Jo “J” Kim AT&T Labs-Research March ‘03, Dallas. 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
E N D
Coexistence of Legacy & RSN STAs in Public WLAN Byoung-Jo “J” Kim AT&T Labs-Research March ‘03, Dallas
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
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
Possible Solutions: continued • 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?
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.
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
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
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