1. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 1 Traffic Filtering and Sleep Mode 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, 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.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart@ok-brit.compatcom@ieee.org Date: 2007-07-14 Authors:

2. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 2 Abstract Aggressive power management demands long periods of low power state. Dynamic security presents issues to clients wishing to minimize their power consumption. This document describes Traffic Filtering and Sleep Mode normative text proposal (doc 11-07/2169r0) in support of the Power Saving objective, REQ2010.

3. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 3 Outline Motivation Solution Today Proposed Solution Proposed Protocol Overview Slide 3

4. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 4 Motivation Example: PC Device Power States –Awake State Host system is fully powered up and in operation mode (S0) WNIC is powered on –Sleep States All power to the CPU in the host system is shut off, and suspended to disk/RAM (S3) WNIC is powered off Aggressive power management demands long periods of low power state to extend battery life and improve energy efficiency Awake State Power is 7, 25, or 55 times the Sleep State Power.

5. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 5 The Solution Today: Client Side Filtering Saves more power than simple 802.11-1999 Power Save NIC uses Vaux while system is in S3 or lower to perform pattern matching on received frames Usually combined with 802.11-1999 Power Save Standard patterns to match: –Magic Packet pattern matching client’s L2 address (broadcast DA) –Unicast IP packets matching client’s IP address (unicast DA) Slide 5

6. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 6 But dynamic security presents issues to client filtering 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/IGTK Only the TK is shared with the NIC FIPS cryptographic boundaries must be respected Any update to key material requires OS participation! Slide 6

7. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 7 Proposed Solution: Network Assistance to allow long sleep periods AP Traffic Filtering Service (TFS) –AP is logical nexus point in network to enforce traffic filter processing –AP/Client negotiate TCLAS patterns for filtering processing –Allows general pattern matches on trigger frames by searching for patterns –Filtering may be one-shot, or until removed by client or AP Sleep Mode support –AP knows the negotiated group key update policy of the client –AP modifies packet delivery semantics for clients in sleep mode –Specific action to wake the client when a traffic filter is triggered Client may optionally request a notification frame before delivering trigger frame Slide 7

8. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 8 Advantages over Client Matching Client saves much more power! –No need to receive multicast or broadcast at all (no DTIM wakeups) –No need to receive unwanted unicast frame –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 Slide 8

9. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 9 TFS Protocol Overview AP advertises support for TFS in Wireless Network Management Capabilities IE AP/Client negotiates TFS via TFS (Sleep Mode, or Re-association) Request and Response frames –Client can add traffic 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) AP Operations –AP inspects unicast and multicast traffic on behalf of client which installed filter. –AP discards unmatched unicast traffic regardless of power states when TFS is enabled –TFS Notify frame is delivered before the triggering frame if requested by the client Slide 9

10. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 10 TFS Request IE Client delivers filtering patterns to AP via TFS Request IEs Slide 10 Element IDLengthTFS IDTFS Action Code TFS Subelement Count TFS Subelements Octets:11111 variable Subelement IDLengthTCLAS Elements TCLAS Processing Element Octets:11variable3 Bit 0Deleteindicates whether the traffic filter is to be deleted when a frame matches the traffic filter. Bit 1Notifyindicates whether the STA is to be sent a TFS Notify frame when a frame matches the traffic filter.

11. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 11 TFS Response IE Slide 11 AP replies with TFS Response IEs Element IDLengthTFS Status Subelements Octets:11N x 2 TSF Response StatusTFS ID Octets:11 ValueDescription 0Accept 1Denied due to malformed request or ambiguous classifier 2Denied due to lack of resources on AP 3Denied due to requested classifier(s) matching 2 or more existing traffic triggers 4Denied. By policy, requested traffic filter is not permitted to participate in TFS 5Overridden due to policy limits on AP 6Denied. AP is unable to perform the requested action 7Overridden due to alternate or duplicate traffic filter set on AP 8-255Reserved

12. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 12 Sleep Mode Protocol Overview AP advertises support for Sleep Mode in Wireless Network Management Capabilities IE AP advertise GTK/IGTK update policy in RSN IE in beacons, probe responses and 4WHS –GTK/IGTK may or may not be updated by AP when client in Sleep Mode AP/Client negotiate Sleep Mode operation via Sleep Mode (or Re-association) Request and Response frames –AP/STA may include TFS Request/Response IE in Sleep Mode Request/Response frames to set up traffic filtering pattern for the sleep mode client –TFS Notify or Triggering frame delivered using standard TIM-based PS operation while client is in Sleep Mode Slide 12

13. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 13 Sleep Mode IE Used for AP/Client negotiate Sleep Mode Operations Slide 13 Element ID LengthAction TypeSleep Mode Response Status Update Policy Sleep Interval Octets:111111 Enter Sleep Mode0 Exit Sleep Mode1 ValueDescription (valid only in Response frame) 0Enter/Exit Sleep Mode Accept 1Denied. AP is unable to perform the requested action 2Denied temporarily. The AP is unable to perform the requested action at the current time. The request can be submitted again at a later time. 3Exit Sleep Mode Accept, GTK/IGTK update required Bit 1 GTK/I GTK Update Policy indicates whether the AP will suppress GTK/IGTK updates to STAs that are in Sleep Mode.

14. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 14 PTK/GTK/IGTK Updates in Sleep Mode Sleep Mode Client shall always wake up for PTK update –When an AP establishes any filters for a requesting STA, the AP shall always establish a traffic filter that matches unicast EAPOL-Key messages addressed to the requesting STA, with bits 0 and 1 of the TFS Action Code field set to 0. If GTK/IGTK Update is not required for Sleep Mode client, AP shall not require a client to participate in group key updates –When client exits from Sleep Mode and the GTK/IGTK which the client currently holds is invalid, AP shall initiate a GTK/IGTK update to the client. Since AP is filtering traffic, client need only wait for AP notification of successful pattern match, disassociation, etc. Slide 14

15. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 15 Sleep Mode with TFS Procedure - Example ClientAP Sleep Mode Request {Sleep Mode IE (enter), TFS Request IEs} Frame 1 Frame n Trigger frame (matched with filter pattern) Beacons (the corresponding TIM bit is set) TFS Notify {TFS ID} if required GTK/IGTK update messages if required       Beacon {RSN IE (Capabilties.SM-GTKU-Policy), WNM capabilities IE (TFS bit, Sleep Mode bit)} Sleep Mode Response {Sleep Mode IE (enter), TFS Response IEs} Beacons {the corresponding TIM bit is set} Client enters Sleep Mode AP sets up traffic filter, group key update policy, and maintains association states for the sleep mode client Traffic is matched with filter pattern, AP to wake up Sleep Mode client. Client exits Sleep Mode Sleep Mode Request {Sleep Mode IE (exit sleep mode)} Sleep Mode Response {Sleep Mode IE (exit sleep mode)}       PS-Poll Trigger frame

16. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 16 Reference 11-07-0730-00 “Sleep Mode with AP Filtering”, by Hayes et al 11-07-0260-02 “Wake-on WLAN”, by Qi et al Slide 16

17. doc.: IEEE 802.11-07/2148r0 Submission July 2007 Emily Qi (Intel Corp) et alSlide 17 Thank You! & Questions? Slide 17