Capwap Mailing List: Re: New mux header for CAPWAP

[David T. Perkins (dperkins]

HI,

Thanks for the note. It looks like what you are calling
CAPWAP Pkt header differs from my use of that term.
Here are my diagrams....
  CAPWAP Packet formats:


    CAPWAP Unprotected Data Packet:
    +-----------------------------------------+
    | IP  | UDP  | CAPWAP | CAPWAP | Wireless |
    | Hdr | Hdr  | Pkt    | Data   | Payload  |
    |     |      | Hdr    | Hdr    |          |
    +-----------------------------------------+


    CAPWAP DTLS Protected Data Packet:
    +-----------------------------------------------------------+
    | IP  | UDP | CAPWAP | DTLS  | CAPWAP  | Wireless | DTLS    |
    | Hdr | Hdr | Pkt    | Hdr   | Data    | Payload  | Trailer |
    |     |     | Hdr    |       | Hdr     |          |         |
    +-----------------------------------------------------------+
                         \--integrity checked---------/
                                 \--encrypted-------------------/


    CAPWAP Unprotected Control Packet:
    +------------------------------------------+
    | IP  | UDP  | CAPWAP | CAPWAP  | Message  |
    | Hdr | Hdr  | Pkt    | Control | Elements |
    |     |      | Hdr    | Hdr     |          |
    +------------------------------------------+


    CAPWAP DTLS Protected Control Packet:
    +----------------------------------------------------------+
    | IP  | UDP | CAPWAP | DTLS | CAPWAP  | Message  | DTLS    |
    | Hdr | Hdr | Pkt    | Hdr  | Control | Elements | Trailer |
    |     |     | Hdr    |      | Hdr     |          |         |
    +----------------------------------------------------------+
                          \--integrity checked-------/
                                \--encrypted-------------------/

As you can see above there is ALWAYs a 2 octet 
"CAPWAP Pkt Hdr" in EVERY CAPWAP packet. The format is:
  CAPWAP Pkt Header:
                         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version       |    Type       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version - the version of the CAPWAP protocol (the first is 0)
                DISCUSS: should this be split into major and minor,
                         and if so, what are the implications of
                         an increment of the major or minor part?

      Type - packet type, values are:
                1 - CAPWAP Unprotected Data Packet
                2 - CAPWAP DTLS Protected Data Packet
                3 - CAPWAP Unprotected Control Packet
                4 - CAPWAP DTLS Protected Control Packet
               0,5-15 - reserved

This is needed because if CAPWAP packets have the format
that you show below, the it is ambiguous whether or
not a DTLS header is present. (Note, I've actually looked
at having packets in that format. To do so would meen
that a CAPWAP header would have the syntax of a DTLS
header, but use types not yet used, and have the
TLS/DTLS spec reserve those type values for applications.
This is doable, but I feel, would be the leading
FAQ.

I hope this is clearer. (If not, call me)

Note, if we were using UDP, we would need 4 ports
(see the 4 types above).

On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote:
> Dave, 
> 
> The proposal you have made relies on a bit in the header, but the
> issue here is that the CAPWAP header is actually encrypted when
> DTLS is on - so I don't see how we can rely on that bit. Perhaps I
> am missing something fundamental in your point, though, and if so
> I apologize in advance.
> 
> What I've been trying to state is that UDP *is* a multiplexor
> technology. We already have a method of differentiating the
> control and/or data using UDP.
> 
> My revised diagram:
> 
>   CAPWAP Pkt Header:
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |  UDP Header   |  DTLS Header  | CAPWAP Header |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                     *optional header*
> 
> What confuses me at this point is that if UDP can provide the exact
> same functions as the MUX header, why is Scott stating that DTLS
> can run over any arbitrary underlying transport without any
> complexity - yet is pushing back that doing this over two UDP
> ports is complex? The only issue that I am aware of that is
> additional complexity with dual ports is the have some form of
> keepalive on the data plane to handle NATed environments. This
> Is a very simply problem to solve. Otherwise, to Scott's point,
> DTLS doesn't care what it runs over.
> 
> Hence my confusion.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems