Subject: Re: [Capwap] Encryption Capabilities

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 6 Jun 2006 10:12:45 -0700

But what we end up doing is providing two means to do the exact same
thing. I admit that I was surprised when the optional DTLS support was
added for data frames in the CAPWAP draft. However, having thought
through the impact of this change, it actually does address the previous
issues I had raised against centralized 802.11i security, which are:
 
1. By encrypting at the AC, how does one support 802.11e (specifically
frame fragmentation to fit a service period)
2. How does the AC provide 802.11n A-MPDU/MSDU aggregation?
 
So I would propose we define one way, and I prefer the DTLS mechanism as
it doesn't introduce any issues in supporting any 802.11 feature.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Monday, June 05, 2006 5:04 PM
	To: Pat Calhoun (pacalhou)
	Cc: Michael Montemurro; David T. Perkins; [email-masked]
	Subject: Re: [Capwap] Encryption Capabilities

	I do not agree with always requiring the WTP to provide wireless
	encryption. The split MAC architecture allows 802.11
encryption/decryption
	at either the WTP or the AC, and this flexibility should be
retained, with use of the
	field in question clearly defined.
	
	Dorothy

	On 6/5/06, Pat Calhoun (pacalhou) <[email-masked]> wrote: 

		Actually, this field was intended to allow the WTP to
communicate whether it is capable of providing its capabilities, and
therefore allow the AC to determine whether it should perform
centralized encryption. However, 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. 

		Pat Calhoun
		CTO, Wireless Networking Business Unit
		Cisco Systems

________________________________

			From: Michael Montemurro
[mailto:[email-masked]] 
			Sent: Saturday, June 03, 2006 12:12 PM
			To: David T. Perkins
			Cc: [email-masked]
			Subject: Re: [Capwap] Encryption Capabilities

		David,
		 
		Would it be sufficient to move Encryption Capabilities
from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information
message element (Section 4.4.39)?
		 
		Mike

		On 6/3/06, Michael Montemurro
<[email-masked]> wrote: 

			David, 
			
			I've created issue 125 to track this issue.
			 
			Mike

			On 6/1/06, David T. Perkins
<[email-masked] > wrote: 

				HI,
				
				The "(4.4.34)WTP Descriptor" message
element has the
				subfield "encryption capabilities". What
is this used 
				for? If for radios, then it should be
per radio. If
				for the user data between the WTP and
AC, then
				it doesn't seem appropriate to say the
value is
				defined by "specific binding"
definitions because
				the WTP can be supporting multiple
radios with
				some that provide encryption services
and some
				that don't.
				
				In general, I don't feel that this
subfield is
				well defined, and it appears to me that
it
				should be a per radio attribute. 
				
				Regards,
				/david t. perkins

_________________________________________________________________
				To unsubscribe or modify your
subscription options, please visit:
	
http://lists.frascone.com/mailman/listinfo/capwap 
				
				Archives:
http://lists.frascone.com/pipermail/capwap 

_________________________________________________________________
		To unsubscribe or modify your subscription options,
please visit:
		http://lists.frascone.com/mailman/listinfo/capwap
		
		Archives: http://lists.frascone.com/pipermail/capwap 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Charles Clancy <[email-masked]>
Date: Tue, 06 Jun 2006 22:53:24 -0400

Removing centralized encryption doesn't change the security properties 
of CAPWAP.

HOWEVER, if you really want packets encrypted all the way to the AC, and 
you remove centralized encryption, your WTPs first have to decrypt the 
802.11 packet, and then re-encrypt it for DTLS transport.  This seems 
like a lot of extra processor time for devices that need to be cheap and 
disposable.  For example, OpenSSL on my dual 2.8GHz P4 machine can 
process AES at roughly 424Mbps [1].  An embedded device with 1/10 my 
processing power could only keep up with a 21.2 Mbps data flow.

[1] openssl speed -elapsed -evp aes-128-cbc

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

Pat Calhoun (pacalhou) wrote:
>     ------------------------------------------------------------------------
>     *From:* Dorothy Stanley [mailto:[email-masked]]
>     *Sent:* Monday, June 05, 2006 5:04 PM
>     *To:* Pat Calhoun (pacalhou)
>     *Cc:* Michael Montemurro; David T. Perkins; [email-masked]
>     *Subject:* Re: [Capwap] Encryption Capabilities
> 
> 
>     On 6/5/06, *Pat Calhoun (pacalhou)* <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         communicate whether it is capable of providing its capabilities,
>         and therefore allow the AC to determine whether it should
>         perform centralized encryption. However, 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.
>          
> 
>         Pat Calhoun
>             ------------------------------------------------------------------------
>             *From:* Michael Montemurro
>             [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Sent:* Saturday, June 03, 2006 12:12 PM
>             *To:* David T. Perkins
>             *Cc:* [email-masked] <mailto:[email-masked]>
>             *Subject:* Re: [Capwap] Encryption Capabilities
> 
>         David,
>          
>         Would it be sufficient to move Encryption Capabilities from the
>         WTP Descriptor (Section 4.4.34) to the WTP Radio Information
>         On 6/3/06, *Michael Montemurro* <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             David,
> 
>             On 6/1/06, *David T. Perkins* <[email-masked]
>             <mailto:[email-masked]>> wrote:
> 
>                 HI,
> 
>                 The "(4.4.34)WTP Descriptor" message element has the
>                 subfield "encryption capabilities". What is this used
>                 for? If for radios, then it should be per radio. If
>                 for the user data between the WTP and AC, then
>                 it doesn't seem appropriate to say the value is
>                 defined by "specific binding" definitions because
>                 the WTP can be supporting multiple radios with
>                 some that provide encryption services and some
>                 that don't.
> 
>                 In general, I don't feel that this subfield is
>                 well defined, and it appears to me that it
>                 <http://lists.frascone.com/mailman/listinfo/capwap>
> 
>                 <http://lists.frascone.com/pipermail/capwap>
> 
> 
> 
> 
>         <http://lists.frascone.com/pipermail/capwap>
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Tue, 6 Jun 2006 22:20:01 -0700

Charles,
I agree with you.  I don't see why this option needs
to be removed.   
 
As you have noted,  DTLS in the data path is going
to require the WTPs to seriously beef up their
crypto capabilities, especially with 802.11n around
the corner.  Terminating roughly 300-350Mbps of
802.11i encryption traffic and then re-encrypting it
for DTLS is going to be a challenge at low cost points.
 
It's amusing that within a span of roughly
2 years we have gone from "fat"  APs to "fit" APs and
now to "weight-lifter" APs. :-)
 
Abhijit

From: Charles Clancy [mailto:[email-masked]]
Sent: Tue 6/6/2006 7:53 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Encryption Capabilities