11-06-1473-03-000u-multi-ssid

Document Sample
11-06-1473-03-000u-multi-ssid Powered By Docstoc
					March 2007                                                                                                                 doc.: IEEE 802.11-06/1473r3


                                              Multiple SSID Support
                                                                             Date: 2007-03-12
         Authors:
           Name                            Company                        Address                             Phone                          email
           Dave Stephenson Cisco Systems                                  170 W. Tasman Dr.                   +1 408 527 7991                daves@cisco.com
                                                                          San Jose, CA 95134
           Joseph Salowey                  Cisco Systems                  170 W. Tasman Dr.                   +1 206 256 3380                jsalowey@cisco.com
                                                                          San Jose, CA 95134
           Amy Zhang                       Huawei                         Bantian, Longgang                   +86 755 896 50361              amyzhang@huawei.com
                                           Technologies                   District Shenzhen
                                                                          518129,P.R.China




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@ok-brit.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                                                 Stephenson, Salowey & Zhang
March 2007                                       doc.: IEEE 802.11-06/1473r3


                               Abstract

       This proposal describes an idea which facilitates multiple SSPNs to
       be represented on one AP and is called multi-SSID.
       Each SSPN may be bound to an SSID and multiple SSIDs are bound
       to a single BSSID.
       This facilitates scaling of hotspot APs to support multiple SSPNs.
       Corresponding normative text is in 11-06-1935r1.




Submission                           Slide 2               Stephenson, Salowey & Zhang
March 2007                                           doc.: IEEE 802.11-06/1473r3


                          Proposal update:



 • Updated to provide better power save support for
   broadcast and multicast frame transmission (cf. 11-07-
   0261r0 for background)




 Text updated from 11-06/1473r2 shown in blue font


Submission                              Slide 3               Stephenson, Salowey & Zhang
March 2007                                               doc.: IEEE 802.11-06/1473r3


                                   Overview
 •    Each directly-connected SSPN may be assigned to a VLAN in the DS
 •    APs are configured to support multiple SSIDs in a BSSID
       – Frames on a particular VLAN are bridged to/from corresponding SSID per AP’s
         configuration
       – Transmissions on SSIDs (which share a common BSSID) are cryptographically
         separated using different GTKs thereby keeping VLAN broadcast domains
         separated
       – Each SSID may have its own security settings (i.e., per-SSPN security
         configuration)
 •    STAs discover supported SSIDs via Advertising (aka Action) frames
       – Based on GAS (Generic Advertising Service) as defined in 802.11u-D0.02
       – This proposal defines a Native Query Protocol which runs over GAS
       – Avoids beacon bloat which would otherwise occur due to length of SSID and
         related IEs.
 •    4-way handshake used to deliver to STA the GTK and GTK ID
      corresponding to SSID with which it’s associated


Submission                                 Slide 4                  Stephenson, Salowey & Zhang
March 2007                                                                doc.: IEEE 802.11-06/1473r3


              Example Message Sequence Chart
     Client                                                                             AP


                                    Probe Request (Broadcast)
                                                                                              Capability
              Probe Response (BSSID, Capabilities, Default SSID, GAS Query Protocols)         Discovery
                   GAS Initial Request (Query Protocol=802.21, SSPN Supported?)


                         GAS Initial Response (QueryID, Comeback Delay)
                                                                                              SSPN
                       GAS Comeback Request (QueryID, SSPN Supported?)                        Discovery
                      GAS Comeback Response (QueryID, SSPN, SSID, ESSID)


                        GAS Initial Request (Query Protocol=Native, mSSID)
                                                                                              mSSID
                    GAS Initial Response (QueryID, Protocol=Native, mSSID List)               Discovery
                                    Association Request(SSID)

                                                                                              Association
                                      Association Response



Submission                                            Slide 5                           Stephenson, Salowey & Zhang
March 2007                                                doc.: IEEE 802.11-06/1473r3


                 GAS Native Query Protocol
             Advertisement Protocol IE {GAS Native Protocol}
                         Element   Length   Delivery   Advertisement
                            ID              Method      Protocol ID
               Octets:     1         1          1           1
               Values:    x+2        2         0x3          0


 • GAS Native Query protocol:
       – Used to deliver L2 or higher layer information to STAs
       – Provided on a request basis so the information is not included in Beacons,
         thereby avoiding beacon bloat
       – Uses either multicast or unicast delivery method
       – Is intended to be handled locally by AP (not by server in DS)
 • GAS Capability IE includes Advertisement Protocol IE {GAS
   Native Protocol}

