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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 30 Nov 2006 16:52:20 -0800

I fundamentally disagree. We have had this debate, and the conclusion of
the debate should stand. Separate ports.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Puneet Agarwal [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 4:31 PM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: RE: [Capwap] Proposed Resolution for Issue 
> 227/224/89 (and part of 146)
> 
>  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)
> 
> 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
> 
_________________________________________________________________
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 19:07:18 -0800

Hi Pat,

I disagree with your assertion. Please see my reasons outlined in the
"RE: [Capwap] Proposed Resolution for Issue 127: Use of Session ID"
email that I recently posted.

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 4:52 PM
To: Puneet Agarwal; [email-masked]
Subject: RE: [Capwap] Proposed Resolution for Issue 227/224/89 (and part
of 146)

Pat Calhoun

> 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?
> 
> 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
>       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
> The reason for this was that it wasn't obvious that any and all DTLS 
> packets would have this bit set.
> 
> Pat Calhoun