doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 1 Policy Enforcement For Resources and Security 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, 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. Date: Authors:

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 2 Abstract This presentation: Identifies policy configuration points in a network architecture Presents sample solutions for enforcing policy when STA roams between APs within an ESS Security Implications

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 3 Resource Reservations STA requires additional guarantees that (QoS) resources will the there at the next AP, when it roams. Resource reservation is determined by –Application –Provider/Network policy –Network Load conditions –Network architecture STA reserves resources at 1..n candidate APs On successful roam, STA commits a reservation, at one of the APs

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 4 Why Resource Reservation Policy Resources are valuable network elements. All networks are always limited (bounded) –There are only so many to go around! Resource Reservations are important, but expensive –STA must reserve judicously –Network must ensure it’s usage policies are not being violated Reservation semantics need to be well understood and defined –What happens to outstanding reservations when a STA commits to one of the “n” APs –Cancellation of resource reservations –Expiration of reservations

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 5 Resource Policy Configuration Points (PCP) Local Policy Server AP1 2 Controller Distribution Service STA Current Association Target Association Mobility Domain PCP Light-Weight AP PCP

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 6 Limits on Reservations Reservations should be performed with constraints –A control on number and types of reservations a STA can perform Flexibility to allow AP vendor proprietary heuristics/algorithms to limit/time reservations. Latitude to the STA to determine which APs it needs to perform reservations –Resource Reservations management Over-subscription resource model for setting policy

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 7 Policy Enforcement Policy enforcement can be only partially standardized in r –Allowable reservation mechanism(s) –Over the air and/or over the DS communication between a STA and its current AP or a roaming candidate AP Frame exchanges Frame content –Allowable responses by an AP to a reservation request –Required and optional actions by a STA upon receipt of AP responses What follows is a discussion of some ways that enforcement can be accomplished

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 8 Policy Enforcement Points Reservation policy enforcement can be done at various points within a network –Depends on AP architecture, reservation messaging, network deployments –Some potential points: The current AP with which STA is associated The next AP where STA re-associates At the controller managing some Light-weight APs At any of the policy configuration points discussed earlier –Policy can be set and implemented in most types of network infrastructures If there is a central QoS/Local Policy/Authentication server, then both Light- weight and traditional APs can query for policy, before enforcing reservations

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 9 Policy Enforcement Mechanisms Number of allowed reservations –A “Counter” per STA, at Policy Configuration Points (PCPs) This “counter” can be established by Policy, or proprietary AP vendor algorithms/mechanisms –Semantics and Management occurs network-wide Enforced, preferably at the current AP Managed using a Local Policy Server, or Controller, or inter-AP communication, or other backend mechanisms On re-association, the counter is reset

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 10 Policy Enforcement Mechanisms (Contd.) Maximum resource reservation time “t” –An upper bound within which this resource must be consumed, or else, will be released –Time “t” established by Resource Policy and Security Policy E.g. – Shorter of the PMK expiration time and Resource policy time –Time “t” conveyed to STA at reservation time. STA must complete transaction (commit) within this time

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 11 Security Implications Reserve only for authenticated flows from authenticated STAs Reservations open potential for various attacks on the network –Resource flooding/exhaustion attacks –Network overload attack due to excessive backend messaging Reservations occur at specific APs, but have network- wide implications Resource Reservations require careful planning, enforcement, and deployment

doc.: IEEE /0199r0 Submission March 2005 Kapil Sood, Intel; Bob O’Hara, AirespaceSlide 12 References TAP (Transition Acceleration Proposal) 11-04/1542r0 Just-in-time 2 Phase Association 11-04/1486r0