Issue EAPoL-Key message generation at WTP or AC Issue 199, summarized as:...the WTP maintains the KeyRSC while the AC requires this information to generate the EAPoL frame for Message-3 of the 4-way handshake..... The proposal is to include a CAPWAP Key Configuration message that can transport the EAPoL frame between AC and WTP before being sent to the client (terminal). Issue 199 appears to be a duplicate of Issue 43, which is being resolved via added text to the security considerations section of the binding document. EAPOL-Key messages in the 4-Way Handshake exchange are always generated at the AC. Proposed resolution: Close as a duplicate. Resolution of Issue 43? Jan 25 th: Consensus to close Issue 199 as a duplicate of issue 43

Issue Issue 138 is the following: with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP. Discussion: (a) The CAPWAP IEEE binding document currently supports encryption to be terminated at either the WTP or the AC. In the current specification, neither is required to be supported at either the WTP or the AC. This presents an interoperability problem, in that a compliant WTP (e.g. supporting only centralized encryption) would not interoperate with a compliant AC (e.g. supporting only WTP encryption). Proposed resolution: Insert the following text at the end of section 2.1 (Split MAC and Local MAC Functionality) To provide system component interoperability, the WTP MUST support encryption/decryption at the WTP and the WTP MUST support encryption/decryption at the AC. The AC MUST support either (a) encryption/decryption at the WTP or (b) encryption/decryption at the AC. The AC MAY support both encryption/decryption at the WTP and encryption/decryption at the AC.

Issue (b) The commenter proposes to disallow the use of centralized encryption, suggesting that mandatory DTLS in the data path can serve as a replacement. This has been discussed on the reflector at length in the past, and at the Dallas meeting. Availability of DTLS in the data path optionally secures the WTP to AC link; it does not provide STA to AC end-to-end protection, and is not a replacement for centralized encryption. Support of centralized encryption has been part of CAPWAP/ from the beginning, and provides unique advantages, including elimination of the Key RSC issue, and support of APs in hostile environments. Proposed resolution: No change to the CAPWAP protocol specification -03 (c) The CAPWAP protocol specification provides for the optional use of DTLS in the Data Plane - No change to the CAPWAP protocol specification -03 Comments (Pat) I still disagree with the proposed resolution for (b), and would like to see it removed from the CAPWAP spec for the following reasons: 1. We already have an optional way to encrypt the frames over the wire, which is based on DTLS. This scheme is completely extensible and will support any wireless technoloy, whereas this proposal only works with i. – encryption from STA to AC has different properties than STA-WTP + WTP-AC 2. This proposal will break some existing (and possibly future) features. For instance, the ability to do A- MSDU aggregation is limited because the WTP is where the actual packet buffering, and aggregation, is performed (since the wireless link is slower than the Ethernet). A-MSDU aggregation requires encryption after the aggregation function has occurred. Any other function that makes use of service periods (e.g., e) also cannot be used as the AC has absolutely no way to identify how to fragment the frames in order to meet with service period. The AC needs to have direct visibility into the air to do this. I do not believe that an implementor reading this specification would understand the restrictions his/her products would have by implementing CAPWAP. Jan 25 th : No consensus to remove centralized encryption

Issue 90 - Using for tunnelling in Split-MAC mode One of the recommendations of the evaluation team was to have a mode to tunnel frames between WTP and AC. It seems that that requirement was interpreted as tunneling frames for local MAC. However after talking to various folks at IETF 65 (dallas), it seems the intent was to tunnel frames in the split MAC (and not local MAC). Hence I would propose the following: –(a) Delete the tunneling of frames between AC WTP for Local MAC and replace it with (b). –(b) Add tunneling frames between AC WTP for Split MAC. Following the notation in section , a new variant of Split MAC should be defined (based on recommendation of the eval team) as follows. –I have marked the changes wrt the draft-00's section with * (note: section remains unchanged - this proposal is an addition to and not a replacement for section ): Function Location Distribution Service AC Integration Service *WTP* Beacon Generation WTP Probe Response WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP Assoc/Disassoc/Reassoc AC e Classifying AC Scheduling *WTP* (I don't understand why section shows.11e scheduling at AC) Queuing WTP i 802.1X/EAP AC Key Management AC Encryption/Decryption *WTP* –Jan 25 th : Consensus to resolve issue 90 by fixing Local Mac mode: change in -01, adding “/AC” in Figure 4 in the Distribution Service and Assoc/Disassoc/Reassoc lines