Capwap Mailing List: Re: Proposed Resolution to Issue 138 - Support and negotiationof WTP data encryption in the CAPWAP protocol

[Pat Calhoun (pacalhou) (pcalhoun]

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.

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.

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

---

From: Dorothy Stanley [mailto:dstanley1389 [at] gmail.com]
Sent: Thursday, January 11, 2007 7:14 AM
To: capwap
Subject: [Capwap] Proposed Resolution to Issue 138 - Support and negotiationof WTP data encryption in the CAPWAP protocol

All,

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 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 802.11 encryption/decryption at
the 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.


(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 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 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 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 welcome,

Thanks,

Dorothy