Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

From: Abhijit Choudhury <[email-masked]>
Date: Thu, 18 Jan 2007 04:01:59 -0800 (PST)

Puneet,
Please see my comments in-line.
Abhijit

----- Original Message ----
From: Puneet Agarwal <[email-masked]>
To: Abhijit Choudhury <[email-masked]>; [email-masked]
Sent: Thursday, January 18, 2007 1:58:32 AM
Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

Hi Abhijit,
 
Looks like other protocols (including .11) did not have any issues putting this 1 bit in the non-protected part of their (.11) hdr and seem to have a very secure protocol (with WPA2 etc). One can always decide which hdr fields one want to include in the part covered by the authentication/encryption.
 
Hence I am having a hard time understanding why we in CAPWAP keep on insisting that the CAPWAP hdr (especially for CAPWAP DATA) needs to be after DTLS. It seems that having DTLS after CAPWAP hdr would be perfectly secure as well.
Hence I disagree with your assertion that DTLS hdr MUST be before CAPWAP hdr.
 
[Abhijit]  We should stay away from having different formats for CAPWAP CONTROL and
CAPWAP DATA.  There should be only one frame format -  the CAPWAP frame format.

As for what needs to be protected, there are parts of the CAPWAP header that needs 
to be protected (wireless info, radio mac etc) and other parts that may not.
I believe the group decided to protect the entire CAPWAP header in the mailing list earlier.  That is why the DTLS header is before the CAPWAP header.

My earlier position is still valid:
Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in the CAPWAP hdr for the encrypted payload flag.
 
Thanks.
 
-Puneet

