Last Modified: 2005-09-27
Done | Last call for problem statement draft. | |
Done | Discuss last call comments for problem statement at IETF 59. | |
Done | Last Call for architecture description document. | |
Done | Submit problem statement to IESG for publication approval. | |
Done | Architecture document to expert review. | |
Done | Stable Architecture document for review/sync-up with IEEE 802 | |
Done | Discuss results of IEEE 802 review/sync-up | |
Done | Issue first Internet-Draft of CAPWAP Objectives document | |
Feb 2005 | Submit CAPWAP Objectives to IEEE/IETF experts review | |
Feb 2005 | First WGLC for CAPWAP Objectives Draft | |
Mar 2005 | Deadline to submit candidate protocol proposals to the WG | |
May 2005 | Shutdown WG if CAPWAP Objectives have not finalized, otherwise continue with next milestones. | |
Jun 2005 | Second WGLC for CAPWAP Objectives Draft | |
Jun 2005 | Submit CAPWAP Objectives draft to IESG as Informational RFC | |
Jul 2005 | Issue first Internet-Draft of CAPWAP Evaluation draft | |
Aug 2005 | WGLC for CAPWAP Evaluation draft | |
Sep 2005 | Submit CAPWAP Evaluation draft to IESG as Information RFC | |
Oct 2005 | Issue first Internet Draft of CAPWAP protocol | |
Nov 2005 | Issue first Internet-Draft of CAPWAP MIB | |
Dec 2005 | WGLC for CAPWAP protocol | |
Jan 2006 | Submit CAPWAP protocol to IESG as Proposed Standard RFC | |
Jan 2006 | WGLC for CAPWAP MIB | |
Mar 2006 | Submit CAPWAP MIB to IESG as Proposed Standard RFC |
RFC | Status | Title |
---|---|---|
RFC3990 | I | CAPWAP Problem Statement |
RFC4118 | I | Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) |
- Review of agenda - Review of milestones - LWAPP Poll results - 39 responses, 26 for and 13 against Summary of no votes: - the majority of the no votes had to do with IPR issues (7 votes) - the protool should not be decoupled from recommendations (2 votes) - the poll will continue until Tuesday 11/15/05 - Issues with poll: - the poll was used to indicate the view of the working group - the poll would be an indicator of the consensus - the protocol was tied with the recommendations to minimize the delay - the work moving forward will be to address issues with the protocol - the recommendations of the evaluation team are subject to consensus among the working group - IEEE 802.11 Liason Report - IEEE 802.11v should be included in the table of Task Groups - IEEE 802.11u should be listed as a potential group of interest - If there is interest, drafts would be available to the working group through an email request to the CAPWAP chairs - CAPWAP Evaluation Draft follow-up - The choice of GRE as a protocol prevents it from working through NAT and addressing NAT Traversal requirements - it requires a NAT traversal helper - LWAPP over DTLS - The protocol works with SCTP - When you use a protocol over a protocol, you need hooks to co-ordinate state machines when errors occur. The discussion will be taken off-line. - It seems to be a relatively straight forward job to define LWAPP over DTLS. - There are potential opportunities for DoS attack during the discovery phase. - There are two potential DoS issues: one during the initial discovery phase - however you could use cookie exchanges to protect from that. - CAPWAP System Security - Replaying a packet to a different destination is covered as long as each SA uses a different key - If an application requires encryption, then that encryption should provide encryption. - You always will need MAC's. - You could replace the proposed DTLS with something similar to 802.1x - The Wi-Fi Alliance is ruling out WEP at the end of 2006 - The AC should proxy management for the WTP's. If you don't have that, you will need to establish a security association between the management console and each WTP. This solution is not scalable. - Any authenticated interaction with the WTP's should go through the AC. - Discussion on CAPWAP evaluation recomendations - The more modes of operation we add, the more complex the protocol becomes. - This mode was discussed in the architecture taxonmy. All the modes in the taxonomy should be supported. - It might be helpful to address this issue by stating mandatory and optional modes of operation. - We should address the pros and cons of each issue to determine whether it should be included in the protocol. - On the DTLS issue, we wanted to have a more detailed proposal. Now we have that. - There are customers who want to run L2 because they can't be bothered configuring IP. However, the IETF should not care about this. - L2TPv3 is tightly coupled with PPP - LWAPP makes use of UDP as a shim protocol. - We are defining the CAPWAP header. We should not be spending time on the transport header. - L2TP already has its own header. GRE needs extensions in order to work. - LWAPP provides configuration consistency through the handshake when it joins the AC. - Configuration consistency should be able to be checked at any time. - There are two pieces of software in LWAPP: the system software, the boot loader, and the radio drivers. Make firmware updates into smaller chuncks. - Discussion on open WG issues - Any form of PMK sharing requires a client/supplicant. Therefore this is an IEEE problem, not an IETF problem. This is an issue addressed by IEEE 802.11r. - Communication is needed to the WG members to indicate the current IPR conditions. - There is no agreement that the IPR statements are not fair. - This WG is bound by the IPR rules of the IETF. - If people are not happy with the fairness of the IPR issues. Regardless of which protocol we move forward with, there will be issues. - There's a cloud of uncertainty no matter how we proceed. - Even if we start clean now free of IPR, there is no guarantee that there won't be IPR issues in the future. - The holder of the patent application cannot be specific on its claims until the patent is granted. - Discussion on WiMAX - Introduction to WiMAX architecture - |