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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 22 Nov 2006 09:19:05 -0800

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 22 Nov 2006 11:41:30 -0800

I failed to mention this also resolves issue 227.

Pat Calhoun

> -----Original Message-----
> From: Pat Calhoun (pacalhou) 
> Sent: Wednesday, November 22, 2006 9:19 AM
> To: [email-masked]
> Subject: [Capwap] Proposed Resolution for Issue 224/89 (and 
> part of 146)
> 
> 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
>