1. Policy Enforcement For Resources and Security
Month Year
doc.: IEEE yy/xxxxr0
March 2005
Policy Enforcement For Resources and Security
Date:
Authors:
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
Kapil Sood, Intel; Bob O’Hara, Airespace
John Doe, Some Company

2. Abstract This presentation:
Month Year
doc.: IEEE yy/xxxxr0
March 2005
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
Kapil Sood, Intel; Bob O’Hara, Airespace
John Doe, Some Company

3. Resource Reservations
March 2005
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 one or more candidate APs
On successful roam, STA commits a reservation, at one of the APs
Kapil Sood, Intel; Bob O’Hara, Airespace

4. Why Resource Reservation Policy
March 2005
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 judiciously
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 APs
Cancellation of outstanding reservations
Expiration of reservations
Kapil Sood, Intel; Bob O’Hara, Airespace

5. Resource Policy Configuration Points (PCP)
March 2005
Resource Policy Configuration Points (PCP)
PCP
Local Policy Server
Distribution
Service
PCP
PCP
PCP
Mobility Domain
Controller AP 1 AP 2
Light-Weight AP
Light-Weight AP
Current
Target
Association
Association
STA
Kapil Sood, Intel; Bob O’Hara, Airespace

6. Limits on Reservations
March 2005
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
Resource Reservation policy can be partially standardized on r
Kapil Sood, Intel; Bob O’Hara, Airespace

7. Policy Enforcement Resource pre-allocation steps:
March 2005
Policy Enforcement
Resource pre-allocation steps:
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
Accept/Deny/Come-back-later and time for allocation
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
Kapil Sood, Intel; Bob O’Hara, Airespace

8. Policy Enforcement Mechanisms
March 2005
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
Kapil Sood, Intel; Bob O’Hara, Airespace

9. Policy Enforcement Mechanisms (Contd.)
March 2005
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
And, there are proprietary backend mechanisms that allow vendor differentiation
Kapil Sood, Intel; Bob O’Hara, Airespace

10. Security Implications
March 2005
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
Kapil Sood, Intel; Bob O’Hara, Airespace

11. References TAP (Transition Acceleration Proposal) 11-04/1542r0
March 2005
References
TAP (Transition Acceleration Proposal) 11-04/1542r0
Just-in-time 2 Phase Association 11-04/1486r2
Kapil Sood, Intel; Bob O’Hara, Airespace