Capwap Mailing List: Re: need clarification on UDP ports

[Navin (NKA) (nka.capwap]

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

[NKA] Scott, so you agree that the logic which I have explained for handling
discovery/DTLS packets is correct, but you feel that it would result in slower
synchronization between WTP and AC FSM?

Fine. Lets discuss how to reduce bring-up time of a Capwap compliant WTP
in general in a seperate NEW thread? It will be confusing for the WG folks
to discuss the same under incorrect/inappropriate thread subject.


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