From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 1:45 AM
To: Puneet Agarwal; [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

Hi Puneet,
 
Unfortunately, the CAPWAP header occurs after the DTLS header.
So, putting info there doesn't help. We need something
before the DTLS header .. all we have there is the IP
and UDP headers and we can't insert anything there.
 
Abhijit

----- Original Message ----
From: Puneet Agarwal <[email-masked]>
To: Abhijit Choudhury <[email-masked]>; Jim Murphy <[email-masked]>
Cc: [email-masked]
Sent: Thursday, January 18, 2007 1:31:30 AM
Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

Hi Abhijit,
 
The real issue is the fact that we are using a full 32 bits to add this 1 bit info. One would be perfectly happy if we put this 1 bit in the CAPWAP hdr (by using one of the flag bits). I speculate that .11 (using your example) would have had a fairly adverse reaction if one suggested adding 32 bits for one bit of info.
 
To your other point about high speed implementations: it depends on your particular implementation. There are many other high speed implementations that do not suffer from the issue that you describe.
 
Hence here is my position:
Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in the CAPWAP hdr for the encrypted payload flag.
 
Comments?
 
Thanks.
 
-Puneet

From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Wednesday, January 17, 2007 8:33 AM
To: Jim Murphy
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

Jim,
You are correct that the UDP port will
identify the packet to be a CAPWAP data 
packet or not.  However, the tunnel 
attribute that you mention, will typically
be the result of a lookup into some data
structure. Since some data tunnels could have
DTLS encryption and some may not, further
parsing of the packet will have to stall
until this lookup is done.  In high speed
implementations, this is not desirable.
 
As I said before, in a clean protocol design,
a packet should have all the information required 
to parse it.
For example, the 802.11 header has an
extended IV bit that indicates whether
the packet carries an extended IV or not.
It can argued that a client's traffic at
a radio will only have one kind of encryption
and hence this is not needed.  However,
this bit allows parsing of the packet without
looking into any client database.

Regards,
Abhijit

----- Original Message ----
From: Jim Murphy <[email-masked]>
To: Abhijit Choudhury <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, January 17, 2007 6:30:00 AM
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

If, as you suggest, DTLS encryption is an attribute of the
tunnel and not of the packet, then indeed the preamble is
superfluous.

There is no additional lookup required if the preamble is not
used. To identify a CAPWAP data packet, the forwarding plane
is plumbed with the data channel 5-tuple (src IP, dst IP, IP proto,
src port, dst port). The forwarding operation is to either decrypt
the packet if the tunnel attribute is DTLS encrypted or to CAPWAP
de-encapsulate if not. There is no need to look at the CAPWAP preamble
to make this decision - it is plumbed in directly.

Given that control and data are using different UDP ports and
most likely processed on completely different processors,
there is no technical or functional value in having uniformity
in headers.

Thanks,

Jim

Abhijit Choudhury wrote:
> There  is no question that the spec has to include a mechanism
> to establish an encrypted data channel.
>  
> I think the expectation is that the DTLS encryption of
> data channel packets will be enabled or not on a per-tunnel basis. 
> That said, I would still strongly recommend that the group consider
> a packet format that is uniform across the control and data channels.
>  
> In general, it is desirable to have enough information in
> a packet header to indicate what the packet format is.  No
> configuration lookups should be needed to parse the packet.
> This is what the proposed CAPWAP preamble header achieves.
> In a lot of hardware implementations,  being able to parse
> packets without waiting for lookup results speeds up the
> implementation.  With the speeds and scales of implemenations
> going up in the future with the adoption of 802.11n, we should
> keep the protocol design clean and simple, and not complicate
> designs to save a few bytes.
>  
>  
> Regards,
> Abhijit
>  
>  
> -----Original Message-----
> From: Jim Murphy [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2007 4:05 PM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
> 146)
> 
> The following proposal suggests that the CAPWAP preamble is required in
> the data channel. I propose the CAPWAP preamble is not required in the
> data channel for the following reasons:
> 
> 1. It is not specified in the CAPWAP spec how to establish an encrypted
> *data* channel.
> 
> 2. Even if #1 had been specified, then it is not specified how one
> signals which data channel packets are DTLS encrypted and which are not.
> One could imagine that it would be based on session, but there is no
> mechanism specified for how this is accomplished.
> 
> Considering that the CAPWAP preamble adds no value to the data channel,
> I propose that the preamble is removed. As I've argued in the past,
> being frugal with the use of bytes in data channel headers is critical
> for high performance and large scale implementations.
> 
> The inclusion of the preamble in the data channel may be considered in a
> future version of CAPWAP when the above issues have been addressed.
> 
> Thanks,
> 
> Jim
> 
> Pat Calhoun (pacalhou) wrote:
>  > All,
>  >  
>  > Following the discussion at the IETF meeting in San Diego, I wanted to
> 
>  > provide the following proposed resolution for the above issues. Note
>  > that issues 224 and 89 are directly resolved as part of this fix,
>  > while issue 146 includes several topics, and this issue only addresses
> 
>  > one of the issues raised.
>  >
>  > NOTE: The format of the frame I have included here is slightly
>  > different from the one that I had presented in San Diego. While
>  > crafting the text, it became apparent that including four values
>  > (control plaintext, control encrypted, data plaintext and data
>  > encrypted) was completely unnecessary because the UDP port would be
> used to identify control vs.
>  > data. So the type field really states whether the field is plain text
>  > or DTLS. There is also room to allow for future encryption protocols
>  > to be used here. The new header is called preamble, and includes 24
>  > reserved bits. This allows for enough room to provide additional
>  > features and ensures 32 bit alignment.
>  >
>  > Proposed Text
>  > -------------
>  >
>  > 4  CAPWAP Packet Formats
>  >
>  >    This section contains the CAPWAP protocol packet formats.  A CAPWAP
>  >    protocol packet consists of a CAPWAP Transport Layer packet header
>  >    followed by a CAPWAP message.  The CAPWAP message can be either of
>  >    type Control or Data, where Control packets carry signaling, and
> Data
>  >    packets carry user payloads.  The CAPWAP frame formats for CAPWAP
>  >    Data packets, and for DTLS encapsulated CAPWAP Data and Control
>  >    packets.  See section Section 3.1 for more information on the use
> of
>  >    UDP.
>  >
>  >    The CAPWAP Control protocol includes two messages that are never
>  >    protected by DTLS.  These messages, called the Discovery Request
> and
>  >    Discovery Response, need to be in the clear in order for the CAPWAP
>  >    protocol to properly identify and process them.  The format of
> these
>  >    packets are as follows:
>  >
>  >        CAPWAP Control Packet (Discovery Request/Response):
>  >        +---------------------------------------------------+
>  >        | IP  | UDP | CAPWAP |CAPWAP | Control | Message    |
>  >        | Hdr | Hdr | p-amble|Header | Header  | Element(s) |
>  >        +---------------------------------------------------+
>  >
>  >    All other CAPWAP control protocol messages MUST be protected via
> the
>  >    DTLS protocol, which ensures that the packets are both
> authenticated
>  >    and encrypted.  The format of these packets are as follows:
>  >
>  >     CAPWAP Control Packet (DTLS Security Required):
>  >
> +------------------------------------------------------------------+
>  >     | IP  | UDP | CAPWAP | DTLS | CAPWAP | Control | Message    | DTLS
> |
>  >     | Hdr | Hdr | p-amble| Hdr  | Header | Header  | Element(s) | Trlr
> |
>  >
> +------------------------------------------------------------------+
>  >                          \----------- authenticated ------------/
>  >                                  \------------- encrypted
>  > -------------/
>  >
>  >    The CAPWAP protocol allows optional encryption of the data frames,
>  >    once again using the DTLS protocol.  Whether or not the data frames
>  >    are encrypted is a matter of policy, which is described in a later
>  >    section of this specification.  The format of these packets is as
>  >    follows:
>  >
>  >        CAPWAP Plain Text Data Packet :
>  >        +-----------------------------------------+
>  >        | IP  | UDP | CAPWAP | CAPWAP | Wireless  |
>  >        | Hdr | Hdr | p-amble| Header | Payload   |
>  >        +-----------------------------------------+
>  >
>  >        DTLS Secured CAPWAP Data Packet:
>  >        +------------------------------------------------------+
>  >        | IP  | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
>  >        | Hdr | Hdr | p-amble| Hdr  |  Hdr   | Payload  | Trlr |
>  >        +------------------------------------------------------+
>  >                              \----- authenticated -----/
>  >                                    \------- encrypted --------/
>  >
>  >    UDP:  All CAPWAP packets are encapsulated within UDP.  Section
>  >       Section 3.1 defines the specific UDP usage.
>  >
>  >    CAPWAP preamble:  All CAPWAP protocol packets are prefixed with the
>  >       preable header, which is used to identify the frame type that
>  >       follows.  This header, is defined in Section 4.1.
>  >
>  >    DTLS Header:  The DTLS header provides authentication and encrytion
>  >       services to the CAPWAP payload it encapsulates.  This protocol
> is
>  >       defined in RFC 4347 [9].
>  > [...]
>  >
>  > 4.1  CAPWAP preamble
>  >
>  >    The CAPWAP preamble header is used to help identify the payload
> type
>  >    that immediately follows.  The reason for this header to is avoid
>  >    needing the perform byte comparisons in order to guess whether the
>  >    frame is DTLS encrypted or not.  The format of the frame is as
>  >    follows:
>  >
>  >         0                   1                   2                   3
>  >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1
>  >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >        |Version| Type  |                    Reserved
> |
>  >        
>  > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >
>  >    Version:  A 4 bit field which contains the version of CAPWAP used
> in
>  >       this packet.  The value for this draft is zero (0).
>  >
>  >    Payload Type:  A 4 bit field which specifies the payload type that
>  >       follows the preamble header.  The following values are
> supported:
>  >
>  >       0 -  Clear text.  If the packet is received on the data UDP
> port,
>  >          the CAPWAP stack MUST treat this as a clear text CAPWAP data
>  >          packet.  If received on the control UDP port, the CAPWAP
> stack
>  >          MUST treat this as a clear text CAPWAP control packet.  If
> the
>  >          control packet is not a Discovery Request or Response packet,
>  >          it is illegal and MUST be dropped.
>  >
>  >       1 -  DTLS Encrypted.  The packet is either of type data or
>  >          control, based on the UDP port it was received on (see
> section
>  >          Section 3.1).
>  >
>  >    Reserved:  The 24-bit field is reserved for future use.  All
>  >       implementations complying with this protocol MUST set to zero
> any
>  >       bits that are reserved in the version of the protocol supported
> by
>  >       that implementation.  Receivers MUST ignore all bits not defined
>  >       for the version of the protocol they support.
>  >
>  > 4.2  CAPWAP Header
>  > [...]
>  >         0                   1                   2                   3
>  >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1
>  >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >        |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|     Flags
> |
>  >        
>  > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  > [...]
>  >
>  >    Version:  A 4 bit field which contains the version of CAPWAP used
> in
>  >       this packet.  The value of this field MUST match the version
> field
>  >       set in the CAPWAP preamble header (see Section 4.1).  The reason
>  >       for this duplicate field is to avoid any possible tampering of
> the
>  >       version field in the preamble header which is not encrypted or
>  >       authenticated.
>  >
>  >
>  > Pat Calhoun
>  > CTO, Wireless Networking Business Unit Cisco Systems
>  > _________________________________________________________________
>  > 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
> 
> 
> ------------------------------------------------------------------------
> Never Miss an Email
> Stay connected with Yahoo! Mail on your mobile. Get started! 
> <http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/services?promote=mail>
> 
> 
> ------------------------------------------------------------------------
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap

Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.

Have a burning question? Go to Yahoo! Answers and get answers from real people who know.

____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 18 Jan 2007 06:17:00 -0800

Hi Abhijit,
 
CAPWAP control and data are completely orthogonal to each other as they
serve very different purpose. For example, MPLS-TE, control and data
plane are different - where MPLS TE used RSVP/LDP for control plane
whose frame formats are completely  different from the MPLS label stack
used for transporting the actual data.
 
I agree with you in the general principle of trying to keeping them same
(to the extent possible) but it should be at the expense of adding
unnecessary overhead to one or both of them. Hence CAPWAP data should
not be bloated to maintain some vague notion of compatibility with
CAPWAP control.
 
With respect to the original question at hand (determine if the CAPWAP
data pkt is encrypted or not), I think there are 3 options that seem
reasonable (without worrying about CAPWAP control compatibility):
 
(a) Have the UDP tunnel itself indicate if the pkt is encrypted (hence
remove the MUX)
(b) Remove MUX and put the "Encrypt" bit in the CAPWAP hdr - with the
caveat that only CAPWAP payload is protected
(c) Remove MUX hdr and remove support for CAPWAP Data DTLS as it is
currently unspecified how this would be set up. When it is specified,
then we can have the debate about what parts of the data needs to be
encrypted.
 
Adding 32 bits for 1 bit of marginally useful information (and still
unspecified setup) is a complete waste of space in a data hdr.
 
Thanks.
 
-Puneet 

________________________________

From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 4:02 AM
To: Puneet Agarwal; [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Puneet,

----- Original Message ----
From: Puneet Agarwal <[email-masked]>
To: Abhijit Choudhury <[email-masked]>; [email-masked]
Sent: Thursday, January 18, 2007 1:58:32 AM
Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Hi Abhijit,
 
Looks like other protocols (including .11) did not have any issues
putting this 1 bit in the non-protected part of their (.11) hdr and seem
to have a very secure protocol (with WPA2 etc). One can always decide
which hdr fields one want to include in the part covered by the
authentication/encryption.
 
Hence I am having a hard time understanding why we in CAPWAP keep on
insisting that the CAPWAP hdr (especially for CAPWAP DATA) needs to be
after DTLS. It seems that having DTLS after CAPWAP hdr would be
perfectly secure as well.
Hence I disagree with your assertion that DTLS hdr MUST be before CAPWAP
hdr.
 
[Abhijit]  We should stay away from having different formats for CAPWAP
CONTROL and
CAPWAP DATA.  There should be only one frame format -  the CAPWAP frame
format.
 
As for what needs to be protected, there are parts of the CAPWAP header
that needs 
to be protected (wireless info, radio mac etc) and other parts that may
not.
I believe the group decided to protect the entire CAPWAP header in the
mailing list earlier.  That is why the DTLS header is before the CAPWAP
header.
 
My earlier position is still valid:
Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in the CAPWAP hdr
for the encrypted payload flag.
 
Thanks.
 
-Puneet
 
________________________________

Hi Puneet,

Abhijit

----- Original Message ----
From: Puneet Agarwal <[email-masked]>
To: Abhijit Choudhury <[email-masked]>; Jim Murphy
<[email-masked]>
Cc: [email-masked]
Sent: Thursday, January 18, 2007 1:31:30 AM
Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Hi Abhijit,
 
The real issue is the fact that we are using a full 32 bits to add this
1 bit info. One would be perfectly happy if we put this 1 bit in the
CAPWAP hdr (by using one of the flag bits). I speculate that .11 (using
your example) would have had a fairly adverse reaction if one suggested
adding 32 bits for one bit of info.
 
To your other point about high speed implementations: it depends on your
particular implementation. There are many other high speed
implementations that do not suffer from the issue that you describe.
 
Hence here is my position:
Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in the CAPWAP hdr
for the encrypted payload flag.
 
Comments?
 
Thanks.
 
-Puneet

________________________________

Jim,

Regards,
Abhijit

----- Original Message ----
From: Jim Murphy <[email-masked]>
To: Abhijit Choudhury <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, January 17, 2007 6:30:00 AM
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Thanks,

Jim

Abhijit Choudhury wrote:
>  >         0                   1                   2
3
>  >         0                   1                   2
3
> Stay connected with Yahoo! Mail on your mobile. Get started! 
<http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/services?prom
ote=mail>

________________________________

Check out the all-new Yahoo! Mail beta
<http://us.rd.yahoo.com/evt=43257/*http://advision.webevents.yahoo.com/m
ailbeta>  - Fire up a more powerful email and get things done faster.

________________________________

Have a burning question? Go to Yahoo! Answers
<http://answers.yahoo.com/;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMz
OTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx>  and get answers
from real people who know.

________________________________

It's here! Your new message!
Get new email alerts
<http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar
/features/mail/>  with the free Yahoo! Toolbar.
<http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar
/features/mail/> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 18 Jan 2007 12:03:48 -0800

Puneet,
 
Addressing your specific list of options:
1) Continuing to bring up the removal of the MUX is simply a waste of
time. The WG has decided, so let's move on please.
2) To propose that the CAPWAP header be secured in a different fashion
is also pointless, because DTLS will encrypt the whole frame.
3) I would certainly be interested in understanding what exactly you
believe has been under-specified for DTLS Data channel in version 4 (for
which text has been provided on the list). The AC Descriptor
communicates the DTLS policy. The state machine has been revised to
ensure that the control channel waits for the data channel to be
established. I'm certainly unaware of any support to remove DTLS on the
data channel, or what the issues you are alluding to.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

	From: Puneet Agarwal [mailto:[email-masked]] 
	Sent: Thursday, January 18, 2007 6:17 AM
	To: Abhijit Choudhury; [email-masked]
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Hi Abhijit,
	 
	CAPWAP control and data are completely orthogonal to each other
