Dis-Association
=====================

.. contents::
   :local:
   :depth: 3

Overview
--------

In IEEE 802.11b, **disassociation** is a MAC management procedure used by either
the **Station (STA)** or the **Access Point (AP)** to terminate an existing
association. After disassociation, the STA remains *authenticated* but is no
longer *associated*, meaning it cannot send or receive data frames via the AP
until it reassociates.

Unlike **deauthentication**, which removes authentication state entirely,
disassociation only ends the logical data relationship between the STA and AP.

When Disassociation Occurs
--------------------------

Common reasons for disassociation include:

- **Voluntary STA departure** (e.g., STA leaves the BSS or disables its radio)
- **Inactivity timeout** — STA silent beyond a configured limit
- **AP resource management** — AP removes STA due to load balancing or resource limits
- **Power management transitions**
- **Policy or security enforcement**
- **Mobility / roaming** to another AP

State Relationships
-------------------

The 802.11 MAC defines three connection states:

| State | Description |
|--------|-------------|
| 1 | Unauthenticated, Unassociated |
| 2 | Authenticated, Unassociated |
| 3 | Authenticated, Associated |

**Disassociation** causes a transition from **State 3 → State 2**, keeping the
STA authenticated but unassociated.
**Deauthentication**, by contrast, transitions to **State 1**, removing authentication.

Frame Format
------------

The Disassociation frame is a **Management Frame** (Type = 0, Subtype = 10).

| Field | Length | Description |
|--------|---------|-------------|
| Frame Control | 2 | Type = Management, Subtype = Disassociation |
| Duration | 2 | NAV (unused here) |
| Destination Address (DA) | 6 | Receiver MAC address |
| Source Address (SA) | 6 | Sender MAC address |
| BSSID | 6 | BSS Identifier |
| Sequence Control | 2 | Sequence number |
| **Reason Code** | 2 | Explains why disassociation occurred |

- No variable-length information elements (IEs) follow.
- In 802.11b, disassociation frames are **not encrypted** or **integrity protected**.

Reason Codes
------------

Reason Codes provide diagnostic context for disassociation events.
Common codes are:

| Code | Meaning |
|-------|----------|
| 1 | Unspecified reason |
| 4 | Disassociated due to inactivity |
| 5 | AP unable to handle all associated STAs |
| 8 | STA leaving BSS (voluntary) |
| 9 | STA not authenticated |
| 10 | Power capability unacceptable |
| 11 | Supported channels unacceptable |
| 17 | Disassociated due to AP policy |
| 32–35 | QoS-related (later amendments) |

In 802.11b environments, codes **1, 4, 5, and 8** are the most frequent.

Exchange Scenarios
------------------

STA-Initiated Disassociation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Used when a STA voluntarily leaves the BSS.

.. code-block:: none

   STA → AP : Disassociation (Reason = 8, Leaving BSS)
   AP → ACK
   AP clears STA’s AID, buffers, and queues.
   STA becomes Authenticated, Unassociated.

Typical triggers:

- User turns off Wi-Fi.
- STA moves to another AP (reassociation).
- STA enters deep sleep.

AP-Initiated Disassociation
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Used when the AP ends a session but keeps the STA authenticated.

.. code-block:: none

   AP → STA : Disassociation (Reason = 4, Inactivity)
   STA → ACK
   STA transitions to Authenticated, Unassociated.

Typical triggers:

- AP idle timeout.
- Resource or load balancing.
- Channel change or maintenance.

Behavior on Receipt
-------------------

When a **STA receives** Disassociation:

1. Validate frame (CRC, subtype).
2. Read Reason Code.
3. Clear association data: AID, buffers, TIM index.
4. Move to **Authenticated, Unassociated** state.
5. Notify upper layers (network manager).
6. STA may reassociate automatically.

When an **AP receives** Disassociation:

1. Identify STA entry (MAC).
2. Free AID slot, clear queues, reset TIM bit.
3. Drop buffered frames for STA.
4. Log event and Reason Code.
5. Optionally inform controller or RADIUS backend.

Interaction with Power Save and AID
-----------------------------------

- Each associated STA has an **AID** and TIM bit in the AP’s beacon.
- When a STA disassociates, the AP clears the corresponding AID and TIM bit.
- Buffered frames for that AID are discarded.
- On reassociation, a new AID is assigned.

Timing and Retransmission
-------------------------

- Disassociation frames follow normal DCF access rules.
- The frame is **ACKed** if unicast.
- Retries may occur if no ACK received.
- Unprotected nature makes them spoofable in legacy 802.11b.

State Transitions Summary
-------------------------

