Internet DRAFT - draft-sarikaya-capwap-capwaphp
draft-sarikaya-capwap-capwaphp
Network Working Group B. Sarikaya
Internet-Draft R. Jaksa
Expires: December 25, 2006 C. Williams
Huawei USA
June 23, 2006
CAPWAP Handover Protocol (CAPWAPHP)
draft-sarikaya-capwap-capwaphp-02
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 December 25, 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 December 25, 2006 [Page 1]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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
1.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Description of the MOBILITY_CACHE Table . . . . . . . . . 7
2.2. Description of the Location Graph Concept . . . . . . . . 8
2.3. Description of the Neighbor Graph Concept . . . . . . . . 8
2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3. CAPWAPHP Packet Format . . . . . . . . . . . . . . . . . . . . 10
3.1. Message Type . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Message Element . . . . . . . . . . . . . . . . . . . . . 11
3.3. CAPWAPHP Message Elements . . . . . . . . . . . . . . . . 11
3.3.1. MAC Address . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Location Data . . . . . . . . . . . . . . . . . . . . 12
3.3.3. Result Code . . . . . . . . . . . . . . . . . . . . . 12
3.3.4. Context Block . . . . . . . . . . . . . . . . . . . . 13
4. CAPWAPHP Messages . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Context Transfer Messages . . . . . . . . . . . . . . . . 15
4.1.1. Context Transfer Data Message . . . . . . . . . . . . 15
4.1.2. Context Transfer Data Reply Message . . . . . . . . . 16
4.1.3. Context Transfer Cancel Message . . . . . . . . . . . 17
5. Handoff Management in CAPWAPHP . . . . . . . . . . . . . . . . 19
5.1. First Time Association - Local MAC WTP . . . . . . . . . . 19
5.2. Reassociation - Local MAC WTP . . . . . . . . . . . . . . 22
5.3. First Time Association - Split MAC . . . . . . . . . . . . 24
5.4. Reassociation - Split MAC . . . . . . . . . . . . . . . . 26
5.5. MOBILITY_CACHE Update Request . . . . . . . . . . . . . . 27
5.5.1. Sending MOBILITY_CACHE Update Requests . . . . . . . . 27
5.5.2. Format of a MOBILITY_CACHE Update Request . . . . . . 27
5.5.3. Receiving MOBILITY_CACHE Update Requests . . . . . . . 27
5.6. MOBILITY_CACHE Update Response . . . . . . . . . . . . . . 27
5.6.1. Sending MOBILITY_CACHE Update Responses . . . . . . . 28
5.6.2. Format of a MOBILITY_CACHE Update Response . . . . . . 28
5.6.3. Receiving MOBILITY_CACHE Update Responses . . . . . . 28
5.7. Location Update Request . . . . . . . . . . . . . . . . . 28
5.7.1. Sending Location Update Requests . . . . . . . . . . . 28
5.7.2. Format of a Location Update Request . . . . . . . . . 28
5.7.3. Receiving Location Update Requests . . . . . . . . . . 28
5.8. Location Update Response . . . . . . . . . . . . . . . . . 29
5.8.1. Sending Location Update Responses . . . . . . . . . . 29
5.8.2. Format of a Location Update Response . . . . . . . . . 29
Sarikaya, et al. Expires December 25, 2006 [Page 2]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
5.8.3. Receiving Location Update Responses . . . . . . . . . 29
5.9. Layer 2 Update Frame Details . . . . . . . . . . . . . . . 29
6. Procotol Constants . . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Sarikaya, et al. Expires December 25, 2006 [Page 3]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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.11 frames +-+ 802.3 frames +-+
+-+ +-+ Local MAC +-+
+-+ 802.11 frames-Split MAC +-+
| |--------------------------------| |
| | +-+ | |
| |--------------| |----- ------ --| |
| | 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
Sarikaya, et al. Expires December 25, 2006 [Page 4]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
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 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
Sarikaya, et al. Expires December 25, 2006 [Page 5]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
[STANDARDS].
1.2. Acknowledgements
We gratefully acknowledge Dr. Charles Clancy for clarifying Split-MAC
operation.
Sarikaya, et al. Expires December 25, 2006 [Page 6]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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 3 of [capwap]. 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 December 25, 2006 [Page 7]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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 [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.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 December 25, 2006 [Page 8]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
----------------------------------------------
| 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
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.4. Definitions
This Document uses terminology defined in [TERMS] and in [capwap-
arch].
Sarikaya, et al. Expires December 25, 2006 [Page 9]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
3. CAPWAPHP Packet Format
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 4.
CAPWAPHP 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-------------------/
CAPWAPHP header has the same format as CAPWAP header defined in
Section 4.1 of [capwap] when CAPWAP transport is used.
All CAPWAPHP messages are sent encapsulated within the CAPWAPHP
control header as the payload and have the format defined in Section
4.3.1 of [capwap].
3.1. Message Type
The Message Type field of CAPWAPHP control header identifies the
function of the CAPWAPHP message. The valid values for Message Type
Values are shown in Figure 5. The 32-bit message type field value is
obtained using these message type values and the formula:
Message Type = IANA Enterprise Number * 256 + Message Type Value
An example value for IANA Enterprise number is IEEE 802.11 IANA
Enterprise number which is 13277.
Sarikaya, et al. Expires December 25, 2006 [Page 10]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
Description Value
CAPWAP messages 1-26
Reserved 27-59
MOBILITY_CACHE Update Request 60
MOBILITY_CACHE Update Response 61
Location Update Request 62
Location Update Response 63
Associate Mobile-Request 64
Associate Mobile-Reply 65
Hoff-Init 66
Hoff-Init-Reply 67
Hoff-CachedContext 70
Hoff-CachedContext-Reply 71
Hoff-CachedContext-Update 72
Hoff-Notify 75
Context Transfer Data 0x3
Context Transfer Data Reply 0x5
Context Transfer Cancel 0x6
Figure 5: Message Type Values
3.2. Message Element
CAPWAPHP 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.
3.3. CAPWAPHP Message Elements
CAPWAPHP messages MAY include a message element. The supported
message elements are defined in this section.
Sarikaya, et al. Expires December 25, 2006 [Page 11]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
The allowable values for the Type field are the following:
Description Type
CAPWAP Reserved 1-24
Location Data 25
CAPWAP Reserved 26-27
Result Code 28
CAPWAP Reserved 29-60
Context Block 61
MAC Addresses 62
IEEE 802.11 Message Elements 1024-2047
CAPWAP types fields are as described in Section 4.3.1.1 of [capwap].
3.3.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 CAPWAPHP 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 CAPWAPHP 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.
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. Result Code
The result code message element value is a 32-bit integer value,
Sarikaya, et al. Expires December 25, 2006 [Page 12]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
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
12 STALE_MOVE
13 BAD_ASSOC
14 NO_ASSOC
15 HOFF_NOAUTH
3.3.4. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sarikaya, et al. Expires December 25, 2006 [Page 13]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
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.
Context Block: variable length field that contains the context
information being forwarded for the reassociated STA.
Sarikaya, et al. Expires December 25, 2006 [Page 14]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
4. CAPWAPHP Messages
The message type values are as given in Figure 5. These messages
contain the parameters as defined in Section 5. Handoff-Init and
Handoff-Init-Reply messages are not used in this version.
4.1. 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.
4.1.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 December 25, 2006 [Page 15]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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
4.1.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 December 25, 2006 [Page 16]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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.
4.1.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 December 25, 2006 [Page 17]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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 December 25, 2006 [Page 18]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
5. 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].
In local MAC WTP cases below it is assumed that WTP is capable of
supporting 802.1X/EAP and 802.11i authentication as well as key
management. WTP also has the AAA client installed. CAPWAP
specification on the other hand leaves 802.1X/EAP support and RSNA
Key Management functions at the AC as well as AAA Client in Figure 6
of [capwap]. Handoff management in that case is very similar to
Split MAC WTP cases as presented in Section 5.3 and Section 5.4.
5.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 Associate
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.1X/EAP
Sarikaya, et al. Expires December 25, 2006 [Page 19]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
authentication starts [802.11i]. AAA server is the authentication
server (AS), WTP is the authenticator and STA is the supplicant.
NAP New AP
ONAP Old Neighbour AP
NNAP Neighbour APs
OTAP All non-neighbor APs
STA NAP AC AAA ONAP NNAP OTAP
Server
| ARq | | | | | |
|---------->| | | | | |
| | ASRq | | | | |
| |---------->| | | | |
| | | | | | |
| | | | | | |
| | ASR | | | | |
| |<----------| | | | |
| AR | | | | | |
|<----------| | | | | |
/----------------------------\
|802.1X EAP authentication |
\----------------------------/
| | H-CC-U | | | |
| |---------->| | | |
/-----------\ | CTD | |
|802.11i | |------------------->| |
|4-way HS | |H-Notify | | |
\-----------/ |------------------------------>|
| |Update
| |------> | | | |
1) ARq ASSOCIATE REQUEST
2) ASRq Associtate Mobile Request
3) ASR Associate Mobile Reply
4) AR ASSOCIATE RESPONSE
802.1X/EAP Authentication
5) H-CC-U Hoff-CachedContext-Update
802.11i 4 way handshake Occurs
6) CTD Context Transfer Data
7) H-Notify Hoff-Notify (to all non-neighbor APs)
8) Update Frame
Figure 6: Scenario 1- Local MAC WTP
If 802.1X/EAP authentication succeeds indicating successful handoff,
a Pairwise Master Key (PMK) is generated. The new AP sends the AAA
context to AC with Hoff-CachedContext-Update (H-CC-U) message.
The format of the message is:
Sarikaya, et al. Expires December 25, 2006 [Page 20]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
{Hoff-CachedContext-Update, AP Id, status, context block}
AP id is of MAC Adress Type and carries WTP MAC address and status is
of Result Code Type and has the value success and the context block
contains the AAA context including PMK.
The new AP and STA are next involved in 802.11i 4-way handshake in
order to generate the session key TK and other keys, e.g. GTK.
When AC receives Hoff-CachedContext-Update message, it initiates the
context update procedures. 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.1X/EAP 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
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 (DS) 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 6.
Sarikaya, et al. Expires December 25, 2006 [Page 21]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
5.2. Reassociation - Local MAC WTP
NAP New AP
OAP Old AP
ONAP Old Neighbour AP
NNAP Neighbour APs
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 7: 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 7 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 December 25, 2006 [Page 22]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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.
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.
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 5.1.
Sarikaya, et al. Expires December 25, 2006 [Page 23]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
See Figure 7.
5.3. First Time Association - Split MAC
When a Split MAC WTP receives an 802.11 associate requests ARq is
tunneled to the AC.
AC sends a reply frame to WTP with the status of SUCCESS. The reply
also indicates that a full 802.1X/EAP authentication is needed.
CAPWAP Config Request message containing Add Mobile and Mobile
Session Key message elements sent from AC to WTP can be used. In the
Mobile Session Key message element A-bit MUST be set to one.
After a successful association with the WTP, 802.1X/EAP
authentication starts. AAA server is the authentication server (AS)
and STA is the supplicant. WTP acts like an authenticator to the STA
and it tunnels all replies to AC to be processed at the AC. AC keeps
the resulting key context, i.e. PMK.
Sarikaya, et al. Expires December 25, 2006 [Page 24]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
NAP New AP
ONAP Old Neighbour AP
NNAP New Neighbour AP
OTAP All non-neighbor APs
STA NAP AC AAA Server NNAP OTAP
| ARq | | | | |
|---------->| | | | |
| |---------->| | | |
| |---------->| | | |
| | | | | |
| | | | | |
| |<----------| | | |
| |<----------| | | |
| AR | | | | |
|<----------| | | | |
/---------------------------------\
|802.1X/EAP authentication |
\---------------------------------/
/-----------------------\
|802.11i 4 way HS |
\-----------------------/
| |Add Mobile |
| |<----------|
| |Update |
| |------> |
1) ARq ASSOCIATE REQUEST
2) ARq tunneled
3) AR tunneled
4) AR ASSOCIATE RESPONSE
802.11i Authentication Occurs
5) Hoff CachedContext-Update H-CC-U
6) Update Frame
Figure 8: Scenario 3 - Split MAC WTP
Next, 802.11i 4-way handshake is performed between STA and AC to
derive TK. AC sends the new 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 TK.
AC keeps the AAA context and no context transfer related messaging
occurs.
After the context is transferred to STA, handoff related messaging
takes place. If all WTPs are split-MAC WTPs then AC keeps all the
Sarikaya, et al. Expires December 25, 2006 [Page 25]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
association state centrally and it does not need to send Hoff-Notify
message (H-Notify) to all non neighbor WTPs to remove any stale
associations they may have with the station whose MAC address was in
the message.
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 10. If any other status message is received
then failure status is returned back to the mobile station.
See Figure 8.
5.4. Reassociation - Split MAC
NAP New AP
OAP Old AP
ONAP Old Neighbour AP
NNAP New Neighbour AP
STA NAP AC OAP ONAP NNAP
| RARq | | | | |
|---------->| | | | |
| |---------->| | | |
| |---------->| | | |
| | | | | |
| |<----------| | | |
| |<----------| | | |
| RAR | | | | |
|<----------| | | | |
/-----------------------\
|802.11i 4-way HS |
\-----------------------/
| |Add Mobile |
| |<----------|
1) RARq RE-ASSOCIATE REQUEST
2) RARq tunneled
3) RAR tunneled
4) RAR RE-ASSOCIATE RESPONSE
802.11i 4-way Handshake Occurs
5) Hoff CachedContext-Update H-CC-U
Figure 9: Scenario 4 - Split MAC WTP
STA reassociates with a neighboring Split MAC WTP. It sends a
Reassociate Request Frame. This frame is tunneled to AC.
AC sends a reply frame to WTP with the status of SUCCESS. CAPWAP
Config Request message containing Add Mobile and Mobile Session Key
Sarikaya, et al. Expires December 25, 2006 [Page 26]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
message elements is sent from AC to WTP. In the Mobile Session Key
message element A-bit MUST be set to one. This indicates that
802.11i 4-way handshake is needed.
After a successful association with the WTP, and since WTP has STA
context which is kept at AC, only 4-way exchange of 802.11i
authentication is executed. 4-way handshake involves STA and AC and
WTP does the bridging. 4-way handshake is triggered by AC picking up
ANonce and then sending EAPoL-Key frame to WTP. At the end of 4-way
handshake, the new context created is kept at the AC. When 4-way
handshake terminates, AC sends CAPWAP Config Request message
containing Add Mobile and Mobile Session Key message elements to WTP.
In the Mobile Session Key message element A-bit MUST be set to zero.
In some cases, TK is needed at WTP. In that case, AC transfers the
TK to WTP in the Key field of Mobile Session Key message element.
See Figure 9.
5.5. 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.
5.5.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.
5.5.2. Format of a MOBILITY_CACHE Update Request
The MOBILITY_CACHE Update Request carries the following message
elements:
Station ID (MAC address)
5.5.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.
5.6. 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.
Sarikaya, et al. Expires December 25, 2006 [Page 27]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
5.6.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).
5.6.2. Format of a MOBILITY_CACHE Update Response
The MOBILITY_CACHE Update Response carries the following message
elements:
Status
5.6.3. Receiving MOBILITY_CACHE Update Responses
No action is required on receiving MOBILITY_CACHE Update Responses.
5.7. Location Update Request
The Location Update Request MAY be sent by the AP to the AC after
receiving a (Re)Associate request.
5.7.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.
5.7.2. Format of a Location Update Request
The Location Update Request carries the following message elements:
Location Data
5.7.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.
Sarikaya, et al. Expires December 25, 2006 [Page 28]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
5.8. 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.
5.8.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).
5.8.2. Format of a Location Update Response
The Location Update Response carries the following message elements:
Status
5.8.3. Receiving Location Update Responses
No action is required on receiving Location Update Responses.
5.9. 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, et al. Expires December 25, 2006 [Page 29]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
6. Procotol Constants
CAPWAPHP_MAX_ATTEMPT_COUNT 32
CAPWAPHP_TIME_FRAME 60s
CAPWAPHP_DOS_WAIT_TIME 3600s
Sarikaya, et al. Expires December 25, 2006 [Page 30]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
7. Security Considerations
Security Concerns raised in CAPWAP are also valid for the CAPWAPHP.
CAPWAPHP 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. 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 protocol
constants section) within a certain time period
(CAPWAPHP_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 CAPWAPHP_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, et al. Expires December 25, 2006 [Page 31]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
8. Future Work
Future versions of this document will contain, apart from the
scenarios not yet covered, the following:
A new section on fast roaming. This section will address IEEE
802.11r results [802.11r]. In particular, the need to use 802.11
authentication phase, the new key hierarchy and preauthentication
will be addressed.
A new section on inter domain roaming. In particular, the issues
involved when roaming to a new domain requiring the change of an AC
will be addressed.
Clarify CAPWAP operation when CAPWAPHP is used.
Sarikaya, et al. Expires December 25, 2006 [Page 32]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
9. References
9.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-2004: 802.11 Medium Access Control (MAC)
Security enhancements", July 2004.
[802.11r] "IEEE Std 802.11r/D2.1: 802.11 Fast BSS Transition",
May 2006.
[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,
<ftp://ftp.isi.edu/in-notes/rfc4067.txt>.
[STANDARDS]
"Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, October 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>.
[TERMS] Manner, J. and M. Kojo, "Mobility Related Terminology",
June 2004, <ftp://ftp.isi.edu/in-notes/rfc3753.txt>.
[WPA] "WiFi Protected Access (WPA) rev 1.6", April 2003.
[capwap] Calhoun, P., Montemurro, M., and D. Stanley, "CAPWAP
Protocol Specification", June 2006, <http://www.ietf.org/
internet-drafts/
draft-ietf-capwap-protocol-specification-02.txt>.
[capwap-arch]
Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access
Points(CAPWAP)", June 2005,
<http://ietf.org/rfc/rfc4118.txt>.
[dtls] Escorla, E. and N. Modadugu, "Datagram Transport Layer
Security", April 2006,
<http://www.ietf.org/rfc/rfc4347.txt>.
Sarikaya, et al. Expires December 25, 2006 [Page 33]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006
9.2. Informative References
[draft-aboba-context-802]
Aboba, B. and T. Moore, "A Model for Context Transfer in
IEEE 802", October 2003, <http://ietfreport.isoc.org/
idref/draft-aboba-context-802/>.
[draft-aboba-ieee802-rel]
Bell, L., Romanascu, D., and B. Aboba, "History of the
IEEE 802/IETF Relationship", April 2005, <http://
ietfreport.isoc.org/idref/draft-aboba-ieee802-rel/>.
[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, <http://www.cs.umd.edu/~mhshin/paper/
mishra2004proactive.pdf>.
Sarikaya, et al. Expires December 25, 2006 [Page 34]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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
Carl Williams
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: carlw@mcsr-labs.org
Sarikaya, et al. Expires December 25, 2006 [Page 35]
Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 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 December 25, 2006 [Page 36]
