TSN Architecture Mike Moreton, STMicroelectronics

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