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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 9 Jun 2006 06:31:55 -0700

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:18:03 -0700 (PDT)

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