2.4.13 Control And Provisioning of Wireless Access Points (capwap) Bof

Current Meeting Report

Control and provisioning of the Wireless (CAPWAP) BoF 

Session: Friday, July 18, 2003 at 0900-1130
BoF Chairs: Dorothy Stanley (dstanley@agere.com) James Kempf 

Agenda Discussion: Chairs 

Accepted with no comment from the room. 

Topic 1: Overview by James Kempf 

Problem statement discussion focused mainly on the 802.11 network 
installation and management. It was mentioned that currently 
installation of the 802.11 is very expensive and complex. Also, the 
management of 802.11 access points is difficult especially the 
interactions between the Access Routers (ARs) and Access Points (APs). 
Also, there are no tools available today for the same. 

The primary reason for chartering this BoF was difficulties in large 
deployments. Currently there is no standard way for establishing the trust 
relation between the APs and ARs and also no mechanism for centrally 
managing configuration of APs. There is no mechanism available for the 
prediction of potential problems until they are encountered. Radio 
resources are unmanaged and lead AP overload unlike in cellular 
systems. Handovers become very complicated because of security reasons. 

In past also, there were a few attempts on this subject. Draft on IAPP 
never became BoF. It is really an IP protocol to carry state 
information between APs after handover (1995). The CRAPS BoF in 2000 
covered many areas including AP control which resulted in to Seamoby WG, but 
AP control was dropped because it was perceived to be a Layer 2 issue. The 
main reason on taking CAPWAP work in IETF now is growing interest in 
802.11 and the need for IP protocols to provide the support. 

The access point was discussed in brief and the architectural 
difference between the AP as a Layer 2 and Layer 3(L3) device was given. 

 Topic 2: LWAPP Architecture by Pat Calhoun 

The intent of having this work in the IETF was discussed in brief. The 
LWAPP architecture includes mainly two components, AR and AP. The LWAPP 
reflects interface between the APs and ARs. Currently there is no 
standard protocol between the ARs and APs. So standardizing LWAPP would 
benefit for ensuring interoperability. The goal is to reduce the amount of 
code and have light APs. Centralized security functions in AR seems 
preferable. The protocol should be extensible to access points other than 
802.11 as well. 

Division of the functionality for the AP and AR was discussed wrt to 
802.11 architecture. The AR basically handles the data and management of the 
802.11 while the AP is mainly responsible for control of the host. The 
LWAPP assumes that the MAC is split between the AP and the AR, reducing the 
functions required on the AP. 

The following components of the LWAPP were discussed: 1. Control channel 
management: Includes discovery and AR-AP session establishment, 
heartbeat and key updates. Plug and Play type of interface and extra 
provisioning are required. Failover mechanism is another important factor to 
be considered. 2. AP Configuration: Configure response, configure 
updates, statistics update and the reset request were discussed. 3. 
Mobile session Management: Pushes a specific rule to the AP. 
Operations like authentication etc. are defined, allowing to add and 
delete the host. 4. Firmware management: During the AP-AR session 
establishment phase, the peers exchange firmware versions. In case of 
unmatched version at the AP, the AR can securely download the image to the 
AP. 5. Transport Services: Ethernet and IP (future non-IP support) are 
options for LWAPP transports. For each transport, discovery, frame of 
packets are considered. 

It is assumed that all LWAPP peers have a certificate. During the AP-AR 
session establishment phase, a session key is exchanged and all control 
packets are subsequently encrypted using AES-CCM. A rekey message exists in 
order to allow the AP (or AR) to create a new session key. 

Points raised on the mailing list included: - Where does encryption occur - 
LWAPP discovery at L3 - LW data message be secured - Used 
certificates or shared key 

Comments: - Asked clarification on the IPR statement mentioned in the 
draft. Free license has been issued to the IETF related to LWAPP work in 
addition to three other IPRs specific for LWAPP. 

Topic 3: Use of SNMP or DHCP for AP Control by Marcus Brunner 

