Network Working Group B. Sarikaya Internet-Draft R. Jaksa Intended status: Standards Track Huawei USA Expires: April 17, 2007 October 14, 2006 CAPWAP Roaming Protocol in 802.11R Domains draft-sarikaya-capwap-fastbss-00 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 April 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Sarikaya & Jaksa Expires April 17, 2007 [Page 1] Internet-Draft CAPWAPRP October 2006 Abstract This document describes the Control And Provisioning of Wireless Access Points (CAPWAP) Roaming Protocol (CAPWAPRP) for roaming in domains where 802.11R is supported. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Description of Optional Features . . . . . . . . . . . . . 6 2.1.1. Description of the MOBILITY_CACHE Table . . . . . . . 6 2.1.2. Description of the Location Graph Concept . . . . . . 7 2.1.3. Description of the Neighbor Graph Concept . . . . . . 7 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 3. CAPWAPRP Packet Format . . . . . . . . . . . . . . . . . . . . 9 3.1. Message Type . . . . . . . . . . . . . . . . . . . . . . . 9 4. CAPWAPRP Messages . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Context Transfer Messages . . . . . . . . . . . . . . . . 10 5. Handoff Management in CAPWAPRP . . . . . . . . . . . . . . . . 11 5.1. Fast BSS Transition in CAPWAP . . . . . . . . . . . . . . 11 5.1.1. Mobility Domain Identifier . . . . . . . . . . . . . . 11 5.1.2. First Time 802.11r Association - Local MAC . . . . . . 12 5.1.3. 802.11r Reassociation Local MAC . . . . . . . . . . . 13 5.1.4. First Time 802.11r Association - Split MAC . . . . . . 15 5.1.5. 802.11r Reassociation - Split MAC . . . . . . . . . . 17 5.2. Layer 2 Update Frame Details . . . . . . . . . . . . . . . 18 6. Optional Features of CAPWAPRP . . . . . . . . . . . . . . . . 19 6.1. Optional Message Elements . . . . . . . . . . . . . . . . 19 6.1.1. MAC Address . . . . . . . . . . . . . . . . . . . . . 20 6.1.2. Location Data . . . . . . . . . . . . . . . . . . . . 20 6.2. MOBILITY_CACHE Update Request . . . . . . . . . . . . . . 20 6.2.1. Sending MOBILITY_CACHE Update Requests . . . . . . . . 20 6.2.2. Format of a MOBILITY_CACHE Update Request . . . . . . 20 6.2.3. Receiving MOBILITY_CACHE Update Requests . . . . . . . 21 6.3. MOBILITY_CACHE Update Response . . . . . . . . . . . . . . 21 6.3.1. Sending MOBILITY_CACHE Update Responses . . . . . . . 21 6.3.2. Format of a MOBILITY_CACHE Update Response . . . . . . 21 6.3.3. Receiving MOBILITY_CACHE Update Responses . . . . . . 21 6.4. Location Update Request . . . . . . . . . . . . . . . . . 21 6.4.1. Sending Location Update Requests . . . . . . . . . . . 21 6.4.2. Format of a Location Update Request . . . . . . . . . 21 6.4.3. Receiving Location Update Requests . . . . . . . . . . 22 6.5. Location Update Response . . . . . . . . . . . . . . . . . 22 6.5.1. Sending Location Update Responses . . . . . . . . . . 22 6.5.2. Format of a Location Update Response . . . . . . . . . 22 Sarikaya & Jaksa Expires April 17, 2007 [Page 2] Internet-Draft CAPWAPRP October 2006 6.5.3. Receiving Location Update Responses . . . . . . . . . 22 7. Procotol Constants . . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 29 Sarikaya & Jaksa Expires April 17, 2007 [Page 3] Internet-Draft CAPWAPRP October 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. CAPWAPRP 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 where all WTPs support IEEE 802.11r which is an enhancement to IEEE 802.11i [802.11i]. CAPWAPRP 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. We support split-MAC and local-MAC WTPs and define a transport mechanism based on CAPWAP. Because of this CAPWAPRP can easily be incorporated into CAPWAP 802.11 Binding [capwap802.11]. CAPWAPRP aims at reducing the authentication delay during Layer 2 handoffs by using context transfer of key context over wired medium to the WTPs the station might roam in the future. +-+802.11 frames +-+ 802.3 frames +-+ +-+ +-+ Local MAC +-+ +-+ 802.11 frames-Split MAC +-+ | |--------------------------------| | | | +-+ | | | |--------------| |----- ------ --| | | | 802.11 PHY/ | | CAPWAPRP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: CAPWAPRP Architecture This document describes the CAPWAPRP, 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 collection of WTPs and adding the task of handover management to the ACs is well warranted. In CAPWAPRP, the STA to WTP protocol is based on IEEE 802.11 and the WTP to AC transport is completely based on CAPWAP. Sarikaya & Jaksa Expires April 17, 2007 [Page 4] Internet-Draft CAPWAPRP October 2006 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, use the secure key distribution protocol of [802.11r] to transfer AAA context of a station to the WTP. 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 MAC 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. 7. Support Fast BSS Transition defined in IEEE 802.11r for both Local and Split MAC WTPs. The CAPWAPRP 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. The document continues as follows: in Section 2 an overview of the protocol is given; in Section 3 packet formats are defined; in Section 4 messages are defined; in Section 5 handoff management issues are explored; in Section 6 optional features are covered; and in Section 8 security considerations are presented. Finaly the document is concluded in Section 9. 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 & Jaksa Expires April 17, 2007 [Page 5] Internet-Draft CAPWAPRP October 2006 2. Protocol Overview Fast BSS transition for the Local MAC WTPs can be supported assuming that NAS Client is implemented at the AC and AC computes PMK-R0 and becomes the PMK-R0 key holder. AC makes PMK-R1 for each WTP and uses the key distribution protocol to transfer PMK-R1 to each WTP. Fast BSS transition for Split MAC WTPs can be supported assuming that NAS Client is implemented in the AC and PMK-R0 and all PMK-R1 keys are computed at the AC. AC transports the session key PTK to WTP at the end of 4-way handshake in case of the first time association or after the authentication request/response exchange in case of reassociation. 2.1. Description of Optional Features There are two features, MOBILITY_CACHE and Location Graph of CAPWAPRP which are described here. These features are used in Section 6. 2.1.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]. --------------------------------------------------------------- | 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 and 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 Sarikaya & Jaksa Expires April 17, 2007 [Page 6] Internet-Draft CAPWAPRP October 2006 Association and Re-association requests. 2.1.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 | -------------------------- Sample Location Graph list Location A is the MAC address of AP and Location B is its location similar to the location Data of CAPWAP [capwap], (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.1.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]). ---------------------------------------------- | Access Point ID | Neighbour ID | Channels | ---------------------------------------------- | 1 | 2 | {2,6,8} | | 1 | 5 | {6} | | 2 | 1 | {2,6,8} | | 2 | 3 | {6} | | 2 | 4 | (6) | | 2 | 5 | (2,6,8) | | 3 | 2 | (6) | ---------------------------------------------- where 1, 2, 3, 4, and 5 in the first two columns represent MAC addresses. Figure 4: Sample AC Neighbor Graph list Sarikaya & Jaksa Expires April 17, 2007 [Page 7] Internet-Draft CAPWAPRP October 2006 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 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.2. Definitions This Document uses terminology defined in [TERMS] and in [capwap-arch]. Sarikaya & Jaksa Expires April 17, 2007 [Page 8] Internet-Draft CAPWAPRP October 2006 3. CAPWAPRP Packet Format All messages in CAPWAPRP are control messages. CAPWAPRP does not provide any tunneling of user data between AC and WTPs but uses CAPWAP's tunneling. CAPWAPRP protocol provides a communication channel between the WTP and the AC and has the distinct message types that are defined in Section 4. CAPWAPRP packet format follows CAPWAP control packet format as shown below: CAPWAP Control Packet (DTLS Security Required): +-----------------------------------------------------------+ | IP |UDP | DTLS | CAPWAP | Control | Message | DTLS | | Hdr |Hdr | Hdr | Header | Header | Element(s) | Trailer | +-----------------------------------------------------------+ \-------authenticated-----------------/ \------------encrypted-------------------/ CAPWAPRP header has the same format as CAPWAP header defined in [capwap] when CAPWAP transport is used. All CAPWAPRP messages are sent encapsulated within the CAPWAPRP control header as the payload and have the format defined [capwap]. Context transfer messages are described in Section 4.1. 3.1. Message Type CAPWAPRP uses CAPWAP messages for 802.11 binding and possibly some new extensions (Figure 5). Description Value CAPWAP messages 1-26 Reserved 27-59 IEEE 802.11 Messages 3398912-3398913 Figure 5: Message Type Values Sarikaya & Jaksa Expires April 17, 2007 [Page 9] Internet-Draft CAPWAPRP October 2006 4. CAPWAPRP Messages The message type values are as given in Figure 5. These messages contain the parameters as defined in Section 5. Context transfer messages are described in this section. CAPWAP messages are described in [capwap]. All other messages are optional and are described in Section 6. 4.1. Context Transfer Messages Context transfer related control messages are encapsulated into CAPWAPRP payload. [802.11r] key distribution requires the exchange of several new fields. These fields are not defined in [capwap802.11]. Future versions of this document will define [802.11r] key distribution fields in this section. Sarikaya & Jaksa Expires April 17, 2007 [Page 10] Internet-Draft CAPWAPRP October 2006 5. Handoff Management in CAPWAPRP 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 reasons 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 CAPWAPRP 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 [802.11r] key distribution protocol for transfering key context for Local MAC WTPs. Authentication Mobile Request, (Re)Associate Mobile Request/Response messages are the same messages CAPWAP uses to transfer Authentication Request and (Re)Associate Request frames from Local MAC WTPs to AC and (Re)Associate Response messages AC generates and sends back to WTP. 5.1. Fast BSS Transition in CAPWAP Fast BSS transition has new features such as: The use of authentication phase (802.11 Authentication Request/ Response messages) as part of the 4-way handshake. The use of reassociation phase (802.11 Reassociation Request/ Response messages) as part of the 4-way handshake. Key hierarchy with PMK at the root and then R0 next level and R1 keys as level two and PTK as the lowest level is defined. The key hierarchy facilitates the context transfer. Note that if PSK can be used instead of PMK then there is no need for 802.1X EAP authentication. 5.1.1. Mobility Domain Identifier AC MUST set the mobility domain identifier in the domain. After discovery, AC sends IEEE 802.11 WLAN Configuration Request message. IEEE 802.11 WLAN Configuration Request message MUST include the Mobility Domain information element defined in [802.11r]. Mobility domain identifier field in mobility domain IE is a 48-bit value that uniquely identifies this domain. AC MUST set Fast BSS transition capability bit in Fast BSS transition capability and resource policy value field to 1. Sarikaya & Jaksa Expires April 17, 2007 [Page 11] Internet-Draft CAPWAPRP October 2006 WTP MUST send IEEE 802.11 WLAN Configuration Response message with a result code. If the result code is set to success, WTP MUST advertise Fast BSS transition capability in its beacons. Local MAC WTPs advertise their NAS Identifiers in their beacons. NAS Id MUST be set to the fully qualified domain name of the WTP. Split MAC WTPs advertise AC's NAS ID in their beacons. 5.1.2. First Time 802.11r Association - Local MAC First STA creates an initial mobility domain association (the scenario is similar to the one given in Fig. 158J in [802.11r]) with a Local MAC WTP. 802.1X EAP authentication is run between STA, AC and AAA server with the AC as the NAS client. After 802.1X EAP authentication, STA generates MSK. AC receives the MSK from the AAA server. AC becomes R0KH. R0KH then generates PMK-R1 for the WTP. R1KH and STA perform a 4-way handshake exchanging EAPOL-Key frames. The 4-way handshake generates PTK at STA and R1KH which is this WTP. Authentication Request and Response messages indicate an open system authentication. Association Request/ Response messages MUST contain the mobility domain and RSN Information Elements. This is followed by 802.1X-EAP authentication. MSK generated is transported to the AC. AC then calculates PMK-R0 and creates a PMK-R0 PMKSA with STA. AC next generates PMK-R1 for R1 key holder (R1KH), i.e. the WTP. AC is now in a position to transfer PMK-R1 context and associated authorization to the WTP. R1KH and STA perform a 4-way handshake and generate the session key, PTK. EAPOL-Key frame fields will be set to specific values given in Fig. 158J in [802.11r]. KeyRSC MUST be set to zero. AC transfers to the WTP the PMK-R1 key and PMK-R1 context and associated authorizations using CAPWAP Config Request message. Config Request message contains Add Mobile and Mobile Session Key elements. Mobile Session Key field MUST contain PMK-R1 key for this WTP. WTP that receives Config Request message removes any stale associations it may have with the station whose MAC address was in the message, thereby 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 (DS) in order to update forwarding tables in switches. If any other status message is received then failure status is returned back to the mobile station. See Figure 6. Sarikaya & Jaksa Expires April 17, 2007 [Page 12] Internet-Draft CAPWAPRP October 2006 NAP New AP NNAP All other APs STA NAP AC AAA NNAP Server |--AutReq-->| | | | |<-AutRsp---| | | | | ARq | | | | |---------->| | | | | | ASRq | | | | |---------->| | | | | | | | | | | | | | | ASR | | | | |<----------| | | | AR | | | | |<----------| | | | /----------------------------\ |802.1X EAP authentication | \----------------------------/ | |Add Mobile | | | |<----------| | /-----------\ |802.11r | |4-way HS | \-----------/ | | | |Update | | | |------> | | 1) AutReq Authentication Request 2) AutRsp Authentication Response 3) ARq ASSOCIATE REQUEST 4) ASRq Associtate Mobile Request 5) ASR Associate Mobile Reply 6) AR ASSOCIATE RESPONSE 802.1X/EAP Authentication 7) CTD Context Transfer Data 802.11r 4 way handshake Occurs 9) Update Frame Figure 6: Scenario FT1- Local MAC WTP 5.1.3. 802.11r Reassociation Local MAC When STA hands over to a new WTP, it sends an Authentication Request message in which it sends R0KH name. Fast Transition (FT) key distribution protocol is used to distribute R1 key (PMK-R1) to this WTP. The scenario is similar to the one given in Fig. 158B in [802.11r]. Sarikaya & Jaksa Expires April 17, 2007 [Page 13] Internet-Draft CAPWAPRP October 2006 After PMK-R1 is received, WTP MUST send Authentication response frame to STA containing R1DISTV Information Element. STA and WTP compute PTK at the end of Authentication Request/ Response exchange. After PTK is computed, it could be used to protect Reassociation Request/ Response transactions. See Figure 7. 5.1.3.1. R1 Key Distribution STA MUST include R1DIST Information Element in the Authentication Request. Token field of R1DIST MUST include NAS Identifier (FQDN of WTP) and Ns, 16 octet random number chosen by STA. Authentication Request will be transported to AC using CAPWAP transport. AC as R0KH validates NAS-Id and if OK, chooses Na (16 octet random number) and sends a Config Request CAPWAP message. Config Request message MUST contain Add Mobile and Mobile Session Key elements. Mobile Session Key field MUST contain PMK-R1 key for this WTP. A token representing AES-Key wrapping of NAS-Id and Na using "mk" shared secret MUST be sent in Config Request message. R1DISTV Information Element consisting of a digest of Ns concatenated with Na MUST be sent in Config Request Message. Sarikaya & Jaksa Expires April 17, 2007 [Page 14] Internet-Draft CAPWAPRP October 2006 NAP New AP STA NAP AC |--AutReq-->| AutSReq | | |---------->| | |Add Mobile | |<-AutRsp---|<----------| | RARq | | |---------->| | | | RASRq | | |---------->| | | RASR | | |<----------| | RAR | | |<----------| | 1) AutReq Authentication Request 2) AutSreq Authentication Mobile Request 3) Add Mobile 4) AutRsp Authentication Response 5) RARq RE-ASSOCIATE REQUEST 6) RASRq Reassocitate Mobile Request 7) RASR Reassocitate Mobile Response 8) RAR RE-ASSOCIATE RESPONSE Figure 7: Scenario FT2- Local MAC WTP 5.1.4. First Time 802.11r Association - Split MAC First STA creates an initial mobility domain association with a WTP (the scenario is similar to the one given in Fig. 158J in [802.11r]). 802.1X EAP authentication occurs with the AC as NAS client. STA and AAA server generate the MSK. AC receives MSK from AAA server. AC becomes R0KH. AC generates PMK-R1 for the WTP. R1KH which is the AC and STA perform a 802.11r 4-way handshake. EAPOL-Key messages received by WTP are tunneled to AC and AC replies with EAPOL-Key message to WTP and WTP sends it to STA. At the end of 4-way handshake PTK is generated. EAPOL-Key frame fields will be set to specific values given in Fig. 158J in [802.11r]. KeyRSC MUST be set to zero. AC sends the new session key PTK and associated context to WTP in CAPWAP Config Request message. CAPWAP Config Request message MUST contain Add Mobile and Mobile Session Key message elements. In the Mobile Session Key message element A-bit MUST be set to zero. Key field MUST contain the PTK. Upon successful handoff, WTP sends a Sarikaya & Jaksa Expires April 17, 2007 [Page 15] Internet-Draft CAPWAPRP October 2006 Layer 2 Update frame to the distribution system in order to update forwarding tables in switches. Details are in Figure 10. If any other status message is received then failure status is returned back to the mobile station. See Figure 8. NAP New AP STA NAP AC AAA Server |--AutReq-->| | | |<-AutRsp---| | | | ARq | | | |---------->| | | | |---------->| | | |---------->| | | | | | | | | | | |<----------| | | |<----------| | | AR | | | |<----------| | | /----------------------------\ |802.1X EAP authentication | \----------------------------/ /-----------------------\ |802.11r | |4-way HS | \-----------------------/ | |Add Mobile | | |<----------| | |Update | | |------> | 1) AutReq Authentication Request 2) AutRsp Authentication Response 3) ARq ASSOCIATE REQUEST 4) ASRq Associtate Mobile Request 5) ASR Associate Mobile Reply 6) AR ASSOCIATE RESPONSE 802.1X/EAP Authentication 802.11r 4 way handshake Occurs 7) Add Mobile 8) Update Frame Figure 8: Scenario FT3 - Split MAC WTP Sarikaya & Jaksa Expires April 17, 2007 [Page 16] Internet-Draft CAPWAPRP October 2006 5.1.5. 802.11r Reassociation - Split MAC When STA hands over to a new Split MAC WTP, it sends an Authentication Request message in which it sends R0KH Name (The scenario is similar to the one given in Fig. 158B in [802.11r]). Authentication Request is tunneled to AC. AC receives the ANonce and sends the SNonce to WTP which includes it in Authentication Response. Since R1KH is the AC, there is no need for a key distribution protocol in this scenario. STA and AC use PMK-R1 to calculate PTK at the end of Authentication Request/ Response exchange. AC sends the new session key PTK and associated context to WTP in CAPWAP Config Request message. CAPWAP Config Request message MUST contain Add Mobile and Mobile Session Key message elements. In the Mobile Session Key message element A-bit MUST be set to zero. Key field MUST contain the PTK. After PTK is computed, it could be used to protect Reassociation Request/Response transactions. See Figure 9. NAP New AP STA NAP AC |--AutReq-->| | | |---------->| | |---------->| | |<----------| | |<----------| |<-AutRsp---| | | |Add Mobile | | |<----------| | RARq | | |---------->| | | |---------->| | |---------->| | |<----------| | |<----------| | RAR | | |<----------| | 1) AutReq Authentication Request 2) AutRsp Authentication Response 3) RARq RE-ASSOCIATE REQUEST 4) RAR RE-ASSOCIATE RESPONSE Figure 9: Scenario FT4- Local MAC WTP Sarikaya & Jaksa Expires April 17, 2007 [Page 17] Internet-Draft CAPWAPRP October 2006 5.2. Layer 2 Update Frame Details Layer 2 Update frame has the format shown in Figure 10. +--------------------------------------------------------+ | MAC DA | MAC SA | Length | DSAP | SSAP | Control | XID | +--------------------------------------------------------+ | 6 | 6 | 2 | 1 | 1 | 1 | 3 | +--------------------------------------------------------+ Figure 10: 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 & Jaksa Expires April 17, 2007 [Page 18] Internet-Draft CAPWAPRP October 2006 6. Optional Features of CAPWAPRP Mobility cache and location update messages are optional features of CAPWAPRP. These messages contain the message elements that are described in Section 6.1. Optional message type values are shown in Figure 11. Description Value MOBILITY_CACHE Update Request 60 MOBILITY_CACHE Update Response 61 Location Update Request 62 Location Update Response 63 Figure 11: Optional Messages 6.1. Optional Message Elements CAPWAPRP optional messages carry zero or more message elements. 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 Message Element Length field. The format of a 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 allowable values for the Type field are the following: Description Type CAPWAP Reserved 1-24 Location Data 25 CAPWAP Reserved 26-61 MAC Addresses 62 IEEE 802.11 Message Elements 1024-2047 CAPWAP types fields are described in [capwap]. Sarikaya & Jaksa Expires April 17, 2007 [Page 19] Internet-Draft CAPWAPRP October 2006 6.1.1. MAC Address MAC address message element contains the MAC addresses. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC address message element normally carries Sta ID and old AP ID to which STA was attached that are of MAC Address Type. This message element MUST be included as the first message element in all CAPWAPRP messages. This message element MAY be followed by zero or more message elements such as Context Block, Location Data, etc. Note that some of the CAPWAPRP messages described below do not carry any station ID fields, e.g. MOBILITY_CACHE Update Response. The length field MUST be set to zero for such messages. 6.1.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. 6.2. MOBILITY_CACHE Update Request The MOBILITY_CACHE Update Request is sent by the AP to the AC to delete the entry for the specified mobile station from the MOBILITY_CACHE Table. 6.2.1. Sending MOBILITY_CACHE Update Requests APs monitor stations associated with them for activity. If no activity is seen for TIMOUT_PERIOD then AP send MOBILITY_CACHE Update Requests to AC. Thus, station id (MAC address) is required as part of the message. 6.2.2. Format of a MOBILITY_CACHE Update Request The MOBILITY_CACHE Update Request carries the following message elements: Sarikaya & Jaksa Expires April 17, 2007 [Page 20] Internet-Draft CAPWAPRP October 2006 Station ID (MAC address) 6.2.3. Receiving MOBILITY_CACHE Update Requests When an AC receives a MOBILITY_CACHE Update Request it deletes the corresponding entry from the MOBILITY_CACHE Table. It then responds with a MOBILITY_CACHE Update Response. 6.3. MOBILITY_CACHE Update Response The MOBILITY_CACHE Update Response is sent by AC to AP to inform the AP whether the request to delete the station was successful or not. 6.3.1. Sending MOBILITY_CACHE Update Responses MOBILITY_CACHE Update Responses are sent by a AC after receiving a MOBILITY_CACHE Update Request. Response is a status element (SUCCESS or FAILURE). 6.3.2. Format of a MOBILITY_CACHE Update Response The MOBILITY_CACHE Update Response carries the following message elements: Status 6.3.3. Receiving MOBILITY_CACHE Update Responses No action is required on receiving MOBILITY_CACHE Update Responses. 6.4. Location Update Request The Location Update Request MAY be sent by the AP to the AC after receiving a (Re)Associate request. 6.4.1. Sending Location Update Requests AP sends Location Update request so that the neighbour graph list can be updated. This requires the location information of the AP. 6.4.2. Format of a Location Update Request The Location Update Request carries the following message elements: Location Data Sarikaya & Jaksa Expires April 17, 2007 [Page 21] Internet-Draft CAPWAPRP October 2006 6.4.3. Receiving Location Update Requests When a AC receives a Location Update Request it first checks to see if it can find location data in the MOBILITY_CACHE Table. If the data is same then it turns the flags on in the Neighbour graph list to make AP-neighbour pairs active. If entry is not found or is not the same (location has changed) then it deletes all entries from the neighbour graph list corresponding to that AP and then finds all the new neighbours of the AP depending upon the passed in location information and the location graph list stored at the AC. It then adds entries for all neighbours in the neighbour graph list. Finally, AC responds back with a Location Update Response message. 6.5. Location Update Response The Location Update Response is sent by AC to AP to inform the AP whether the request to update the location of AP was successful or not. 6.5.1. Sending Location Update Responses Location Update Responses are sent by a AC after receiving a Location Update Request. Response is a status element (SUCCESS or FAILURE). 6.5.2. Format of a Location Update Response The Location Update Response carries the following message elements: Status 6.5.3. Receiving Location Update Responses No action is required on receiving Location Update Responses. Sarikaya & Jaksa Expires April 17, 2007 [Page 22] Internet-Draft CAPWAPRP October 2006 7. Procotol Constants CAPWAPRP_MAX_ATTEMPT_COUNT 32 CAPWAPRP_TIME_FRAME 60s CAPWAPRP_DOS_WAIT_TIME 3600s Sarikaya & Jaksa Expires April 17, 2007 [Page 23] Internet-Draft CAPWAPRP October 2006 8. Security Considerations Security Concerns raised in CAPWAP are also valid for the CAPWAPRP. CAPWAPRP secures all the message exchange with DTLS [dtls] as in CAPWAP. 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. CAPWAPRP 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 (CAPWAPRP_MAX_ATTEMPT_COUNT as defined in protocol constants section) within a certain time period (CAPWAPRP_TIME_FRAME as defined in protocol constants 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 CAPWAPRP_DOS_WAIT_TIME (defined in protocol constants 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 & Jaksa Expires April 17, 2007 [Page 24] Internet-Draft CAPWAPRP October 2006 9. Conclusions We presented the operation of CAPWAPRP on 802.11r based fast roaming for CAPWAP. The protocol behaviour for Local MAC and Split MAC WTPs is explained using scenarios. Sarikaya & Jaksa Expires April 17, 2007 [Page 25] Internet-Draft CAPWAPRP October 2006 10. References 10.1. Normative References [802.11i] "IEEE Std 802.11i-2004: 802.11 Medium Access Control (MAC) Security enhancements", July 2004. [802.11r] "IEEE Std 802.11r/D3: 802.11 Fast BSS Transition", September 2006. [802.2] "IEEE Std 802.2: Logical Link Control", May 1998. [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] Calhoun, P., Montemurro, M., and D. Stanley, "CAPWAP Base Protocol Specification", October 2006, . [capwap-arch] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", June 2005, . [capwap802.11] Calhoun, P., Montemurro, M., and D. Stanley, "CAPWAP Protocol 802.11 Binding Specification", October 2006, . [dtls] Escorla, E. and N. Modadugu, "Datagram Transport Layer Security", April 2006, . 10.2. Informative References [draft-aboba-context-802] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", October 2003, . [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 & Jaksa Expires April 17, 2007 [Page 27] Internet-Draft CAPWAPRP October 2006 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: Email: sarikaya@ieee.org Robert Jaksa Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: rjaksa@huawei.com Sarikaya & Jaksa Expires April 17, 2007 [Page 28] Internet-Draft CAPWAPRP October 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Sarikaya & Jaksa Expires April 17, 2007 [Page 29]