Capwap Mailing List: Re: Proposed Resolution for Issue 224/89 (and part of 146)

[Pat Calhoun (pacalhou) (pcalhoun]

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

 

> -----Original Message-----
> From: Jim Murphy [mailto:jmurphy [at] trapezenetworks.com] 
> Sent: Wednesday, January 17, 2007 6:30 AM
> To: Abhijit Choudhury
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 
> (and part of 146)
> 
> 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:
> > 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:jmurphy [at] trapezenetworks.com]
> > Sent: Tuesday, January 16, 2007 4:05 PM
> > To: Pat Calhoun (pacalhou)
> > Cc: capwap [at] frascone.com
> > 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
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 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?pr
> > omote=mail>
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _________________________________________________________________
> > 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
>