Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11] REVme: Protected BA - ADDBA Req to advance WinStartB

--- This message came from the IEEE 802.11 Working Group Reflector ---

 

Hi again!

 

I am starting a separate email conversation to discuss another topic that was discussed during today’s REVme call (from doc 11-22/0082r3 – Part 4).

 

Since a BAR frame is not protected, it is vulnerable to an attack – i.e., an attacker can inject a BAR frame with the Block Ack Starting Sequence Control subfield set to an arbitrary value. Such attack would go unnoticed and would mess the reorder buffer and scoreboard context at a recipient STA.

 

Baseline spec addresses this vulnerability (under the protected BA framework) by requiring the recipient to ignore the BAR frame for the purpose of updating the WinStartB. Instead, the originator transmits an ADDBA Request frame for advancing the window. However, the current spec is lacking several details on the procedure. For example,

  1. The spec doesn’t provide a mechanism to differentiate between an ADDBA Request sent to advance the window versus an ADDBA Request sent to update the parameters (such as timeout) of an existing BA agreement.
  2. The spec is ambiguous on whether the recipient is required to send an ADDBA Response frame in response to such an ADDBA Request frame.

To summarize the proposal from doc 11-22/0082r3:

  1. Use the Fragment Number subfield in the Block Ack Starting Sequence Control subfield to differentiate between the two cases
    • Current spec states this subfield is set to 0. The proposal is to set the value to 1 for the case when ADDBA Request is sent to advance the window.
      • At a high-level it would help to have this indicate in the early portion of the frame so that the receiver can quickly determine the intention of the frame and hence take the right course of action while processing the frame
    • An alternative discussed during today’s call was to define a new frame (under the Block Ack Action) for the purpose of advancing the window.
  2. Treat the ADDBA Request (meant for advancing the window) similar to a BAR frame
    • The ACK frame received from the receiver STA in response to the reception of the ADDBA Req is sufficient confirmation for the transmitter to advance WinStartO
    • Some members expressed reservations against this proposal with concerns that mgmt. frames are processed at a slower pace compared to a Control frame (such as BAR) and hence an explicit (mgmt.) response frame from the recipient is required to confirm the update of WinStartB.
      • However, this approach would mean that the originator is kept waiting for a response. This can have an impact on throughput and latency.

I’d like to hear additional opinions on the topic and alternatives (if any) to address above two cases.

 

Regards,

Abhi

 

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1