Subject: [Capwap] Necessity of Session ID in unencrypted Data Channel

From: Jim Murphy <[email-masked]>
Date: Thu, 14 Dec 2006 17:12:30 -0800

Hi,

I would like to open up a discussion on the list regarding the
necessity of the session ID in the unencrypted data channel.

The argument for the session ID is to allow one to correlate
the control and data channels when addresses and ports are modified
by NAT devices.

The downside of the session ID is additional overhead in the CAPWAP
tunneling encapsulation. We can have arguments about how bad this
overhead is in the real world, but it is clear that forwarding
performance and scaling using CAPWAP will be worse than existing
solutions that have smaller encapsulation headers.

As has been discussed on the list in the past, in order to maintain
the state in the NAT device, the data channel will require periodic
keep-alives. This email proposes that only the periodic keep-alives
must contain the session ID, note that the session ID need not be part
of the CAPWAP header. When an AC receives a keep-alive on the
data channel it can correlate data channel address and ports with the
control channel and plum the forwarding path accordingly.

Thanks,

Jim

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Charles Clancy <[email-masked]>
Date: Mon, 18 Dec 2006 08:54:25 -0500

Jim,

We'd have to guarantee that a keep-alive was sent before any other 
packets on the data channel.  Then correlation could be done based on 
the DTLS context or ip/port (if data channel unencrypted).  If so, then 
it should be okay.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 18 Dec 2006 18:40:16 -0800

I agree with Charles. It should not be too hard to guarantee a keepalive
to be sent on the data-channel before other traffic.

Looks like we can take out the session id from the regular capwap data
frames.

Thanks.

-Puneet

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 5:54 AM
To: Jim Murphy
Cc: capwap
Subject: Re: [Capwap] Necessity of Session ID in unencrypted Data
Channel

Jim,

Jim Murphy wrote:
> The argument for the session ID is to allow one to correlate the 
> control and data channels when addresses and ports are modified by NAT

> devices.

> of the CAPWAP header. When an AC receives a keep-alive on the data 
> channel it can correlate data channel address and ports with the

---

From: Scott G Kelly <[email-masked]>
Date: Mon, 18 Dec 2006 20:05:14 -0800

> Looks like we can take out the session id from the regular capwap data

There's a little more to specify: the initial data channel packet 
containing the sessionID MUST be acknowledged before any data is sent. 
Otherwise, if the set-up packet is lost, the subsequent data must be 
dropped by the AC, and there is no defined way to let the WTP know it 
needs to send the sessionID again.

This approach saves you 8 bytes per data packet at the cost of 
additional connection set-up latency (and a small amount of added 
complexity). Given that this is a "special" connection setup packet, I'm 
not sure calling it a keepalive is appropriate. It seems like if we are 
going to take this approach, it might make sense to define a specific 
protocol exchange for this purpose.

Scott