Subject: Re: [Capwap] Encryption Capabilities

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Tue, 6 Jun 2006 21:43:03 -0700

Charles,

I think I agree with you though I'm not sure I understand the full
thread.

It seems that the current email thread is mixing the securing of
different transport layers, e.g. CAPWAP with that of 802.11i.

802.11i is designed to afford protection of the 802.11 transport layer,
providing both packet confidentiality and authentication; but it does
not address securing the CAPWAP transport layer.  An obvious example of
this is that the CAPWAP header is not authenticated!  

So whether the 802.11i crypto is done either at the WTP or AC should be
construed as a different feature than that of securing the CAPWAP
transport layer.  Also, I do not understand what the notion of
"centralized" encryption is as the client has no clue of the topology or
architecture behind the AP?

>From a threat model, if we are intending to address secure transport of
data packets within CAPWAP, doing 802.11i at the AC does not address
this requirement, CAPWAP must secure its own encapsulation as well.
That is why the draft includes the option of establishing a DTLS tunnel
for its data transport.  

   Nancy.

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, June 06, 2006 7:53 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
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.  <>  [email-masked]  <>  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:[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]
>     <mailto:[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]
>             <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
>         message element (Section 4.4.39)?
>          
>         Mike
> 
>          
>         On 6/3/06, *Michael Montemurro* <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             David,
> 
>             I've created issue 125 to track this issue.
>              
>             Mike
> 
>              
>             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
>                 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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: <[email-masked]>
Date: Wed, 7 Jun 2006 00:20:49 -0700

Hi Nancy,

Comments inline... 

-----Original Message-----
From: ext Nancy Winget (ncamwing) [mailto:[email-masked]] 
Sent: Tuesday, June 06, 2006 9:43 PM
To: Charles Clancy; Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Encryption Capabilities

Charles,

transport layer.  

/mgw/ Yes. I read Charles as also agreeing with this.

Also, I do not understand what the notion of "centralized" encryption is
as the client has no clue of the topology or architecture behind the AP?

/mgw/ The centralized comment refers to where the upstream 802.11i
decryption is happening. If it is happening at the AC endpoint of the
CAPWAP tunnel (centralized), then the WTP is only performing encryption
for the CAPWAP tunnel and is not involved in downstream OTA encryption.
If the .11i decryption is happening at the WTP, then the WTP is
decrypting packets from the STA first, then encrypting to send the clear
text packet through the protected CAPWAP tunnel upstream to the AC.

/mgw/ Agreed!

   Nancy.

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]]
Sent: Tuesday, June 06, 2006 7:53 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Encryption Capabilities

capabilities,
to
the

---

From: Charles Clancy <[email-masked]>
Date: Wed, 07 Jun 2006 09:24:58 -0400

Nancy,

You've brought up a good point.  Relying on 11i to encrypt data packets 
between the WTP and AC only provides confidentiality of the data, and 
does not protect the CAPWAP data transport protocol.

Each scenario has its pros and cons... this to me implies they should 
all be supported in the standard, and let users pick the one that fits 
their environment (though that can be dangerous when it comes to security).