Capwap Mailing List: Re: New mux header for CAPWAP

[David T. Perkins (dperkins]

HI,

DISCOVERY request/response are control and have to
be in the clear. Otherwise, all other control 
traffic is protected.

On data traffic, one might want to encrypt some
data streams from a WTP and not encrypt other
streams. (For example, why encrypt data using
an "open SSID"?)

So, when add it all up, there are 4 types
of CAPWAP traffic as specific by the type field
below.

Regards,
/david t. perkins

On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote:
> 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
> > 
>