Capwap Mailing List: Re: Proposed Text for Issue 244

[Jim Murphy (jmurphy]

Pat,

One minor comment in line...

Pat Calhoun (pacalhou) wrote:
> Given that, I would like to send the proposed text to the list. Please
> note that it is nearly identical to Jim's original text, with a couple
> of very small tweaks, which I believe are necessary given the change in
> direction. These are all editorial in nature.
>  
> <proposed text>
> 4.  CAPWAP Packet Formats
>
>    This section contains the CAPWAP protocol packet formats.  A CAPWAP
>    protocol packet consists of one or more CAPWAP Transport Layer packet
>    headers 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 are defined below.
>
>    The CAPWAP Control protocol includes two messages that are never
>    protected by DTLS: the Discovery Request message and the Discovery
>    Response message.  These messages need to be in the clear to allow
>    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 | Control | Message    |
>        | Hdr | Hdr | 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.  These packets include the CAPWAP DTLS Header, which
>    is described in Section 4.2.  The format of these packets is as
>    follows:
>
>     CAPWAP Control Packet (DTLS Security Required):
>     +------------------------------------------------------------------+
>     | IP  | UDP | CAPWAP   | DTLS | CAPWAP | Control| Message   | DTLS |
>     | Hdr | Hdr | DTLS Hdr | Hdr  | Header | Header | Element(s)| Trlr |
>     +------------------------------------------------------------------+
>                            \---------- authenticated -----------/
>                                   \------------- encrypted ------------/
>
>    The CAPWAP protocol allows optional protection of data packets, using
>    DTLS.  Use of data packet protection is determined by AC policy.
>    When DTLS is utilized, the optional CAPWAP DTLS Header is present,
>    which is described in Section 4.2.  The format of CAPWAP data packets
>    is shown below:

You can remove the "CAPWAP Preamble" box from the following
diagram as it is implicit in the CAPWAP header. Also, this
header structure should be the same as the non-DTLS structure
for control packets shown above.

>        CAPWAP Plain Text Data Packet :
>        +-----------------------------------------+
>        | IP  | UDP | CAPWAP  | CAPWAP | Wireless |
>        | Hdr | Hdr | Preamble| Header | Payload  |
>        +-----------------------------------------+
>
>        DTLS Secured CAPWAP Data Packet:
>        +--------------------------------------------------------+
>        | IP  | UDP |  CAPWAP  | DTLS | CAPWAP | Wireless | DTLS |
>        | Hdr | Hdr | DTLS Hdr | Hdr  |  Hdr   | Payload  | Trlr |
>        +--------------------------------------------------------+
>                               \------ authenticated -----/
>                                      \------- encrypted --------/
>
>    UDP Header:  All CAPWAP packets are encapsulated within UDP.  Section
>       Section 3 defines the specific UDP usage.
>
>    CAPWAP DTLS Header:  All DTLS encrypted CAPWAP protocol packets are
>       prefixed with the CAPWAP DTLS header (see Section 4.2).
>
>    DTLS Header:  The DTLS header provides authentication and encrytion
>       services to the CAPWAP payload it encapsulates.  This protocol is
>       defined in RFC 4347 [8].
>
>    CAPWAP Header:  All CAPWAP protocol packets use a common header that
>       immediately follows the CAPWAP preamble or DTLS header.  The
>       CAPWAP Header is defined in Section 4.3.
>
>    Wireless Payload:  A CAPWAP protocol packet that contains a wireless
>       payload is a CAPWAP data packet.  The CAPWAP protocol does not
>       specify the format of the wireless payload, which is defined by
>       the appropriate wireless standard.  Additional information is in
>       Section 4.4.
>
>    Control Header:  The CAPWAP protocol includes a signalling component,
>       known as the CAPWAP control protocol.  All CAPWAP control packets
>       include a Control Header, which is defined in Section 4.5.1.
>       CAPWAP data packets do not contain a Control Header field.
>
>    Message Elements:  A CAPWAP Control packet includes one or more
>       message elements, which are found immediately following the
>       Control Header.  These message elements are in a Type/Length/value
>       style header, defined in Section 4.6.
>
>    A CAPWAP implementation MUST be capable of receiving a reassembled
>    CAPWAP message of length 4096 bytes.  A CAPWAP implementation MAY
>    indicate that it supports a higher maximum message length, by
>    including the Maximum Message Length message element, see
>    Section 4.6.29 in the Join Request message or the Join Response
>    message.
>
> 4.1.  CAPWAP Preamble
>
>    The CAPWAP preamble header common to all CAPWAP transport headers and
>    is used to identify the header type that immediately follows.  The
>    reason for this header to is avoid needing to perform byte
>    comparisons in order to guess whether the frame is DTLS encrypted or
>    not.  It also provides an extensibility framework that can be used to
>    support additional transport types.  The format of the frame is as
>    follows:
>
>          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 specification 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 -  CAPWAP Header.  The CAPWAP Header (see Section 4.3)
>          immediately follows the the CAPWAP Preamble Header.  If the
>          packet is received on the CAPWAP data channel, the CAPWAP stack
>          MUST treat the packet as a clear text CAPWAP data packet.  If
>          received on the CAPWAP control channel, the CAPWAP stack MUST
>          treat the packet as a clear text CAPWAP control packet.  If the
>          control packet is not a Discovery Request or Discovery Response
>          packet, the packet MUST be dropped.
>
>       1 -  CAPWAP DTLS Header.  The CAPWAP DTLS Header, and DTLS packet,
>          immediately follows the CAPWAP Preamble Header (see
>          Section 4.2).
>
> 4.2.  CAPWAP DTLS Header
>
>    The CAPWAP DTLS Header is used to identify the packet as a DTLS
>    encrypted packet.  The first eight bits includes the common CAPWAP
>    Preamble Header.  The remaining 24 bits are padding to ensure 4 byte
>    alignment, and MAY be used in a future version of the protocol.  The
>    DTLS packet [8] always immediately follows this header.  The format
>    of the CAPWAP DTLS Header 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
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |CAPWAP Preamble|                    Reserved                   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    CAPWAP Preamble:  The CAPWAP Preamble header is defined in
>       Section 4.1.  The CAPWAP Preamble Header's Payload Type field MUST
>       be set to one (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.3.  CAPWAP Header
>
>    All CAPWAP protocol messages are encapsulated using a common header
>    format, regardless of the CAPWAP control or CAPWAP Data transport
>    used to carry the messages.  However, certain flags are not
>    applicable for a given transport.  Refer to the specific transport
>    section in order to determine which flags are valid.
>
>    Note that the optional fields defined in this section MUST be present
>    in the precise order shown below.
>
>         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
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |CAPWAP Preamble|  HLEN   |   RID   | WBID   |T|F|L|W|M|K|Flags |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Fragment ID          |     Frag Offset         |Rsvd |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                 (optional) Radio MAC Address                  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |            (optional) Wireless Specific Information           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                        Payload ....                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    CAPWAP Preamble:  The CAPWAP Preamble header is defined in
>       Section 4.1.  The CAPWAP Preamble Header's Payload Type field MUST
>       be set to zero (0).  If the CAPWAP DTLS Header is present, the
>       version number in both CAPWAP Preamble Headers MUST match.  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.
>
>    HLEN:  A 5 bit field containing the length of the CAPWAP transport
>       header in 4 byte words (Similar to IP header length).  This length
>       includes the optional headers.
>
>    RID:  A 5 bit field which contains the Radio ID number for this
>       packet.  Given that MAC Addresses are not necessarily unique
>       across physical radios in a WTP, the Radio Identifier (RID) field
>       is used to indiciate which physical radio the message is
>       associated with.
>
>    WBID:  A 5 bit field which is the wireless binding identifier.  The
>       identifier will indicate the type of wireless packet type
>       associated with the radio.  The following values are defined:
>
>       1 -  IEEE 802.11
>
>       2 -  IEEE 802.16
>
>       3 -  EPCGlobal
>
>    T: The Type 'T' bit indicates the format of the frame being
>       transported in the payload.  When this bit is set to one (1), the
>       payload has the native frame format indicated by the WBID field.
>       When this bit is zero (0) the payload is an IEEE 802.3 frame.
>
>    F: The Fragment 'F' bit indicates whether this packet is a fragment.
>       When this bit is one (1), the packet is a fragment and MUST be
>       combined with the other corresponding fragments to reassemble the
>       complete information exchanged between the WTP and AC.
>
>    L: The Last 'L' bit is valid only if the 'F' bit is set and indicates
>       whether the packet contains the last fragment of a fragmented
>       exchange between WTP and AC.  When this bit is 1, the packet is
>       the last fragment.  When this bit is 0, the packet is not the last
>       fragment.
>
>    W: The Wireless 'W' bit is used to specify whether the optional
>       Wireless Specific Information field is present in the header.  A
>       value of one (1) is used to represent the fact that the optional
>       header is present.
>
>    M: The M bit is used to indicate that the Radio MAC Address optional
>       header is present.  This is used to communicate the MAC address of
>       the receiving radio.
>
>    K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep
>       Alive packet.  This packet is used to map the data channel to the
>       control channel for the specified Session ID and to maintain
>       freshness of the data channel.  The K bit MUST NOT be set for data
>       packets containing user data.
>
>    Flags:  A set of reserved bits for future flags in the CAPWAP header.
>       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.
> </text>
>
> Comments please,
>
> PatC
> ________________________________
>
> From: Dorothy.Gellert [at] nokia.com [mailto:Dorothy.Gellert [at] nokia.com] 
> Sent: Monday, April 23, 2007 6:40 PM
> To: capwap [at] frascone.com
> Cc: margaret [at] thingmagic.com; rbonica [at] juniper.net
> Subject: [Capwap] Closure of Issue 244
>
>
>
> Dear WG: 
>
> Based on the WG response to re-open Issue 244:  Preamble Header
> Optimization, this issue will be moved to the active issues database and
> resolved with the solution proposed in:
> http://lists.frascone.com/pipermail/capwap/msg04161.html
> <http://lists.frascone.com/pipermail/capwap/msg04161.html> 
>
> There were some objections to resolve since its late to consider
> optimizations at this stage of the draft, however most responses were in
> favor of adding the change.
>
> Issue 244 will be reflected in the updates to the CAPWAP drafts during
> upcoming WGLC. 
>
> If there are no further comments by Thursday, April 26th, Issue 244 will
> be moved to the active database and closed as agreed by consensus.
>
>
> Best Regards, 
> Mani, Margaret and Dorothy 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap