Subject: Re: [Capwap] need clarification on UDP ports

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 18 Oct 2006 14:01:01 -0700 (GMT-07:00)

<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

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Navin (NKA)" <[email-masked]>
Date: Fri, 20 Oct 2006 00:38:01 +0530

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