Subject: Re: [Capwap] New mux header for CAPWAP

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 9 Jun 2006 08:34:03 -0700

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

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Friday, June 09, 2006 8:18 AM
> To: Pat Calhoun (pacalhou)
> Cc: Rohit Suri (rsuri); [email-masked]
> Subject: RE: [Capwap] New mux header for CAPWAP
> 
> HI,
> 
> LWAPP (and SNMPv3, which I know quite well) don't have a 
> packet header to distingush between protected and unprotected 
> payloads because the payload type is outside the encrypted 
> portion. In CAPWAP, the use of DTLS has the packet type in 
> the encrypted portion, and thus a packet header is needed 
> before the encrypted portion that specifies what follows.
> 
> I thought this was quite clear with the diagrams.
> Could you provide some suggestions to the disagrams or the 
> packet formats that I sent in the mail message to help make 
> sure that this is clear.
> 
> Regards,
> /david t. perkins
> 
> On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote:
> 
> > I don't believe this argument. It is being made to justify the MUX. 
> > The LWAPP protocol defined two UDP ports and no MUX.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:[email-masked]]
> > > Sent: Thursday, June 08, 2006 3:09 PM
> > > To: Rohit Suri (rsuri)
> > > Cc: [email-masked]
> > > Subject: Re: [Capwap] New mux header for CAPWAP
> > > 
> > > HI,
> > > 
> > > Did you see and understand the following from my message 
> from "Thu, 
> > > 8 Jun 2006 01:47:21 -0700 (PDT)" with subject "[Capwap] 
> Proposal for 
> > > CAPWAP packet format":
> > > 
> > >  NOTE: A CAPWAP MUX header is needed whether or not the same or
> > >         different UDP ports are used for CAPWAP control and
> > >         data messages. This is because both CAPWAP data and
> > >         control messages can be unprotected or protected by
> > >         DTLS, and the MUX header is needed to distinguish
> > >         protected from unprotected. Remember that CAPWAP
> > >         "discovery requests" and "discovery responses" are
> > >         unprotected, and that all other CAPWAP control
> > >         message types are protected.
> > > 
> > > It does not look like it was factored into your argument.
> > > 
> > > On Fri, 9 Jun 2006, Rohit Suri (rsuri) wrote:
> > > > I have been reading through the conversations on this 
> and I think 
> > > > there is a bigger issue that has not been considered. 
> Not allowing 
> > > > separation of data and control plane by using easy to
> > > recognize method
> > > > such as UDP ports would restrict system scaling. 
> Consider for the 
> > > > moment the fact that because we are bundling the 
> channels into a 
> > > > single crypto stream, it will become impossible to separate
> > > the control and data planes.
> > > > 
> > > >  I understand that this is not currently in the protocol,
> > > the reality
> > > > is that creating such a restriction today will dictate
> > > future systems. 
> > > > The side effect I believe is being lost is that an AC can
> > > only be as
> > > > fast as a single DTLS crypto accelerator. As faster 802.11 
> > > > technologies come around, such as 802.11n, there will be a need 
> > > > for bigger and faster systems. In order to solve this, 
> we will in 
> > > > the future have to remove the MUX and allow for the separation.
> > > > 
> > > > I think system scaling is much bigger issue than NAT, 
> which can be 
> > > > addressed by adding an keepalive mechanism in the data
> > > plane. We can
> > > > also do this only when we detect a NAT is in play (look 
> at outer 
> > > > IP address vs. a message element in the protocol). So 
> we can have 
> > > > our cake and eat it too.
> > > > 
> > > > Therefore, I personally feel very uncomfortable 
> crippling future 
> > > > products to up front protocol development time.
> > > > 
> > > > Regards
> > > > Rohit
> > > 
> > > 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

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 9 Jun 2006 08:59:19 -0700 (PDT)

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).