Capwap Mailing List: Re: New mux header for CAPWAP

[Pat Calhoun (pacalhou) (pcalhoun]

> This is quite restrictive.  An AC can have some data traffic 
> from a remote office and require DTLS on that traffic, as 
> well as some traffic coming from within the local premises 
> for which it may not require DTLS in the data plane.  DTLS on 
> the data plane should be a property of the specific tunnel. 
> This needs to supported.

Perhaps I wasn't clear, this is done on a per WTP basis. I can't
imagine some traffic being in the clear, and some not. I see the
decision to encrypt the data plane, on a per WTP basis, as a binary
decision.

> In general, it is a better design to have the packet fields 
> clearly indicate that what the nature of the payload is, 
> rather than depend on lookups of policy tables to decide how 
> to parse the packet.

The reality is that you have to do the policy lookup anyhow. You
don't want to accept an unencrypted packet, when the policy
requires it to be. So you can't avoid this lookup.


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

> -----Original Message-----
> From: Abhijit Choudhury [mailto:Abhijit [at] sinett.com] 
> Sent: Friday, June 09, 2006 1:01 PM
> To: Pat Calhoun (pacalhou); David T. Perkins
> Cc: capwap [at] frascone.com
> Subject: RE: [Capwap] New mux header for CAPWAP
> 
>       Pat wrote:
> 
>       Actually, I disagree. First of all, relying on a bit that states
> 
>       whether the data frame is encrypted or not is irrelevant because
> 
>       the AC (and WTP, for that matter) will probably rely on 
> the policy 
>       negotiated during the control plane setup more than the bit.
> 
>       For instance, if the AC stated that DTLS was required 
> on the data 
>       plane, would it accept a packet in the clear? No, so I 
> don't think 
>       we need to signal that the data plane is explicitely encrypted.
> If 
>       it doesn't comply to the negotiated mode of operation, 
> it is dropped.
> 
>       For that matter, only 2 ports are needed.
> 
> 
> 
> 
> Abhijit
>