Tx & Rx Pseudo Code

1. Tx & Rx Pseudo Code David Johnston david.johnston@ieee.org David Johnston, Mobilian.

2. Problems • Section 8.7.1 Tx PseudoCode & 8.7.2 Rx PseudoCode • “attempt to decrypt with that key, incrementingdot11WEPICVErrorCount if the ICV check fails” • This mandates an ICV check for M[PS]DUs, regardless of whether they have an ICV, MPDU level MIC, MSDU level MIC or OCB authentication. David Johnston, Mobilian.

3. Problems • Title “Temporal Key Processing” is inappropriate • Maybe “Per Packet Transmit and Receive Procedures” • MDPU & MDSU • .,$s/MDPU/MPDU/g • .,$s/MDSU/MSDU/g David Johnston, Mobilian.

4. Problems • Layer Violations • “if Ethertype is 802.1X then transmit the MPDU without protection” • “dot11WEPKeyMappings matching the MPDU’s TA and Ethertype is 802.1X then” • The MAC should not be looking outside its layer • The MAC cannot look outside its layer on MPDUs (might not have encapsulation header in fragment) David Johnston, Mobilian.

5. Support of Cipher Suites is not Taken into Account • Thus if we can’t find a key, we report a WEP error and increment a WEP mib variable, even if we have no WEP. • Checking the support for any given cipher is not done before invoking the cipher David Johnston, Mobilian.

6. MPDU vs MSDU differentiation is not clear • “if (MSDU has an individual RA anddot11WEPKeyMappings has an entry for that RA anddot11WEPKeyMappingsKeyBroadcast is false) or (the MDPU has a multicast RA and the network type is IBSS and the network is RSN and there is an entry in dot11KeyMapppings for the TA anddot11WEPKeyMappingsKeyBroadcast is true) then” • Operations simultaneously described over MSDU & MPDUs! • So the semantics are not clear • So defeats the intent of pseudocode (Clarity) David Johnston, Mobilian.

7. Solution • Rewrite as 4 pseudo code behaviours • Per MSDU Tx Behaviour • Per MPDU Tx Behaviour • Per MPDU Rx Behaviour • Per MSDU Rx Behaviour • Enable 802.1x to signal packet filtering state to MAC • aHavePTK set by MLME.SETKEYS.request for PTKs • aHaveGTK set by MLME.SETKEYS.request for GTKs • Note MPDU Rx before MSDU Rx and MPDU Tx after MPDU Rx to match natural processing order David Johnston, Mobilian.

8. Per MSDU Tx Behaviour • Check aDot11PrivacyInvoked • Find an entry in dot11WEPKeyMappings • Have different behaviour for CCMP, WRAP, TKIP and WEP • CCMP and WEP are null at MSDU level • Handle null key case (report null key) • Report if unsupported cipher suite • Handle case of BSS broadcast with mix of protected and non protected STAs • Handle WEP Default key case when WEP supported David Johnston, Mobilian.

9. Per MPDU Tx Behaviour • Transmit MPDU based upon the cipher suite selected for the MSDU that the MPDU is a fragment of • WRAP is a NOP at MPDU level David Johnston, Mobilian.

10. Per MPDU Rx Behaviour • Handle unprotected Rx MPDU • Throw away if aExcludeUnencrypted set • Otherwise receive it • Find an entry in dot11WEPKeyMappings • Handle protected Rx MPDU • Handle WEP Default Key Case when no key found when WEP supported • Handle null WEP Default key case when WEP Supported • When entry found • If cipher suite unsupported, discard MPDU and report • Otherwise receive packet using cipher of entry in mapping table providing cipher • WRAP is NOP at MPDU level David Johnston, Mobilian.

11. Per MSDU Rx Behaviour • Handle unprotected Rx MSDU • Throw away if aExcludeUnencrypted set • Otherwise receive it • Find an entry in dot11WEPKeyMappings • Handle protected Rx MSDU • Handle null key case • Handle null WEP Default key case when WEP Supported • When entry found • If cipher suite unsupported, discard MPDU and report • Otherwise receive packet using cipher of entry in mapping table providing cipher • WEP and CCMP are NOPs at MSDU level David Johnston, Mobilian.

12. Packet Filtering • MAC is asked to filter based on following MPDU state • Is MPDU a member of an 802.1x MSDU • Is 802.1x MSDU from associated STA? (and we are an AP) • Is MPDU protected? • Is MPDU unicast or broadcast/multicast? • MAC has only visibility of protected and group state, not 802.1x content • The MAC gets the following clues to dictate filtering behaviour of received MPDUs: • MLME-SETKEYS.request for PTKs • MLME-SETKEYS.request for GTKs • dot11PrivacyInvoked • aExcludeUnencrypted • TA David Johnston, Mobilian.

13. Packet Filtering • Since MAC should not examine the 802.1x content of payloads, MAC must pass unencrypted MSDUs up to 802.1x layer and permit 802.1x to discard MPDUs based on its own port admission policy, in case the MSDU carries an 802.1x payload, during the period which the MAC is currently asked to pass 802.1x traffic but filter all other unprotected traffic. • The MAC is required to filter out unprotected unicast MPDUs once PTKs have been installed for that association • The MAC is required to filter out unprotected group MPDUs once GTKs have been installed for that association David Johnston, Mobilian.

14. MAC Level MPDU Filtering • Add aHavePTK • Add aHaveGTK • Initialize both to FALSE • Set aHavePTK following MLME-SETKEYs for PTK • Set aHaveGTK following MLME-SETKEYs for GTK • Set both aHavePTK and aHaveGTK to FALSE on disassociate or de-authenticate • Use aExcludeUnencrypted for non RSN situations David Johnston, Mobilian.

15. Motion • Move that the editor incorporate into the draft the changes described in document 11-02-???r?-TxRxPseudoCode David Johnston, Mobilian.