Capwap Mailing List: Re: New mux header for CAPWAP

[Pat Calhoun (pacalhou) (pcalhoun]

Wow - I'm embarassed I missed your point, I see what you are stating
now.

>      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

There has never been a mention that the control plane would be in the
clear, so I believe we can remove that element. The issue I have 
with this proposal is that fields in the CAPWAP header are not
protected.

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

Actually, I disagree. First of all, relying on a bit that states 
whether the data frame is encrypted or not is irrelevant because 
the AC (and WTP, for that matter) will probably rely on the policy
negotiated during the control plane setup more than the bit.

For instance, if the AC stated that DTLS was required on the data
plane, would it accept a packet in the clear? No, so I don't think
we need to signal that the data plane is explicitely encrypted. If
it doesn't comply to the negotiated mode of operation, it is dropped.

For that matter, only 2 ports are needed.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins [at] dsperkins.com] 
> Sent: Friday, June 09, 2006 8:59 AM
> To: Pat Calhoun (pacalhou)
> Cc: Rohit Suri (rsuri); capwap [at] frascone.com
> Subject: RE: [Capwap] New mux header for CAPWAP
> 
> 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
> 
> 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
>