Subject: Re: [Capwap] Encryption Capabilities

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 12 Jun 2006 08:04:05 -0700

However, the MUX issue has raised another interesting problem,
which
	was raised by Scott, which is that in order for the WTP to
perform 
	packet classification, and tagging, it needs to have access to
the
	data frames in the clear, which is not possible with this
feature.

The WTP can perform marking by
mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings 
Access to data frames in the clear is not needed.

As raised a few times, one cannot trust a client's marking. Centralized
802.11i encryption does not allow the WTP to inspect packets for TSPEC
conformance.

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: "Michael Montemurro" <[email-masked]>
Date: Mon, 12 Jun 2006 14:57:51 -0400

So, again I propose the following changes for draft 2.0:

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).

This addresses the comment on the WTP Descriptor and that change can be made
for draft 2.0.

Now it seems there is another broader issue on the support for different
modes of wireless link layer encryption in the CAPWAP architecture. I've
created issue 138 to address this issue.

Cheers,

     Mike

On 6/12/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
>   However, the MUX issue has raised another interesting problem, which
> > was raised by Scott, which is that in order for the WTP to perform
> > packet classification, and tagging, it needs to have access to the
> > data frames in the clear, which is not possible with this feature.
>
>