as they serve very different purpose. For example, MPLS-TE, control and
data plane are different - where MPLS TE used RSVP/LDP for control plane
whose frame formats are completely  different from the MPLS label stack
used for transporting the actual data.
	 
	I agree with you in the general principle of trying to keeping
them same (to the extent possible) but it should be at the expense of
adding unnecessary overhead to one or both of them. Hence CAPWAP data
should not be bloated to maintain some vague notion of compatibility
with CAPWAP control.
	 
	With respect to the original question at hand (determine if the
CAPWAP data pkt is encrypted or not), I think there are 3 options that
seem reasonable (without worrying about CAPWAP control compatibility):
	 
	(a) Have the UDP tunnel itself indicate if the pkt is encrypted
(hence remove the MUX)
	(b) Remove MUX and put the "Encrypt" bit in the CAPWAP hdr -
with the caveat that only CAPWAP payload is protected
	(c) Remove MUX hdr and remove support for CAPWAP Data DTLS as it
is currently unspecified how this would be set up. When it is specified,
then we can have the debate about what parts of the data needs to be
encrypted.
	 
	Adding 32 bits for 1 bit of marginally useful information (and
still unspecified setup) is a complete waste of space in a data hdr.
	 
	Thanks.
	 
	-Puneet 

	From: Abhijit Choudhury [mailto:[email-masked]] 
	Sent: Thursday, January 18, 2007 4:02 AM
	To: Puneet Agarwal; [email-masked]
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Puneet,

	----- Original Message ----
	From: Puneet Agarwal <[email-masked]>
	To: Abhijit Choudhury <[email-masked]>; [email-masked]
	Sent: Thursday, January 18, 2007 1:58:32 AM
	Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Hi Abhijit,
	 
	Looks like other protocols (including .11) did not have any
