Seamless BSS Transition Protocol January 2005 doc.: IEEE 802.11-04/1158r0 January 2005 Seamless BSS Transition Protocol Date: 2004-12-18 Authors: 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.kerry@philips.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>. Steve Emeott, Motorola Steve Emeott, Motorola

January 2005 doc.: IEEE 802.11-04/1158r0 January 2005 Abstract – sBSSTP This presentation describes a new proposal submitted to IEEE 802.11 TGr called the Seamless BSS Transition Protocol (sBSSTP) The sBSSTP proposal extends 802.11i and 802.11e services and features to offer mobile stations new ways to authenticate, manage keys and reserve resources at access points before, during and after a BSS transition. The goals and objectives of the sBSSTP proposal are to reduce the amount of time during a BSS transition when a mobile station does not have access to a controlled port. The sBSSTP proposal accomplishes these aims, in part, through new authentication and key management procedures that permit mobile stations to complete time consuming authentication and key confirmation handshake procedures before selecting a destination access point and to piggyback information elements onto reassociation request frames Procedures are also defined by the sBSSTP proposal to permit mobile stations to submit resource reservations prior to a transition Steve Emeott, Motorola Steve Emeott, Motorola

Outline General Introduction Security Preadmissions Summary January 2005 Outline General Introduction Security Preadmissions Summary Steve Emeott, Motorola

January 2005 Overall Goals Reduce the amount of time during a BSS transition when a mobile station does not have access to a controlled port Reduce the number of steps a station must go through to complete its key confirmation handshake Provide a secure and convenient means for a mobile station to complete preauthentication before it selects a destination AP Offer a mobile station a means to reserve resources for its use at a destination AP before it starts a BSS transition Steve Emeott, Motorola

January 2005 General Principles Offer a wide variety of new fast transition features Build upon capabilities already defined in 802.11i and 802.11e Extend 802.11i to permit mobile stations to find an authenticator that can serve multiple AP When possible, rely on simple extensions to existing protocols, like EAPOL, to permit mobile stations to execute portions of a key confirmation station over the DS Expand reassociation request and response frames to include new information elements to be used in expediting BSS transitions Extend admissions control services defined in 802.11e to include support for fast transition services and preadmissions Steve Emeott, Motorola

Overview Proposed Security Services January 2005 Overview Proposed Security Services Pre-Transition Authenticator (PTA) An entity that enables a STA to preauthenticate prior to a BSS transition and before the STA chooses a destination Stores cryptographic key material obtained during preauthentication until a station is ready to complete a key confirmation handshake with an access point Pre-Transition Handshake The STA communicates with an AP before reassociation and completes a portion of the 4-way handshake over the DS Shortened Handshake A portion of the 4-way handshake is incorporated into existing Reassociation frames, and the STA may request to skip the final message if capability is supported at the new AP Steve Emeott, Motorola

Extensions to Admissions Control January 2005 Extensions to Admissions Control Preadmission Request Admissions control service that is available from AP that have QoS and Fast Transition capabilities STA may request current AP to forward a preadmission request to one or more transition candidate APs Preadmission Status Report Report sent in response to a Preadmission Status Inquiry frame from STA or after receiving a preadmissions decision from a transition candidate AP Report indicates whether transition candidate AP accepted, altered, or declined TSPECs, and conveys bandwidth holding time during which the AP will hold the reservation Admissions Control STA may include 802.11e TSPECs in Reassociation Request to create new or alter existing bandwidth reservation Steve Emeott, Motorola

Sample Use Case Scenarios January 2005 Sample Use Case Scenarios Residential Office Open space Corridors and Stairwells and Elevators and Entranceways and Atriums, etc. Steve Emeott, Motorola

(Seamless BSS Transition Protocol) January 2005 Security (Seamless BSS Transition Protocol) Steve Emeott, Motorola

What problems are being solved? January 2005 What problems are being solved? When a mobile station roams, it is highly desirable to provide fast and seamless BSS transitions Problems to avoid Long interaction with Authentication Server (AS) to set up PMK during a transition Longer than necessary key confirmation handshake Transition to an access point that is unable to guarantee a resource reservation (see preadmissions section) The sBSSTP proposal addresses these issues Steve Emeott, Motorola

