Capwap Mailing List: Re: need clarification on UDP ports

[Pat Calhoun (pacalhou) (pcalhoun]

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:margaret [at] thingmagic.com] 
> Sent: Wednesday, October 25, 2006 10:09 AM
> To: Pat Calhoun (pacalhou)
> Cc: Scott G. Kelly; Hasan Raza; pagarwal [at] broadcom.com; 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:s.kelly [at] ix.netcom.com]
> >> Sent: Tuesday, October 24, 2006 1:24 PM
> >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal [at] broadcom.com
> >> 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
>