issues putting this 1 bit in the non-protected part of their (.11) hdr
and seem to have a very secure protocol (with WPA2 etc). One can always
decide which hdr fields one want to include in the part covered by the
authentication/encryption.
	 
	Hence I am having a hard time understanding why we in CAPWAP
keep on insisting that the CAPWAP hdr (especially for CAPWAP DATA) needs
to be after DTLS. It seems that having DTLS after CAPWAP hdr would be
perfectly secure as well.
	Hence I disagree with your assertion that DTLS hdr MUST be
before CAPWAP hdr.
	 
	[Abhijit]  We should stay away from having different formats for
CAPWAP CONTROL and
	CAPWAP DATA.  There should be only one frame format -  the
CAPWAP frame format.
	 
	As for what needs to be protected, there are parts of the CAPWAP
header that needs 
	to be protected (wireless info, radio mac etc) and other parts
that may not.
	I believe the group decided to protect the entire CAPWAP header
in the mailing list earlier.  That is why the DTLS header is before the
CAPWAP header.
	 
	My earlier position is still valid:
	Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in the
CAPWAP hdr for the encrypted payload flag.
	 
	Thanks.
	 
	-Puneet

	From: Abhijit Choudhury [mailto:[email-masked]] 
	Sent: Thursday, January 18, 2007 1:45 AM
	To: Puneet Agarwal; [email-masked]
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Hi Puneet,

	Abhijit

	----- Original Message ----
	From: Puneet Agarwal <[email-masked]>
	To: Abhijit Choudhury <[email-masked]>; Jim Murphy
<[email-masked]>
	Cc: [email-masked]
	Sent: Thursday, January 18, 2007 1:31:30 AM
	Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Hi Abhijit,
	 
	The real issue is the fact that we are using a full 32 bits to
add this 1 bit info. One would be perfectly happy if we put this 1 bit
in the CAPWAP hdr (by using one of the flag bits). I speculate that .11
(using your example) would have had a fairly adverse reaction if one
suggested adding 32 bits for one bit of info.
	 
	To your other point about high speed implementations: it depends
on your particular implementation. There are many other high speed
implementations that do not suffer from the issue that you describe.
	 
	Hence here is my position:
	Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in the
CAPWAP hdr for the encrypted payload flag.
	 
	Comments?
	 
	Thanks.
	 
	-Puneet

	From: Abhijit Choudhury [mailto:[email-masked]] 
	Sent: Wednesday, January 17, 2007 8:33 AM
	To: Jim Murphy
	Cc: [email-masked]
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Jim,

	Regards,
	Abhijit

	----- Original Message ----
	From: Jim Murphy <[email-masked]>
	To: Abhijit Choudhury <[email-masked]>
	Cc: [email-masked]
	Sent: Wednesday, January 17, 2007 6:30:00 AM
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	There is no additional lookup required if the preamble is not
	used. To identify a CAPWAP data packet, the forwarding plane
	is plumbed with the data channel 5-tuple (src IP, dst IP, IP
proto,
	src port, dst port). The forwarding operation is to either
decrypt
	the packet if the tunnel attribute is DTLS encrypted or to
CAPWAP
	de-encapsulate if not. There is no need to look at the CAPWAP
preamble
	to make this decision - it is plumbed in directly.

	Thanks,
	
	Jim
	
3
3

---

From: Jim Murphy <[email-masked]>
Date: Fri, 19 Jan 2007 00:52:14 -0800

> time. The WG has decided, so let's move on please.

When was this WG decision made? Your original proposal (this thread)
was made on Nov. 22, 2006 (after the IETF meeting) and we are merely
discussing the merits of the proposal on the mailing list, as we should.

Thanks,

Jim

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 19 Jan 2007 01:30:34 -0800

I typed too fast. To keep bringing up the use of a single port has been
decided by the WG. I will let the chairs respond to this.

Pat Calhoun

> Sent: Friday, January 19, 2007 12:52 AM
> When was this WG decision made? Your original proposal (this 
> thread) was made on Nov. 22, 2006 (after the IETF meeting) 
> and we are merely discussing the merits of the proposal on 
> the mailing list, as we should.
> 
> Thanks,
> 
> Jim
>

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 14:40:49 -0600

Hi Jim-

The call for consensus on the port issues was made on the list by the
chairs in late Sept, (Sept 19th) and the final resolution deterimined on
the list on Oct 10th.  I've included the final WG decision as there was
so much discussion on this topic over the last year.

Best Regards,
DorothyG

-----Original Message-----
From: ext Jim Murphy [mailto:[email-masked]] 
Sent: Friday, January 19, 2007 12:52 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

> time. The WG has decided, so let's move on please.

When was this WG decision made? Your original proposal (this thread) was
made on Nov. 22, 2006 (after the IETF meeting) and we are merely
discussing the merits of the proposal on the mailing list, as we should.

Thanks,

Jim

Subject: LACK OF CONSENSUS: 2-port/mux issue
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 10 Oct 2006 08:53:41 -0600

Hi All,

