Capwap Mailing List: Re: Use of SESSION ID

[Bob O'Hara (boohara) (boohara]

Abhijit,

I apologize if my original reply seemed to dismiss all of your
proposals.  I was addressing only the first proposal that was to replace
the "shim" header with a CAPWAP header and still run over a single UDP
port.

I believe that your second proposal is worth further discussion, as it
does seem to address the issue of existing switches and routers being
able to classify CAPWAP data and control traffic separately.  It does
leave us with the difficulties you describe below.

 -Bob
 
-----Original Message-----
From: Abhijit Choudhury [mailto:Abhijit [at] sinett.com] 
Sent: Friday, June 02, 2006 5:31 PM
To: Bob O'Hara (boohara); capwap [at] frascone.com
Subject: RE: [Capwap] Use of SESSION ID

Bob,

I have already addressed your concern in one 
of the proposals in my earlier email.  
If you look at point (2) below, separate UDP 
ports are used for control and data.
However, we still need to solve the following
two problems:

1. NAT traversal: That's where the SessionId
  in the CAPWAP header can help. It can bind
  the control and data channels together even
  if there is a NAT box in between the WTP and AC.

2. DTLS: For (1) to work, the SessionId needs
   to be outside the DTLS payload. That's why the
   the CAPWAP header carrying the sessionID 
   needs to be outside the DTLS payload. 
   
The result is an architecture that uses two 
separate UDP ports for control and data and can
support both NAT traversal as well as optional DTLS on 
the data path.
The packet format would be:

        IP/UDP/CAPWAP/DTLS/payload

Thanks,
   Abhijit




-----Original Message-----
From: Bob O'Hara (boohara) [mailto:boohara [at] cisco.com] 
Sent: Friday, June 02, 2006 12:02 PM
To: capwap [at] frascone.com
Subject: Re: [Capwap] Use of SESSION ID


Abhijit,

The use of the CAPWAP header to distinguish between control and data
suffers from all the same problems that using a custom shim for that
purpose, i.e., there is not a router or switch in the world that
understands either one.

 -Bob
 
-----Original Message-----
From: Abhijit Choudhury [mailto:Abhijit [at] sinett.com] 
Sent: Friday, June 02, 2006 11:48 AM
To: Scott G. Kelly; David T. Perkins; capwap [at] frascone.com; Pat Calhoun
(pacalhou)
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
_________________________________________________________________
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