| Before | After | Trigger | Description |
|---------|-------|----------|--------------|
| Authenticated, Associated | Authenticated, Unassociated | Disassociation | Logical link removed, authentication remains |
| Authenticated, Unassociated | Unauthenticated, Unassociated | Deauthentication | Full session teardown |

Comparison: Disassociation vs Deauthentication
----------------------------------------------

| Property | Disassociation | Deauthentication |
|-----------|----------------|------------------|
| Frame subtype | 10 | 12 |
| State change | Associated → Unassociated | Authenticated → Unauthenticated |
| Authentication | Retained | Lost |
| Use case | Normal leave or inactivity | Security or session reset |
| STA rejoin | Reassociation possible | Must reauthenticate |
| ACK expected | Yes | Yes |
| Protected (PMF)? | Optional (later) | Optional (later) |

Examples
--------

STA-Initiated Example
~~~~~~~~~~~~~~~~~~~~~

.. code-block:: none

   STA (Associated)
   -------------------------------------->
       Disassociation (Reason = 8)
                                         <--- ACK
   STA → Authenticated, Unassociated

AP-Initiated Example
~~~~~~~~~~~~~~~~~~~~

.. code-block:: none

   AP detects STA inactivity
   AP ------------------------------>
       Disassociation (Reason = 4)
                                         <--- ACK
   AP clears AID, buffers
   STA becomes Authenticated, Unassociated

Sequence Diagram
----------------

.. code-block:: none

   +-----------+                       +-----------+
   |    STA    |                       |     AP    |
   +-----------+                       +-----------+
         |                                     |
         |<---------- Association ------------>|
         |             (Established)           |
         |                                     |
         |--- Disassociation (Reason=8) -----> |  (STA leaving)
         |<-------------- ACK -----------------|
         |                                     |
         |      (Authenticated, Unassociated)  |
         |                                     |

Security Implications
---------------------

- In 802.11b, disassociation frames are **not protected** and can be spoofed.
- Attackers can inject fake disassociation frames to disconnect users.
- Mitigation came with **802.11w / PMF**, which authenticates management frames.

Mitigation
~~~~~~~~~~

- Enable **Protected Management Frames (PMF)** where available.
- Use WPA2/WPA3 with PMF required mode.
- Ignore unprotected disassociation frames if PMF negotiated.

Implementation Guidelines
--------------------------

**Access Point (AP):**
- Transmit disassociation only when necessary (policy, timeout, etc.).
- Immediately clear AID, buffers, and per-STA queues.
- Log reason codes for debugging.

**Station (STA):**
- On receipt, clear state and notify OS.
- Reassociate or roam if AP still within ESS.
- Rate-limit reassociation attempts to avoid loops.

Debugging and Analysis
----------------------

- Capture frames using Wireshark filter:
  ``wlan.fc.type_subtype == 0x000a``
- Inspect Reason Code field.
- Check if disassociation is followed by reassociation (indicates roaming).
- Repeated disassociations with identical Reason Codes may imply DoS or configuration issues.

Common Scenarios
----------------

| Scenario | Initiator | Reason | Description |
|-----------|------------|--------|--------------|
| STA leaving | STA | 8 | STA voluntarily leaves BSS |
| Inactivity timeout | AP | 4 | STA inactive |
| Resource overload | AP | 5 | AP capacity reached |
| Power off | STA | 8 | User disables Wi-Fi |
| Policy enforcement | AP | 17 | Security/policy rule |
| Signal loss | AP | 4 | STA deemed inactive |

Summary
-------

| Concept | Description |
|----------|-------------|
| Purpose | Graceful termination of association |
| State change | Associated → Unassociated |
| Authentication | Remains valid |
| Frame protection | None in 802.11b (added in 802.11w) |
| Trigger | Inactivity, leaving BSS, policy enforcement |
| ACK | Yes, if unicast |
| Spoofable | Yes (legacy networks) |
| Remedy | Use PMF-enabled WPA2/WPA3 |

References
----------

- IEEE Std **802.11b-1999**, Clause **18.2.3.9 (Disassociation Procedure)**
- IEEE Std **802.11-2020**, Clause **9.3.3.8 (Disassociation Frame)**
- Gast, M. *802.11 Wireless Networks: The Definitive Guide*, O’Reilly
- Tanenbaum & Wetherall, *Computer Networks*, 5th Edition
- Wireshark Filter: ``wlan.fc.type_subtype == 0x000a``

Figures
-------

.. figure:: _static/disassociation_sequence.svg
   :align: center
   :alt: Disassociation exchange sequence

   Disassociation message flow between STA and AP with ACK and state transition.