Subject: Re: [Capwap] need clarification on UDP ports

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 03:44:04 -0700

ok... no real objections on including an interim (short) tag to
represent the packet type. If we are to go down this path, I would
prefer that we maintain consistency across both the control and data
plane, and include the same header on both UDP ports. This way, if a
DTLS session is being used to secure the data plane, the (relatively)
same pre-parsing and security validation logic can be used.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Wednesday, October 25, 2006 10:09 AM
> To: Pat Calhoun (pacalhou)
> Cc: Scott G. Kelly; Hasan Raza; [email-masked]; capwap
> Subject: Re: [Capwap] need clarification on UDP ports
> 
> 
> Hi all,
> 
> Just commenting as an individual contributor...
> 
> I prefer the intermediate header approach to the third port 
> approach, because I think it is a cleaner representation of 
> what is actually happening.
> 
> Different ports are used to reach different end points 
> (different systems or different processes running on the same 
> system).  In CAPWAP, we have one port to reach the data 
> end-point and another to reach the control end-point, because 
> we think there are cases when the data and control end-points 
> may be different processes or run on different systems.  That 
> makes sense to me.
> 
> However, when we are talking about DTLS-encrypted and 
> unencrypted control packets, we aren't really talking about 
> two different end- points.  We are talking about a single 
> control application that needs to decide whether to treat 
> each packet it received as unencrypted or as DTLS-encrypted, 
> in which case it needs to be handed to the DTLS engine for 
> decryption.  If you think about it that way, I think it would 
> be better for the control application to receive a packet 
> that starts with a short header that indicates whether this 
> packet is DTLS- encrypted or unencrypted.  If the packet is 
> unencrypted, the control application processes it directly 
> (or ignores the packet if it isn't a discovery packet), and 
> if it is DTLS-encrypted, the control application strips off 
> the header and send the packet to the DTLS engine for 
> decryption.  This type of header might also allow for later 
> expansion if the security world evolves and a better security 
> mechanism for CAPWAP's purposes emerges.
> 
> So, I would prefer that we add a short header after the UDP 
> header (a CAPWAP control header?) that indicates the type of 
> the encapsulated packet (DTLS-encrypted or unencrypted).  I 
> think 4 bytes would be long enough for this header, and that 
> would maintain 32-bit alignment.  IMO, it should contain 2 
> fields -- a one byte version number (0x01) and a three-byte 
> type field.  At this point, only two types would be defined.
> 
> I do not have a major technical objection to the third port 
> option, I just think it is less clean from an architectural 
> standpoint.
> 
> I would rather strenuously object to the proposed approaches 
> that involve zeroing out the DTLS header or running a packet 
> through DTLS and then treating it as unencrypted if that fails, etc.
> 
> Margaret
> 
> 
> On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote:
> 
> > Not pushing for the hack. I've stated I do not object to a 
> third UDP 
> > port, but provided an alternative should IANA refuse to 
> give it to us.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> >
> >
> >
> >> -----Original Message-----
> >> From: Scott G. Kelly [mailto:[email-masked]]
> >> Sent: Tuesday, October 24, 2006 1:24 PM
> >> To: Pat Calhoun (pacalhou); Hasan Raza; [email-masked]
> >> Cc: capwap
> >> Subject: RE: [Capwap] need clarification on UDP ports
> >>
> >> "Pat Calhoun (pacalhou)" wrote:
> >>
> >>> Except we can document that any CAPWAP implementation receiving a
> >>> packet with  'n' zeroes uses DTLS header format foo, which
> >> is of lengh 'y'.
> >>
> >> ...except that it is decidedly *not* a DTLS header, right?
> >> I'm having a really hard time understanding why you're
> >> pushing for a hack at any/all costs to solve this problem. We
> >> are at the design stage - if there were ever a time to do it
> >> right, that time is now. Exactly what will break if we don't
> >> adopt this hack?
> >>
> >> Scott
> >>
> > _________________________________________________________________
> > 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: Margaret Wasserman <[email-masked]>
Date: Thu, 26 Oct 2006 08:00:41 -0400

Hi Pat,

> same pre-parsing and security validation logic can be used.

That works for me, too

The main reason I had not suggested including the tag on both control  
and data packets was that I was concerned about lowering the MTU of  
the link for little benefit.  Is there some reason why that isn't a  
concern?

Margaret

---

From: Hasan Raza <[email-masked]>
Date: Thu, 26 Oct 2006 19:02:58 +0530

> same pre-parsing and security validation logic can be used.
Usually data plane is implemented in hardware and control plane in
software. Though a bit tricky, but bump in the stack is easier to
implement in software than hardware. Changing fast path logic in
hardware just for capwap packets may not be worth an effort if the extra
type header field does not serve any purpose. Since it is more or less
decided that DTLS is enabled or disabled on data plane is just based on
a binary configuration at AC, there does not seem to be any purpose of
extra type header field for data packets. May be we should look into
issue #221.

Hasan