Over the past few months, we have had an open issue in the CAPWAP WG  
that we refer to as the "2-port/mux issue".  The current CAPWAP  
protocol specification indicates that the CAPWAP protocol will run  
over two UDP ports, one for control traffic and one for data  
traffic.  Proposals have been made to move to a single-port approach  
or to allow for a single-port option.

There has been much discussion of this issue, including e-mail  
discussion and presentations at WG meetings.  We have consulted with  
the IESG, and the outcome of those discussions has been sent to the  
group.  At this point, we believe that every interested party has had  
an opportunity to present technical facts in support of his/her  
position, and we believe that the WG is aware of the technical  
differences between the two approaches.  So, it is time to determine  
the resolution of this issue.

The WG chairs have reviewed the status of this issue, and we have  
found that the WG does not have consensus to modify the  
demultiplexing mechanism described in the current CAPWAP  
specification, either to move to a single-port approach or to add a  
single-port option.  Therefore, in the absence of any new technical  
information, we are closing this discussion.  Editors, please close  
this issue in the issue tracker with a resolution indicating that  
there is no WG consensus to make this change.

We realize that this has been a contentious issue for the WG, and  
that some people may be dissatisfied with this resolution.  We all  
would have preferred our technical discussions to converge on a  
single correct choice, but that hasn't happened.  In this case, it is  
possible to build a viable CAPWAP protocol using either approach, and  
both approaches have advantages and disadvantages that are weighed  
differently by different parties.  Unless new technical information  
comes to light, we do not believe that continued discussion of this  
issue will lead to consensus on the technical superiority of either  
approach.

The WG chairs have reviewed the history of this issue to determine  
how to move forward, given that our technical discussions have not  
converged.  The two-port approach was part of the original LWAPP  
specification, and It was also included in the -00 version of the  
CAPWAP specification that was accepted as a WG work item in early  
2006.  There was WG consensus to accept LWAPP as the basis of the  
CAPWAP specification, therefore the WG chairs believe that WG  
consensus would be required to change the demultiplexing mechanism.   
Despite lengthy discussion, the WG has not reached consensus to do that.

We would like to thank everyone who has participated in this  
discussion.  We hope that we will be able to put this issue behind us  
and continue to work together towards a well-defined and widely- 
deployed CAPWAP specification.

Best Regards,

Dorothy Gellert, Mahalingam Mani & Margaret Wasserman
The CAPWAP WG Co-Chairs

---

From: Jim Murphy <[email-masked]>
Date: Mon, 22 Jan 2007 13:09:31 -0800

I think there is some confusion here. Adding the MUX header (preamble)
to the CAPWAP header was not proposed until Nov. 22. This is independent
of the port issue.

Thanks,

Jim

[email-masked] wrote:
> To:
> <[email-masked]>
> To:
> <[email-masked]>
> CC:
> <[email-masked]>, <[email-masked]>
> 
> 
> Hi All,
>

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 22 Jan 2007 15:18:42 -0800

Hi Pat,
 
(1) The WG decided that we need the MUX for the control plane. We
believed we might potentially need it for the DATA plane at that time
but as it turns out we don't need it for the data plane (as a given DATA
tunnel is either DTLS encrypted or not)- so why have this mux CAPWAP
data?
 
(3a) As to the open issues on the data channel, we have a state that
describes data association done but I didn't find text (maybe I didn't
look in the right place so a ptr would be helpful) that describes how
the CAPWAP Data session negotiates the key info under the control of the
state m/c. 
 
(3b) For the data channel, we still haven't decided whether we are going
to require different classes of service (say upto 4/8) to have their own
DTLS sessions. This is to prevent frame reordering between different
classes of traffic from confusing the DTLS machines replay windows.
Depending on how this may need to be implemented (different UDP tunnels
or same UDP tunnel carrying different DTLS session - that may actual
require 2/3 bits for demuxing).
 
Thanks.
 
-Puneet

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 12:04 PM
To: Puneet Agarwal; Abhijit Choudhury; [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Puneet,

Pat Calhoun

	Hi Abhijit,

	 

	 
	Thanks.
	 
	-Puneet 

	Puneet,

	----- Original Message ----
	From: Puneet Agarwal <[email-masked]>
	To: Abhijit Choudhury <[email-masked]>; [email-masked]
	Sent: Thursday, January 18, 2007 1:58:32 AM
	Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Hi Abhijit,

	 

	 
	Thanks.
	 
	-Puneet

	Hi Puneet,

	Abhijit

	----- Original Message ----
	From: Puneet Agarwal <[email-masked]>
	To: Abhijit Choudhury <[email-masked]>; Jim Murphy

	Hi Abhijit,

	 
	 
	Comments?
	 
	Thanks.
	 
	-Puneet

	Jim,

	Regards,
	Abhijit

	----- Original Message ----
	From: Jim Murphy <[email-masked]>
	To: Abhijit Choudhury <[email-masked]>
	Cc: [email-masked]
	Sent: Wednesday, January 17, 2007 6:30:00 AM
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	
	
	Thanks,
	
	Jim
	
3
3

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 23 Jan 2007 09:35:41 -0800

> (1) The WG decided that we need the MUX for the control plane. We
believed we might potentially need it for the DATA plane at that 
> time but as it turns out we don't need it for the data plane (as a
given DATA tunnel is either DTLS encrypted or not)- so why have 
> this mux CAPWAP data?
I find it most interesting how there are inconsistent views on similar
topics. If you recall, earlier versions of the protocol did not state
what the format of the encapsulated payload was (e.g., 802.3 vs.
802.11), and at the time it was required that the header include this
information to make it simpler for the data plane to determine how to
handle the packet. Now we have a very similar problem, but for some
reason we are now ok with state being maintained and not requiring the
packet to be explicit about its contents. The group had agreed at the
time that providing explicit notification in the payload is mandatory,
which you requested (see
http://lists.frascone.com/pipermail/capwap/msg02747.html), so I am not
sure why this case is any different.

> (3a) As to the open issues on the data channel, we have a state that
describes data association done but I didn't find text (maybe 
> I didn't look in the right place so a ptr would be helpful) that
describes how the CAPWAP Data session negotiates the key info 
> under the control of the state m/c. 
It was sent some time ago, but if you take at look at the most recent
226 proposed text, you will notice the "Data Check" state, and the
associated text for that state transition.

> (3b) For the data channel, we still haven't decided whether we are
going to require different classes of service (say upto 4/8) to 
> have their own DTLS sessions. This is to prevent frame reordering
between different classes of traffic from confusing the DTLS 
> machines replay windows. Depending on how this may need to be
implemented (different UDP tunnels or same UDP tunnel carrying 
> different DTLS session - that may actual require 2/3 bits for
demuxing). 
Correct, and we discussed this at the last IETF meeting. The preamble
includes a reserved field which we had discussed could be used  for
multiplexing purposes. 

Pat Calhoun

	From: Puneet Agarwal [mailto:[email-masked]] 
	Sent: Monday, January 22, 2007 3:19 PM
	To: Pat Calhoun (pacalhou); Abhijit Choudhury;
[email-masked]
	Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Hi Pat,
			Thanks.
	 
	-Puneet

	Puneet,
	 
	Addressing your specific list of options:
	1) Continuing to bring up the removal of the MUX is simply a