Components of the Security Solution January 2005 Components of the Security Solution Pre-Transition Authenticator (PTA) An entity that enables a STA to preauthenticate prior to a BSS transition and before the STA chooses a destination Stores cryptographic key material obtained during preauthentication until a station is ready to complete a key confirmation handshake with an access point Pre-Transition Handshake The STA communicates with an AP before reassociation and completes a portion of the 4-way handshake over the DS Shortened Handshake A portion of the 4-way handshake is incorporated into existing Reassociation frames, and the STA may request to skip the final message if capability is supported at the new AP Steve Emeott, Motorola

January 2005 Preauthentication PMK 2 AS Preauthentication procedures establish a PMK at a destination AP before a transition Preauthentication requires advance knowledge of destination APs. Preauthentication is not scalable: multiple destination APs each require authentication. switch PMK 2 AP 1 AP 2 authenticator STA PMK 2 supplicant Steve Emeott, Motorola

Improved Preauthentication January 2005 Improved Preauthentication authenticator AS PTA A Pre-transition Authenticator (PTA) can facilitate 802.1X authentication and hold a PMK until a destination AP is chosen. The PTA can generate an ANonce value before handover to accelerate the 4-way handshake. PMK PMK AP ? switch AP 2 AP 1 AP 3 STA PMK supplicant Steve Emeott, Motorola

How is Fast Transition capability signaled? January 2005 How is Fast Transition capability signaled? A STA determines if its current AP is sBSSTP-capable. The “Fast Transition” bit of the RSN Capabilities field in the RSN IE indicates an sBSSTP-capable AP. RSN Information Element: RSN Capabilities Field An sBSSTP-capable AP will also provide the Fast Transition Capability IE in Beacons and in Probe Responses. Indicates support of preadmissions Steve Emeott, Motorola

January 2005 How is PTA Found? A STA sends a Transition Candidate Report Request Action frame to determine neighbor APs. AP responds with Transition Candidate Report Response Action frame with several reports. STA records PTA addresses for current AP and neighbors (possibly all identical). Transition Candidate Report information element Steve Emeott, Motorola

Establishing a PMK at the PTA January 2005 Establishing a PMK at the PTA RADIUS authenticator AS PTA STA sends EAPOL-Start frame to PTA PTA acts as 802.1X authenticator (relaying messages between STA & AS) AS transfers PMK to PTA when complete No change in AS behavior No change in STA behavior other than designating the PTA address PMK PMK switch EAPOL AP ? AP 1 STA PMK supplicant Steve Emeott, Motorola

Components of the Security Solution January 2005 Components of the Security Solution Pre-Transition Authenticator (PTA) An entity that enables a STA to preauthenticate prior to a BSS transition and before the STA chooses a destination Stores cryptographic key material obtained during preauthentication until a station is ready to complete a key confirmation handshake with an access point Pre-Transition Handshake The STA communicates with an AP before reassociation and completes a portion of the 4-way handshake over the DS Shortened Handshake A portion of the 4-way handshake is incorporated into existing Reassociation frames, and the STA may request to skip the final message if capability is supported at the new AP Steve Emeott, Motorola

January 2005 Pre-Keying over the DS If a means of requesting message #1 of the 4-way handshake were provided, the first portion of the handshake could be completed over the DS with a PTA or an AP Once a destination AP is chosen, the mobile station could continue the 4-way handshake over the DS (message #2 and #3) to pre-key the AP, or wait until reassociation New AP STA Authentication complete; data traffic may begin. 4-way H.S. #1 (ANonce) 4-way H.S. #2 (SNonce, MIC, RSN IE) 4-way H.S. #3 (ANonce, MIC, GTK, RSN IE) 4-way H.S. #4 (MIC) Calculate PTK Steve Emeott, Motorola

