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

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 18 Dec 2006 22:52:20 -0800

Hi Scott,

This pkt needs to be periodic otherwise the nat state in the nat gateway will get timed out during extended periods of capwap data inactivity. 

This again is an artifact of a separate tunnel for data vs control. If needed, we will need to tie it to the protocol exchange (I agree).

Thanks

Puneet

Sent from my handheld enabled by Broadcom EDGE/GPRS/GSM Processor and Bluetooth Technologies (www.broadcom.com)

 -----Original Message-----
From: 	Scott G Kelly [mailto:[email-masked]]
Sent:	Monday, December 18, 2006 08:05 PM Pacific Standard Time
To:	Puneet Agarwal
Cc:	Charles Clancy; Jim Murphy; capwap
Subject:	Re: [Capwap] Necessity of Session ID in unencrypted Data Channel

Puneet Agarwal wrote:
> 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.
> 

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

> 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,
> 
> 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
> 
> Jim Murphy wrote:
>> 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
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 

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

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

---

From: Scott G Kelly <[email-masked]>
Date: Tue, 19 Dec 2006 05:57:54 -0800

Hi Puneet,

I wasn't saying a keepalive is not required, and agree with what you say 
below. I was just suggesting that since you only need the sessionID in 
the first exchange, and since that exchange is semantically different 
than a keepalive, it might make sense to consider making this a separate 
(uniquely named) exchange. But I'm not stuck on this.

In any event, I think everyone needs to respond to the bigger question 
Pat asked, that being, do we want to incur the signaling cost in 
exchange for the per-packet overhead savings? It seems like a reasonable 
trade-off to me, but I'd like to hear what others here think.

Scott

Puneet Agarwal wrote:
> Hi Scott,
> 
> This pkt needs to be periodic otherwise the nat state in the nat
> gateway will get timed out during extended periods of capwap data
> inactivity.
> 
> This again is an artifact of a separate tunnel for data vs control.
> If needed, we will need to tie it to the protocol exchange (I agree).
> 
> 
> Thanks
> 
> Puneet
> 
> Sent from my handheld enabled by Broadcom EDGE/GPRS/GSM Processor and
> Bluetooth Technologies (www.broadcom.com)
> 
> -----Original Message----- From: 	Scott G Kelly
> [mailto:[email-masked]] Sent:	Monday, December 18, 2006 08:05
> PM Pacific Standard Time To:	Puneet Agarwal Cc:	Charles Clancy; Jim
> Murphy; capwap Subject:	Re: [Capwap] Necessity of Session ID in
> unencrypted Data Channel
> 
> Puneet Agarwal wrote:
>> 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.
>> 
> 
> 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.
> 
> 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
> 
>> 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,
>> 
>> 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
>> 
>> Jim Murphy wrote:
>>> Hi,
>>> 
>>>  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
>>>