waste of time. The WG has decided, so let's move on please.
	2) To propose that the CAPWAP header be secured in a different
fashion is also pointless, because DTLS will encrypt the whole frame.
	3) I would certainly be interested in understanding what exactly
you believe has been under-specified for DTLS Data channel in version 4
(for which text has been provided on the list). The AC Descriptor
communicates the DTLS policy. The state machine has been revised to
ensure that the control channel waits for the data channel to be
established. I'm certainly unaware of any support to remove DTLS on the
data channel, or what the issues you are alluding to.

	Pat Calhoun

		From: Puneet Agarwal [mailto:[email-masked]] 
		Sent: Thursday, January 18, 2007 6:17 AM
		To: Abhijit Choudhury; [email-masked]
		Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		Hi Abhijit,
		 
		CAPWAP control and data are completely orthogonal to
each other as they serve very different purpose. For example, MPLS-TE,
control and data plane are different - where MPLS TE used RSVP/LDP for
control plane whose frame formats are completely  different from the
MPLS label stack used for transporting the actual data.
		 
		I agree with you in the general principle of trying to
keeping them same (to the extent possible) but it should be at the
expense of adding unnecessary overhead to one or both of them. Hence
CAPWAP data should not be bloated to maintain some vague notion of
compatibility with CAPWAP control.
		 
		With respect to the original question at hand (determine
if the CAPWAP data pkt is encrypted or not), I think there are 3 options
that seem reasonable (without worrying about CAPWAP control
compatibility):
		 
		(a) Have the UDP tunnel itself indicate if the pkt is
encrypted (hence remove the MUX)
		(b) Remove MUX and put the "Encrypt" bit in the CAPWAP
hdr - with the caveat that only CAPWAP payload is protected
		(c) Remove MUX hdr and remove support for CAPWAP Data
DTLS as it is currently unspecified how this would be set up. When it is
specified, then we can have the debate about what parts of the data
needs to be encrypted.
		 
		Adding 32 bits for 1 bit of marginally useful
information (and still unspecified setup) is a complete waste of space
in a data hdr.
		 
		Thanks.
		 
		-Puneet 

		From: Abhijit Choudhury [mailto:[email-masked]] 
		Sent: Thursday, January 18, 2007 4:02 AM
		To: Puneet Agarwal; [email-masked]
		Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		Puneet,

		----- Original Message ----
		From: Puneet Agarwal <[email-masked]>
		To: Abhijit Choudhury <[email-masked]>;
[email-masked]
		Sent: Thursday, January 18, 2007 1:58:32 AM
		Subject: RE: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		Hi Abhijit,
		 
		Looks like other protocols (including .11) did not have
any issues putting this 1 bit in the non-protected part of their (.11)
hdr and seem to have a very secure protocol (with WPA2 etc). One can
always decide which hdr fields one want to include in the part covered
by the authentication/encryption.
		 
		Hence I am having a hard time understanding why we in
CAPWAP keep on insisting that the CAPWAP hdr (especially for CAPWAP
DATA) needs to be after DTLS. It seems that having DTLS after CAPWAP hdr
would be perfectly secure as well.
		Hence I disagree with your assertion that DTLS hdr MUST
be before CAPWAP hdr.
		 
		[Abhijit]  We should stay away from having different
formats for CAPWAP CONTROL and
		CAPWAP DATA.  There should be only one frame format -
the CAPWAP frame format.
		 
		As for what needs to be protected, there are parts of
the CAPWAP header that needs 
		to be protected (wireless info, radio mac etc) and other
parts that may not.
		I believe the group decided to protect the entire CAPWAP
header in the mailing list earlier.  That is why the DTLS header is
before the CAPWAP header.
		 
		My earlier position is still valid:
		Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in
the CAPWAP hdr for the encrypted payload flag.
		 
		Thanks.
		 
		-Puneet

		From: Abhijit Choudhury [mailto:[email-masked]] 
		Sent: Thursday, January 18, 2007 1:45 AM
		To: Puneet Agarwal; [email-masked]
		Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		Hi Puneet,
		 
		Unfortunately, the CAPWAP header occurs after the DTLS
header.
		So, putting info there doesn't help. We need something
		before the DTLS header .. all we have there is the IP
		and UDP headers and we can't insert anything there.
		 
		Abhijit

		----- Original Message ----
		From: Puneet Agarwal <[email-masked]>
		To: Abhijit Choudhury <[email-masked]>; Jim Murphy
<[email-masked]>
		Cc: [email-masked]
		Sent: Thursday, January 18, 2007 1:31:30 AM
		Subject: RE: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		Hi Abhijit,
		 
		The real issue is the fact that we are using a full 32
bits to add this 1 bit info. One would be perfectly happy if we put this
1 bit in the CAPWAP hdr (by using one of the flag bits). I speculate
that .11 (using your example) would have had a fairly adverse reaction
if one suggested adding 32 bits for one bit of info.
		 
		To your other point about high speed implementations: it
depends on your particular implementation. There are many other high
speed implementations that do not suffer from the issue that you
describe.
		 
		Hence here is my position:
		Remove MUX hdr for CAPWAP Data. Potentially add 1 bit in
the CAPWAP hdr for the encrypted payload flag.
		 
		Comments?
		 
		Thanks.
		 
		-Puneet

		From: Abhijit Choudhury [mailto:[email-masked]] 
		Sent: Wednesday, January 17, 2007 8:33 AM
		To: Jim Murphy
		Cc: [email-masked]
		Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		Jim,

		Regards,
		Abhijit

		----- Original Message ----
		From: Jim Murphy <[email-masked]>
		To: Abhijit Choudhury <[email-masked]>
		Cc: [email-masked]
		Sent: Wednesday, January 17, 2007 6:30:00 AM
		Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		If, as you suggest, DTLS encryption is an attribute of
the
		tunnel and not of the packet, then indeed the preamble
