doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 1 Redefining the SSID Notice: This document has been prepared to assist IEEE 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 2 Abstract This submission proposes that the definition of the SSID should be expanded to a broader definition as appropriate to current practice and a new identifier “ESSID” strictly tied to the ESS should be defined.

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 3 The SSID Original IEEE standard incorporated a trivially simple discovery mechanism based on a text string called the SSID Unformatted character field of up to 32 bytes which is usually constructed by ASCII characters

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 4 “Correct use” of SSID

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 5 Problems with SSID SSIDs cannot be guaranteed unique SSID value has no integrity No specification for how to assign SSID default value SSID does not scale to use in global networks

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 6 Importance of Legacy Cannot simply “replace” SSID Hundreds of millions of legacy systems have behaviour based on existing SSID Any new system must be 100% backwards compatible with simple SSID approach.

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 7 Current definition of SSID The standard says almost nothing about it: – SSID element: The SSID element indicates the identity of an ESS or IBSS. The intent was that it should (uniquely) identify an ESS to form a “roaming group” of APs ESS is defined by layer 2 connectivity But in practice most implementers use SSID as a service identifier and reuse the same name across multiple ESSs - even without layer 2 connectivity

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 8 Current situation is a mess In the majority of cases the SSID is used incorrectly - based on it’s definition in the standard What to do? 1.Write to everyone and tell them they are doing it wrong? That won’t work! 2.Adjust the definition of SSID to match current practice That sounds dangerous - does it affect correct legacy implementations?

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 9 Modified Definition of SSID We propose that the definition is changed from: –“The SSID element indicates the identity of an ESS or IBSS.” to: –“The SSID element indicates the identity of an ESS a group of ESSs or an IBSS.” This changes the definition to include current practice but does not affect legacy implementations that followed the “one SSID per ESS” rule But this still leaves a problem...

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 10 The need for an ESS identifier Since SSID is not used as an ESS identifier - and we are proposing to make this “official” - we need a new ESS identifier to allow intra-ESS roaming. Propose a new identifier to be included in beacons with the following information: –Unique ESS Address –ESS Name (text field) –Path Index(es)

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 11 Contents of ESS-ID (1) Unique ESS Address: a 48 bit value intended to uniquely define the ESS. –Default value can be AP’s BSSID. This ensures that AP will not accidentally indicate membership of a roaming set unless configured. –Value can be configure to match other APs when a roaming set is formed –Possible recommended practice for “auto assignment” based on layer 2 broadcasts across the DS

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 12 Contents of ESS-ID (2) Name field –32 octet field can be manually assigned to indicate ESS identity –default value is same as SSID

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 13 Contents of ESS-ID (3) Connectivity Index(es) –Each ESS can support multiple layer 2 connectivity paths. Could be VLANs Could be multiple router ports (multiple IP subnets) Could be service differentiation –Same connectivity Index at two APs ensures that same layer2 connectivity is available at both APs –Single octet index allows up to 256 paths to be advertised. –In short it tells the STA whether its IP address and/or VLAN and/or service will become invalid when moving to a new ESS.

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 14 New ESS-ID Element New ESS-ID element to be carried in beacon and probe requests. ESS-ID element to be included in r to provide post-authentication verification that it was not modified or forged.

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 15 Mapping Service to ESSID If station knows ESSID it includes this is association request instead of SSID If station does not know correct ESSID to use it includes SSID in association request and AP returns ESSID in association response. –Useful for APs that support multiple SSIDs for different services Network assigned ESSID –Station provides service identifier at association –AP selects correct VLAN/IP subnet for service –AP sends value of ESSID in association response.

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 16 Summary of Proposal 1.Deprecate SSID to be service provider hint 2.Provide new ESS-ID to enable reliable definition of roaming groups 3.ESS-ID provides hint about higher layer compatibility 4.Provides post-verification of claimed ESS-ID can be included to detect forged identity. 5.Allows AP to support multiple service connectivies and inform station at time of association

doc.: IEEE /0971r0 Submission Sept 2005 Jon Edney, Stefano Faccin, NokiaSlide 17 References frfh-what-ess.ppt u-ds-ess-subnet-and-vlan.ppt