1 / 12

TSN Architecture Mike Moreton, STMicroelectronics

TSN Architecture Mike Moreton, STMicroelectronics. February 19, 2004. Why MLME?. MLME and MA interfaces describe a functional split between the MAC and “everything else” Make it easier to understand the problem, by splitting it in two.

cole-rose
Download Presentation

TSN Architecture Mike Moreton, STMicroelectronics

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. TSN ArchitectureMike Moreton, STMicroelectronics February 19, 2004 Mike Moreton, STMicroelectronics

  2. Why MLME? • MLME and MA interfaces describe a functional split between the MAC and “everything else” • Make it easier to understand the problem, by splitting it in two. • Describe the architecture – particularly important in security. • Needs to be “almost” implementable. • Does not constrain implementation. • It’s exactly these issues of “who knows what when” that have led to problems with the 4 way handshake. Mike Moreton, STMicroelectronics

  3. 802.1X Filtering • The 802.1X filtering function is “above” the MAC • MLME-ASSOCIATE.ind requires filtering to exist for STAs that the Authenticator doesn’t know about. • In a TSN, some STAs are not RSNA capable • 802.1X filtering will be applied to them as well Mike Moreton, STMicroelectronics

  4. Pre-RSNA Ports • How is 802.1X filtering turned off for pre-RSNA devices? • Could have special code in the filtering code to handle such devices. • But if already treating them as if there was a controlled/uncontrolled port pair, why not just authorise the controlled port? • Conclusion: Pre-RSNA devices have controlled/uncontrolled ports • But they don’t have an 802.1X PAE Mike Moreton, STMicroelectronics

  5. Filtering in an 802.11 Environment • 802.1X filtering only works if protection is enabled before the controlled port is authorised. • For a pre-RSNA device, this means turning on WEP. • Two options – the MAC could do it, or the SME could do it. Mike Moreton, STMicroelectronics

  6. Option 1 – MAC Enables WEP • MAC digs into the Association Request, spots that there is no RSN IE, and hence turns on WEP. • Against the spirit of both TGi and 802.11-1999 where enabling/disabling encryption is the responsibility of the SME • Requires extra code in the MAC • AP architecture for pre-RSNA devices different than for RSNA devices. Mike Moreton, STMicroelectronics

  7. Option 2 – SME Enables WEP • By default MAC receives unencrypted frames from anywhere • Relies on 802.1X filtering that we know is there. • When SME gets a pre-RSNA association, it enables WEP before authorising the controlled port for that device. • No special handling in the MAC • AP Architecture for Pre-RSNA and RSNA devices is the same Mike Moreton, STMicroelectronics

  8. One slight twist… • The current WEP configuration interface is not flexible enough • The current WEP configuration interface is not synchronised • So… • Allow WEP to be configured as a pairwise key through the SETKEYS and SETPROTECTION interfaces Mike Moreton, STMicroelectronics

  9. One Unexpected Benefit? • TSN APs don’t have to support pre-RSNA per-frame pseudocode Mike Moreton, STMicroelectronics

  10. One Unavoidable(?) Problem • When a pre-RSNA device associates, some frames from it may be lost while the 802.1X port is authorised. • Implementations could fix it by attaching a flag to frames indicating the association type. • Correct architectural solution is to add MLME-ASSOCIATE.response Mike Moreton, STMicroelectronics

  11. Architectural Responsibilities • MAC sends and receives frames, protected or unprotected as required. • SME decides which encryption suites to use, and when. • SME is responsible for protocol based frame filtering. • MAC is responsible for source based filtering (when required by SME) Mike Moreton, STMicroelectronics

  12. Conclusion • This is not the only possible architecture • But we need an architecture to analyse, and this is one. • Relatively simple and consistent. Mike Moreton, STMicroelectronics

More Related