How to Request Message #1 January 2005 How to Request Message #1 AP to AP protocol An AP to AP protocol is already defined in 802.11i for preauthentication, namely EAPOL using EtherType 88-C7 It is easy to extend this protocol to support Pre-Keying Key request frame and other pre-key messages An EAPOL-key frame with the request bit set to 1 in the RSNA key descriptor may be used to prompt a PTA or an AP to send message #1 of the 4-way handshake Similarly, EAPOL-key data field may be used to transport one or more information elements, a feature which may be used in a message #2 frame to identify the address of a PTA when pre-keying an AP, etc. Steve Emeott, Motorola

Handshake Request Frame Format January 2005 Handshake Request Frame Format Request an ANonce from the PTA via the DS Allows for shorter exchange during reassociation Send EAPOL-Key “Handshake Request” message 802.11 MAC Header (data frame) Ether. Type (88-C7) Version Packet Type (Key) Packet Body Length Packet Body FCS Octets: 24 2 1 var. 4 EAPOL Frame Format To: PTA Address 802.11i Preauthentication Ether-Type 802.11i-defined Key Descriptor with: Request = 1, Key Ack = 0 Steve Emeott, Motorola

PTA Response to Handshake Request January 2005 PTA Response to Handshake Request PTA creates an ANonce for a STA, and stores ANonce to send to an AP during handover PTA sends ANonce to STA before handover 4-way Handshake Message #1 sent via the DS to the STA PTA always sets: Key Ack = 0 in Key Information field Key Nonce field contains the ANonce. Key Data field is empty. STA receives Message #1 via the DS; extracts ANonce. STA does not send Message #2 to PTA Steve Emeott, Motorola

Situation before Reassociation January 2005 Situation before Reassociation AS PTA After choosing destination: STA generates SNonce STA calculates PTK STA calculates PMKID using destination AP address for PMK located at PTA With a destination selected, STA has option to continue pre-keying or issue a reassociation frame PMK ANonce switch AP 2 AP 1 STA PMK ANonce SNonce + AA  PTK Steve Emeott, Motorola

If STA chooses to Pre-Key … January 2005 If STA chooses to Pre-Key … AS PTA STA chooses destination AP STA sends Message #2 to destination AP via the DS RSN IE, including PMKID FT Control IE AP retrieves ANonce (and PMK) from PTA AP calculates PTK, verifies MIC PMK ANonce Request (PMKID) switch Message 2 AP 2 AP 1 STA PMK ANonce SNonce + AA  PTK Steve Emeott, Motorola

802.11 MAC Header (data frame) January 2005 Message #2 via DS 802.11 MAC Header (data frame) Ether. Type (88-C7) Version Packet Type (Key) Packet Body Length Packet Body FCS Octets: 24 2 1 var. 4 EAPOL Frame Format To: destination AP 802.11i Preauthentication Ether-Type Key Descriptor includes: RSN IE with 1 or more PMKIDs FT Control IE with PTA Address indicate if PMK at PTA Key Descriptor constructed as in 802.11i, but add FT Control IE in “Key Data” field Steve Emeott, Motorola

January 2005 Message #3 via DS AS PTA AP constructs Msg #3 as described in 802.11i and sends it to STA via DS STA verifies MIC and constructs Msg #4 (as in 802.11i) Msg 4 not sent via DS PTK not yet installed switch Message 3 AP 2 AP 1 PMK PTK STA PMK PTK Steve Emeott, Motorola

Components of the Security Solution January 2005 Components of the Security Solution Pre-Transition Authenticator (PTA) An entity that enables a STA to preauthenticate prior to a BSS transition and before the STA chooses a destination Stores cryptographic key material obtained during preauthentication until a station is ready to complete a key confirmation handshake with an access point Pre-Transition Handshake The STA communicates with an AP before reassociation and completes a portion of the 4-way handshake over the DS Shortened Handshake A portion of the 4-way handshake is incorporated into existing Reassociation frames, and the STA may request to skip the final message if capability is supported at the new AP Steve Emeott, Motorola

Fast Transition Handshake January 2005 Fast Transition Handshake Multiple options provided Handshake after Pre-Key Handshake with cached PMK, Anonce from PTA Handshake with PMK and Anonce from PTA In all cases, Reassociation frames are expanded to accommodate an EAPOL-Key message EAPOL-Key message is encapsulated into an IE which may be included in a reassociation frame transmitted by a STA Steve Emeott, Motorola

