Subject: Re: [Capwap] need clarification on UDP ports

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 07:05:24 -0700

Have you considered that some hardware may be providing an interface to
hardware DTLS logic prior to forking off to data or control plane
processing?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Hasan Raza [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 6:33 AM
> To: Pat Calhoun (pacalhou)
> Cc: Margaret Wasserman; Scott G. Kelly; [email-masked]; capwap
> Subject: RE: [Capwap] need clarification on UDP ports
> 
> On Thu, 2006-10-26 at 03:44 -0700, Pat Calhoun (pacalhou) wrote:
> > ok... no real objections on including an interim (short) tag to 
> > represent the packet type. If we are to go down this path, I would 
> > prefer that we maintain consistency across both the control 
> and data 
> > plane, and include the same header on both UDP ports. This 
> way, if a 
> > DTLS session is being used to secure the data plane, the 
> (relatively) 
> > same pre-parsing and security validation logic can be used.
> Usually data plane is implemented in hardware and control 
> plane in software. Though a bit tricky, but bump in the stack 
> is easier to implement in software than hardware. Changing 
> fast path logic in hardware just for capwap packets may not 
> be worth an effort if the extra type header field does not 
> serve any purpose. Since it is more or less decided that DTLS 
> is enabled or disabled on data plane is just based on a 
> binary configuration at AC, there does not seem to be any 
> purpose of extra type header field for data packets. May be 
> we should look into issue #221.
> 
> Hasan
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Hasan Raza <[email-masked]>
Date: Thu, 26 Oct 2006 20:07:27 +0530

In that case, the capwap control port would be different from capwap
data port in a manner as any other non-capwap udp port which may need
DTLS processing. The type header stripping logic would be anyway
implemented on the port basis as an special case for capwap port(s). So
why this special case should be there for two ports if the second port
does not require it?

Hasan

---

From: Scott G Kelly <[email-masked]>
Date: Thu, 26 Oct 2006 07:50:47 -0700

But I think the assumption that encryption on the data port is binary 
on/off is a little premature. I think that for any given WTP, it will be 
binary, but that for a given deployment, some WTPs could require data 
channel encryption while others do not.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 26 Oct 2006 12:48:44 -0400

Hi Scott,

> channel encryption while others do not.

Good point.  I'm now convinced (by this note and Pat's) that it would  
be best to include a short header on both the data and control  
channels to indicate whether the packet is a DTLS packet or an  
unencrypted packet.

Margaret