1. Just-In-Time 2 Phase Association TGr Proposal for Fast BSS Transitions
October 2004
Just-In-Time 2 Phase Association TGr Proposal for Fast BSS Transitions
Editors:
Kapil Sood
Mike Montemurro
N. Cam-Winget, et al

2. Contributors Nancy Cam-Winget, Rajneesh Kumar - Cisco Systems
October 2004
Contributors
Nancy Cam-Winget, Rajneesh Kumar - Cisco Systems
Kapil Sood, Jesse Walker, Emily Qi - Intel Corporation
Michael Montemurro - Chantry Networks
Chris Durand, Keith Amann - Spectralink
Mike Moreton, Paul Newton - ST Microelectronics
Randy Chou - Aruba Networks
Florent Bersani - France Telecom
Artur Zaks - Texas Instruments
N. Cam-Winget, et al

3. October 2004
Proposal and PAR
The TGr PAR document contains the following text (Section 18 in reference to Section 12):
“The scope of modifications is during the STA transfer from one AP to another (BSS transition). Determination of the need for a BSS transition, selection of which AP to BSS transition to (with the exception of the advertisement of the availability of fast BSS transition services to the STA), and determination of when to BSS transition are all outside the scope of this project. As a design criteria, the proposed mechanism must accomplish this goal without compromising security or existing Station services”
Presumes that STA can use the TGe and TGk to provide high confidence for resource availability.
Scanning time and “which AP” decision is out of scope.
N. Cam-Winget, et al

4. Proposal Outline Lightly Loaded Network: Just-In-Time Reassociation
October 2004
Proposal Outline
Lightly Loaded Network: Just-In-Time Reassociation
Addressing Congestion: Query + Just-in-Time Reassociation
Congestion Peaks and Slow Backends: Pre- Reservation + Just-in-Time Reassociation
N. Cam-Winget, et al

5. Motivation Systems adapt to current loading
October 2004
Motivation
Systems adapt to current loading
Systems pay for only the level of service required
Just-In-Time (JIT) Association
Address the “90%” case:
The next AP will be lightly loaded
The STA can tell this from Beacons/Probe Responses
Query + Just-in-Time Association
Address the “90%” of the other cases
The next AP is fairly heavily loaded but transitions are infrequent
Pre-Reservation + Just-in-Time Association
Address the rest of the cases
Infrastructure is under-provisioned or the back-end is slow
Provider wants to offer guaranteed service
JIT always backs up other mechanisms
N. Cam-Winget, et al

6. Just-in-Time (JIT) Re-Association
October 2004
Just-in-Time (JIT) Re-Association
N. Cam-Winget, et al

7. October 2004
Why Confidence in JIT?
TGk neighbor reports assist in optimizing scanning
AP conveys QBSS IE in Probe responses/beacons
QBSS IE has three fields
STA count, channel utilization, and available admission capacity.
QBSS provides next AP’s head-room for new traffic.
In properly engineered networks, most APs are not fully loaded, most of the time
If STA acts promptly, resources won’t disappear at next AP
N. Cam-Winget, et al

8. QoS during JIT re-association
October 2004
QoS during JIT re-association
If the STA has admitted Traffics Streams, the next AP ought to reaffirm the “QoS bandwidth needs” that the current AP is providing the STA
The STA sends new AP IEs found in ADDTS request (11e) such as TSPEC IE, TCLAS IE for each TS.
If STA does not require QoS re-affirmation
Then, 11e IEs not sent
N. Cam-Winget, et al

9. JIT Operational Messaging
October 2004
JIT Operational Messaging
JIT messaging between STA and APnext
Re-Association Requests/Response messages:
convey one or more Action IEs, such as a TSPEC, TCLAS
A Reassociation Response may indicate:
Acceptance/Rejection of TSPEC, suggested TSPEC
MIC across entire message
Re-Association Rejected or Response missing
Status codes reflect resource allocation failures
STA free to roam to a different AP
New frames sizes in this proposal
Fit 2K payload; Even fits 1500 Bytes Ethernet
N. Cam-Winget, et al

