Subject: [Capwap] Proposed Resolution to Issue 138 - Support and negotiation of WTP data encryption in the CAPWAP protocol

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 11 Jan 2007 07:14:18 -0800

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

(b) The commenter proposes to disallow the use of centralized
802.11encryption, 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.11encryption.
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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 17 Jan 2007 08:17:31 -0800

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:[email-masked]] 
	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,

	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: 
	
	(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