is
		superfluous.
		
		There is no additional lookup required if the preamble
is not
		used. To identify a CAPWAP data packet, the forwarding
plane
		is plumbed with the data channel 5-tuple (src IP, dst
IP, IP proto,
		src port, dst port). The forwarding operation is to
either decrypt
		the packet if the tunnel attribute is DTLS encrypted or
to CAPWAP
		de-encapsulate if not. There is no need to look at the
CAPWAP preamble
		to make this decision - it is plumbed in directly.
		
		Given that control and data are using different UDP
ports and
		most likely processed on completely different
processors,
		there is no technical or functional value in having
uniformity
		in headers.
		
		Thanks,
		
		Jim
		
		>  >                                  \-------------
encrypted
3
		>  >        |Version| Type  |
Reserved
3
		>  > Archives:
http://lists.frascone.com/pipermail/capwap

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 24 Jan 2007 00:20:57 -0800

Hi Pat,

Please see comments inline.

Thanks.

-Puneet
-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Tuesday, January 23, 2007 9:36 AM
To: Puneet Agarwal; Abhijit Choudhury; [email-masked]
Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

[Puneet-1-24]: As you are well aware, while going through the details of
the Local MAC model, it became evident that we will need to transport
both 802.3 frames and 802.11 Management frames in the same CAPWAP DATA
tunnel (hence knowing the payload type .11/.3 etc is now a requirement).

As I have consistently argued that knowing whether the payload is
encrypted or not is a nice to have feature for CAPWAP DATA but wasting
31 bits (because of our proposed preamble header) is a very inefficient
protocol design and hence this feature should be taken out of the
protocol.

[Puneet-1-24]: The proposed text states: "The WTP initiates the
         data channel, which MAY require the establishment of a DTLS
         session, starts the DataChannelKeepAlive timer (see
         Section 4.6) and transmits a Data Channel Keep Alive (see
         Section 4.3.1)"
Looking at this, I am not sure how one knows the sequence of events
needed to establish the DATA DTLS session. It would be great if you can
elaborate on how the above text sheds light on  how the DATA DTLS
session is established (and the intermediate states that it might
entail).

demuxing). 
Correct, and we discussed this at the last IETF meeting. The preamble
includes a reserved field which we had discussed could be used  for
multiplexing purposes.
[Puneet-1-24]: We discussed this briefly without reaching any
conclusion. I haven't seen any rough consensus on the list either. Hence
this is still an open question 

Pat Calhoun

	Hi Pat,
			Thanks.
	 
	-Puneet

	Puneet,

	Pat Calhoun

		Hi Abhijit,

		 

		 
		Thanks.
		 
		-Puneet 

		Puneet,

		----- Original Message ----
		From: Puneet Agarwal <[email-masked]>
		To: Abhijit Choudhury <[email-masked]>;
[email-masked]

		Hi Abhijit,

		 

		 
		Thanks.
		 
		-Puneet

		Hi Puneet,

		Abhijit

		----- Original Message ----
		From: Puneet Agarwal <[email-masked]>
		To: Abhijit Choudhury <[email-masked]>; Jim Murphy

		Hi Abhijit,

		 
		 
		Comments?
		 
		Thanks.
		 
		-Puneet

		Jim,

		Regards,
		Abhijit

		----- Original Message ----
		From: Jim Murphy <[email-masked]>
		To: Abhijit Choudhury <[email-masked]>
		Cc: [email-masked]
		Sent: Wednesday, January 17, 2007 6:30:00 AM
		Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of 146)

		
		
		Thanks,
		
		Jim
		
		> Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of
encrypted
3
Reserved
3

---

From: Jim Murphy <[email-masked]>
Date: Thu, 25 Jan 2007 00:19:12 -0800

Please consider the following alternative proposal to optimize the data
channel when no DTLS encryption is present. With this proposal,
CAPWAP data channels running in the clear will not require the CAPWAP
preamble. However, CAPWAP data channels running DTLS must have the
CAPWAP preamble.

The CAPWAP preamble is modified as follows:

[...]
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version| Type  |                    Reserved                 |P|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
     P: Must be 1. Indicates that this is a CAPWAP preamble.
[...]

The CAPWAP Header is modified as follows:

[...]
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|    Flags  |P|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
     P: Must be 0. Indicates that this is a CAPWAP preamble.
[...]

The basic idea is to overlay the CAPWAP preamble and the first
32 bits of the CAPWAP Header. Note the intentional overlap of
the Version field and the P bit. Essentially the P bit is a type
indicator that indicates the type of super field present. A 1
indicates a CAPWAP preamble, a 0 indicates the first 32 bits of
the CAPWAP Header.

Any data packet on a clear (unencrypted) data channel looks
as follows (to illustrate the use of the P bit):

        CAPWAP Plain Text Data Packet:
        +--------------------------------+
        | IP  | UDP | CAPWAP | Wireless  |
        | Hdr | Hdr | Header | Payload   |
        |     |     | P=0    |           |
        +--------------------------------+

Any data packet on an encrypted data channel or a DTLS
session establishment packet looks as follows:

        |     |     | P=1    |      |        |          |      |

A switching entity need only check the CAPWAP Version and then the P
bit to determine if the CAPWAP packet needs DTLS processing.
If the P but is not set, the switching entity may immediately
assume only a CAPWAP header and commences de-encapsulation and
possible reassembly processing.

This proposal serves the following purposes:

  - The CAPWAP preamble is present only when really needed. Specifically
    to identify CAPWAP packet attributes outside of the DTLS encrypted/
    authenticated area when DTLS is used.

  - Eliminates the waste of 32 bits of header information to convey a
    single bit of information when in the clear.

  - Allows for the continued use of the CAPWAP preamble for other
    purposes, such as DTLS session de-multiplexing to deal with the
    issue of QoS reordering. (see earlier email from Mani - The QoS DTLS
    factor)

Please let me know if you have any questions.

Thanks,

Jim

---

From: "Sudhanshu" <[email-masked]>
Date: Thu, 25 Jan 2007 10:23:59 -0800

Jim,

I think it is a good idea to overlay some bit in preamble and header.

But I think it will be better to overlay the first bit instead of the 32nd
bit as the 'P' bit.

So it will look like, in your solution.

<<snip>>

 [...]
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |P|Version| Type  |                    Reserved                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
     P: Must be 1. Indicates that this is a CAPWAP preamble.
[...]

[...]
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |P|Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|    Flags  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]

<<snip>>

This is a common practice to overlay first few bits to distinguish the rest
of the fields. It is a cleaner implementation. Also it will help in the HW
parsing of the packet.

