1. Sleep Mode with AP Filtering
Month Year
doc.: IEEE yy/xxxxr0
May 2007
Sleep Mode with AP Filtering
Authors:
Date:
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
K. Hayes, M. Smith
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
May 2007
Abstract
Aggressive power management demands long periods of low power state. Dynamic security presents issues to clients wishing to minimize their power consumption. We present two simple protocols for infrastructure assistance to allow long sleep periods by clients.
K. Hayes, M. Smith
John Doe, Some Company

3. May 2007
Client side filtering
Saves more power than simple PowerSave
NIC uses Vaux while system is in S3 or lower to perform pattern matching on received frames
Standard patterns to match:
Magic Packet pattern matching client’s L2 address (broadcast DA)
Unicast IP packets matching client’s IP address (unicast DA)
Usually combined with PowerSave
K. Hayes, M. Smith

4. But dynamic security presents issues to client filtering
May 2007
But dynamic security presents issues to client filtering
Pairwise and group key updates must be tracked
Security protocol acknowledgements must be MIC’d
OS is the container of all of the following keys: MK
PMK
PTK {KCK, KEK}
GTK
Only the TK is shared with the NIC
FIPS cryptographic boundaries must be respected
Any update to key material requires OS participation!
K. Hayes, M. Smith

5. How can infrastructure help?
May 2007
How can infrastructure help?
Traffic Filtering support
General classification strategy
Allows general pattern matches on trigger frames by searching for patterns
Allows general actions to be taken when match occurs
Filtering may be one-shot, or until removed by client or AP
Executed by infrastructure
Sleep Mode support
Specific action to wake the client when a filter is triggered
Trigger frame delivered using standard mechanisms
Client may optionally request a notification frame before the trigger frame
K. Hayes, M. Smith

6. Advantages over Client Matching
May 2007
Advantages over Client Matching
Client saves much more power!
No need to receive multicast or broadcast at all (no DTIM wakeups)
Only required to receive unicast wakeup management frame
Sleep Mode security state simplified on client
No key rotation support required during Sleep Mode
No need to expand cryptographic boundary
No need for OS API to provide more key material to NIC
AP saves airtime of frames which would be dropped by client
K. Hayes, M. Smith

7. AP Filtering Offload filtering function to AP
May 2007
AP Filtering
Offload filtering function to AP
AP is logical nexus point in network to enforce filter processing
Client delivers TCLAS patterns to AP via management action frame
AP knows the negotiated security state of the client
AP modifies packet delivery semantics for clients in sleep mode
AP processing load bounded
Unicast frames require only lookup of client’s Sleep Mode state and pattern matching for frames destined for client. Number of these frames should be small as client is sleeping/hibernating
Multicast/broadcast data frames are usually infrequent and carry no burden of retry
K. Hayes, M. Smith

8. Filtering Negotiation and Management
May 2007
Filtering Negotiation and Management
AP advertises support for Filtering in Network Management Capabilities
Client can add filters any time after association (non-RSN) or key establishment (RSN)
Client can delete filters at any time
AP may delete filters if it executes the filter action (e.g. wakeup) first
K. Hayes, M. Smith

9. May 2007
Filtering Protocol
Client delivers filtering patterns to AP with Traffic Filter Request
Management action frame specifying TCLAS pattern, ID, action code, and recurrence code
Filter Action code definitions: 8 bits (see Sleep Mode protocol for example)
Recurrence code definitions: 0 = delete filter on trigger, 1 = do not delete filter on trigger
Room for ~32 filters in single management action frame
AP replies with Traffic Filter Response
Could reject filter for various reasons such as out of filtering resources, etc.
K. Hayes, M. Smith

10. May 2007
Filtering Protocol (2)
AP inspects unicast and multicast traffic on behalf of client which installed filter
When trigger occurs, AP executes action specified by action code (send notification or not)
AP deletes filter if recurrence code = 0
K. Hayes, M. Smith

11. May 2007
Sleep Mode Protocol
AP advertises Sleep Mode support and GTK and PTK update policy in RSN IE in beacons, probe responses and 4WHS
Both GTK and PTK may or may not be updated by AP when client in Sleep Mode
Client uses Filter Protocol to set up Sleep Mode
Following filter action codes shall specify AP action when filter is triggered:
0x00 – null action
0x01 – send notification frame
Notification frames precede unicast triggering frames. No such guarantee for multicast triggering frames.
K. Hayes, M. Smith

12. Sleep Mode Protocol (2) Client sends MAF to request Sleep Mode entry
May 2007
Sleep Mode Protocol (2)
Client sends MAF to request Sleep Mode entry
STA sends its GTK and PTK capability as Sleep Mode Property
0x0 = Do not update any keys while in Sleep Mode
0x1 = Allow update of PTK while in Sleep Mode
0x2 = Allow update of GTK while in Sleep Mode
0x3 = Allow update of all keys while in Sleep Mode
AP sends MAF containing Sleep Mode response
Can reject for various reasons, including policy mismatch of GTK or PTK update
K. Hayes, M. Smith

13. Sleep Mode Protocol (3) AP detects pattern match:
May 2007
Sleep Mode Protocol (3)
AP detects pattern match:
If Filter Action = 1, transmit notification MAF
Filter ID is included in notification
Triggering frame then delivered using standard TIM-based PS operation
NIC wakes system and (re)associates with AP
NIC or host may also wake system for outbound traffic or any other reason
K. Hayes, M. Smith

14. AP Filtering Protocol May 2007
Beacon {RSN IE (Capabilities.SM-PTKU-Policy, Capabilties.SM-GTKU-Policy)} AP
STA
Filter Add {ID, TCLAS, Action, Recurrence}
Sleep Mode Request
Frame 1
Sleep Mode Response
Frame n
Trigger frame
TIM bit set in next beacon
Sleep Mode Wakeup frame {Filter ID}
Trigger frame
Re-association Request
K. Hayes, M. Smith

15. May 2007
Security model of Sleep Mode Property when PTK or GTK update not required
During Sleep Mode:
AP shall not require a client to participate in pairwise or group key updates
AP shall drop any non-null data frames from client
AP shall not deliver any data frames to client
Since AP is filtering traffic, client need only wait for AP notification of successful pattern match, disassociation, etc.
K. Hayes, M. Smith

16. Next Steps Interested people contact authors
Create normative text between now and July
Target motion in July

17. May 2007
Questions?
K. Hayes, M. Smith

18. Sleep Mode State Machine
May 2007
Add filter
Delete filter
Awake, no filter installed
Awake, filter set, S1, D1
Sleep mode response received from AP
Wakeup, Recurrence = 0
STA Sleep mode request ???
wakeup, Recurrence = 1
wakeup
Sleep with no filter, S3, D3
Sleep with filter, S3, D3
S3 – suspend to RAM
D3 – device powered off
K. Hayes, M. Smith