Capwap Mailing List: Re: Encryption Capabilities

[Abhijit Choudhury (Abhijit]

Title: Re: [Capwap] Encryption Capabilities

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:clancy [at] cs.umd.edu]
Sent: Tue 6/6/2006 7:53 PM
To: Pat Calhoun (pacalhou)
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] Encryption Capabilities

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.  <>  tcc [at] umd.edu  <>  www.cs.umd.edu/~clancy

Pat Calhoun (pacalhou) wrote:
> 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:dstanley1389 [at] gmail.com]
>     *Sent:* Monday, June 05, 2006 5:04 PM
>     *To:* Pat Calhoun (pacalhou)
>     *Cc:* Michael Montemurro; David T. Perkins; capwap [at] frascone.com
>     *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)* <pcalhoun [at] cisco.com
>     <mailto:pcalhoun [at] cisco.com>> 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:montemurro.michael [at] gmail.com
>             <mailto:montemurro.michael [at] gmail.com>]
>             *Sent:* Saturday, June 03, 2006 12:12 PM
>             *To:* David T. Perkins
>             *Cc:* capwap [at] frascone.com <mailto:capwap [at] frascone.com>
>             *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* <montemurro.michael [at] gmail.com
>         <mailto:montemurro.michael [at] gmail.com>> wrote:
>
>             David,
>
>             I've created issue 125 to track this issue.
>             
>             Mike
>
>             
>             On 6/1/06, *David T. Perkins* <dperkins [at] dsperkins.com
>             <mailto:dperkins [at] dsperkins.com>> 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
>                 <http://lists.frascone.com/mailman/listinfo/capwap>
>
>                 Archives: http://lists.frascone.com/pipermail/capwap
>                 <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
>         <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