January 2005 EAPOL-Key Message IE The EAPOL-Key Message information element contains an EAPOL-Key frame to enable IEEE 802.1X messages to be included in management frames Both the AP and the non-AP STA may use the IE to transport EAPOL-Key messages in Reassociation frames Steve Emeott, Motorola

Case 1: Handshake after Pre-Key January 2005 Case 1: Handshake after Pre-Key AS PTA STA sends Reassociation request RSN IE with PMKID EAPOL-Key Message IE (with Msg #4) AP verifies MIC, then Sends (normal) Reassociation response Installs keys STA installs keys after receiving Reassociation response switch AP 2 AP 1 Reassociation request + Msg 4 Reassociation response STA Steve Emeott, Motorola

Case 2: Handshake with Cached PMK January 2005 Case 2: Handshake with Cached PMK AS STA chose destination AP 2, where it has cached a PMK STA can use ANonce obtained from PTA prior to transition to shorten handshake STA starts handshake by embedding message #2 into reassociation request frame STA does this using EAPOL-Key message IE STA also embeds a Fast Transition Control IE into reassociation request providing address of PTA where Anonce is stored PTA Anonce switch PMK 2 AP 2 AP 1 STA PMK 2 Anonce Steve Emeott, Motorola

Fast Transition Control IE January 2005 Fast Transition Control IE Fast Transition Control IE B0 B1 B2 B3 B7 Shortened Handshake PMK in PTA Activate TS Reserved If set, AP will contact PTA to retrieve PMK. AP records value. In case 2, PMK in PTA subfield is set to 0 PTA Address is location where Anonce is stored Steve Emeott, Motorola

Shortened Handshake FT Control IE contains “Shortened Handshake” bit January 2005 Shortened Handshake FT Control IE contains “Shortened Handshake” bit When set (1) and sent by STA in Reassociation Request, STA indicates desire to omit Message #4 AP evaluates STA request; When set (1) and sent by AP in Reassociation Response, AP allows STA to omit Message #4 When Message #4 is omitted, AP installs PTK after sending Reassociation Response STA installs PTK after receiving Reassociation Response and verifying Message 3 MIC Steve Emeott, Motorola

Case 3: Handshake with PMK in PTA January 2005 Case 3: Handshake with PMK in PTA AS PTA STA sends Reassociation request frame RSN IE with PMKID Fast Transition (FT) Control IE EAPOL-Key Message IE FT Control IE contains PTA address EAPOL-Key Message IE contains 4-way Handshake Message #2 PMK ANonce switch AP 2 AP 1 Reassociation request STA PMK PTK PMKID Steve Emeott, Motorola

Transfer of PMK to AP AP submits request to PTA containing PMKID January 2005 Transfer of PMK to AP AS AP submits request to PTA containing PMKID Requires PMK to calculate Request binds PMK to AP 2 (no replay) PTA to AP protocol for key movement is out of scope PTA verifies; moves PMK and ANonce to AP2. AP 2 calculates PTK; verifies Msg #2 MIC PTA PMK ANonce switch Request (PMKID) AP 2 AP 1 STA PMK PTK PMKID Steve Emeott, Motorola

Responding to Reassociation Request January 2005 Responding to Reassociation Request AS PTA AP sends Reassociation response RSN IE with PMKID Fast Transition (FT) Control IE EAPOL-Key Message IE EAPOL-Key IE: contains Msg #3 If “Shortened Handshake” behavior has been selected, AP2 may install PTK after sending Reassociation response switch PMK PTK AP 2 AP 1 Reassociation response STA PMK PTK Steve Emeott, Motorola

Security Summary 4 new Information Elements 2 new Action Frames January 2005 Security Summary 4 new Information Elements Fast Transition Capability element Fast Transition Control element EAPOL-Key Message element Transition Candidate Report element 2 new Action Frames Transition Candidate Report Request Transition Candidate Report Response Addition of Fast Transition Control IE and EAPOL-Key Message IE to Reassociation frames Identification of EAPOL-Key frames for use in Pre-Keying Benefit: New AKM services are provided that may be used in a variety of ways to reduce BSS transition times Steve Emeott, Motorola

(Seamless BSS Transition Protocol) January 2005 Use Cases (Seamless BSS Transition Protocol) Steve Emeott, Motorola

Use Case - Residential Operation Characteristics January 2005 Transition candidate report may indicate only a small number of neighboring AP PTA: STA may choose to preauthenticate with all neighbors instead of with PTA Pre-Key: When roaming, a STA may reserve bandwidth at destination and complete portion of handshake over DS FT: STA may also take advantage of new capabilities added to reassociation request frame STA Portal Current AP AP2 AP3 Characteristics Small number of APs Overlapping coverage Steve Emeott, Motorola

Use Case - Office with Open Space January 2005 Use Case - Office with Open Space Operation Transition candidate report provides identities of one or more PTA, possibly large number of AP PTA: PTA helps in cases where key is not cached at destination Pre-Key: When roaming, a STA may reserve bandwidth at destination and pre-key over DS FT: STA may also take advantage of new capabilities added to reassociation request frame to quickly install PTK Concentrator w/ PTA STA Current AP AP2 AP3 AP4 Characteristics Large number of APs Good visibility to neighbor AP Steve Emeott, Motorola

Use Case – Complex Office Building January 2005 Use Case – Complex Office Building Operation Transition candidate report provides identities of one or more PTA, possibly large number of AP PTA: PTA relied upon to accommodate unexpected BSS transitions Pre-Key: When roaming, a STA may reserve bandwidth at multiple destinations and obtain Anonce from PTA FT: STA rely on new capabilities added to reassociation request frame Concentrator w/ PTA STA Current AP AP2 AP3 AP4 Characteristics Large number of APs Unpredictable movement and unreliable neighbor lists Steve Emeott, Motorola

(Seamless BSS Transition Protocol) January 2005 Preadmissions (Seamless BSS Transition Protocol) Steve Emeott, Motorola

Preadmission Overview January 2005 Preadmission Overview STA Serving AP DS Transition Candidate AP Preadmission Request Preadmission Response Preadmission Status Inquiry Preadmission Status Report All frames sent between STA and serving AP are 802.11 Management Action frames Non-AP STA makes preadmission via the serving AP Serving AP relays TSPECs to a list of transition candidate APs via DS Each transition candidate AP sends preadmission status and modified TSPECs, if any, back to the serving via DS Serving AP may send preadmission status report autonomously or upon STA’s request Steve Emeott, Motorola

STA Operations in Preadmission January 2005 STA Operations in Preadmission STA send Preadmission Request only if the current AP advertised support for preadmission in beacon/probe response Preadmission request includes a list of candidate APs and TSPECs for BW reservation BW reservation can only be made for currently admitted traffic streams associated with AC_VO and AC_VI during preadmission STA may choose to receive “immediate” or “delayed” status update in preadmission request STA may send Preadmission Status Inquiry to solicit Preadmission Status Report Steve Emeott, Motorola

Preadmission Request Frame Format January 2005 Preadmission Request Frame Format TSPEC IE 1 TSPEC IE 2 : TSPEC IE n Element ID Length Preadmission Policy AP List Immediate Status Update Reserved B0 B1 B7 1 variable BSSID 1 BSSID 2 …. BSSID n Preadmission Control IE 1 – Immediate Status Update 0 – Delayed Status Update Steve Emeott, Motorola

Current AP Operations in Preadmission January 2005 Current AP Operations in Preadmission Current AP may accept or decline Preadmission Request in Preadmission Response with appropriate Status Code Current AP forwards TSPECs to all transition candidate APs through the DS Current AP sends Preadmission Status Report as soon as information is available if STA has requested “immediate status update” in preadmission request Current AP buffers status information and send in response to Preadmission Status Inquiry if STA requested “delayed status update” in preadmission request Preadmission Status Update includes TSPECs altered by any transition candidate APs Steve Emeott, Motorola

Preadmission Response Frame Format January 2005 Preadmission Response Frame Format Status Code Preadmission Request Accepted Request Declined – Preadmission is not supported Request Declined – The current AP is busy, try again Request Declined – No existing admitted AC_VO or AC_VI TS Request Declined – Preadmission for AC_BE or AC_BK TS not allowed Request Declined – Invalid TSPEC parameter Request Declined – Invalid transition candidate address Steve Emeott, Motorola

Candidate AP Operations in Preadmission January 2005 Candidate AP Operations in Preadmission Candidate AP may accept, alter, or deny TSPECs Candidate AP sends back “BW Holding Time” and hold BW reservation for as long as the “BW Holding Time” Candidate AP sends back altered TSPEC if BW reservation is not made according to the original TSPEC Candidate AP holds original or altered TSPECs for as long as the “BW Holding Time” Inter-AP protocol is undefined. Nonetheless, it may be accomplished by introducing new frame types into 802.11 or utilizing other developing standards (e.g. IETF) Steve Emeott, Motorola

Preadmission Status Report Frame Format January 2005 Preadmission Status Report Frame Format Altered TSPEC IE 1 Altered TSPEC IE 2 Preadmission Status Report IE – Candidate AP 2 : Preadmission Status Report IE – Candidate AP 1 Element ID Length BSSID Lower Timestamp Status Code BW Holding Time Altered TSPEC Cnt 1 6 4 2 Identifies a Transition Candidate AP Preadmission Status Starting Point of BW Holding Time BW Holding Time (TUs) Preadmission Status Report IE – Candidate AP n No. of Altered TSPECs Enclosed in the Status Report Steve Emeott, Motorola

STA & AP Operations During Transition January 2005 STA & AP Operations During Transition When associating with a QAP, STA may include TSPECs in Reassociation Request to request new or alter existing BW reservations TSPECs sent in reassociation request supersedes TSPECs admitted during preadmission Candidate AP may not honor preadmission BW reservation if it has exceeded the “BW Holding Time” The original serving AP may clean up all buffered preadmission information upon completion of the transition Steve Emeott, Motorola

Preadmissions Summary January 2005 Preadmissions Summary 3 new Information Elements Fast Transition Capability element (in common with security) Preadmission Control element Preadmission Status Report element 4 new Action Frames Preadmission Request Preadmission Response Preadmission Status Inquiry Preadmission Status Report Addition of Fast Transition IE to Reassociation frames (in common with security) Benefit: New feature allows STA to make informed decision about availability of resources at transition candidate APs Steve Emeott, Motorola

(Seamless BSS Transition Protocol) January 2005 Overall Summary (Seamless BSS Transition Protocol) Steve Emeott, Motorola

sBSSTP Benefits January 2005 Flexible approach An RSNA capable AP may signal support for fast transition security services, including the fast transition handshake A QAP may signal support for preadmissions An AP that supports both QoS and RNSA may signal support for both the fast transition security services and preadmissions Supports independent PMK at each AP The proposal supports both independent PMK at each AP and fast transition security services, and copies of PMK at PTA are used at one and only one AP PTA offers a spare key which makes the STA less vulnerable to PMK timeouts and to transitions to BSS where a PMK is not readily available The AP to AP Protocol defined for fast transition security procedures is based on same protocol used in 802.11i for preauthentication A single preadmissions request can reserve resources at one or more transition candidate AP Steve Emeott, Motorola

January 2005 References [1] Steve Emeott, Tony Braskich, Floyd Simpson and Stephen Wang, “Seamless BSS Transition Protocol Preliminary Draft Text,” IEEE submission 802.11-04-1557-00-000r, January 2005. [2] ANSI/IEEE Std 802.11, 1999 Edition [3] IEEE Std 802.11i, 2004 [4] IEEE P802.11e/D11.0, October 2004 [5] Steve Emeott, Tony Braskich, Floyd Simpson, Ruben Formoso, and Stephen Wang, “Motorola TGr Fast Handover Proposal,” IEEE submission 802.11-04-1185-00-000r, November 2004. Steve Emeott, Motorola