_Suds

-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 12:19 AM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

[...]
         0                   1                   2                   3

[...]
         0                   1                   2                   3

Thanks,

Jim

---

From: Jim Murphy <[email-masked]>
Date: Thu, 25 Jan 2007 11:17:21 -0800

Your proposal sounds good. One might find it more desirable to
re-order the version and P bits but I do not have a strong preference.

Thanks,

Jim

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 26 Jan 2007 16:28:09 -0800

It's always fun to be part of an exercise to optimize something until it
can't be optimized any further, and let's be clear about it.  That is
what we are doing here.  The current preamble, common to both control
and data packets, works.  What is being proposed is to make the data
packet preamble as short as possible, by reducing its size by 32 bits.
This comes at the cost of having the control and data packet formats
diverge.

Let me propose some reasons for keeping the preamble of the control and
data packets the same as they were.

1. A DTLS-protected packet, either control or data, is handled exactly
the same way to produce the decrypted CAPWAP payload.  This decrypted
payload can then be passed to software for processing (either control or
data) or can be passed to fast path hardware for data path processing.

2. 32 bits take exactly 32ns to transmit at a gigabit per second, which
is likely to be the predominant connection for both WTPs and ACs.
Optimizing the protocol to save these 32ns is a foolish economy.  Is
there a dire cost that we encounter, in order to send these bits?

3. Having two different CAPWAP preambles doubles the cost of development
of this portion of the protocol (particularly if the CAPWAP header
cracking is done in hardware), doubles the hardware necessary to process
this portion of the packet (perhaps even that necessary to process the
entire packet), and doubles the number of bugs to discover and fix.

I believe these practical reasons outweigh the reasons presented for
making the change to the header.

 -Bob
 
-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 12:19 AM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

[...]
         0                   1                   2                   3
 
|P|

[...]
         0                   1                   2                   3
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|    Flags
|P|

Thanks,

Jim

---

From: "Sudhanshu" <[email-masked]>
Date: Fri, 26 Jan 2007 17:36:44 -0800

Bob,

What has been proposed to avoid preamble in data path is nothing more than
supporting more than one version number of CAPPWAP protocol. A good *HW*
implementation should address it anyway. IMHO, multiple versions is going to
be very common going forward as the current standard, in the interest of
interoperability, has been made very restrictive.

And all the reason you have mentioned below does not look very strong to
afford 4 bytes in each data packet. Please see inline comments.

-Suds

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 4:28 PM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

[Suds] In the propose solution also a DTLS protected packet will always be
handled in the same way. No difference. Only in case of non-protected packet
there will be a difference. In that case, DTLS processing has to be bypassed
any way. 

[Suds] Don't forget about the remote APs, where 32 byte overhead could be
undesirable. 

[Suds] As I mentioned earlier, HW implementation is nothing more than two
version of CAPOWAP supported, in a modified proposal send by me. A good HW
implementation should definitely consider it to make it easier for future
enhancements.

[Suds] As I explain above, these reasons do not hold much ground.

-Suds

-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 12:19 AM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

[...]
         0                   1                   2                   3

[...]
         0                   1                   2                   3

Thanks,

Jim

---

From: Jim Murphy <[email-masked]>
Date: Fri, 26 Jan 2007 23:56:53 -0800

Bob,

I see no reason why this optimization can not be
used in the control channel as well. If so, then the
concerns about the data and control channel having to
be exactly the same are eliminated with the added benefit
of improved performance in each case.

That said, I think we could improve the format a bit based on
feedback from Sudhanshu and some new observations based on the
idea of packet header overlay.

The basic idea is that Version and Type fields are what is needed
for the "preamble" and exist for every type of packet. However, only
8 bits are required. We then define the DTLS shim and CAPWAP Header to
include the preamble. The resulting format is something like this:

CAPWAP Preamble
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

    Version:  A 4 bit field which contains the version of CAPWAP used in
       this packet.  The value for this draft is zero (0).

    Payload Type:  A 4 bit field which specifies the payload type that
       follows the preamble header.  Unsupported values MUST be silently
       dropped. The following values are supported:

       0 -  Clear text.  If the packet is received on the data UDP port,
          the CAPWAP stack MUST treat this as a clear text CAPWAP data
          packet.  If received on the control UDP port, the CAPWAP stack
          MUST treat this as a clear text CAPWAP control packet.  If the
          control packet is not a Discovery Request or Response packet,
          it is illegal and MUST be dropped.

       1 -  DTLS Payload.  The packet is either a DTLS packet and MAY be
          a data or control packet, based on the UDP port it was received
          on (see section Section 3.1).

CAPWAP DTLS shim:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version| Type  |                    Reserved                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or, said slightly differently:

CAPWAP DTLS shim:

         0                   1                   2                   3
        | Preamble      |                    Reserved                   |

For the header we then have the following:

CAPWAP Header:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version| Type  |  HLEN   |  RID    |  WBID   |T|F|L|W|M|K|Flags|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Fragment ID          |     Frag Offset         |Rsvd |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note, Version/Type are the CAPWAP preamble.

Essentially, what we have created a de-multiplexing scheme that has
the following properties:

  - Its performance characteristics are no worse than those of the -04
    preamble. In fact, demuxing directly off the preamble type is
    very attractive from a performance perspective.
  - It does not waste 32 bits in the clear path case.
  - It works equally well for the data path and the control path so
    it is a universal solution.
  - It provides for a powerful extensibility feature that will enhance
    the longevity of the protocol.

Other notes:

  - I have transposed RID and HLEN to give the hint of a TLV structure.
    I think this is a useful concept that we should support in the
    protocol.

  - I belive the F and L flags could be moved to the Rsvd area of the
    fragmentation super frame as suggested by David Perkins. This opens
    up some more flag space in the first super frame.

Thanks,

Jim

---

From: "Sudhanshu" <[email-masked]>
Date: Mon, 29 Jan 2007 19:24:17 -0800

I like this proposal and make it very *consistent* both in Control and Data
plane.

But I don't think it is a good idea to move the 'F' and 'L' bit to the rsvd
field. I would prefer to see the F and L bit before fragment ID and fragment
offset. 

_Suds

-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 11:57 PM
To: Bob O'Hara (boohara)
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

Bob,

CAPWAP Preamble
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

CAPWAP DTLS shim:

         0                   1                   2                   3

CAPWAP DTLS shim:

         0                   1                   2                   3

CAPWAP Header:

         0                   1                   2                   3

Other notes:

Thanks,

Jim