Capwap Mailing List: Re: Issue 30: Inconsistent state tracking onAC priortoDTLSEstablishment

[Pat Calhoun (pacalhou) (pcalhoun]

The current spec clearly states:

12.3.  Discovery Attacks

   Since the Discovery Request messages are sent in the clear, it is
   important that AC implementations NOT assume that receiving such a
   request from a WTP implies that it has rebooted, and consequently
   tear down any active DTLS sessions.

We can expand this text to include the initiation of DTLS sessions.

PatC 

-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
Sent: Monday, December 17, 2007 11:12 AM
To: Pat Calhoun (pacalhou); Charles Clancy; capwap
Subject: RE: [Capwap] Issue 30: Inconsistent state tracking onAC
priortoDTLSEstablishment

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