Capwap Mailing List: Re: need clarification on UDP ports

[Scott G. Kelly (s.kelly]

Hi Abhijit,

>[Abhijit] That is exactly why I did not suggest a shim header or type
>field. Instead, I suggested separate UDP ports to indicate the type
>af packet. That way we don't need a separate header between 
>UDP and DTLS headers.

Yes, because we all know that putting anything between the UDP header and the 
DTLS header is *EVIL*, and anyone who would even *SUGGEST* such heresy should 
be crucified! And BURNED! And STABBED, SHOT, BEATEN, and RIDICULED, and then 
FEASTED UPON BY MAGGOTS!

But a little more seriously :-), one reason I still consider a type header 
worthy of consideration (despite the choice of separate ports for 
control/data): if we implement data channel crypto (and there seems to be 
stronger support for this now), we are either going to have to use exactly one 
QoS level for all data, or we'll need to be able to support multiple encrypted 
data channel streams per wtp (up to a maximum of 1 per QoS level, or 8).  
Otherwise, the DTLS antireplay mechanism and QoS won't play well together.

This is a well-documented problem that we ran into in IPsec, and it will also 
occur here in CAPWAP, and especially once 11n shows up.  See RFC 4301, halfway 
into section 4.1 (starting near the bottom of page 13):

   If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,
   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.
-----------------------

Antireplay is not optional in DTLS, so the same issues apply - you need 
per-QoS-level session identifiers to resolve this -- that is, if you want data 
channel QoS support. One option is to choose a separate port for each QoS 
level, but that would mean we'd potentially need to support 8 ports for data, 
and if we ever decide we need to differentiate QoS levels on the control 
channel for some reason, we'll need even more ports for that.

Even with 50K ports still available (or more, or less, don't know the exact 
number today),  it's possible that IANA and/or the IESG will object to us 
grabbing this many ports for one protocol. Especially when this could be easily 
solved by putting a few bytes between the udp header and the payload. This 
doesn't mean you don't use two ports, one for control, one for data - it simply 
means you have a stream id+type in the clear after the UDP header.

Scott