Marcus Brunner argued there are two major issues in the CAPWAP 
scenario, which are AP control/management and 802.11 frame tunneling. The 
tunneling part makes sense because of security and multiplexing issues. 
But, since the current draft doesn't have IP transport, he was not sure the 
tunneling part is an IETF issue. For control/management part, SNMP is just 
fine. But AP needs IP address in this case. DHCP is also fine, but it 
doesn't have functions for coniguration information read back and 
statistics report from AP. He agreed on the significance of the 
proposed work (LWAPP) itself, and recommended to include a work on IP 
transport. It was recommended in the end that DHCP and/or SNMP works fine 
for the configuration, control, and management. 

No WG discussion took place on this topic. 

Topic 4: Access point Discovery by Inderpreet Singh 

The applicability of this talk is specific to L3 only. Per AR, there may be 
100s of access points. Goal is to have plug and play type of 
interface. AR may or may not matter but light APs are desirable. 
Discovery comes in to the picture when the AP needs to find its AR from the 
available list of ARs. It can be either at bootup or dynamic 
discovery. Potential solution could be 

- SLP based discovery: Unicast, multicast SLP based discovery 
scenarios were discussed along with the pros and cons. - DHCP based 
discovery: This option was discussed with some pros and cons. - Static 

Next step should include security and authentication options in 
addition to the discovery. 

Comments: - DHCP database is not dynamically updated that may be an 
issue. - Is there any support for IPv6 since current work seems like for 
IPv4 only. The reply was that IETF work should cover IPv6 as well but as a 
starting point, the focus is just IPv4 because that's what the vendors 

Topic 5: Security Issues by David Molnar 

David Molnar introduced three parts, radio control, session 
management, and data tunneling, which need to be protected from 
attacks. Especially for data tunneling, he pointed out the choice we need to 
make carefully is MAC termination point. Then, he stated the 
constraints and types of attacks clearly for discussion. He explained the 
issues in secure associations between AP and AR. After the 
association, secure transport is used to prevent attacks. For the secure 
transport, he argued pros. and cons. of several schemes including IPSec, 
TLS, CMS, and a custom scheme for this purpose. Then, he presented four 
scenario for provisioning associations. He also pointed out those 
security scheme might lead AP to heavyweight, which contradict the 
initial purpose of this work. Finally he suggested future directions and 
possible solutions. 

Comments: - This presentation is not specific to wireless and may be very 
generic. It should be common to all types of devices. Reply is that the 
main focus is what has been done so far but it is agreed that the scope may 
be larger than expected. - Work in SEND WG may be also related. It was 
clarified that it is mainly for the host. But the cryptographic work can be 
reused. - What is really light-weight AP? It was mentioned that most 
likely vendors will split the functionality between the hardware, 
software or combination of both. Mobility and security demands vertical 
solutions which can't be met by a single standards body. Light weight APs 
are desired and they can be cheap and dumb devices. Reference to 
draft-irtf-aaaarch-handoff-02 and 
draft-mistra-seamoby-context drafts were given related to this subject. - It 
seems the problem targeted to solve is focused toward basic 
configuration for cheap (other) Ethernet devices. What is really 
different here from what has been expected for other devices. It was 
clarified that the current AP has a narrow view. This BoF is expected to 
make AP having broader view. This is lot more than just 
configuration. - Taking away burden of the management and config from the AP 
is useful for the lightweightness. It was clarified that the 
perspective of a functionality for light vs heavy might be different 
everywhere. - Since the focus is on the provisioning and more toward 
real-time support, opinion on QoS was asked. One of the BOF co-chairs 
pointed toward the current mailing list discussion on this topic. - 
Question was asked on the overlap between the IAPP and this work. It was 
mentioned that there is very minimal overlap. Focus on provisioning and 
managing is completely different from the IAPP. It's a different problem and 
this is completely outside of the IEEE. - Is there any formal liaison 
between the IEEE and IETF? It was clarified that Dorothy Stanley 
(co-chair) is the current liaison. The request is basically coming from the 
vendors to work on this problem statement. 

Topic 6 - AAA, James Kempf for Bill Arbaugh 