Submission                                  Slide 6                    Stephenson, Salowey & Zhang
March 2007                                                   doc.: IEEE 802.11-06/1473r3


                          GAS Request IE

                       Element ID   Length          Advertisement   Query
                                                     Protocol IE
             Octets:       1          1               variable      variable




 • GAS Request IE copied from 802.11u-D0.02 for reference purposes
 • GAS Native Query Protocol ID in Advertisement Protocol IE
 • GAS Native Query in Query field




Submission                                Slide 7                        Stephenson, Salowey & Zhang
March 2007                                                       doc.: IEEE 802.11-06/1473r3


                          GAS Native Query IE
             Element ID   Length    Native                Query Info                   Info ID
                (0)                Query Info
                                                          Capability List                  0
Octets:          1          1       Variable
                                                          mSSID List                       1
                                                          Emergency Networks List          2
                                                          Reserved                      3-255



 • Native query is a variable length list of 1-octet values which request
   desired information from AP




Submission                                      Slide 8                     Stephenson, Salowey & Zhang
March 2007                                                        doc.: IEEE 802.11-06/1473r3


                          GAS Response IE

                       Element ID   Length      Advertisement       Response
                                                 Protocol IE          Info

             Octets:       1          1                variable      variable




 • GAS Response IE copied from P802.11u-D0.02 for reference
   purposes
 • GAS Native Query Protocol ID in Advertisement Protocol IE
 • GAS Native Query Response in Response Info field



Submission                                   Slide 9                            Stephenson, Salowey & Zhang
 March 2007                                                               doc.: IEEE 802.11-06/1473r3


                     GAS Native Query Response
            Element ID    Length         Native                  Native         …            Native
               (1)                     Info IE #1              Info IE #2                  Info IE #N
                                                               (optional)                   (optional)
Octets:         1           2          variable                variable         …           variable




  •       There is one Native Info included in the Native Query Response for each
          Native Query Info ID
  •       This proposal supports three Native Info IEs: Capabilities List, mSSID List
          and Emergency Networks List (defined on next slides)
  •       In order to keep native protocol simple, fragmentation of Query Responses
          is not supported
           – A response to a single query (i.e., Native Query Info length is 1 octet) by design will
             fit 802.11 MSDU limit
           – If Query Response is larger than MSDU size, then error status code is returned.
             Status code is in the GAS Initial Response action frame which is not shown on this
             slide.

 Submission                                         Slide 10                        Stephenson, Salowey & Zhang
March 2007                                                            doc.: IEEE 802.11-06/1473r3


             GAS Native Info: Capabilities List

                       Info ID   Length   Status       Info ID     Info ID    …     Info ID
                         (0)              Code           #1          #2               #N
                                                         (0)     (optional)       (optional)
             Octets:     1         2        2             1          1        …       1




 • The Capabilities List defines a list of Info IDs which have been
   configured in this ESSID. Info ID(0) is always in the list by default.
 • The status code has the following values defined and shall be used
   in all Native Info responses defined. The following are the status
   codes and their associated meanings:
       – Status code = 0, requested information is present in response
       – Status code = 58, requested information corresponding to the Info ID of the
         query is not configured in this BSS

Submission                                         Slide 11                       Stephenson, Salowey & Zhang
March 2007                                                            doc.: IEEE 802.11-06/1473r3


                 GAS Native Info: mSSID List

                       Info ID   Length   Status    SSIDC IE      SSIDC       …    SSID IE
                         (1)              Code         #1          IE #2             #N
                                                    (optional)   (optional)       (optional)
             Octets:     1         2        2        variable    variable     …   variable




 • Maximum number of SSIDCs (SSID Containers) is limited by the
   maximum MSDU size of the 802.11 frame
 • SSIDC IE #1 is shown as optional since a query for this element,
   when not configured, would return only a failure status code and
   zero SSIDC IEs.
 • Goal is to support up to 32 SSIDs per BSSID (which is also the
   number of GTK IDs required—see subsequent slides)


Submission                                         Slide 12                         Stephenson, Salowey & Zhang
March 2007                                                               doc.: IEEE 802.11-06/1473r3

      GAS Native Info: Emergency Networks
                       List
               Info ID   Length   Status     ESO           SSID IE        Default Emergency      SSID IE
                 (2)              Code     Capability   (conditionally    Services Realm IE   (conditionally
                                                          optional)           (optional)        optional)
     Octets:     1         2        2          1              variable        variable          variable


 •    With a single Native GAS query, STA can obtain all configured information relating
      to emergency networks (i.e., wireless networks which provide emergency service)
 •    ESO bit and Default Emergency Services Realm IE are currently defined in 802.11u-
      D0.02
 •    ESO bit in Interworking Capability IE is now also in ESO capability field (defined
      on subsequent slide)
 •    ESO bit and Default Emergency Services Realm, as currently defined in 802.11u-
      D0.02 are defined for an SSID, so with mSSID feature and without this modification,
      binding of emergency network information to SSID could be ambiguous.
 •    Note: the Default Emergency Services Realm IE and ESO capability could instead
      have been put into the SSIDC, but then STA seeking emergency network
      information would need to search the mSSID List.
