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

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 19 Oct 2006 18:11:23 -0400 (EDT)

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

Actually, no, I don't agree. A discovery packet should be deterministically treated as a discovery packet - not sometimes erroneously treated as a dtls packet. I think introducing this ambiguity is unnecessary, to say the least. 

I think Abhijit's point is correct: it should be very clear whether a packet is control, data, discovery, and protected vs unprotected. Either we can do that by using more ports, or we can find another way. But I don't think shoving a discovery packet into the dtls engine is "a good thing".

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: Sat, 21 Oct 2006 01:30:52 +0530

> Actually, no, I don't agree. A discovery packet should be deterministically treated as a discovery packet - not sometimes erroneously treated as a dtls packet. I think introducing this ambiguity is…

[NKA] Scott, now you are not agreeing to what you said in youre previous email.
Look at the snippet of the same.

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

[NKA] My point is that seperate discovery packet processing via a special port
is a bad idea. And it doesn't bring any additional value than what can be
achieved without special port approach. Scott's additional reasoning that two
port approach would open up scope for DOS atack. I totally disagree with
the argument. I claim that the same risk exists even with 3-port approach also.