Capwap Mailing List: Re: need clarification on UDP ports

[Abhijit Choudhury (Abhijit]

On 10/18/06, Abhijit Choudhury <Abhijit [at] sinett.com> wrote:
>        I think for data channel security, it will have
>        to be a binary decision for an AC/WTP pair, i.e.
>        if data channel encryption is enabled, it is for all data.
>
>        For the control channel, I think to have a clean
>        solution (with deterministic behavior) we need either
>        a separate discovery port or a type header which allows
>        one to distinguish between discovery and dtls packets.
>
>        Scott
>
> In a clean solution, the packet itself should have enough information 
> to clearly classify it as one of the four types of packets. We should 
> not have to depend on configuration lookups to check whether the 
> packet is supposed to be DTLS encrypted or not.

[NKA] Good point. But remember that for this flag to be affective, it
needs to appear before the DTLS header. Currently Capwap transport
header comes after DTLS. If we take your suggestion, Capwap header will
be in two part. One part will appear before DTLS header and second one
will be after DTLS header. But didn't we recently decided to not go with
Mux header approach?

[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.
>
> We have used this principle already in designing the CAPWAP header.  
> The T bit clearly identifies the payload as 802.3 or native format. 
> This could have been identified based on a config lookup since an AC 
> would typically handle 802.3 payload or native but rarely both. But we

> chose to include this information the header itself to make the design

> clean.
>
> The same idea should be used for distinguishing between
> the four packet types.  Having four distinct UDP ports is one option. 
> I'm sure there are others.
>
> Regards,
> Abhijit
>