Subject: Re: [Capwap] Encryption Capabilities

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 8 Jun 2006 09:45:18 -0700

> The text refers to 
> comparing the 802.11 crypto with DTLS crypto, noting that the
> DTLS crypto would not necessarily re-use the 802.11 hardware
> engine, and referencing Charles' comment:
	
>>Yes, DTLS provides a superset of security, but also triples the
>>computational requirements.  My point is that in many cases, the
subset
>>of security offered by 11i encryption is sufficient.

True, but Charles also stated:
> Terminating 11i at the WTP and optionally using DTLS makes much more
> sense in the larger security paradigm. Then everything's clean and
> modular.	

> I agree that 802.11 chipsets shipping today support hardware crypto-
> AES-CCMP, and RC4-TKIP/WEP to be specific.
> There are also "legacy" devices out there that just support 
> WEP/TKIP in hardware/firmware -  one example which would use
> existing CAPWAP support of 802.11i crypto at the AC to provide
> AES encryption, independent of the WTP-AC
> channel security discussion.

I agree, but would claim that the devices you claim are *really* old -
and
I would even wonder whether they would be capable of supporting many
other
CAPWAP features, such as multiple SSIDs, 802.11e, etc. Further, AES
capable
APs appeared in the market as early as 2002 (maybe earlier, but this is
the
first reference I can find quickly) - that's four years ago. I think
those
customers have had a good return on their investment already. Not clear
we
need to optimize today's protocol for those devices.

So I'll return to the original question, how does "centralized
encryption"
Allow CAPWAP WTPs to NOT BREAK the 802.11 protocol and provide:
1. 802.11e frame fragmentation (fragment to fit a TXOP)
2. 802.11n A-MSDU aggregation (even though we may opt to not include
802.11n
support in the first version, going out of our way to not support the
protocol
seems like a bad idea)

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 8 Jun 2006 12:17:15 -0700

Pat,

Comments inline.

Thanks,

Dorothy

> > sense in the larger security paradigm. Then everything's clean and

I disagree with this additional statement. Terminating .11i at the WTP
and then using DTLS is one option. Depending on one's goals and
constraints, it may or may not be the right security paradigm of the
the desired solution. See Scott's post on the two scenarios, which have
their
pros and cons, and should both remain in the spec.

> need to optimize today's protocol for those devices.

We are not optimizing for those devices. We are allowing, in an optional
configuration for support of those kind of devices and applications, and not
closing the door on flexibility in the protocol, and architecural
flexibility.
There is still a fair amount of legacy equipment out there for this example,
WPA testing is still required for Wi-Fi certification for this reason.

> support in the first version, going out of our way to not support the

Providing centralized encryption has a wide range of pros and cons.
Providing
encryption at the WTP has a wide range of pros and cons. The feature
needs of the application and specific vendor choices will dictate which one
is used.
Tthe CAPWAP protocol as currently written can support both cases and should
continue to do so.

Pat Calhoun