James Kempf presented AAA issues on behalf of Bill Arbaugh. He pointed out 
mobility and security demand vertical solutions which can't be met by 
single (IEEE or IETF) standards body. An example of the objectives is 
secure movement of STA security associations considering 802.11f (IAPP) and 

- Question: Is IAPP IPR-encumbered? Answer: Check IEEE. 

Topic 6: Charter Discussion by all 

The rationale was given by one of the co-chairs on why IETF should take on 
this particular work item. Lightweight AP model could simplify 
deployment, security, and maintenance of 802.11 networks. Multiple 
vendors are interested in a standardized, secure protocol for 
lightweight access points so their routers, switches, and access points 
interoperate. It was mentioned that APs have enough L3 
characteristics and hence this work may be suitable for the IETF. 

The following items are discussed as a part of the proposed charter: 1. 
Independent of wireless link protocol 2. Discovery of a CAPWAP manager (AR, 
IP addressable switch) 3. Acquisition of APs by CAPWAP manager 4. 
Configuration and monitoring of wireless link by CAPWAP manager 5. 
Partially or fully terminate the wireless MAC layer at the CAPWAP 
manager 6. Control of AP host load 7. Security for CAPWAP signaling 

Next Step: As a part of finalize charter topic, the following comments were 
received from the WG: 

- Light weight v.s. heavy weight? - Architecture issue should be 
addressed - The same thing happened in ethernet hub 8-10 years ago - The 
goal is centralized control of APs - It's not just light weight AP 
problem - That's why CAPWAP named, LWAPP is one solution - Trying to 
specify interfaces between AP and AR, splitting MAC - The purpose of the 
protocol is simple configuration, centralized AP management. Vendors want 
interoperability solutions. - 2 node architecture (AP,AR) or 3 node 
architecture (+other node)? Chair: 2 node architecture - The Ops AD 
questioned whether this work is well aligned with the IEEE work. Dorothy 
indicated that she thought this work is currently in the alignment with the 
IEEE expectations. - The recommendation was that since the security of the 
signalling be discussed here. It is good to have input from the 
Security AD as well. - Asked the clarification of point 1 
(Independent of wireless link protocol). It was clarified that the 
current intent is to have a protocol which is basically independent of the 
radio network and includes support of non-IEEE links as well. - If the 
current focus is on provided L3 solution, why the emphasize on only IEEE at 
this time. The reply was that 802.11 is of more interest today. This is 
just viewed as a near term requirements on this. - The question raised 
whether there is any potential interest from the 3GPP2 as well. The 
co-chair mentioned that 3GPP2 input on this work would be of interest. - 
Clarify point 3 and 4. Any real time function will be in the AP. Other 
wireless technology may not be that simple to fit in here. - In the 
clarification of point 6 above, it was mentioned that CAPWAP requires 
mobility as well. It was agreed in the sense of the definite overlap for the 
context transfer. - It was clarified that although the security of the 
signaling is mentioned in the charter, it is also applicable to the data 
traffic for the network leg in question. Also, both, IPv4 and IPv6 are 
included in the scope and this BoF will cover only L3 related work. - It 
seems it is not clear why the split of MAC layer at the CAPWAP manager is in 
the items list since it is basically Layer 2 issue. No 
clarification was given on this point. - Ops AD basically compared this 
problem domain with the AAA/Diameter as an example and suggested that this 
BoF needs to identify exactly what should be done vs what everyone else 
think what this BoF/WG should be doing. Hence, it is essential to 
understand this difference well. 

BoF Conclusion 

1. Should a WG be formed in order to look at design protocol for CAPWAP? 
This was agreed by the group. 2. Should above bullets (items) become the 
basis of the charter discussion on the list. There was 60/40 split on the 
agreement (mostly agreed) 

The conclusion of this BoF was to continue work as a BoF and have 
further mailing list discussion. If there is an enough interest, it will be a 
meeting in the next IETF meeting (IETF-58). 


AP/AR Discovery
Wireless Facts
Light Weight Access Point Protocol
Control And Provisioning of Wireless Access Points
CAPWAP Security Issues
Use of SNMP or DHCP for AP Control