Capwap Mailing List: Re: need clarification on UDP ports

[Abhijit Choudhury (Abhijit]

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

Folks,

I like the solution below, but I'd go one step further.

We should just have a single CAPWAP packet format.

The shim header should be present in both capwap

control and data packets, and  should have a

field to indicate  encrypted/unencrypted as well

as a type/sessionId field.

 

For packets arriving  on either control or data port,

the encrypted/unencrypted field indicates whether

the payload is DTLS encrypted.

 

For DTLS encrypted packets arriving on the data port,

the type/sessionId field  indicates the QoS level in

order to avoid antireplay issues.

 

This approach is simple, clean and addresses all the

concerns raised so far on this issue:

 

1.  Uses separate control and data UDP ports to steer packets

      through legacy devices with different levels of QoS

2.  Is able to distinguish between encrypted and unencrypted packets

     in the CAPWAP payload.

3.  Is able to support multiple QoS levels if the data channel is

     DTLS encrypted.

I believe this is similar to the proposal that Scott

presented in one of his earlier emails. 

 

Regards,

Abhijit

---

From: Puneet Agarwal [mailto:pagarwal [at] broadcom.com]
Sent: Wed 10/25/2006 11:17 PM
To: Margaret Wasserman; Pat Calhoun
Cc: Hasan Raza; capwap
Subject: Re: [Capwap] need clarification on UDP ports

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



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap