Sleep Mode with AP Filtering Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2007 Sleep Mode with AP Filtering Authors: Date: 2007-05-14 Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 stuart@ok-brit.com 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. K. Hayes, M. Smith John Doe, Some Company

Month Year doc.: IEEE 802.11-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

May 2007 Client side filtering Saves more power than simple 802.11-1999 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 802.11-1999 PowerSave K. Hayes, M. Smith

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

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 802.11 mechanisms Client may optionally request a notification frame before the trigger frame K. Hayes, M. Smith

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

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 802.11 retry K. Hayes, M. Smith

Filtering Negotiation and Management May 2007 Filtering Negotiation and Management AP advertises support for Filtering in 802.11 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

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

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

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

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

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

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

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

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

May 2007 Questions? K. Hayes, M. Smith

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