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

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

Based on a private note I have received, I would like to change the
definition of one of the bits in the CAPWAP preamble header. The new
text would look like:

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

[...]

      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).

The reason for this was that it wasn't obvious that any and all DTLS
packets would have this bit set.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

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

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 30 Nov 2006 16:31:20 -0800

Hi Pat,

With the addition of the "CAPWAP-preamble", why does one still need a
separate UDP port for CAPWAP control and a separate UDP port for CAPWAP
data?

I would propose that we get rid of separate UDP ports (for data and
control) and add a bit in the "CAPWAP-preamble" to indicate
CAPWAP-control vs CAPWAP-data.

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Wednesday, November 22, 2006 11:47 AM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 227/224/89 (and part
of 146)

        0                   1                   2                   3

[...]

Pat Calhoun

> 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
> 
>    type Control or Data, where Control packets carry signaling, and 
> Data
>    packets.  See section Section 3.1 for more information on the use 
> of
>    UDP.
> 
>    protected by DTLS.  These messages, called the Discovery Request 
> and
>    protocol to properly identify and process them.  The format of 
> these
>    packets are as follows:
> 
>    All other CAPWAP control protocol messages MUST be protected via 
> the
>       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
>    Version:  A 4 bit field which contains the version of CAPWAP used 
> in
>       0 -  Clear text.  If the packet is received on the data UDP 
> port,
>          packet.  If received on the control UDP port, the CAPWAP 
> stack
>          MUST treat this as a clear text CAPWAP control packet.  If 
> the
>          control, based on the UDP port it was received on (see 
> section
>          Section 3.1).
> 
>       implementations complying with this protocol MUST set to zero 
> any
>       bits that are reserved in the version of the protocol supported 
> by
>    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
>       for this duplicate field is to avoid any possible tampering of 
> the
> CTO, Wireless Networking Business Unit Cisco Systems