Enhancing MAC Header Protection in IEEE 802.11 Networks

This document discusses the need for improved protection of MAC headers in IEEE 802.11 networks to address security concerns related to certain fields that are currently not adequately protected. It emphasizes the importance of safeguarding vital information in MAC headers to prevent potential attacks and ensure data integrity during transmission.

• MAC header protection
• IEEE 802.11
• Network security
• Data integrity
• Wireless communication

myaleeab Follow

Uploaded on Oct 07, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. doc.: IEEE 802.11-23/1997r0 MAC Header Protection Date: 2023-11-09 Authors: Name Affiliations Address Phone Email Po-Kai Huang Daniel F Bravo Ido Ouzieli Intel Johannes Berg Ilan Peer Danny Alexander Submission Slide 1 Po-Kai Huang (Intel)

2. doc.: IEEE 802.11-23/1997r0 Abstract Protection of MAC header has been discussed [1] We provide our thoughts in this presentation Submission Slide 2 Po-Kai Huang (Intel)

3. doc.: IEEE 802.11-23/1997r0 Need for MAC Header Protection Several fields in the MAC header today are masked out and not protected by the frame body protection Due to possibility of value change during retransmission and the need to reuse a PN However, those masked out fields do introduce security concern PM bit as discussed in [2] SN field due to BA protocol attack to complete the protection of BA protocol attack HT control due to various information that maybe piggybacked Hence, it is indeed useful to protect MAC header Submission Slide 3 Po-Kai Huang (Intel)

4. doc.: IEEE 802.11-23/1997r0 Scope of MAC Header Protection The problem we have in hand (ex, PM, SN, HT Control) are in the MAC header of data and management. Further, those problems (PM, BA protocol, HT Control) are specific to individually addressed data and management frame. Introduce MAC header protection for group addressed data and management frame likely have backward compatibility issues or blow out the group addressed transmission over the air It then makes sense for 11bn to focus the design of MAC Header protection on individually addressed data and management frame Slide 4 Submission Po-Kai Huang (Intel)

5. doc.: IEEE 802.11-23/1997r0 Direction of Protection To accommodate the possibility of MAC header change during retransmission, MAC header protection and Frame body protection needs to be MIC separately Imply separate key different from frame body protection Imply separate PN field different from frame body protection Imply separate MIC computation different from frame body protection Submission Slide 5 Po-Kai Huang (Intel)

6. doc.: IEEE 802.11-23/1997r0 Requirement on Response Today acknowledgement is sent to individually addressed data/management frame after FCS check With MAC header protection, acknowledge then needs to be sent only after FCS check and MIC check of MAC header If Acknowledgement is sent without MIC check of MAC header, then we still have attack on transmitter side modify SN 1 in MAC header Data frame 1 SN 2 in MAC header Data frame 1 Ack without checking MIC Submission Slide 6 Po-Kai Huang (Intel)

7. doc.: IEEE 802.11-23/1997r0 Fields to be Protected Fields like PM, SN, HT Control should naturally be protected Fields like Duration need separate discussion Recall Duration from any 3rd party CTS is not protected, and is difficult to be protect if feasible at all Security header of frame body protection needs to be considered to have some coupling between MAC header protection and Frame body protection Otherwise, possibility of swap attack Swap SN 1 MAC header 1 Data frame 1 SN 2 MAC header 2 Data frame 1 Receiver uses SN2 for data frame 1 SN 2 MAC header 2 Data frame 2 SN 1 MAC header 1 Data frame 2 Submission Slide 7 Po-Kai Huang (Intel)

8. doc.: IEEE 802.11-23/1997r0 Conclusion We think MAC header protection is an important feature for 11bn Focus on individually addressed data and management frame Have separate key, PN field, MIC calculation different from frame body protection Require to send response after checking FCS and MIC of MAC header protection Protect security header (if present) to have some coupling of MAC header protection and frame body protection Submission Slide 8 Po-Kai Huang (Intel)

9. doc.: IEEE 802.11-23/1997r0 SP #1 Do you support to define MAC header protection for individually addressed data and management in 11bn? Submission Slide 9 Po-Kai Huang (Intel)

10. doc.: IEEE 802.11-23/1997r0 SP #2 Do you support that the checking the MIC of MAC header protection is required before sending response to individually addressed data and management with MAC header protection? Submission Slide 10 Po-Kai Huang (Intel)

11. doc.: IEEE 802.11-23/1997r0 SP #3 Do you support that MAC header protection for individually addressed data and management will at least protect the following fields? PM bit Sequence Control HT Control (if present) security header of frame body protection (if present) Submission Slide 11 Po-Kai Huang (Intel)

12. doc.: IEEE 802.11-23/1997r0 Reference [1] 11-23-1888 MAC Header Protection follow up [2] Framing Frames: Bypassing Wi-Fi Encryption by Manipulating Transmit Queues Submission Slide 12 Po-Kai Huang (Intel)