10. Just-In-Time Re-association
October 2004
Just-In-Time Re-association
Authenticator
Next AP
STA
Supplicant
STA determines next AP for roam, Get PMKID
Builds a list of TSPECs, TCLAS, etc.
Increments ANONCE, generates new PTKi,
Generate 802.1X Optimized 4-way Message #2
Reassociate Request( TSPEC IE’s, EAPOL-Key 4-way Message #2)
Next AP validates TSPECs and ANONCE
Generates new PTK validate EAPOL-Key 4-way Message #2
Generates TSPECs in response; Allocate resources
Generate Optimized EAPOL-Key 4-way Message #3
Reassociate Response( TSPEC IE’s, EAPOL-Key 4-way Message #3)
STA validates Message #3
EAPOL-Key 4-way Message #4
802.1X port unblocked: Client and AP can now protect data packets
N. Cam-Winget, et al

11. AP-transition timeline for JIT
October 2004
AP-transition timeline for JIT
Current communications (incl i)
Transition decision point
Data resumes
Just-In-Time:
Data
Probe
Reassoc Req
4WH M4
ADDTS req
Probe Resp
Reassoc Resp
ADDTS resp
Open sys auth req
4WH M2
Open sys auth resp
4WH M3
N. Cam-Winget, et al

12. Summary thus far… “Just-in-Time” mechanism enables the means to:
October 2004
Summary thus far…
“Just-in-Time” mechanism enables the means to:
Minimize “over the air” latency by piggybacking resource allocation
Minimize PTK computation and plumbing latencies by enabling the STA to pre-compute prior to re-association
Enable “Authenticated” re-association exchange
Removes the i 4-way handshake race conditions
Allocation of QoS resource at re-association time
N. Cam-Winget, et al

13. Query + Just-in-Time Pre-Reservation + Just-in-Time
October 2004
Query + Just-in-Time Pre-Reservation + Just-in-Time
N. Cam-Winget, et al

14. Motivations Query Mechanism: Reservation Mechanism:
October 2004
Motivations
Query Mechanism:
Just-in-Time (JIT) preceded with a Query phase
Improve STA transition under high network load conditions
QBSS information may not be good enough
Reservation Mechanism:
Phase 1 of 2 phase commit; JIT is phase 2
Used under loading spikes
QBSS/Query fail only when all neighboring APs near load limit or
By policy because backend too slow to respond to JIT
Used when dictated by operator policy
Pre-reservation is costly and must be used judiciously
Backend co-ordination defined to prevent resource reservation attacks
N. Cam-Winget, et al

15. Extended JIT Operation
October 2004
Extended JIT Operation
“Policy” can enable a 2 phase re-association
Phase 1 involves a
Query, or
Reservation, or
Query followed by reservation
Phase 2 commits phase 1 using JIT mechanism
STA executes phase 1 while associated with APcurrent
If phase 1 fails, STA can fall back to JIT!
N. Cam-Winget, et al

16. Query Mechanism STA initiates phase 1 Query mechanism
October 2004
Query Mechanism
STA initiates phase 1 Query mechanism
Over the air with APnext
Query request for:
TSPEC availability
PMK availability
Query response is:
Resources Available (incl. suggested TSPECs)
Resource Not Available
STA may continue “query” until it gets “Available”; or finds next AP
N. Cam-Winget, et al

17. Query Mechanism Flow October 2004
STA
Authenticator
Next AP
Supplicant
STA determines potential next AP for roam
STA requires assurances for QoS resources: composes TSPECs, TCLAS etc
STA requires assurances for PMKSA: composes PMKID request
STA composes a Resource Request and transmits to next AP
Resource Request ( TSPEC IEs, PMKID Request)
Next AP determines if STA is authorized to have QoS and/or PMKSA
If STA is authorized and additional assurance information available
then
AP responds Available
else
AP responds Not Available
Resource Response ( TSPEC IEs, PMKID Response)
If STA decides to re-associate
Then
STA performs JIT mechanism with next AP
Else
STA continues looking for other potential APs
N. Cam-Winget, et al

18. October 2004
AP-transition timeline for Phase 1 (Query / Reservation) followed by JIT
Current communications (incl i)
Transition decision point
Data resumes
Phase 1:
Query/Reservation in parallel with STA  APcurrent communication
JIT:
Probe
Reassoc Req
4WH M4
ADDTS req
Probe Resp
Reassoc Resp
ADDTS resp
Open sys auth req
4WH M2
Resource Req
Open sys auth resp
4WH M3
Data
Resource Resp
Note: Dotted arrows denote multiple request/response
N. Cam-Winget, et al

19. Resource Query Mechanism over the Air
October 2004
Resource Query Mechanism over the Air
STA may initiate Resource Query over the air:
AP may respond to query by advising STA of QoS and PMK availability, without any pre-allocation
Unprotected best effort exchange
Resource Request message is a next Action Frame
STA must stay on next AP’s channel to obtain response for this to work
N. Cam-Winget, et al

20. Reservation Mechanism
October 2004
Reservation Mechanism
STA initiates phase 1 pre-reservation mechanism
STA  APcurrent  DS  APnext
Reservation Phase Response
Resources pre-allocated for a time period, t
Is configurable
Suggest Resources available (eg. suggested TSPECs)
Resources Not Available
If STA performs a successful reservation phase, then policy permits STA perform “n” reservations
Upcoming backend enforcement protocol as recommended practice
N. Cam-Winget, et al

21. Resource Reservation STA initiates Resource Request over current AP:
October 2004
Resource Reservation
STA initiates Resource Request over current AP:
Resource Request embedded in action frame format sent as a data frame protected by current AP channel
New Ether-Type transport
Backend may throttle the request if STA has spent it’s reservation limit
STA continues data flow with current AP
STA can choose to wait for Resource Response, or initiate new one
N. Cam-Winget, et al

22. Reservation Mechanism Flow
October 2004
Reservation Mechanism Flow
STA
Authenticator
Current AP
Authenticator
Next AP
Supplicant
STA determines potential next AP for roam
STA requires assurances for QoS resources: composes TSPECs, TCLAS etc
STA requires assurances for PMKSA: composes PMKID request
STA composes a Resource Request and transmits to current AP
Current AP will transmit request to backend for reservation
Resource Request ( TSPEC IEs, PMKID Request)
Next AP determines if STA is authorized to reserver QoS and/or PMKSA
Current AP sends message to STA over same channel
If STA is authorized and reservation succeeded
then
AP responds Reserved for time “t”
else
AP responds Not Available
Backend Resource Reservation Protocol
Resource Response ( TSPEC IEs, PMKID Response)
If STA decides to re-associate
Then
STA performs JIT mechanism with next AP
Else
STA continues looking for other potential APs
STA may not pre-allocate resources at more than “n” APs
N. Cam-Winget, et al

23. Backend Considerations
October 2004
Backend Considerations
Back-end out-of-scope but must be considered to:
understand security
address PMK optimizations
address performance optimizations that require back-end
address Phase 1 reservation mechanism
N. Cam-Winget, et al

24. Backend Framework Requirements
October 2004
Backend Framework Requirements
Get the correct PMKs at roam time, at each AP and STA
JIT and 2-Phase association mechanisms can work with any backend key management model
802.11i pre-authentication
Proprietary means
Upcoming recommended practices
Deliver QoS policy to AP
N. Cam-Winget, et al

25. Recommended Practice proposal for Backend
October 2004
Recommended Practice proposal for Backend
Recommended Practice introduces:
Local Policy Server
As a logical, not a physical concept
May be stand-alone server
May be embedded in a switch controller
May be embedded in a classical AP
Always resides on the LAN local to the AP consuming its services
New Key Hierarchy
Enables PMK provisioning (obviates full EAP authentication with AS)
PMK Provisioning protocol to be documented as an Internet Draft/RFC
N. Cam-Winget, et al

26. Local Policy Server (LPS)
October 2004
Local Policy Server (LPS)
LPS can enable
Use of a new key hierarchy to obviate need for full 802.1X EAP authentication
Policy enforcement for different resource allocation mechanisms
LPS and APs can communicate using RADIUS extensions/DIAMETER
Enable PMK provisioning
Enable resource requests
Recommended practice: Build on top of existing mechanisms
N. Cam-Winget, et al

27. Conclusion Flexible scheme for all deployments
October 2004
Conclusion
Flexible scheme for all deployments
JIT: Lightweight scheme to address “normal” networks
Query + JIT: To deal with congestion spikes
Reservation + JIT: For saturated networks; slow network backends; In response to policy
Suitable for all environments
Home
SoHo
Enterprise
Operator
N. Cam-Winget, et al

28. October 2004
Backup: Details
N. Cam-Winget, et al

29. October 2004
Addressing QoS
Ensure that the STA can maintain its QoS streams when it roams to a new AP -- with the same or freshly negotiated QoS params.
Ensure that the next AP can deliver the negotiated QoS for the STA
Mechanisms to help us achieve this:
“QBSS element” in the probe responses and beacons can help STA determine which AP has the higher probability of meeting it’s QoS requirements.
The re-association request contains a ADDTS like request that contains TSPECs, thus conveying traffic specs of Streams that need QoS from the next AP.
The successful re-association response with ADDTS like response containing TSPECs indicates that the next AP is ready to provide the QoS Specified in TSPECs.
N. Cam-Winget, et al

30. October 2004
QoS Mechanism Details
(Re-)Association Requests/Responses convey IEs that are found in QoS Action Message (11e)
Requests contains a TSPECs(s) that specify the QoS characteristics of the TS(s) in question.
We embed the set of TSPEC IEs in Reassociation Requests to request traffic streams from the AP.
We embed the set of TSPEC IEs in the Reassociation Responses so the AP can respond to each TSPEC with medium time granted.
A reassociation response may indicate it
Accepts the STA’s request; the TSPECs have been accepted
Convey that one or more TSPEC has been “rejected” by way of a special Status code.
Include a “suggested TSPEC” from the AP.
This permits TSPEC parameter negotiation
N. Cam-Winget, et al

31. JIT: Action IE Piggybacking on Re-Association
October 2004
JIT: Action IE Piggybacking on Re-Association
Requirements:
Support for any ADDTS/action like request
Allow for multiple TSs within the mechanism
Requests should be Protected in a secure environment
Solution:
Create an envelope around the QoS related IEs – TSPEC, TCLAS, etc
Heading IE lists the number of these IEs
Trailing IE is the EAPoL-Key message and the MIC (calculated on all IE’s from Header IE to the Trailer IE)
Allows for future requirements (802.11k, s, etc.)
N. Cam-Winget, et al

32. Fast BSS-Transition Advertisement
October 2004
Fast BSS-Transition Advertisement
Fast BSS-Transitions involves QoS, RSN, or both
In the future, there may be a requirement to set up other kinds of state on re-association
Want to advertise Fast BSS-Transition in the Beacon, Probe, Re-association exchanges, TGk neighbour report
Use the Capabilities Exchange
Use extended capability IE (64-bit) to advertise
N. Cam-Winget, et al

33. Security Aspects for JIT
October 2004
Security Aspects for JIT
DoS attacks not worse than i
Works with i and new key hierarchies
Pre-compute PTK on the STA prior to Re-Association
Security association liveness and GTK at re-association
Protocol updates:
Eliminate 4-Way Handshake Msg 1 by making ANonce predictable for AP-to-AP transition
Embed 4-Way Handshake Msg 2 in Re-Association Request
Embed 4-Way Handshake Msg 3 in Re-Association Response
N. Cam-Winget, et al

34. ANonce Computation Algorithm
October 2004
ANonce Computation Algorithm 2 1
Association: (1st Time)
ANonce  Initialized (random)
Cache ANonce with (STA, BSSID, PMKID, PMK)
Association:
ANoncen  AP1 (random) for n = 0
Cache ANonce0 with (BSSID, PMKID, PMK)
Client STA
Authenticator
AP1 6 4
Supplicant
Provisioned PMK: (1st Time)
ANonce  Initialized to 0
Cache ANonce with (STA, BSSID, PMKID, PMK)
Everytime Ready to Roam:
ANoncen  ANoncen–1 + 1 for ANoncen–1 saved with (BSSID, PMKID, PMK)
Replace saved ANoncen–1 with ANoncen
Pre-compute PTK
Client STA
Authenticator
AP2
Supplicant 5
Re-Association:
Want: ANonce < ANoncen
If (ANonce(STA, BSSID, PMKId) AND
(ANonce = ANoncen (STA, BSSID, PMKId))
then reject re-association request
else
attempt reassociation
If reassociation succeeds, update cached ANonce to ANoncen 3
1st Re-Association with a next AP2:
STA selects any ANoncen for n = 0 and sends ANoncen sent to AP2
Cache ANonce0 with (BSSID, PMKID, PMK)
N. Cam-Winget, et al

35. STA ANonce Algorithm If (association) Get ANoncei from APfirst
October 2004
STA ANonce Algorithm
If (association)
Get ANoncei from APfirst
If 4-Way Handshake succeeds, then Cache <BSSID, STA-MAC-Addr, PMKID, PMK, ANoncei>
If (re-association)
if (no ANonce for this BSSID)
ANoncej = 1 for this BSSID
if (ANoncei exists for this BSSID)
ANoncej = ANoncei + 1 (monotonically increasing Counter)
Send ANoncej to APnext
If Optimized 4-Way Handshake succeeds then Cache <BSSID, STA-MAC-Addr, PMKID, PMK, ANoncej>
STA will save and increment (counter) ANonce for each BSSID
BSSID specific ANonce increment will be sent for subsequent reassociations to that AP
If ANonce rolls over (i.e., 2256 – 1  0), provision a new PMK
If STA initializes (reboots), empty cache and start over
N. Cam-Winget, et al

36. AP ANonce Algorithm If (association) Choose ANoncei randomly
October 2004
AP ANonce Algorithm
If (association)
Choose ANoncei randomly
Send ANoncei from APfirst to STA.
If 4-Way Handshake succeeds, then cache with <BSSID, STA-MAC-Addr, PMKID, PMK, ANoncei>
If (re-association and PMKID is cached)
If PMK but no ANonce cached for this STA
Cache <BSSID, STA-MAC-Addr, PMKID, PMK, ANonce> with ANonce = 0
Get ANoncej from STA
If (ANonce  ANoncej) then reject reassociation request
If Optimized 4-Way Handshake succeeds then Cache <BSSID, STA-MAC-Addr, PMKID, PMK, ANoncei>
Else If (reassociation and PMKID is not cached)
Force STA to do a full 802.1X authentication and 4-Way Handshake
AP caches most recent ANonce value from STA that reassociated with that AP
ANonce is unique for (STA, BSSID, PMKID)
If AP (Authenticator) initializes (reboots), empty cache and start over
N. Cam-Winget, et al

37. Recovery from Crashes If STA crashes: If AP crashes:
October 2004
Recovery from Crashes
If STA crashes:
STA loses its volatile state, including all <BSSID, STA-MAC-Addr, PMK, PMKID, ANonce> values
STA associates and authenticates with 1st AP to get a new <BSSID, STA-MAC-Addr, PMK, PMKID, ANonce> value
On a roam, if AP has new PMKID, then it has initialized its state to ANonce = 0 (if STA 1st associated with a different AP), or ANonce set by association (if STA 1st associated with this AP)
On a roam, if AP doesn’t have new PMKID, then AP will force STA to do full authentication.
If AP crashes:
AP loses its volatile state, so can’t support fast roam until it is updated by the AS (either as a side effect of authentication or by some other mechanism)
N. Cam-Winget, et al

38. October 2004
Recovery Notes
If STA wants to do a full authentication, then it omits the EAPOL-Key information element from its Reassociation Request (don’t break backward compatibility)
The optimized 4-Way Handshake assumes the PMKs at different APs are cryptographically independent (just like the normal 4-Way Handshake)
N. Cam-Winget, et al

39. October 2004
Vs EAPOL-Key Message
In Phase 2, 3rd message: STA -> AP, Should a new management message be introduced, or use EAPOL-Key 4-way message #4?
Management Message:
Uniform treatment for securing mgmt frames
EAPOL-Key Message:
Additional messages (beyond re-assoc req/resp) is new paradigm for system/IDS/firewall troubleshooting
Just for signaling to unblock the port
Modify current state m/c for EAPOL-Key message in new context
Conclusion: Keep EAPOL-Key Message in JIT
N. Cam-Winget, et al

40. October 2004
Inserting 802.1X in
802.1X EAPOL Key Frame (Message 2 and 3) are embedded into Reassociation Request and Response in new IE
Element ID
Length
Data
TBD
802.1X packet length
802.1X EAPOL Key frame
N. Cam-Winget, et al

41. Reassociation Request
October 2004
Reassociation Request
Order
Information
Notes 1
Capability 2
Listen interval 3
Current AP address 4
SSID 5
Supported rates 6
Extended Supported Rates 7
Power Capability 8
Supported Channels 9
Action IE List
Lists the number of Action IEs 10
Action Frame Request IE’s
A set of IE’s describing the Action Request, e.g TSPEC, TCLAS IEs …
10+n+1
EAPoL_Key (msg 2)
EAPoL Message #2; MIC calculated across Action Frame List IE to EAPol-Key message
N. Cam-Winget, et al

42. Reassociation Response
October 2004
Reassociation Response
Order
Information
Notes 1
Capability 2
Status code 3
AID 4
Supported rates 5
Extended Supported Rates 6
Action IE List
Specifies the number of action frames 7
Action Response IE’s – response 1
A set of Action Response IE’s to be evaluated by the STA. e.g TSPEC, TCLAS IEs …
7+n+1
EAPoL_Key (msg 3)
EAPoL Message #3; MIC calculated across Action Frame List IE to EAPol-Key message
N. Cam-Winget, et al

43. Action IE List Element ID = TBD
October 2004
Action IE List
Element ID
Length
Number of
IEs 1
Octets:
Element ID = TBD
Number of Action IEs – The number of IEs in the re-association request. The IEs are the ones that generally go into various action frames.
N. Cam-Winget, et al

44. October 2004
Action IE Elements
There is a set of request/response IE’s in each individual re-association request/response
The number of IE elements is limited to the maximum size of a MAC Management PDU.
N. Cam-Winget, et al

45. 4-way Handshake Optimized Message 2
October 2004
4-way Handshake Optimized Message 2
Key Descriptor Type (1 octet)
Key Information (2 octets)
Key Length (2 octets)
Key Replay Counter (8 octets)
SNonce (32 octets)
Key MIC (16 octets)
Key Data Length (2 octets)
RSN IE, PMKID, ANonce
N. Cam-Winget, et al

46. 4-way Handshake Optimized Message 3
October 2004
4-way Handshake Optimized Message 3
Key Descriptor Type (1 octet)
Key Information (2 octets)
Key Length (2 octets)
Key Replay Counter (8 octets)
ANonce (32 octets)
Key MIC (16 octets)
Key Data Length (2 octets)
RSN IE, GTK, AP-Challenge
N. Cam-Winget, et al

47. 4-way Handshake Optimized Message 4
October 2004
4-way Handshake Optimized Message 4
Key Descriptor Type (1 octet)
Key Information (2 octets)
Key Length (2 octets)
Key Replay Counter (8 octets)
Key MIC (16 octets)
Key Data Length (2 octets)
AP-Challenge
N. Cam-Winget, et al

48. New Action Frames for Resource Request
October 2004
New Action Frames for Resource Request
Action Field Value
Meaning
Resource Request 1
Resource Response
2-255
Reserved
N. Cam-Winget, et al

49. New Resource Request Action Frame
October 2004
New Resource Request Action Frame
Order
Size
(octets)
Information 1
Category must be ‘TBD” for TGr 2
Action field value: must be 0x00 3 6
New BSSID 4
Action IEs Count
5 ….n
variable
(IE count) Requesting Action IEs
1 Requesting Action IE include IEs like TSPEC, TCLAS and PMKID requests
N. Cam-Winget, et al

50. New Resource Response Action Frame
October 2004
New Resource Response Action Frame
Order
Size
(octets)
Information 1
Category must be ‘TBD’ for TGr 2
Action field value: must be 0x01 3 6
New BSSID 4
Action Frame Number (= n) 5
Status
Pre-allocation expiry time: if resources are allocated, those will be available for m milliseconds
7 …. n+2
variable
(IE count) Responding Action IE
1 Requesting Action IE include IEs like TSPEC, TCLAS and PMKID requests
N. Cam-Winget, et al

51. Status Codes on Resource Response
October 2004
Status Codes on Resource Response
Status Field Value
Meaning
Resource Request Successful but no reservation. (query) 1
Resource Request Successful, resources reserved. 2
Resource Request failed.
N. Cam-Winget, et al

52. PMKSA Request = RSN IE Order Size (octets) Information 1 Element ID 2
October 2004
PMKSA Request = RSN IE
Order
Size
(octets)
Information 1
Element ID 2
Length 3
Version 4
Group Key Cipher Suite 5
Pairwise Key Cipher Suite count (m) 6
4*m
Pairwise Key Cipher Suite List 7
AKM Suite count (n) 8
4*n
AKM Suite List 9
RSN Capabilities: must include TGr capabilities 10
PMKID Count: must be 1 11 16
PMKID
N. Cam-Winget, et al

53. PMKSA Response = RSN IE Order Size (octets) Information 1 Element ID 2
October 2004
PMKSA Response = RSN IE
Order
Size
(octets)
Information 1
Element ID 2
Length 3
Version 4
Group Key Cipher Suite 5
Pairwise Key Cipher Suite count: must be 1 6
Pairwise Key Cipher Suite chosen 7
AKM Suite count : must be 1 8
AKM Suite chose 9
RSN Capabilities: must include TGr capabilities 10
PMKID Count: must be 1 11 16
PMKID
N. Cam-Winget, et al

54. TGr Frame Component Sizes
October 2004
TGr Frame Component Sizes
ADDTS
Request
107 bytes * 8 (Max TSPECS) = 856 bytes for aggregated TSPEC request
Assuming TCLASS is present describing Type 1 frame IP v6 TCP/IP packets
Response
TSPEC Request + 24 bytes (size of additional fields) = 1048 bytes for aggregated TSPEC response
Additional fields are Status, TS Delay and Schedule if present
4 Way Handshake Message
Message #2
95 bytes (EAPOL Descriptor) + 46 bytes (Key data for RSN IE) = 141 bytes
Message #3
95 bytes (EAPOL Descriptor) + (46 bytes (Key data for RSN IE) * 2) + 38bytes(GTK) = 225 bytes
Assuming largest group key (32 bytes)
Message #4
99 bytes
Assumption no Key Data field (as none is required)
Request Mode
1 byte
Assuming this is enough to identify the request mode
AP Challenge
255 bytes
2 bytes for header and 253 maximum size for challenge text
MIC
16 bytes
2 x 64 bit keys
N. Cam-Winget, et al

55. Calculation of Just-in-Time Frame Sizes
October 2004
Calculation of Just-in-Time Frame Sizes
All payloads must be below 2K for the message to fit in to one frame
Just-in-Time messages:
Reassociate Request( TSPEC, TCLAS etc IEs, 802.1X 4-way Message #2)
= 997 bytes
Reassociate Response( TSPEC, TCLAS etc. IEs , 802.1X 4-way Message #3)
= 1273 bytes
AP-Challenge + MIC
= 272 bytes
The header for each frame defined has not be included in the frame sizes specified
N. Cam-Winget, et al

56. Decision factors for Phase 1 (Query and Reservation) channels
October 2004
Decision factors for Phase 1 (Query and Reservation) channels
Over The Wire
Over The Air
Undisrupted data flow by staying in the current AP. No need to go off channel.
Ensures STA can reach BSSID
STA can request and can wait for BSSID to respond when it has them. Obviates need for a come-back-later alternative.
Enforces STA to check resource availability when in reach
Obviates need to pre-allocate the PTKSA: provides AP policy flexibility of query vs. pre-allocation of resources
Implicitly enables better scalability (across different ESS)
Protection of the QoS requests is achieved through the current AP’s security mechanisms
Enables a smooth transition, integration with the “Just-in-Time” protocol mechanism. Proposal enables the “Just-in-Time” to persist unmodified
N. Cam-Winget, et al

57. October 2004
What .11k Can Provide
STA can gather Neighbor Report (.11k Action Frame) from current AP
Neighbor Report provides candidate APs for STA roaming to. For each of candidate APs, Neighbor Report includes the following information:
BSSID
BSSID Information
Reachability, RSN, Key Scope, Capabilities (Spectrum management, QoS, APSD, Radio Measurement, and Block ACK)
Channel number
Channel Band
PHY options
Neighbor TBTT offset (optional)
Beacon Interval (optional)
Neighbor Report helps STA to decide its candidate APs and accelerate scanning
N. Cam-Winget, et al

58. October 2004
What .11e Can Provide
QAP can advertise its load and admission capacity through QBSS Load IE in Probe Responses and Beacons.
QBSS Load IE has three fields
STA count
channel utilization and
available admission capacity
QBSS Load helps STA to estimate AP’s head-room for QoS traffic and decide its target AP who can likely honor STA’s TSPEC requirements
N. Cam-Winget, et al

59. What STA Can do in Discovery Phase
October 2004
What STA Can do in Discovery Phase
STA can gather its neighbor AP information (.11k) from its current AP and decide the candidate APs for the roaming
STA scans its candidate APs and collects channel information from candidate APs
Received Signal Strength Indicator (RSSI)
QBSS Load information (.11e)
Etc..
From the information that STA collects, STA can decide its target AP who can likely honor its TSPEC requirements,
N. Cam-Winget, et al

60. Previous Contributions
October 2004
Previous Contributions
11-04/707
11-04/1114
11-04/1127
TGk draft 1.0
TGe draft 9
N. Cam-Winget, et al