Capwap Mailing List: Re: Issue 30: Inconsistent state tracking onAC prior toDTLSEstablishment

[Scott G. Kelly (s.kelly]

Hi Pat,

pcalhou wrote:
>If the issue is with Sulking, we can fix that. I'm open the making
>necessary changes to avoid security vulnerabilities. We can remove the
>Sulking state our of the DTLS Setup/Connect states, although there
>really is no perfect world here. Either you are open to constantly
>processing invalid connect setup requests, or you disable this for a
>period of time from a given IP address. I understand the consequences,
>but it is a decision that an implementer needs to make. If we decide
>that rate limiting is the way to go, I'm ok with that too (and this
>could cause the same effect as the current text, btw).
>
>That said, I think that the state machine clearly shows how one *could*
>implement the state machine. It does not limit how an implementer can,
>but I believe it provides the right guidance, and really helps
>understand how the AC should work. There was text previously, but
>frankly, it was hard to understand. Further, we opted to make a "SHOULD
>NOT" for maintaining state, but that means that while one SHOULD NOT,
>one can if they want to. So the state machine must allow for that. I
>believe it does now, and an implementer is free to choose whether he/she
>wants to or not.

First, regarding sulking: as currently worded/defined, if I can spoof 
(unauthenticated) packets from a client, I can cause that client to be locked 
out, _even if it already has a valid DTLS session_. This is bad. It would be 
much better if it only prevented initiation of new handshakes for a limited 
period, but I'm not sure if the complexity is justified. Rate-limiting plus 
admin alerts seems like a simpler strategy.

Second, regarding the state machine documentation, I don't think we have any 
precedent for detailing how to implement "SHOULD NOT" features in an RFC. 
"SHOULD NOT" means "don't try this at home, kiddies", and I don't think the 
IESG would agree that the state machine should document how to "allow" for 
things we are saying you SHOULD NOT implement.
 
Scott