Network Working Group B. Sarikaya Internet-Draft R. Jaksa Expires: August 31, 2006 C. Williams Futurewei Technologies February 27, 2006 CAPWAP Handover Protocol (CAPWAPHP) draft-sarikaya-capwap-capwaphp-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the Control And Provisioning of Wireless Access Points (CAPWAP) Handover Protocol (CAPWAPHP) which is a protocol allowing the access controller of CAPWAP Working Group architecture to anchor and manage 802.11 handovers of the stations between a collection of Wireless Termination Points (access points). The protocol, like IEEE's IAPP aims to ensure that a station is connected to a single access point and provides an efficient context Sarikaya, et al. Expires August 31, 2006 [Page 1] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 transfer mechanism during handover using neighbor graphs. CAPWAPHP handles local MAC and Split MAC with separate procedures. CAPWAPHP can be transported using CAPWAP protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Description of the MOBILITY_CACHE Table . . . . . . . . . 6 2.2. Description of the Location Graph Concept . . . . . . . . 7 2.3. Description of the Neighbor Graph Concept . . . . . . . . 7 2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 3. CAPWAPHP Packet Format . . . . . . . . . . . . . . . . . . . . 9 3.1. CAPWAPHP Message Header Format-CAPWAP Transport . . . . . 9 3.1.1. Flags Field . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. VER field . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. RID . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. C, F and L Bits . . . . . . . . . . . . . . . . . . . 9 3.1.5. Flags and Frag ID . . . . . . . . . . . . . . . . . . 9 3.1.6. Length . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.7. Status . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.8. RSSI . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.9. SNR . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.10. WLAN IDs . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.11. Payload . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. CAPWAPHP Messages . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Message Format . . . . . . . . . . . . . . . . . . . . 11 3.3. CAPWAPHP Message Elements . . . . . . . . . . . . . . . . 13 3.3.1. Result Code . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. Location Data . . . . . . . . . . . . . . . . . . . . 14 3.3.3. Context Block . . . . . . . . . . . . . . . . . . . . 14 3.4. CAPWAPHP Transport Layer . . . . . . . . . . . . . . . . . 15 3.4.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.2. Layer 3 Using CAPWAP . . . . . . . . . . . . . . . . . 15 4. Handoff Management in CAPWAPHP . . . . . . . . . . . . . . . . 17 4.1. First Time Association - Local MAC WTP . . . . . . . . . . 17 4.2. Reassociation - Local MAC WTP . . . . . . . . . . . . . . 20 4.3. First Time Association - Split MAC . . . . . . . . . . . . 22 4.4. Reassocaition - Split MAC . . . . . . . . . . . . . . . . 24 4.5. Layer 2 Update Frame Details . . . . . . . . . . . . . . . 25 5. CAPWAPHP Message Formats . . . . . . . . . . . . . . . . . . . 26 5.1. Association Mobile Request Message . . . . . . . . . . . . 26 5.2. Association Mobile Reply Message . . . . . . . . . . . . . 26 5.3. Hoff-Init Message . . . . . . . . . . . . . . . . . . . . 27 5.4. Hoff-Init Reply Message . . . . . . . . . . . . . . . . . 27 5.5. Handoff Cached Context Message . . . . . . . . . . . . . . 27 Sarikaya, et al. Expires August 31, 2006 [Page 2] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 5.6. Handoff Cached Context Reply Message . . . . . . . . . . . 27 5.7. Context Transfer Messages . . . . . . . . . . . . . . . . 27 5.7.1. Context Transfer Data Message . . . . . . . . . . . . 27 5.7.2. Context Transfer Data Reply Message . . . . . . . . . 28 5.7.3. Context Transfer Cancel Message . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Normative References . . . . . . . . . . . . . . . . . . . 32 7.2. Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Sarikaya, et al. Expires August 31, 2006 [Page 3] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 1. Introduction The emergence of simple 802.11 Access Points [WPA] that are managed by a router (also known as an access controller, or AC) suggests that having a standardized, interoperable protocol called CAPWAP protocol could radically simplify the deployment and management of wireless networks, a trend that could become more important in new wireless Layer 2 protocols. CAPWAP WG architecture document [capwap-arch] defines several architectures for deploying IEEE WLANs. CAPWAPHP is a protocol between the wireless termination points (WTP) and the access controller (AC) in order to manage the mobility of the stations (STA) in a single administrative domain. The protocol architecture is shown in Figure 1. WTP represents the physical device for an access point (AP). CAPWAPHP borrows ideas from IEEE 802.11F, the Inter- Access Point Protocol (IAPP) [802.11f] which enables Access Points to exchange station context during Layer 2 handoffs. IEEE has recently deprecated IAPP [draft-aboba-ieee802-rel]. CAPWAPHP assumes a network configuration that consists of multiple WTPs connected either via layer 2 (Ethernet), or layer 3 (IP) to an AC. The WTPs can be considered as remote RF interfaces, being controlled by the AC (see Figure 1) where AC could be connected to WTPs directly or there may be switched/ routed connections between the AC and WTPs. In this version of CAPWAPHP, we support split-MAC and local-MAC WTPs and define a transport mechanism based on CAPWAP. Because of this CAPWAPHP can easily be incorporated into CAPWAP. +-+ 802.11frames +-+ | |----------------- Direct --| | | | +-+ Switched | | | |--------------| |----- Routed --| | | | 802.11 PHY/ | | CAPWAPHP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: CAPWAPHP Architecture CAPWAPHP aims at reducing the authentication delay during Layer 2 handoffs. CAPWAPHP protocol operations are dependent of local MAC or split MAC WTPs. CAPWAPHP can be implemented on local MAC or split MAC WTPs. This document describes the CAPWAPHP, a Layer 2 handover protocol that allows handover of STAs from one WTP to another be managed by the AC. The rationale behind it is the fact that the AC manages a Sarikaya, et al. Expires August 31, 2006 [Page 4] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 collection of WTPs and adding the task of handover management to the ACs is well warranted. In CAPWAPHP, the STA to WTP protocol is based on IEEE 802.11 and the WTP to AC transport is completely based on CAPWAP. CAPWAPHP will be extended for 802.16 controller anchored handover management of 802.16e mobiles connected to 802.16 base stations. Goals The following are goals for this protocol: 1. Provide smooth handover access to mobile stations when it enters the range of another WTP. 2. For Local MAC WTPs, enable transfer of AAA context of a station among the neighboring WTPs. Neighbors to an AP are determined by the neighbor graph which is maintained at the AC. Handover time is reduced by AAA context transfer in the wired medium because the station can be authenticated faster. 3. For Split MAC WTPs, all AAA context is stored at the AC not at the WTPs. No context transfer is needed if all neighboring WTPs are Split MAP WTPs. 4. Use the generic encapsulation and transport mechanism, provided by CAPWAP. 5. Enable builtin security features to provide better protection for the WTPs and AC. 6. Ensure that the station has an association with a single WTP and when the station does a handover to another WTP, ensure that forwarding tables of the switches are updated. The CAPWAPHP protocol concerns itself on the interface between the stations and the WTP as well as the WTP and the AC. Inter-AC communication is strictly outside the scope of this document. Direct mobile to AC communication is not possible unless AC is also the subnet router. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [STANDARDS]. Sarikaya, et al. Expires August 31, 2006 [Page 5] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 2. Protocol Overview CAPWAPHP is a handover protocol defining how the station context maintained at each WTP when STA was connected to the WTP is transferred to the new AP with the help of the neighbor graph maintained at the AC. CAPWAPHP messages and procedures defined in this document represent extensions to the CAPWAP protocol for the WTP to AC communication and they are triggered by STAs' handover interactions with the WTPs. CAPWAPHP Transport Layer (CTL) is based on CAPWAP Transport Layer and is defined in section Section 3.4. CTL defines the framing, fragmentation/reassembly, and multiplexing services to CAPWAPHP. CAPWAPHP begins its operation after a discovery phase in which WTPs will select an Access Router (AC) with which to associate and followed by the configuration exchange in which WTPs are provisioned and are enabled for operation. These are the phases defined in CAPWAP. CAPWAPHP handles smooth handover when a mobile station moves from one WTP to another WTP. When a mobile station moves under the range of another WTP, it sends a ReAssociation Request to the WTP. On receiving such a request from a mobile station, the Local MAC WTP sends an initiate handoff request to the AC (Hoff-Init). For both Local and Split MAC WTPs, authentication is based on IEEE 802.11i. Full 802.11i authentication is carried for the first time association of the stations. CAPWAPHP transfers AAA context to the neighbor Local MAC WTPs so that when the station reassociates with a neighbor WTP, only 4-way handshake of 802.11i authentication can be carried. For Split MAC WTPs, the context is kept at the AC and no context transfer is needed. 2.1. Description of the MOBILITY_CACHE Table Access controller stores a list which contains the MAC addresses of the station and the AP they are currently associated with. This is required for security checks later on in the HOFF-INIT process. Also the context information is stored here. The context block is similar to that of IAPP (AP Context Block) except that we have added an additional parameter, namely the AC session key context. An specific example of AAA context to transfer between devices supporting IEEE 802.1X network port authentication is defined in [draft-aboba-context-802]. Sarikaya, et al. Expires August 31, 2006 [Page 6] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 --------------------------------------------------------------- | MAC Address of Station | MAC Address of AP | Context Block | --------------------------------------------------------------- | 1 | 5 | CB for STA 1 | | 2 | 5 | CB for STA 2 | | 3 | 7 | CB for STA 3 | --------------------------------------------------------------- where 1,2,3,5,7 represent MAC addresses CB - Context Block Figure 2: Sample MOBILITY_CACHE Table Because the MOBILITY_CACHE Table is soft-state i.e. it only exists for a certain timeout period, the WTPs monitor the activity of the mobile stations. When they haven't had any activity for a long time, TIMEOUT_PERIOD, then WTPs send request to AC to remove entry from MOBILITY_CACHE Table. Entries are added/updated as part of the Association and Re-association requests. 2.2. Description of the Location Graph Concept The access controller (AC) stores a list as shown in the figure below for the purpose of keeping track of all the neighbour locations. -------------------------- | Location A | Location B | -------------------------- | 1 | 2 | | 3 | 4 | | 5 | 8 | | 9 | 10 | | 3 | 2 | -------------------------- Location A is the MAC address of AP and Location B is its location similar to the location Data of CAPWAP [LWAPP], (e.g. ???Next to Fridge???). The WTPs during the discovery phase send a location field, specifying their location. AC can use the location field in conjunction with the above list to build the neighbor graph for WTPs dynamically. This list (Location Graph) is a static entity and must be instantiated (or loaded) during system startup. 2.3. Description of the Neighbor Graph Concept The access controller (AC) stores a list as shown in the figure below for the purpose of keeping track of the neighbours (Representation of Figure 7 in [mishrashin2004]). Sarikaya, et al. Expires August 31, 2006 [Page 7] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 ----------------------------------------------------- | Access Point ID | NeighBour ID | Channels | Flags | ----------------------------------------------------- | 1 | 2 | {2,6,8} | T | | 1 | 5 | {6} | T | | 2 | 1 | {2,6,8} | T | | 2 | 3 | {6} | T | | 2 | 4 | (6) | T | | 2 | 5 | (2,6,8) | T | | 3 | 2 | (6) | T | ----------------------------------------------------- where 1, 2, 3, 4, and 5 in the first two columns represent MAC addresses. Figure 4: Sample AC Neighbor Graph list The first column contains the access point id (MAC address) of the access point for which the neighbour has been stored. Second column contains the MAC address of the neighbouring AP. Third column contains a list of channels through which these two WTPs can communicate. The last column is used for Flags, which is used when an AP which went offline is being brought back online (this will be discussed in details later on). The neighbour graph is a dynamic entity and gets updated when an AP starts up during the discovery phase. This neighbour graph(or list) is stored at the AC level and the AC acts as the management entity which co-ordinates the association/re-association requests. 2.4. Definitions This Document uses terminology defined in [TERMS] Sarikaya, et al. Expires August 31, 2006 [Page 8] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 3. CAPWAPHP Packet Format This section contains the general packet header format. The CAPWAPHP protocol is designed to be transport agnostic. Transport details can be found in Section 3.4. CAPWAPHP packets take the format described in Section 3.1 when transported in CAPWAP. 3.1. CAPWAPHP Message Header Format-CAPWAP Transport CAPWAPHP message header has the following format when CAPWAP transport is used. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |C|F|L| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status/WLANs | Payload... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: CAPWAP Message Header 3.1.1. Flags Field The first byte contains several flag fields. 3.1.2. VER field The VER field identifies the CAPWAPHP protocol version carried in this packet. For this version of the protocol, the value of this field is 0. 3.1.3. RID The RID field contains the Radio Identifier. For WTPs that contain more than one radio, this field is used to idenfity each Radio. 3.1.4. C, F and L Bits [LWAPP] 3.1.5. Flags and Frag ID As defined in [LWAPP]. Sarikaya, et al. Expires August 31, 2006 [Page 9] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 3.1.6. Length The value of this field is unsigned and indicates the number of bytes in the Payload field. 3.1.7. Status When an CAPWAPHP packet is transmitted from an AP to an AC, this field indicates link layer information associated with the frame. When the C bit is 0, this field is transmitted as zero and ignored on reception. For 802.11, the signal strength and signal to noise ratio with which an 802.11 frame was received, encoded in the following manner: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.8. RSSI RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. 3.1.9. SNR SNR is a signed, 8-bit value. It is the signal to noise ratio of the received 802.11 frame, in dB. 3.1.10. WLAN IDs When a CAPWAPHP packet is transmitted from an AC to a WTP, this field indicates on which WLANs the encapsulated 802.11 frame is to be transmitted. For unicast packets, this field is not used by the AP, but for broadcast or multicast packets, the AP may require this information if it provides encryption services. Given that a single broadcast or multicast packet may need to be sent to multiple wireless LANs (presumably each with a different broadcast key), this field must be a bit field. The bit position indicates the WLAN ID the frame is to be transmitted to. The WLAN IDs field is encoded in the following manner: Sarikaya, et al. Expires August 31, 2006 [Page 10] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN ID(s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.11. Payload The Payload field contains data equal in size to the value of the Length field, found within the CAPWAPHP header. 3.2. CAPWAPHP Messages All messages in CAPWAPHP are control messages. CAPWAPHP does not provide any tunneling of user data between AC and WTPs but uses CAPWAP's tunneling. CAPWAPHP protocol provides a communication channel between the WTP and the AC and has the distinct message types that are defined in Section 5. 3.2.1. Message Format All CAPWAPHP messages are sent encapsulated within the CAPWAPHP header (see Section 3.1) as the payload in CAPWAP: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Seq Num | Msg Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Element [0..N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 3.2.1.1. Message Type The Message Type field identifies the function of the CAPWAPHP message. The valid values for Message Type are shown in Figure 7. Sarikaya, et al. Expires August 31, 2006 [Page 11] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 Description Value CAPWAP messages 1-40 Reserved 41-59 MOBILITY_CACHE Update Request 60 MOBILITY_CACHE Update Response 61 Location Update Request 62 Location Update Response 63 Association-Mobile-Request 64 Association-Mobile-Reply 65 Hoff-Init 66 Hoff-Init-Reply 67 Hoff-CachedContext 70 Hoff-CachedContext-Reply 71 Context Transfer Data 0x3 Context Transfer Data Reply 0x5 Context Transfer Cancel 0x6 Figure 7: Message Type Values 3.2.1.2. Sequence Number The Sequence Number Field is an identifier value to match request/ response packet exchanges. When an CAPWAPHP packet with a request message type is received, the value of the sequence number field is copied into the corresponding response packet. 3.2.1.3. Msg Element Length The Length field indicates the number of bytes following the Session ID field. 3.2.1.4. Session ID The Session ID is a 32-bit unsigned integer that is used to identify the security context for encrypted exchanges between the AP and the AC. 3.2.1.5. Message Element[0..N] The message element(s) carry the information pertinent to each of the control message types. The total length of the message elements is indicated in the Msg Element Length field. The format of a message element uses the standard TLV format shown here: Sarikaya, et al. Expires August 31, 2006 [Page 12] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Type identifies the character of the information carried in the Value field and Length indicates the number of bytes in the Value field. The CAPWAPHP message elements are defined next in Section 3.3 3.3. CAPWAPHP Message Elements CAPWAPHP messages MAY include a message element. The supported message elements are defined in this section. The allowable values for the Type field are the following: Description Type Result Code 1 CAPWAP Reserved 2-34 Location Data 35 CAPWAP Reserved 36-60 Context Block 61 CAPWAP types fields are as described in [LWAPP]. 3.3.1. Result Code The result code message element value is a 32-bit integer value, indicating the result of the request operation corresponding to the sequence number in the message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Result Code: The following values are supported 0 Success 1 Failure Sarikaya, et al. Expires August 31, 2006 [Page 13] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 2 STALE_MOVE 3 BAD_ASSOC 4 NO_ASSOC 5 HOFF_NOAUTH 3.3.2. Location Data The location data message element is a variable length byte string containing user defined location information. The string is NOT zero terminated. 3.3.3. Context Block The Context Block is a container for information that needs to be forwarded from one AP to another upon reassociation of a STA. The format of the Information Element is shown below. AAA context containing selected fields from [draft-aboba-context-802] will be transported in this field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Context Block | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | Context Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of Context Block: A 16-bit integer that indicates the number of octets in the Context Block field. Length of Session Key Payload: a 160-bit integer which is sent by the AC to the AP and includes the randomly generated session key, which is used to protect the CAPWAPHP control messages. Sarikaya, et al. Expires August 31, 2006 [Page 14] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 Context Block: variable length field that contains the context information being forwarded for the reassociated STA. 3.4. CAPWAPHP Transport Layer The CAPWAPHP protocol can operate at layer 2 or 3 using CAPWAP. For layer 2 support, the CAPWAPHP frames are carried in a native Ethernet frame. As such, the protocol is not routable and depends upon layer 2 connectivity between the AP and the AC. Layer 3 support is provided by encapsulating the CAPWAPHP frames within UDP. 3.4.1. Layer 2 This section describes how the CAPWAPHP protocol is provided over native Ethernet frames. All CAPWAPHP frames are encapsulated within 802.3 frames, whose fields are defined below. 3.4.1.1. Source Address A MAC address belonging to the interface from which this message is sent. If multiple source addresses are configured on an interface, then the one chosen is implementation dependent [LWAPP]. 3.4.1.2. Destination Address A MAC address belonging to the interface to which this message is to be sent. This destination address MAY be either an individual address or a multicast address, if more than one destination interface is intended [LWAPP]. 3.4.1.3. Ethertype The Ethertype field is set to 0x88bb. 3.4.1.4. CAPWAPHP Message Header Format over 802.3 MAC CAPWAPHP header is the same as described in Section 3.1. However, fragmentation/reassembly is managed using F,L and Frag ID fields. Multiplexing of control and data messages is done using the C bit. 3.4.2. Layer 3 Using CAPWAP CAPWAPHP makes use of IPv4/UDP transport between the AP and the AC. Frame formats, framing, AC discovery, fragmentation/reassembly and multiplexing are as described in [LWAPP]. Sarikaya, et al. Expires August 31, 2006 [Page 15] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 3.4.2.1. CAPWAPHP Message Header Format over IPv4/UDP F and L bits and Frag ID field bits are not used and MUST be set to zero. The frame format is the same as CAPWAP Control Frame as shown below: +--------------------------------------------+ | MAC Header | IP | UDP |CAPWAPHP Header[C=1]| +--------------------------------------------+ | Control Message | Message Elements ... | +-----------------+----------------------+ where CAPWAPHP Header is as shown in Figure 5 with C bit set to 1 and control message follows Figure 6. Sarikaya, et al. Expires August 31, 2006 [Page 16] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 4. Handoff Management in CAPWAPHP A Handoff occurs when a mobile station moves from one Wireless Termination Point (WTP) to another WTP. This move could happen because of a number of reason such as the weakening of the strength of the signal from the current WTP. During the handoff process, management frames are exchanged between station (STA) and the WTP. We present CAPWAPHP scenarios starting with the two scenarios of local MAC WTP case followed by the two scenarios of the split MAC WTP case. Context information also changes hand between the old WTP to the new WTP via the AC. We use CxTP for context transfer [CxTP]. 4.1. First Time Association - Local MAC WTP When a WTP receives an 802.11 associate requests, it first performs any authentication necessary. The WTP then sends the Association- Mobile request (ASRq) to the AC. This message is used by an WTP to inform the AC that a STA has requested an association with it via an 802.11 associate request. ASRq contains the STA id of the mobile (MAC Address). {ASRq, STA id, old AP id} STA id and old AP id are of MAC Adress Type. With each unique (STA id (MAC Address)) received in an Associate- Mobile message, increment a COUNTER for that station. If this counter exceeds a certain CAPWAPHP_MAX_ATTEMPT_COUNT within an CAPWAPHP_TIME_FRAME unit of time, an Associate-Mobile-Reply is generated indicating how long it should be ignored (in seconds), and denoted as Associate-Mobile-IGNORE. This should prevent excess network traffic due to a malicious or malfunctioning STA. If none of these conditions are met, the AC send a Associate-Mobile- Reply (ASR) with the status of SUCCESS back to the WTP. After a successful association with the WTP, 802.11i authentication starts [802.11i]. AC is the authentication server (AS), WTP is the authenticator and STA is the supplicant. Sarikaya, et al. Expires August 31, 2006 [Page 17] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 NAP New AP ONAP Old Neighbour AP NNAP New Neighbour AP OTAP All non-neighbor APs STA NAP AC ONAP NNAP OTAP AAA Server | ARq | | | | | |---------->| | | | | | | ASRq | | | | | |---------->| | | | | | | | | | | | | | | | | | ASR | | | | | |<----------| | | | | AR | | | | | |<----------| | | | | /-----------|-----------\ |802.11i authentication | \-----------|-----------/ | | | CTD | | | | |------------------->| | | | |H-Notify | | | | |Update |------------------------------>| | |------> | | | | 1) ARq ASSOCIATE REQUEST 2) ASRq Associtate Mobile Request 3) ASR Associate Mobile Reply 4) AR ASSOCIATE RESPONSE 802.11i Authentication Occurs 5) CTD Context Transfer Data 6) H-Notify Hoff-Notify (to all non-neighbor APs) 7) Update Frame Figure 8: Scenario 1- Local MAC WTP If 802.11i authentication succeeds indicating successful handoff, AC sends Context Transfer Data (CTD) message to all neighbor WTPs. WTPs receiving CTD first remove any stale associations with the STA and then cache the AAA context into their MOBILITY_CACHE table. AC can request an acknowledgement of CTD by setting the A bit, then WTPs respond with a Context Transfer Data Reply (CTDR) message. When a STA reassociates with this WTP, the table is consulted and if there is a matching entry, the STA context is activated in order to avoid a full 802.11i authentication exchange. After the context transfer, handoff related messaging takes place. AC sends Hoff-Notify message (H-Notify) to all non neighbor WTPs. Hoff-Notify message contains only MAC address of the station that has Sarikaya, et al. Expires August 31, 2006 [Page 18] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 associated with the WTP. (Hoff-Notify STA id) WTPs receive Hoff-Notify message remove any stale associations they may have with the station whose MAC address was in the message. Hoff-Notify message has the purpose of ensuring that a station is associated with a single WTP at a given time. Upon successful handoff, WTP sends a Layer 2 Update frame to the distribution system in order to update forwarding tables in switches. Details are in Figure 12. If any other status message is received then failure status is returned back to the mobile station. See Figure 8. Sarikaya, et al. Expires August 31, 2006 [Page 19] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 4.2. Reassociation - Local MAC WTP NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-CC | | | | | |---------->| | | | | | | | | | | | H-CC-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | /-----------\ |802.11i | |4-way HS | \-----------/ | | H-CC-U | | | | | |---------->| | | | | | | | CTC | | | | |---------+--------->| | | | | | | CTD | | | |-------->+----------+---------->| | | | | | | 1) RARq RE-ASSOCIATE REQUEST 2) H-CC Hoff-CachedContext 3) H-CC-R Hoff-CachedContext-Reply 4) RAR RE-ASSOCIATE RESPONSE 802.11i 4-way Handshake Occurs 5) H-CC-U Hoff-CachedContext-Update 6) CTC Context Transfer Cancel (to all ONAP) 7) CTD Context Transfer Data (to OAP and all NNAP) Figure 9: Scenario 2 - Local MAC WTP In case STA hands over to a neighboring WTP that has already cached STA context, the signaling shown in Figure 9 is used. When a mobile station moves under the range of another WTP, it sends a ReAssociation Request to the AP. On receiving such a request from a mobile station, the WTP sends an initiate handoff request to the AC (Hoff-CachedContext). This indicates that the STA was previously associated with one of the WTP's known neighbours. Sarikaya, et al. Expires August 31, 2006 [Page 20] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 The message contains the STA id (MAC Address) of the mobile, and the id of the WTP (MAC Address) the STA used to be associated with. {Hoff-CachedContext, STA id (MAC Address), old AP id (MAC Address)} STA id and old AP id are of MAC Adress Type. If authorization is granted, it also confirms the previous association and checks whether it matches with what the station is claiming. For this, the MOBILITY_CACHE table can be used. If no association or a different association is found then appropriate error messages are returned(NO_ASSOC or BAD_ASSOC) and the station must attempt a fresh association. With each unique (STA id (MAC Address), old AP id (MAC Address)) pair received in a Hoff-CachedContext message, AC increments a counter for that pair. If this counter exceeds CAPWAPHP_MAX_ATTEMPT_COUNT within an CAPWAPHP_TIME_FRAME unit of time, a Hoff-CachedContext-Reply is generated indicating how long it should be ignored (in seconds), and denoted as HOFF-IGNORE. This should prevent excess network traffic due to a malicious or malfunctioning STA. If everything checks out, a successful Hoff-CachedContext-Reply is generated. The format of the reply is: {Hoff-CachedContext-Reply, STA id (MAC Address),status} STA id is of MAC Adress Type and status is of Result Code Type. Next 802.11i 4-way handshake will occur between STA and WTP. This will create new AAA context for STA. WTP sends Hoff-CachedContext- Update (H-CC-U) message to AC in order to update STA's context. The format of the message is: {Hoff-CachedContext-Update, STA id (MAC Address), status, context block} STA id is of MAC Adress Type and status is of Result Code Type. When AC receives this message, it initiates the context update procedures. First a Context Transfer Cancel (CTC) message is sent to the old WTP. This message also serves to cancel any stale association with the old WTP. Next, Context Transfer Data message is sent to the old WTP and all other neighboring WTPs and it carries the new context. Sarikaya, et al. Expires August 31, 2006 [Page 21] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 WTPs receiving CTC search STA entry in their MOBILITY_CACHE table and delete it if one is found. For WTPs receiving CTD, the action is the same as described in Section 4.1. See Figure 9. 4.3. First Time Association - Split MAC When a Split MAC WTP receives an 802.11 associate requests it sends the Association-Mobile request (ASRq) to the AC or ARq is tunneled to the AC. AC sends an Add-Mobile CAPWAP control message [LWAPP] to WTP with the status of SUCCESS back to the WTP. Add-Mobile indicates that a full 802.11i authentication is needed. After a successful association with the WTP, 802.11i authentication starts. AC is the authentication server (AS), WTP is the authenticator and STA is the supplicant. Sarikaya, et al. Expires August 31, 2006 [Page 22] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 NAP New AP ONAP Old Neighbour AP NNAP New Neighbour AP OTAP All non-neighbor APs STA NAP AC ONAP NNAP OTAP AAA Server | ARq | | | | | |---------->| | | | | | | ASRq | | | | | |---------->| | | | | | | | | | | | | | | | | |Add Mobile | | | | | |<----------| | | | | AR | | | | | |<----------| | | | | /-----------|-----------\ |802.11i authentication | \-----------|-----------/ | | |H-Notify | | | | |Update |------------------------------>| | |------> | | | | 1) ARq ASSOCIATE REQUEST 2) ASRq Associtate Mobile Request 3) ASR Associate Mobile Reply 4) AR ASSOCIATE RESPONSE 802.11i Authentication Occurs 5) H-Notify Hoff-Notify (to all non-neighbor APs) 6) Update Frame Figure 10: Scenario 3 - Split MAC WTP If 802.11i authentication succeeds indicating successful handoff, AC keeps the AAA context and no context transfer related messaging occurs. After the context transfer, handoff related messaging takes place. AC sends Hoff-Notify message (H-Notify) to all non neighbor WTPs. Hoff-Notify message contains only MAC address of the station that has associated with the WTP. (Hoff-Notify STA id) WTPs receive Hoff-Notify message remove any stale associations they may have with the station whose MAC address was in the message. Hoff-Notify message has the purpose of ensuring that a station is associated with a single WTP at a given time. Sarikaya, et al. Expires August 31, 2006 [Page 23] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 Upon successful handoff, WTP sends a Layer 2 Update frame to the distribution system in order to update forwarding tables in switches. Details are in Figure 12. If any other status message is received then failure status is returned back to the mobile station. See Figure 10. 4.4. Reassocaition - Split MAC NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | |---------->| | | | | |---------->| | | | | | | | | | | |Add Mobile | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | /-----------\ |802.11i | |4-way HS | \-----------/ | | H-CC-U | | | | | |---------->| | | | 1) RARq RE-ASSOCIATE REQUEST 2) 3) Add Mobile 4) RAR RE-ASSOCIATE RESPONSE 802.11i 4-way Handshake Occurs 5) H-CC-U Hoff-CachedContext-Update Figure 11: Scenario 4 - Split MAC WTP Split MAC STA reassociates with a neighboring WTP. It sends a Reassociate Request Frame. This frame is tunneled to AC. AC sends an Add-Mobile CAPWAP control message [LWAPP] to WTP with the status of SUCCESS back to the WTP. AC places AAA context of STA into Add-Mobile message so that WTP need not provoke 802.11i full authentication procedures. Sarikaya, et al. Expires August 31, 2006 [Page 24] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 After a successful association with the WTP, and since WTP has STA context, only 4-way exchange of 802.11i authentication is executed. The new context created at WTP is sent to AC using Hoff- CachedContext-Update (H-CC-U) message. AC sends this context if STA reassociates with a neighbor WTP in an Add-Mobile message. See Figure 11. 4.5. Layer 2 Update Frame Details Layer 2 Update frame has the format shown in Figure 12. +--------------------------------------------------------+ | MAC DA | MAC SA | Length | DSAP | SSAP | Control | XID | +--------------------------------------------------------+ | 6 | 6 | 2 | 1 | 1 | 1 | 3 | +--------------------------------------------------------+ Figure 12: L2 Update Frame Format where MAC DA takes 6 octets and is the broadcast MAC address, MAC SA is 6 octets and is the MAC address of STA that has just been associated/ reassociated successfully. The Length field is set to 8 octets. The values of both DSAP and SSAP fields of length 1 octet is null. The Control field is of length 1 octet, XID Information Field is of length 3 octets. Control and XID fields are defined in [802.2]. Sarikaya, et al. Expires August 31, 2006 [Page 25] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 5. CAPWAPHP Message Formats Sample Message Format: The format of the first CAPWAPHP message element uses the standard TLV format shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Message Type | Length | Sta ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sta ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sta ID | old AP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | old AP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This element may be followed by zero or more message elements such as Context Block, Location Data, etc. Type identifies the message (Hoff-Init, etc.) Value field and Length indicates the number of bytes in the Value field. Type values are as listed in Figure 7. Length = length of all parameters i.e. length of Sta ID + length of old AP id field i.e. Length = 2 * Length of AP Address field = 2 * 48 = 96 bits = 12 bytes if both Sta ID and Old AP Id fields are used. Note that some of the CAPWAPHP messages described below do not carry any station ID fields, e.g. MOBILITY_CACHE Update Response. The length field is set to zero for such messages. Sta ID and old AP ID are of MAC Address Type (as in Section 3.4.1). 5.1. Association Mobile Request Message This message's Type value is 64. The Associate-Mobile-Request message element carries the information pertinent to the Associate- Mobile-Request message. 5.2. Association Mobile Reply Message This message's Type value is 65. The Associate-Mobile-Reply message element carries the information pertinent to the Associate-Mobile- Sarikaya, et al. Expires August 31, 2006 [Page 26] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 Reply message. 5.3. Hoff-Init Message This message's Type is 66. The Hoff-Init message element carries the information pertinent to the Hoff-Init message. 5.4. Hoff-Init Reply Message This message's Type is 67. The Hoff-Init-Reply message element carries the information pertinent to the Hoff-Init-Reply message. 5.5. Handoff Cached Context Message This message's Type is 70. The Hoff-CachedContext message element carries the information pertinent to the Hoff-CachedContext message. 5.6. Handoff Cached Context Reply Message This message's Type is 71. The Hoff-CachedContext Reply message element carries the information pertinent to the Hoff-CachedContext Reply message. 5.7. Context Transfer Messages Context transfer related control messages are encapsulated into CAPWAPHP payload following the same format as in [CxTP] which is different than the other control messages described so far. 5.7.1. Context Transfer Data Message This message's Type is 0x3. CTD message format is the same as in [CxTP] as follows: Sarikaya, et al. Expires August 31, 2006 [Page 27] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V|A| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous Care-of Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ~ First Context Data Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Next Context Data Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CXTP protocol = 0x1 Type CTD = 0x3 (Context Transfer Data) 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. 'A' bit When set, the pAR requests an acknowledgement. Length Message length in units of octets. Elapsed Time The number of milliseconds since the transmission of the first CTD message for this MN. MN's Previous IP Address Field contains either: IPv4 Address, 4 octets, or IPv6 Address, 16 octets. Context Data Block The Context Data Block 5.7.2. Context Transfer Data Reply Message This message's Type is 0x5. Context Transfer Data Reply Message is the same as in [CxTP] as follows: Sarikaya, et al. Expires August 31, 2006 [Page 28] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V|S| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT (if present) | Status code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CXTP protocol = 0x1 Type CTDR = 0x5 (Context Transfer Data) 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. 'S' bit When set to one, this bit indicates that all feature contexts sent in CTD were received successfully. Reserved Set to zero by the sender and ignored by the receiver. Length Message length in units of octets. MN's Previous IP Address Field contains either: IPv4 Address, 4 octets, or IPv6 Address, 16 octets. FPT 16 bit unsigned integer, listing the Feature Profile Type that is being acknowledged. Status Code A context-specific return value, zero for success, nonzero when 'S' is not set to one. 5.7.3. Context Transfer Cancel Message This message's Type is 0x6. Context Transfer Cancel Message is the same as in [CxTP] as follows: Sarikaya, et al. Expires August 31, 2006 [Page 29] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CXTP protocol = 0x1 Type CTC = 0x6 (Context Transfer Cancel) Length Message length in units of octets. 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. Reserved Set to zero by the sender and ignored by the receiver. MN's Previous IP Address Field contains either: IPv4 Address, 4 octets, or IPv6 Address, 16 octets. Sarikaya, et al. Expires August 31, 2006 [Page 30] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 6. Security Considerations Security Concerns raised in CAPWAP are also valid for the CAPWAPHP. This is in reference to the public key cryptography which is used for AP-AC communication. There are primarily two main security concerns: DOS attacks and malicious mobile trying to illegally gain entrance to the network. 1. Denial Of Service attacks are one of the main security issues that can be faced by a mobile network. CAPWAPHP provides mechanisms to overcome such a situation if it ever arises. WTPs route the association/re-association requests to the AC. AC processes these requests and informs the AP of how to respond. If AC receives more than a certain threshold of association/re-assoication requests (CAPWAPHP_MAX_ATTEMPT_COUNT as defined in CAPWAPHP configuration variables section) within a certain time period (CAPWAPHP_TIME_FRAME as defined in CAPWAPHP configuration variables section) then AC assumes a DOS attack is being presented to it or there is some malicious activity going on at the mobile end. It then, informs the AP to ignore any further communication from that mobile (using the MAC address) for CAPWAPHP_DOS_WAIT_TIME (defined in CAPWAPHP configuration variables section) before opening communication with that mobile again. 2. Another important security concern is when a mobile station is trying to maliciously assume another mobile's MAC address in order to gain entry to the network. To avoid such a situation, when a mobile station requests a re-association with an AP, the mobile station is required to send in MAC address and the id (MAC address) of the AP it was previously associated with. This is passed onto the AC by the AP. AC then checks whether the entry it has in its MOBILITY_CACHE table is the same as the one being sent by the AP. If so, then access is allowed. If not, then AC assumes that it is an attempt to breach security and it doesn't allow access to the network. Sarikaya, et al. Expires August 31, 2006 [Page 31] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 7. References 7.1. Normative References [802.11f] "IEEE Std 802.11F: IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter- Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", July 2003. [802.11i] "IEEE Std 802.11i/D10.0: Specification for Enhanced Security", April 2004. [802.2] "IEEE Std 802.2: Logical Link Control", May 1998. [CxTP] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005, . [LWAPP] Calhoun, P., O'Hara, B., Suri, R., Cam Winget, N., Kelly, S., Williams, M., and S. Hares, "Light Weight Access Point Protocol (LWAPP)", June 2005, . [STANDARDS] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997, . [TERMS] Manner, J. and M. Kojo, "Mobility Related Terminology", June 2004, . [WPA] "WiFi Protected Access (WPA) rev 1.6", April 2003. [capwap-arch] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", June 2005, . 7.2. Informative References [draft-aboba-context-802] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", October 2003, . [draft-aboba-ieee802-rel] Bell, L., Romanascu, D., and B. Aboba, "History of the Sarikaya, et al. Expires August 31, 2006 [Page 32] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 IEEE 802/IETF Relationship", April 2005, . [mishrashin2004] Mishra, A., Shin, M., Petroni, N., Clancy, C., and W. Arbaugh, "Proactive Key Distribution Using Neighbor Graphs", IEEE Wireless Communications pp.26-36, February 2004, . Sarikaya, et al. Expires August 31, 2006 [Page 33] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 Authors' Addresses Behcet Sarikaya Futurewei Technologies 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: bsarikaya@huawei.com Robert Jaksa Futurewei Technologies 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: rjaksa@huawei.com Carl Williams Futurewei Technologies 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: carlw@mcsr-labs.org Sarikaya, et al. Expires August 31, 2006 [Page 34] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sarikaya, et al. Expires August 31, 2006 [Page 35]