Submission                                         Slide 13                         Stephenson, Salowey & Zhang
March 2007                                                doc.: IEEE 802.11-06/1473r3

      GAS Native Info: Emergency Networks
                   List (cont.)

 •    The SSID IE immediately following the ESO capability is present only if the ESO
      network is defined; if present the SSID IE may contain either the default SSID or an
      SSID from the mSSID List.
 •    The Default Emergency Services Realm IE is only present if this information has
      been configured on the AP
 •    The SSID IE immediately following the Default Emergency Services Realm IE is
      present only if Default Emergency Services Realm IE is present; if present the SSID
      IE may contain either the default SSID or an SSID from the mSSID List.




Submission                                 Slide 14                  Stephenson, Salowey & Zhang
March 2007                                                          doc.: IEEE 802.11-06/1473r3

                                      SSIDC IE
                          Element   Length   Index       SSID IE       RSN
                             ID                                          IE
                                                                     (optional)
                Octets:     1         1       1          variable    variable
 • Index
       – For each SSID in the SSID List, 1 bit in the Partial Virtual bitmap of the TIM IE is
         reserved to indicate bc/mc frame transmission (no modification to DTIM IE
         required)
       – Index is an integer from 1 to 32 whose value corresponds to the bit number in the
         Partial Virtual bitmap used for bc/mc TIM for the SSID (Index takes on a different
         range when mBSSID configured—see next slide)
       – The AP assigns AID values beginning with bit number after the highest valued Index
         number
 • RSN IE
       – If RSN IE is not included, then RSN IE contained in beacon applies to this
         SSID/ESSID pair
       – If RSN IE is included, then the RSN parameters MUST be the same for all
         APs in the ESS (as defined by the ESSID); this is helpful to support fast
         transition as mSSID List is not included in beacon frames
Submission                                    Slide 15                            Stephenson, Salowey & Zhang
March 2007                                                 doc.: IEEE 802.11-06/1473r3

               Harmonizing TIM handling for
                   mSSID and mBSSID
 • The TIM handling of mBSSID (Virtual AP) proposal reserves the
   first 2^n bits for bc/mc for each BSS which is similar with the TIM
   handling of mSSID.
 • When both mBSSID and mSSID are implemented:
       – If the SSID IE is included in the Multiple BSSID IE
             • The STA uses the mBSSID TIM method
             • The STA shall interpret the AID 0 IE in the Non-Transmitted-BSSID Profile IE
               if FBMS is implemented
       – If the SSID IE is included in an SSIDC IE
             • The STA uses the mSSID method (i.e., Index field)
 • The 1~ (2^n-1) bits in TIM IE is reserved for the mBSSID method
   (―n‖ is the Maximum BSS Indicator in the Multiple BSSID
   element); the SSID Index allocation begins with bit number 2^n.

Submission                                  Slide 16                   Stephenson, Salowey & Zhang
March 2007                                            doc.: IEEE 802.11-06/1473r3


               ESO Capability field

                             B0          B1    B7
                         Emergency         Reserved
                        Services Only
                Bits:        1                 7




 • Emergency Services Only (ESO) bit defined in 802.11u-
   D0.02




Submission                          Slide 17                   Stephenson, Salowey & Zhang
March 2007                            doc.: IEEE 802.11-06/1473r3


              Operational Comments
 • When AP receives a Probe Request from a legacy STA
   with wildcard SSID, it responds with default SSID (the
   one in the beacon).
 • When AP receives a Probe Request from legacy STA
   with non-default SSID in the mSSID list, it does not
   respond to Probe Request
 • To provide backwards compatibility with legacy STAs,
   TGu-capable non-AP STAs shall transmit Probe
   Requests and APs shall transmit Probe Responses in
   accordance with the ―Use SSIDC in Probes‖ bit (see
   subsequent slides)

