1 / 11

TGi Motions

TGi Motions. Mike Moreton, STMicroelectronics. Justification.

edison
Download Presentation

TGi Motions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TGi Motions Mike Moreton, STMicroelectronics Mike Moreton, STMicroelectronics

  2. Justification • This document documents a series of motions. The intention of these motions is to clarify the position of the TG before comment resolution commences. Note that no such motion can be binding, but it is hoped that discussion of these motions will help achieve consensus. Mike Moreton, STMicroelectronics

  3. RSN Capable • It is the intention of TGi, that the term “RSNACapable” should only imply that the device is capable of establishing an RSNA, not that it is configured to do so. Dot11RSNAEnabled shall be set to true when RSNA is actually enabled, and hence is a far more common determinant of RSNA type behaviour than RSNACapable. Mike Moreton, STMicroelectronics

  4. Using 802.1X AKMP to get a WEP Key • It is the intention of TGi, that the combination of Group Key Cipher Suite = WEP, and Pairwise Key Cipher Suite = Use Group Key should not be allowed. Mike Moreton, STMicroelectronics

  5. IBSS Policy • The intention of TGi is that IBSS support should be based on the concept of a uniform security policy for all members of the BSS. A uniform security policy shall include a single pairwise encryption suite, and a single AKMP. Mike Moreton, STMicroelectronics

  6. Deleting an RSNA • Given that a MAC can not be expected to maintain state for a disassociated STA indefinitely, and that equally such state should not be discarded before the Controlled Port has been blocked, it is the intention of TGi to add an MLME-DEAUTHENTICATE.reponse primitive so that the MAC can know when it is safe to delete state. Mike Moreton, STMicroelectronics

  7. MAC Signalling of a New STA in an IBSS • The draft currently describes two mechanisms by which the MAC can inform the SME of a new STA in an IBSS. Section 11.3.2 describes a mechanism based on MLME-AUTHENTICATE.indication, while other sections use a mechanism based on a new MLME-PROTECTEDFRAMEDROPPED.indication primitive. It is the intention of TGi that the latter should be removed in favour of the mechanism described in section 11.3.2. Mike Moreton, STMicroelectronics

  8. MAC Authentication in an IBSS • It is the intention of TGi that TSN should not be supported in an IBSS, and hence the optional MAC authentication stage is of no value, and should be removed. Mike Moreton, STMicroelectronics

  9. MAC Authentication in an ESS • It is the intention of TGi to remove the MAC Authentication stage when establishing an RSNA in an ESS. Mike Moreton, STMicroelectronics

  10. IBSS 4-way Handshakes • Given that the second 4-way handshake in an IBSS only serves to slightly optimise GTK delivery, and introduces a great deal of complexity, it is the intention of TGi to move to a single 4-way handshake for IBSS. Mike Moreton, STMicroelectronics

  11. Local Multicast • TGi do not intend to include protection of TGe’s “Local Multicast” feature. It’s too late in the process for such a significant change, and TGe should fix the problem themselves, as only they can determine if the usefulness of this feature justifies the changes to support it. Mike Moreton, STMicroelectronics

More Related