Capwap Mailing List: Re: need clarification on UDP ports

[Puneet Agarwal (pagarwal]

Hi Margaret,

I am OK with your 2 port solution (with shim header for capwap control
only).

To summarize, it seems that you are proposing that there be two UDP
ports reserved for CAPWAP:

A) CAPWAP Control Port: All discovery and capwap control messages flow
on this UDP port. There is a new shim (control mux) header added between
the UDP Header and the following header (where the following header
could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The control
mux would specify if the packet is DTLS encrypted or not. I didn't want
to use the "Control Header" for the new shim as section 4 already talks
about a "Control Header".

B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP port. It
is a property of the UDP tunnel whether the payload in encrypted or not.
If the tunnel is encrypted, then a DTLS header follows the UDP Header.
If the tunnel is not encrypted, then a CAPWAP Header follows the UDP
Header. Note that there is no "control mux" after the UDP header.

Is the above interpretation correct?

Thanks.

-Puneet

-----Original Message-----
From: Margaret Wasserman [mailto:margaret [at] thingmagic.com] 
Sent: Wednesday, October 25, 2006 10:09 AM
To: Pat Calhoun
Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; 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