Submission                 Slide 18            Stephenson, Salowey & Zhang
March 2007                                                       doc.: IEEE 802.11-06/1473r3


             Use of SSIDC in Probe Requests

                          B0     B1      B2              B3       B4           B15

                          QoS    EBR    ESO       Use SSIDC IE         Reserved
                          Map                       in Probes
                  Bits:    1      1       1              1                12



 •    ―Use SSIDC in Probes‖ bit is included for operation with legacy (non-
      TGu capable) STAs
       – If legacy STAs are associated or are actively scanning a BSS, B3 shall be set to 1
       – If no legacy STAs are associated and no legacy STAs have been actively scanning,
         then an AP may set B3 to 0.
       – If B3 is set to 0 and an AP receives a Probe Request from a legacy STA, the AP
         must set B3 to 1 within 1s for a minimum of 60s.




Submission                                    Slide 19                         Stephenson, Salowey & Zhang
March 2007                                                  doc.: IEEE 802.11-06/1473r3


      Use of SSIDC in Probe Requests (cont.)

 •    If B3 is set to 1
       – TGu-capable non-AP STAs shall use the default SSID in Probe Requests and
         include an SSIDC IE containing the SSID which is being actively scanned; if the
         desired SSID is the default SSID, then TGu-capable STAs shall not include an
         SSIDC IE in Probe Requests.
       – APs receiving Probe Requests with an SSIDC IE shall use the default SSID and
         include an SSIDC IE containing the requested SSID and optional RSN IE in Probe
         Responses
       – APs receiving a Probe Request without an SSIDC IE shall not include an SSIDC IE
         in the Probe Response.
 •    If B3 is set to 0
       – TGu-capable non-AP STAs shall not include the SSIDC ID in Probe Requests;
         rather they shall include the SSID IE specifying the desired SSID to actively scan
         whether or not that SSID is in the mSSID List.
       – APs shall not include an SSIDC IE in a Probe Response.

Submission                                  Slide 20                    Stephenson, Salowey & Zhang
March 2007                                          doc.: IEEE 802.11-06/1473r3

     Extended GTK for Supporting Multiple
                   SSIDs
 • Current limitations
       –     Only one (+1 for rollover) GTK per AP currently supported
       –     Current key ID only 2 bits
       –     Number of SSIDs can easily exceed this
       –     If identifiers are reused then STA does not know which key to use
             for which packet or even if it should decrypt the packet
 • Enhancements
       – Allow for multiple broadcast and multicast keys
       – Longer key ID allows for flexible key management
       – Reduces STA ―guessing‖ and associated errors


Submission                              Slide 21              Stephenson, Salowey & Zhang
March 2007                                      doc.: IEEE 802.11-06/1473r3


                Multiple GTK Hierarchies

 • On the AP, each SSID may have its own GMK used to
   derive GTKs for each SSID
       GTK[s] = PRF-X(GMK[s],―Group key expansion‖,AA||GNonce)

 • Each GTK has its own ID
       – GTKID[s] is determined by the AP
       – Must support 64 IDs (32 SSIDs x 2 for rollover)
       – Minimum 6-bit ID is necessary


 • Proposal makes used of reserved key ID bits in CCMP
   header (protected header)

Submission                          Slide 22               Stephenson, Salowey & Zhang
 March 2007                                            doc.: IEEE 802.11-06/1473r3


              MPDU Format with Extended GTK
      Frame        CCMP Header              Data        MIC
      Header         (8 bytes)




PN0    PN1      Rsvd    Ext       Ext          Key    PN2   PN3     PN4         PN5
                       Key ID     IV           ID


                       b0   b4     b5         b6 b7
                             Key ID Byte




 Submission                                Slide 23               Stephenson, Salowey & Zhang
March 2007                                       doc.: IEEE 802.11-06/1473r3


                        Extended Key ID

 • Extended key ID uses 5 reserved bits in the CCMP
   header key ID field
 • Combined with existing key ID this provides 7 bits
       – Enough room for 32 keys plus rollover
 • Existing implementations should work as today
       – Ignore reserved bits so will not be able to determine correct key
       – If key matches then decryption succeeds, else decrypt error
       – Implementations may be done in software as only multicast traffic
         is considered
 • New implementations avoid decrypt error

Submission                          Slide 24              Stephenson, Salowey & Zhang
  March 2007                                            doc.: IEEE 802.11-06/1473r3


                Extended GTK Key Management
• GTK is established during 4-way handshake and/or group key
  handshake of 802.11 using a GTK KDE
• Extend existing GTK KDE format by using 5 reserved bits

               Key ID    Tx     Ext ID         Rsvd             GTK

                Bits    Bit 2    Bits          1 byte        Length – 6
                0-1              3-7                           bytes

• Alternatively a new GTK KDE could be defined
• Existing key ID could be used for key roll-over




  Submission                        Slide 25                     Stephenson, Salowey & Zhang
