1. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 1 Security aspects of MAC Aggregation Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-05-16 Author NameCompanyAddressPhoneEmail Amit Bansal Wipro Technologies Electronic City, Bangalore, India +91 80 30295128 amit.bansal@wipro.c om

2. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 2 Aggregation Methods TGNSync’s and WWise’s A-MSDU are equivalent from view of encryption (MAC High) TGNSync’s A-MPDU or WWise’s HTP Burst are equivalent from view of aggregation (MAC Low)

3. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 3 A-MSDU Structure (TgnSync)

4. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 4 A-MSDU Structure (WWise)

5. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 5 MAC High Encryption A-MSDU structure is the same for TgnSyn or WWise proposals. All MSDUs in an A-MSDU are directed to the same immediate receiver (RA). –each MSDU can have different DA when sending from STA to AP –each MSDU can have different SA when sending from AP to STA This is aggregation “above” the MAC and the encryption engine should not have been aware of MSDU boundaries However, TKIP MIC and CCMP algorithms both need access to DA and SA, which are part of the sub frame header Hence, –The encryption algorithm needs to know MSDU boundaries even in an aggregation that is “above” the MAC –Encryption needs to be done on a per MSDU basis, and each individual MSDU should have the IV, EIV, MIC and/or ICV fields The A-MSDU frame cannot be treated as a single frame as far as encryption is concerned (except by the WEP algorithm)

6. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 6 Proposed Sub-frame Header MSDU Length SADAIVEIV 2 bytes6 bytes 4 bytes New fields

7. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 7 A-MPDU Structure (TgnSync)

8. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 8 HTP Burst (WWise)

9. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 9 MAC Low Encryption The A-MPDU frame (or HTP Burst) cannot be encrypted as a single frame; each individual MPDU has to be encrypted separately because: –If the SR A-MPDU (or HTP Burst) is encrypted as a whole, the robustness is lost –Both TKIP MIC and CCMP algorithms need access to DA and SA, which are part of each MPDU –A MR A-MPDU (or MR HTP Burst) cannot anyway be encrypted as a whole, since security keys are generated pair-wise Each individual MPDU has to have the IV, EIV, MIC and/or ICV fields. If the individual MPDU header is compressed, the CHDATA MPDU (in TgnSync) should also have the IV and EIV fields

10. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 10 Proposed CHDATA MPDU (TgnSync) Octets: 221441n4 Frame Control Sequence Control HIDIVEIVReservedPayload DataFCS Compressed Header New fields

11. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 11 Overhead of Inline TKIP Key Search (say 256 keys, split key search, @ 100MHz = 1.28µs) TKIP Key mixing (52 clocks @ 100MHz = 0.52µs) RC4 transformation (768 clocks @ 100 MHz = 7.68µs) Total time per un-aggregated frame = 9.48µs

12. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 12 Without Aggregation The large pre-processing time –is swallowed in the preamble time and the MAC Header time for every frame during transmission –Is swallowed in the preamble time and the MAC Header time of the next frame during reception Usually the MAC gets at least 12µs before the PHY requires encrypted data during transmission Usually the MAC gets at least 28µs (4µs of the SIFS + 20µs of the next preamble + 4µs of the first OFDM symbol) before the PHY supplies encrypted data during reception

13. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 13 With Aggregation Since there is no preamble between frames, the ≈10µs pre- processing time cannot be made parallel Only an offline WEP/TKIP engine can handle the pre- processing latency However, an offline WEP/TKIP engine is subject to its own constraints –Limited by maximum operating frequency –Bus utilization is roughly 3X as compared to an inline WEP/TKIP engine

14. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 14 Legacy Systems: WEP/TKIP Overhead processing of WEP/TKIP encryption algorithms is not conducive to per-frame encryption in an aggregate Since WEP need not be applied on a per MSDU basis in MAC High encryption –TKIP could be challenging for TgnSync’s or WWise’s A-MSDU aggregation WEP or TKIP could be challenging for TgnSync’s A-MPDU aggregation or WWise’s HTP Burst

15. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 15 Overhead of Inline CCMP Key Search (say 256 keys, split key search, @ 100MHz = 1.28µs) CCMP pre-processing (44 clocks @ 100 MHz = 0.44µs) Total time per un-aggregated frame = 1.72µs

16. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 16 With Aggregation The latency of 1.72µs can be absorbed by running the MAC faster than the PHY requires data E.g. if the PHY requires a data stream at 240Mbps, the MAC might be run at 40MHz to deliver (in a burst) 320Mbps on an 8-bit data path to the PHY

17. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 17 RSNA Systems: CCMP Overhead processing of CCMP encryption algorithm is conducive to MAC High or Low Aggregation TgnSync’s or WWise’s A-MSDU aggregation can be handled by CCMP TgnSync’s A-MPDU aggregation or WWise’s HTP Burst can be handled by CCMP Recommendation: Use of only CCMP encryption algorithm with aggregation with the proposed Header changes.

18. doc.: IEEE 802. 11-05/0415r0 Submission May 2005 Amit Bansal, WiproSlide 18 Conclusion Encryption algorithm ► WEPTKIPCCMP Aggregation scheme ▼ A-MSDU aggregationYesNoYes A-MPDU aggregation or HTP Burst No Yes