Capwap Mailing List: Re: need clarification on UDP ports

[Scott G. Kelly (s.kelly]

<this is getting too hard to read, so extraneous text elided...>

>[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).

That's not the point, and this is minor compared to the real issue, which is 
below.

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

Yes, but only in the absence of better information. If it's FSM state is RUN 
and it receives a discovery packet, though, going by its FSM state leads to an 
error condition.

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

The WTP may also be in in a different FSM state because it was restarted, 
either due to a crash, power failure, operator action, etc.  - it does not 
(necessarily) imply some freak accident or bug. 

In this case the WTP will often need to go through discovery again before 
reconnecting to the AC. If the AC erroneously feeds these packets to its DTLS 
implementation, they will be rejected, and the WTP will get no response.  This 
means failure recovery will not occur until the AC times out its DTLS session, 
and since these timeouts are frequently set as high as 30 seconds in the field, 
 and since the WTP may exhaust its discovery timers and go into sulking state 
due to AC unresponsiveness, this has the potential to signficantly (and 
unfortunately, completely avoidably) exacerbate the outage. 

You could try to work around this by handing every packet that fails in the 
DTLS engine to some other code to see if it's a discovery packet, but in doing 
so you're adding complexity, and compounding the amount of per-packet work an 
adversary can make an AC do.

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

Umm... you lost me. I don't see how adding non-determism to save a port (or a 
few header bytes) results in an optimal solution.

Thanks,

Scott