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

From: Abhijit Choudhury <[email-masked]>
Date: Wed, 17 Jan 2007 02:05:25 -0800 (PST)

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

____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

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

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

---

From: Jim Murphy <[email-masked]>
Date: Wed, 17 Jan 2007 06:30:00 -0800

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:
> ------------------------------------------------------------------------
> 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>
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 17 Jan 2007 06:25:33 -0800

Hi Abhijit,
 
Common packet format would have been required if CAPWAP control and
CAPWAP data used a single tunnel for transport but the group has settled
on 2 tunnel solution (much as I dislike it and had voiced my opinion in
earlier emails to the group).
 
Hence I respectfully disagree with your position. I strongly support
removing the MUX hdr for CAPWAP data as one can derive whether the
payload is DTLS encrypted (or not) purely based on the UDP tunnel
itself. The MUX hdr serves no purpose in the data plane. There is no
reason to burden the CAPWAP Data with completely redundant and useless
information.
 
Thanks.
 
-Puneet

________________________________

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

 

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)

Thanks,

Jim

Data
of
and
these
the
authenticated
|
|
is
type
1
|
in
port,
stack
the
section
any
by
1
|
in
field
the

________________________________

Never Miss an Email
<http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/services?prom
ote=mail>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 17 Jan 2007 08:09:41 -0800

I believe Abhijit's point is that regardless of what processor handles
the data path, an AC will have to handle non-encrypted DTLS traffic, and
MAY have to handle encrypted DTLS traffic. Because this is an optional
feature, the forwarding plane would in fact have to perform a table
lookup in order to determine how to parse the packet. It would be much
better to not require a table lookup prior to the packet parsing engine.

I agree with Abhijit. We should not make this change.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> Sent: Wednesday, January 17, 2007 6:30 AM
> To: Abhijit Choudhury
> Cc: [email-masked]
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 
> (and part of 146)
> 
> tunnel and not of the packet, then indeed the preamble is superfluous.
> 
> 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.
> 
> 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.
> > 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
> >  
> >  
> > 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:
> > 
> > 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
> > 
> >  > 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
> > 
> >  > 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  > 
> >  > 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
> >  >
> >  >         0                   1                   2        
>            3
> >  >         0                   1                   2        
>            3
> >  > CTO, Wireless Networking Business Unit Cisco Systems  >