Capwap Mailing List: Re: need clarification on UDP ports

[NKA (nka.capwap]

Please go through my inline comments below.

NKA

On 10/18/06, Scott G. Kelly <s.kelly [at] ix.netcom.com> wrote:
> 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.

[NKA] Even if a less-robust AC implementation ends up interpreting DTLS
message as a Discovery packet, do you think WTP (which unfortunately
has passed discovery state) will be able to carry on with its DTLS
session establishment and succeed ultimately? :-( I don't think so.  (Imagine
this: WTP needs to successfully interpret Discovery response as HelloVerify
request, followed by which AC needs to interpret ClientHello (with cookie) as
Client Hello without Cookie, and so on).

Folks,
I want to ask you this DTLS/discovery control packet question in a different
form. Suppose by accident (or due a bug), WTP happens to be in a FSM
state which is not same as that of AC. How would AC process the arrived
packet from the faulty WTP? It would go by its FSM state. The logic for this
is based on the fact that capwap header doesn't carry FSM state information
and both the involved entities process packets based on the assumption
that their FSM is in sync. Hence I conclude that discovery packets should
not be treated in any special fashion.

Having extra fields in the header or usage of seperate UDP ports will definitely
ease up the situation here, but we, at IETF, are here to define a specification
which is optimum in nature.


> >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