Subject: Re: [Capwap] Encryption Capabilities

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 7 Jun 2006 14:19:25 -0700

> As you mention, 802.11i encryption/decryption at the AC can
> provide a subset of the security (over the WTP-AC link) for a
> fraction of the processing time, likely to be a very practical, real 
> concern for WTP devices. 
 
Dorothy, I don't think that's a very fair statement. There is no 802.11
chipset that is selling today, which I am aware of, that doesn't support
hardware crypto. The impact on the WTP's processor is negligible. 

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: Wed, 7 Jun 2006 16:26:47 -0700

Pat,

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.

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.

Dorothy

On 6/7/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> Dorothy, I don't think that's a very fair statement. There is no 802.11chipset that is selling today, which I am aware of, that doesn't support

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 7 Jun 2006 17:41:26 -0700 (PDT)

HI,

Section 4.3.1 shows the header for control messages, and has
a 32 bit field for the message type value, which is described
in section 4.3.1.1 shown below. There is a typo in the text.
It is marked with the correction.

-------------------------
4.3.1.1.  Message Type

   The Message Type field identifies the function of the CAPWAP control
   message.  The Message Type field is comprised of an IANA Enterprise
   Number and a message type value field.  The first two byte contain
                                                     ^^^^^^^^
                                             should be "three octets"
   the IANA Enterprise Number (for example, the IEEE 802.11 IANA
   Enterprise number is 13277), and the second two bytes contain the
                                        ^^^^^^^^^^^^^^^^
                                        should be "last octet"
   Message Type value.  The message type field can be expressed as:

   Message Type = IANA Enterprise Number * 256 + Message Type Value
--------------------------

Note, the above is an OK fix, but I'd change the text to the
following to make it clearer.

4.3.1.1.  Message Type

   The Message Type field identifies the function of the CAPWAP control
   message.  The Message Type field is comprised of an IANA Enterprise
   Number[IANA.enterpriseNumber.ref] and an enterprise specific message
   type number.  The first three octets is the enterprise number in
   network byte order, with zero being used for CAPWAP generic
   message types and the IEEE 802.11 IANA assigned enterprise
   number 13277 being used for IEEE 802.11 technology specific
   message types. The last octet is the enterprise specific
   message type number, which has a range from 0 to 255.

   The value of the message type field can be expressed as:

   Message type value = IANA Enterprise Number * 256 +
                              enterprise specific message type number
   
--------------------------
And, I'd make the identification of the message elements encoded
identically. Thus, I'd change the message element header
in section 4.4 to the following format:

   0                   1                   2                   3   
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type                                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Length                      |  Value ...                                              
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-                                                

  Where the value of Type is expressed as:
  
  Message Element Type value = IANA Enterprise Number * 256 +
                                 enterprise specific type number

Regards,
/david t. perkins

---

From: "Michael Montemurro" <[email-masked]>
Date: Thu, 8 Jun 2006 21:52:09 -0400

I've captured this as issue 136.

I will fix in -02