1. TSN Architecture Mike Moreton, STMicroelectronics
doc.: IEEE /xxxx
February 2004
February 2004
TSN Architecture Mike Moreton, STMicroelectronics
February 19, 2004
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

2. doc.: IEEE /xxxx
February 2004
February 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.
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.
While the MLME/MA architectural split does not constrain an implementation, it’s up to the implementer to check the security of any other architecture.
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

3. 802.1X Filtering The 802.1X filtering function is “above” the MAC
doc.: IEEE /xxxx
February 2004
February 2004
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
To prevent a race condition between an MLME-ASSOCIATE.indication and an immediately following data frame, the 802.1X filtering function must behave as if there is an uncontrolled/(unauthorised)controlled port pair instantiated for every possible MAC address.
At this point we’re not saying that there isn’t WEP based filtering as well, just that whether there is or not, 802.1X filtering will be applied anyway.
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

4. doc.: IEEE /xxxx
February 2004
February 2004
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
In some senses you could argue that they do have a PAE, but that it’s different from an 802.1X one
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

5. Filtering in an 802.11 Environment
February 2004
Filtering in an 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
doc.: IEEE /xxxx
February 2004
February 2004
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 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.
(1) Alternatively WEP is normally on, and when an RSN IE is present it turns it off for that STA.
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

7. Option 2 – SME Enables WEP
doc.: IEEE /xxxx
February 2004
February 2004
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
Fred Stivers, Texas Instruments

8. doc.: IEEE /xxxx
February 2004
February 2004
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
The issue with WEP configuration is that the Discard Protected flag is not per-STA.
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

9. One Unexpected Benefit?
doc.: IEEE /xxxx
February 2004
February 2004
One Unexpected Benefit?
TSN APs don’t have to support pre-RSNA per-frame pseudocode
An advantage when WEP dies…
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

10. One Unavoidable(?) Problem
doc.: IEEE /xxxx
February 2004
February 2004
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
This is an existing problem, not one introduced by this proposal.
For pre-RSNA devices, SME would enable WEP, authorise the controlled port, and send MLME-ASSOCIATE.response.
Could this also remove the need for 1X filtering on pre-RSNA connections? Well no, the same arguments about whether you want WEP specific functionality in the 1X filtering, and how actually to configure WEP still apply.
Mike Moreton, STMicroelectronics
Fred Stivers, Texas Instruments

11. Architectural Responsibilities
February 2004
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
February 2004
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