March 2007                                                 doc.: IEEE 802.11-06/1473r3


               Comparison to TGv’s mBSSID
 • Benefits of TGv’s mBSSID method
       – Provides greater flexibility of configuring an ESS than mSSID
 • Benefits of TGu’s mSSID method
       – Smaller beacon size
             • mBSSID adds up to 42N octets to beacon where N is number of SSIDs
               supported; SSID element adds up to 34 octets dependent on number of octets
               in SSID
             • If ESS supports 32 SSPNs, this could add up to 1344 octets to beacon
       – TGv method cannot be used until all non-AP STAs in BSS are TGv
         capable; mSSID method can be used in conjunction with virtual AP
         method in the ―interim‖ (possibly a long time)—STAs must just be TGu
         capable.
       – If MAC addresses installed on AP during manufacturing are used up (as in
         TGv method), mSSID feature still allows more SSPNs to be added to AP.
         In addition to better scalability, it provides better backward compatibility
         with existing AP HW.
       – Does not require allocation of additional MAC addresses for AP
Submission                                  Slide 26                   Stephenson, Salowey & Zhang
March 2007                                     doc.: IEEE 802.11-06/1473r3


        Comparison to TGv’s mBSSID (cont.)

 • mSSID and mBSSID have complementary benefits and
   coexistence is not mutually exclusive
 • Standardizing both methods gives operators the most
   flexibility in hotspot AP deployment
       – mSSID used when hotspot can be otherwise configured using IEs
         present in a single Beacon
       – mBSSID and mSSID when hotspot must support multiple
         configurations which are not possible using a single Beacon




Submission                         Slide 27             Stephenson, Salowey & Zhang
March 2007                            doc.: IEEE 802.11-06/1473r3


                Benefits of Proposal

 • Directly-connected SSPNs can have their presence
   advertised via SSID at hotspots
 • Allows greater flexibility in mapping SSPNs to SSIDs
 • Each SSID may have its own RSN configuration
 • Each SSID has its own GTK thereby keeping SSPNs’
   broadcast domains separated
 • Introduction of GTK ID facilitates STAs to
   differentiate bc/mc frames corresponding to the SSID
   with which they’re associated
 • Building this capability upon GAS Native Query
   (introduced herein) avoids beacon bloat

Submission                 Slide 28            Stephenson, Salowey & Zhang
March 2007                                       doc.: IEEE 802.11-06/1473r3


                             G1 Analysis
 • All proposals (whichever requirements they address)
   shall describe how they minimize battery consumption
   for mobile devices.
       – This proposal has negligible effect on battery consumption




Submission                          Slide 29               Stephenson, Salowey & Zhang
March 2007                                      doc.: IEEE 802.11-06/1473r3


                            G2 Analysis

 • All proposals (whichever requirements they address)
   shall describe the security impact of the functions they
   propose.
       – This proposal improves security of overall solution
       – Minimizes crypto error by explicitly allowing cryptographic
         separation of the VLANs
       – Minimizes the potential for information leakage across SSIDs by
         providing cryptographic separation of broadcast traffic between
         SSIDs so that only authorized parties have the correct GTK for
         decryption



Submission                          Slide 30              Stephenson, Salowey & Zhang
March 2007                                                 doc.: IEEE 802.11-06/1473r3


                                   G3 Analysis

 • All proposals must allow APs to serve legacy STAs in addition to
   STAs that have been upgraded to 11u. Proposals must describe
   how this is achieved.
       – Legacy STAs may not be capable of associating to SSIDs other than the
         SSID carried in the beacon—same situation for both mBSSID and
         mSSID.
       – De-crypt errors on bc/mc frames for some legacy STAs may cause
         undesired behavior (e.g., roaming); many legacy STAs already tolerant of
         decrypt errors.
             • TGw draft permits multiple IGTKs per IBSS (same issue)
             • Currently, many STAs known to be tolerant of bc/mc decrypt errors
       – Any undesirable effects can be mitigated by:
             • Having legacy STAs associate to default SSID/BSSID
             • Having legacy STAs associate to VAP (not the TGv type of VAP) or 2nd AP in
               hotspot configured without mSSID capability.




Submission                                  Slide 31                   Stephenson, Salowey & Zhang
March 2007                             doc.: IEEE 802.11-06/1473r3


                         Motion

 • Move to instruct the Technical Editor to include
   normative text from document 11-06/1935r1 for Multi-
   SSID feature into the TGu draft amendment.

 • Moved: Dave Stephenson
 • Second:
 • Yes = , No = , Abstain = .




Submission                  Slide 32            Stephenson, Salowey & Zhang

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:12/19/2011
language:English
pages:32