1. Security aspects of MAC Aggregation
Month 2004
doc.: IEEE /xxxr0
May 2005
Security aspects of MAC Aggregation
Date:
Author
Name
Company
Address
Phone
Amit Bansal
Wipro Technologies
Electronic City, Bangalore, India
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Amit Bansal, Wipro
John Doe, His Company

2. May 2005
Aggregation Methods
TGNSync’s and WWise’s A-MSDU are equivalent from view of encryption (MAC High)
TGNSync’s A-MPDU or WWise’s A-PPDU/HTP Burst are equivalent from view of aggregation (MAC Low)
Amit Bansal, Wipro

3. A-MSDU Structure (TgnSync)
May 2005
A-MSDU Structure (TgnSync)
Amit Bansal, Wipro

4. A-MSDU Structure (WWise)
May 2005
A-MSDU Structure (WWise)
Amit Bansal, Wipro

5. May 2005
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)
Amit Bansal, Wipro

6. Proposed Sub-frame Header
May 2005
Proposed Sub-frame Header
MSDU Length SA DA IV
EIV
2 bytes
6 bytes
4 bytes
New fields
Amit Bansal, Wipro

7. May 2005
Alternatives
The TKIP and CCMP algorithms use SA and DA. Why not use TA in place of SA and RA in place of DA in the algorithm? This will ensure that the encryption can be done on the complete A-MSDU, and has the following advantages:
Decrease in computation
Decrease in the per MSDU overheads of IV, EIV, MIC and/or ICV
This may not be feasible because
“The amendment shall not redefine mechanisms in the baseline that do not pertain to higher throughput.”
From a cryptographic point of view, it would be less secure to replace the use of SA/RA with TA/DA. The TKIP and CCMP MIC are used for authentication, and the SA/RA is one of the fields required for robustness.
Amit Bansal, Wipro

8. A-MPDU Structure (TgnSync)
May 2005
A-MPDU Structure (TgnSync)
Amit Bansal, Wipro

9. May 2005
HTP Burst (WWise)
Amit Bansal, Wipro

10. May 2005
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.
Amit Bansal, Wipro

11. Overhead of Inline TKIP
Month 2004
doc.: IEEE /xxxr0
May 2005
Overhead of Inline TKIP
Key Search (say 256 keys, split key 100MHz = 1.28µs)
TKIP Key mixing (52 100MHz = 0.52µs)
RC4 transformation ( MHz = 7.68µs)
Total time per un-aggregated frame = 9.48µs
Amit Bansal, Wipro
John Doe, His Company

12. Without Aggregation The large pre-processing time
May 2005
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
Amit Bansal, Wipro

13. May 2005
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
Amit Bansal, Wipro

14. Legacy Systems: WEP/TKIP
Month 2004
doc.: IEEE /xxxr0
May 2005
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
Amit Bansal, Wipro
John Doe, His Company

15. Overhead of Inline CCMP
May 2005
Overhead of Inline CCMP
Key Search (say 256 keys, split key 100MHz = 1.28µs)
CCMP pre-processing ( MHz = 0.44µs)
Total time per un-aggregated frame = 1.72µs
Amit Bansal, Wipro

16. May 2005
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
Amit Bansal, Wipro

17. Month 2004
doc.: IEEE /xxxr0
May 2005
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.
Amit Bansal, Wipro
John Doe, His Company

18. Encryption algorithm ► A-MPDU aggregation or A-PPDU/HTP Burst
May 2005
Conclusion
Encryption algorithm ►
WEP
TKIP
CCMP
Aggregation scheme ▼
A-MSDU aggregation
Yes No
A-MPDU aggregation or A-PPDU/HTP Burst
Amit Bansal, Wipro