Capwap Mailing List: Re: Proposed Resolution for Issue 224/89 (and part of 146)

[Pat Calhoun (pacalhou) (pcalhoun]

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:pagarwal [at] broadcom.com]
Sent: Thursday, January 18, 2007 6:17 AM
To: Abhijit Choudhury; capwap [at] frascone.com
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:abhijit10425 [at] yahoo.com]
Sent: Thursday, January 18, 2007 4:02 AM
To: Puneet Agarwal; capwap [at] frascone.com
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

Puneet,

Please see my comments in-line.

Abhijit

----- Original Message ----
From: Puneet Agarwal <pagarwal [at] broadcom.com>
To: Abhijit Choudhury <abhijit [at] ieee.org>; capwap [at] frascone.com
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:abhijit10425 [at] yahoo.com]
Sent: Thursday, January 18, 2007 1:45 AM
To: Puneet Agarwal; capwap [at] frascone.com
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 <pagarwal [at] broadcom.com>
To: Abhijit Choudhury <abhijit [at] ieee.org>; Jim Murphy <jmurphy [at] trapezenetworks.com>
Cc: capwap [at] frascone.com
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:abhijit10425 [at] yahoo.com]
Sent: Wednesday, January 17, 2007 8:33 AM
To: Jim Murphy
Cc: capwap [at] frascone.com
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 <jmurphy [at] trapezenetworks.com>
To: Abhijit Choudhury <abhijit [at] ieee.org>
Cc: capwap [at] frascone.com
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:jmurphy [at] trapezenetworks.com]
> Sent: Tuesday, January 16, 2007 4:05 PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap [at] frascone.com
> 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.

---

It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.