Subject: Re: [Capwap] Use of SESSION ID

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Sun, 4 Jun 2006 10:40:48 -0700

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:[email-masked]] 
Sent: Friday, June 02, 2006 5:31 PM
To: Bob O'Hara (boohara); [email-masked]
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:[email-masked]] 
Sent: Friday, June 02, 2006 12:02 PM
To: [email-masked]
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:[email-masked]] 
Sent: Friday, June 02, 2006 11:48 AM
To: Scott G. Kelly; David T. Perkins; [email-masked]; 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:[email-masked]] 
Sent: Thursday, June 01, 2006 3:49 PM
To: David T. Perkins; [email-masked]
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" <[email-masked]>
>Sent: Jun 1, 2006 3:22 PM
>To: [email-masked]
>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
_________________________________________________________________
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: Sun, 04 Jun 2006 11:31:59 -0700

> the "shim" header with a CAPWAP header and still run over a single UDP

I think we need to correct a potential misperception, that being that 
what is being proposed is kludgy, a "shim", and therefore worthy of 
denigration.  This has no technical justification - and it's what I've 
been referring to as misdirection, because it tends to evoke a 
pejorative interpretation which is neither technically justified nor 
appropriate.

CAPWAP is a single protocol which currently supports three classes of 
protocol data unit (PDU): discovery, control, and data. The proposed 
de-multiplexing mechanism is simply a PDU type field. We have ample 
precedence for the use of such PDU type fields in other widely deployed 
protocols such as tls, snmp, l2tp, pptp, and yes, even lwapp (where the 
'c' bit serves this function). Layered protocols are quite common in the 
Internet today.

Existing routers and switches have no difficulty in handling these 
widely deployed protocols, perhaps because they have no mandate other 
than to route and or switch the traffic. In particular, there has never 
been a general IETF protocol design requirement for routers and switches 
to be able to perform economy packet classication via tcp/udp ports - if 
there were, all protocols would be tcp/udp-based, and all of the various 
protocols' PDU's would be similarly decomposed by port. But they aren't.

Reiterating my earlier observation, backward compatibility with a 
particular vendor's legacy network gear in terms of identifying capwap 
internals is not a stated goal of this working group, nor should it be. 
It's not in the objectives draft, the architectural taxonomy, or the 
working group charter. It is not a requirement. And it's not in the 
common interest of the broader community - vendors *or* customers.

--Scott