Capwap Mailing List: Re: Use of SESSION ID

[Scott G. Kelly (s.kelly]

Hi Abhijit,

I thought about this quite a bit overnight, and realized I jumped the gun in 
replying to David's initial post. I think David is right, if you assume a mux 
header: since the dtls session is identified by source IP/port, and the control 
channel and data channel live and die together, there is no need for a session 
ID in that case. The session is entirely identified by source IP address and 
port (and the data channel is tightly bound to the control channel).

Scott

-----Original Message-----
>From: Abhijit Choudhury <Abhijit [at] sinett.com>
>Sent: Jun 2, 2006 11:48 AM
>To: "Scott G. Kelly" <scott [at] hyperthought.com>, "David T. Perkins" 
><dperkins [at] dsperkins.com>, capwap [at] frascone.com, "Pat Calhoun 
>(pacalhou)" <pcalhoun [at] cisco.com>
>Subject: RE: [Capwap] Use of SESSION ID
>
>Interesting....
>
>If we are carrying a SessionId in the CAPWAP header,
>it opens up lots of possibilities.  
>
>Here're some thoughts:
>
>1. Currently, as proposed below, the SessionID is
>   in the CAPWAP header and that is inside the DTLS
>   payload.  I'm not sure why the format cannot be 
>
>      IP/UDP/CAPWAP/DTLS/payload
>
>   instead of 
>      IP/UDP/Shim/DTLS/CAPWAP/payload
>
>   There is nothing really confidential in the CAPWAP
>   header, and so there is no reason it cannot 
>   be outside the DTLS.  If it is outside, it could
>   very well indicate the Data/Control information,
>   as well as the SessionId.
>   
>2. If the session ID is available outside the DTLS
>   payload it's possible to support 2 separate UDP
>   ports for control and data.  The SessionId can
>   be used to bind them even if there are NAT boxes
>   the path.
>
>3. Even if you don't agree to (1), we can put the
>   sessionId in the Shim and be able to support 
>   2 separate UDP ports based on (2).
>
>4. We need some indication in the header itself
>   to show if the Data payload is DTLS encrypted.
>   There could very well be some data sessions that
>   have DTLS encryption and some that don't.
>
>Thanks,
>   Abhijit
>
>-----Original Message-----
>From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
>Sent: Thursday, June 01, 2006 3:49 PM
>To: David T. Perkins; capwap [at] frascone.com
>Subject: Re: [Capwap] Use of SESSION ID
>
>
>Hi David,
>
>Good catch - I think that got lost in the shuffle of the various header
>changes. The session ID is required for capwap processing, and is
>independent of the DTLS session (and you need it for the data channel,
>too). I think it needs to be included in the generic capwap header. That
>is currently defined as follows:
>
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Version|   RID   | HLEN  |F|L|W|M|            Flags
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Fragment ID          |     Frag Offset
>|Rsv-2|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                 (optional) Radio MAC Address
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |            (optional) Wireless Specific Information
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                        Payload ....
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>But it should probably be like this, instead:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Version|   RID   | HLEN  |F|L|W|M|            Flags
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Fragment ID          |     Frag Offset
>|Rsv-2|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                          Session ID
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                 (optional) Radio MAC Address
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |            (optional) Wireless Specific Information
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                        Payload ....
>|
> 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>--Scott
>
>
>-----Original Message-----
>>From: "David T. Perkins" <dperkins [at] dsperkins.com>
>>Sent: Jun 1, 2006 3:22 PM
>>To: capwap [at] frascone.com
>>Subject: [Capwap] Use of SESSION ID
>>
>>HI,
>>
>>The join request operation contains the "Session ID" information 
>>element. Where is this used after the join? Is it somehow related to 
>>the DTLS session ID?
>>
>>Regards,
>>/david t. perkins
>>
>>_________________________________________________________________
>>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