Capwap Mailing List: Re: need clarification on UDP ports

[Abhijit Choudhury (Abhijit]

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

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:scott [at] hyperthought.com]
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

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
>
>  -----Original Message-----
> From:   Abhijit Choudhury [mailto:Abhijit [at] sinett.com]
> 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: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
>
>
>
> ------------------------------------------------------------------------
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap