Capwap Mailing List: Re: need clarification on UDP ports

[Scott G. Kelly (s.kelly]

Comments inline below...

-----Original Message-----
>From: NKA NKA <nka.capwap [at] gmail.com>
>Sent: Oct 17, 2006 1:00 PM
>To: Abhijit [at] sinett.com, pcalhoun [at] cisco.com, dstanley1389 [at] 
>gmail.com, montemurro.michael [at] gmail.com
>Cc: capwap [at] frascone.com
>Subject: Re: [Capwap] need clarification on UDP ports
>
> ________________________________
>From: Abhijit Choudhury [mailto:Abhijit [at] sinett.com]
>> Sent: Tue 10/17/2006 10:37 PM
>> To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro
>> Cc: capwap [at] frascone.com
>> Subject: [Capwap] need clarification on UDP ports
>>
>>
>>
>> Pat, Mike, Dorothy:
>>
>> I have a question based on v03 of the capwap spec.
>> In section 3.1, the spec mentions well-known UDP
>> ports for the CAPWAP control and data packets.
>>
>> There are four kinds of CAPWAP packets:
>> 1. DTLS protected control packets
>> 2. Unprotected control packets
>> 3. Unprotected data packets
>> 4. (Optional) DTLS protected data packets
>>
>>
>> Will there be 4 well-known UDP port numbers ?
>
>[NKA} As per my understanding, you don't need to have two seperate UDP ports
>for handling DTLS and Non-DTLS control packets. Following is the logic which
>I would use at AC:
>
>  1. If AC receives a UDP packet on its control port, and if it CAN'T
>find the session
>  information corresponding to the sender WTP, then the arrived packet can
>  be considered to be a discovery packet.
>
>  In the above situation, for some reason, if WTP sent a DTLS packet, AC can
>  continue to assume it to be a discovery packet. So it should feed the arrived
>  DTLS packet to its discovery packet processing module. Ultimately the
>  packet will get dropped by AC due to packet parsing error (chances of DTLS
>  packet looking like a valid discovery packet is very very slim).

Here are the first few words of the latest proposed capwap header, which would 
be at the head of the discovery message:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Fragment ID          |     Frag Offset         |Rsvd |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Here's the DTLS record header, which will be present after dtls negotiation 
starts:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
     |    type       |    protocol version           |  epoch
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
       epoch, cont   |       (6 byte sequence #)
     /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The type will be from TLS; the ClientHello is 0x16, or 00010110 (other tls 
types of interest are similar), and the DTLS protocol version will be 0xFEFF, 
and any dtls version changes will just decrement the first version byte (FE, 
FD, FC, etc). This translates to the following bits:

    1   6    F    E    F   F
  0001 0110 1111 1110 1111 1111

Putting this into the capwap header:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|0 1 1 0 1|1 1 1 1 1|1 0 1 1 1|1 1 1 1 1 0 0 0 0 0 0 0 0|
    |VERSION|   RID   | HLEN    |  WBID   |   Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

or, 

VERSION..: 0001
RID......: 01101 (13)
HLEN.....: 11111 (31)
WBID.....: 10111 (23)

Today, we don't have WBID of 23, so a robust implementation should interpret 
this as an error, but I wouldn't say
chances of a DTLS packet looking like a discovery packet are really all that 
slim.  It depends on several assumptions.

>After a few trial,
>  WTP will reboot and ultimately get in sync with AC's State machine.
>  2. If AC receives a UDP packet on its control port, and if it CAN
>find the session
>  information corresponding to the sender, then the arrived packet can be
>  considered as a DTLS packet. So AC should feed such packets to DTLS module
>  directly.

.. unless it's as discovery packet from a WTP that reset and no longer has the 
DTLS session context. Eventually, that session will timeout, but how long this 
takes depends on the configured echo interval. If it's more than a few seconds 
(e.g. say, 30 seconds), this adds a significant bit of latency to recovery 
scenarios.

>  You may have a situation in which session information exists for a WTP at AC,
>  but WTP is sending non-DTLS packet. Even in such situation, AC can feed such
>  packets to DTLS module, which will ultimately reject the packet. AC can use
>  this kind of notification to tear down the existing session, which
>will bring AC's
>  state machine in sync with that of WTP.

The WTP - or someone who spoofs the WTP address. Sounds like a very simple DoS 
attack. 

>I have not given much thought about the data path issue. May be the
>initial policy
>(about dtls) exhcnage would help. Once both the party (AC as well as WTP) agree
>whether DTLS will be used or not, the same information can be used for
>programming the hardware. I know that issue # 221 is tracking data
>path policy issue.
>
>NKA
>
>>
>> 1, 2 and 3 will be present simultaneously in any
>> deployment. 3 and 4 may co-exist in a deployment
>> if some data channels are encrypted and some not.
>> There has to be a way to distinguish these four
>> kinds of packets.  The draft is not clear about how
>> this is done.
>>

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