Redefining Ssid

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 17

Sept 2005 doc.: IEEE 802.

11-05/0971r0

Redefining the SSID


Date: 2005-07-15
Authors:
Name Company Address Phone email
+441353648567 EXT-jon.1.edney@nokia.com
Jon Edney Nokia Cambridge, UK
Stefano Faccin Nokia 3421 Dartmoor, Dallas, TX +1 972 894 4994 Stefano.faccin@nokia.com

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 <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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
<stuart.kerry@philips.com> 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 <patcom@ieee.org>.

Submission Slide 1 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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.

Submission Slide 2 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

The SSID

• Original IEEE802.11 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

Submission Slide 3 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

“Correct use” of SSID

LAN HUB ROUTER LAN HUB

AP AP ESS AP AP

SSID = “Net1” SSID = “Net2”

Submission Slide 4 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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

Submission Slide 5 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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.

Submission Slide 6 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

Current definition of SSID

• The standard says almost nothing about it:


– 7.3.2.1 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

Submission Slide 7 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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?

Submission Slide 8 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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

Submission Slide 9 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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)

Submission Slide 10 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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

Submission Slide 11 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

Contents of ESS-ID (2)

• Name field
– 32 octet field can be manually assigned to indicate ESS identity
– default value is same as SSID

Submission Slide 12 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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.

Submission Slide 13 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

New ESS-ID Element

• New ESS-ID element to be carried in beacon and probe


requests.
• ESS-ID element to be included in 802.11r to provide
post-authentication verification that it was not
modified or forged.

EN
ESS Address ESS Name Path Index** Path Index
Ln*

6 Octets 2 0 – 32 Octets 1-16 Octets

* EN Ln – length of ESS Name, 0 = ESS Name not present


** First octet contains length

Submission Slide 14 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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.

Submission Slide 15 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

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

Submission Slide 16 Jon Edney, Stefano Faccin, Nokia


Sept 2005 doc.: IEEE 802.11-05/0971r0

References

• 11-04-0614-00-frfh-what-ess.ppt
• 11-05-0522-00-000u-ds-ess-subnet-and-vlan.ppt

Submission Slide 17 Jon Edney, Stefano Faccin, Nokia

You might also like