Issue 199 - EAPoL-Key message generation at WTP or AC

1. Issue 199 - EAPoL-Key message generation at WTP or AC • Issue 199, summarized as:...the WTP maintains the KeyRSC while the AC requires this information to generatethe 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 isbeing resolved via added text to the security considerations sectionof the 802.11 binding document. EAPOL-Key messages in the4-Way Handshake exchange are always generated at the AC.Proposed resolution: Close as a duplicate. Resolution of Issue 43? • Jan 25th: Consensus to close Issue 199 as a duplicate of issue 43

2. Issue 138 - 1 • 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 802.11 binding document currently supports 802.11 encryption to beterminated at either the WTP or the AC. In the current specification, neither is required to be supportedat 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 onlyWTP 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 802.11 encryption/decryption atthe WTP  and the WTP MUST support 802.11  encryption/decryption at the  AC.The AC MUST support either (a) 802.11 encryption/decryption at the WTP or (b) 802.11 encryption/decryption at the AC. The AC MAY support both 802.11 encryption/decryption at the WTP and 802.11 encryption/decryption at the AC.

3. Issue 138 - 2 • (b) The commenter proposes to disallow the use of centralized 802.11 encryption, suggesting that mandatory DTLS in the data path can serve as a replacement. This has been discussed on thereflector 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 toAC end-to-end protection, and is not a replacement for centralized 802.11 encryption. Support of centralized encryption has been part of CAPWAP/802.11 from the beginning,and provides unique advantages, including elimination of the Key RSC issue, and support ofAPs 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 802.11i. • 802.11 encryption from STA to AC has different properties than STA-WTP + WTP-AC • 2. This proposal will break some existing (and possibly future) 802.11 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 802.11 function that makes use of service periods (e.g., 802.11e) 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 25th: No consensus to remove centralized encryption

4. Issue 90 - Using 802.3 for tunnelling in Split-MAC mode • One of the recommendations of the evaluation team was to have a mode to tunnel 802.3 frames between WTP and AC. It seems that that requirement was interpreted as tunneling 802.3 frames for local MAC. • However after talking to various folks at IETF 65 (dallas), it seems the intent was to tunnel 802.3 frames in the split MAC (and not local MAC). Hence I would propose the following: • (a) Delete the tunneling of 802.3 frames between AC<->WTP for Local MAC and replace it with (b). • (b) Add tunneling 802.3 frames between AC <-> WTP for Split MAC. Following the notation in section 11.1.1, 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 11.1.1 with * (note: section 11.1.1 remains unchanged - this proposal is an addition to and not a replacement for section 11.1.1): 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 802.11e Classifying AC Scheduling *WTP* (I don't understand why section 11.1.1 shows .11e scheduling at AC) Queuing WTP 802.11i 802.1X/EAP AC Key Management AC 802.11 Encryption/Decryption *WTP* • Jan 25th: Consensus to resolve issue 90 by fixing Local Mac mode: change 2.1.2 in -01, adding “/AC” in Figure 4 in the Distribution Service and Assoc/Disassoc/Reassoc lines