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

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

Could you explain why you believe the sessionID should not be protected? Seems like the IP address and UDP port are sufficient to distinguish the WTP (for encrypted data plane, this would be known after the first packet is received.

PatC

 -----Original Message-----
From: 	Abhijit Choudhury [mailto:[email-masked]]
Sent:	Wednesday, October 25, 2006 11:59 PM Pacific Standard Time
To:	Puneet Agarwal; Margaret Wasserman; Pat Calhoun (pacalhou); Scott G. Kelly
Cc:	capwap
Subject:	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:[email-masked]]
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:[email-masked]]
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:[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

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

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

---

From: Scott G Kelly <[email-masked]>
Date: Thu, 26 Oct 2006 05:02:37 -0700

I think what Abhijit suggested can be accomplished without exposing the 
session id itself. The functionality we're after is really a (QoS) 
tunnel id, so we know what dtls session to use for the given source. One 
solution is to plumb an ACL and rely on the source port, but this value 
could also be included in the type header:

+------------+------------+------------+------------+
| version    | tunnel id  |          type           |
+------------+------------+------------+------------+

It could be less than 8 bits - this is merely illustrative. This is 
equivalent to the 'channel id' I suggested concatenating with the 
sessionID earlier, but this approach exposes it and uses it for dtls 
session selection (and the sessionID would still be in the protected 
portion, and used to bind control/data channels).

The source port can also be used, but with multiple WTPs going through a 
NAT, the approach above doesn't chew up (potentially) 8+ ports per WTP 
in the NAT's binding table (and fwiw, there's no corresponding chance of 
being 'bumped' from the binding table on a heavily loaded NAT).

Pat Calhoun (pacalhou) wrote:
> Could you explain why you believe the sessionID should not be protected? 
> Seems like the IP address and UDP port are sufficient to distinguish the 
> WTP (for encrypted data plane, this would be known after the first 
> packet is received.
> 
> PatC
> 
> ------------------------------------------------------------------------
>

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Thu, 26 Oct 2006 10:07:04 -0700

Scott,
That's exactly what I had in mind.
Thanks for clarifying my point.
The tunnelId is sufficient to pull out the correct
information for anti-replay checking.
 
Seems like we are then reaching a consensus
that both control and data channels will have
the same format with a 4-byte header between
the UDP header and the DTLS or CAPWAP header.
I think we should make it a 4-byte header since
all the headers so far (UDP, CAPWAP etc.)
are nicely 4-byte aligned.  As Pat pointed out,
the overhead is minimal  in the grand scheme of
things.
 
Regards,
Abhijit

From: Scott G Kelly [mailto:[email-masked]]
Sent: Thu 10/26/2006 5:02 AM
To: Pat Calhoun (pacalhou)
Cc: Abhijit Choudhury; Puneet Agarwal; Margaret Wasserman; Scott G. Kelly; capwap
Subject: Re: [Capwap] need clarification on UDP ports