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 (kempf@docomolabs-usa.com) 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 configuration 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 want. ======================================== =============================== 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 802.11k. - 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). |