Subject: Re: [Capwap] Issue 30: Inconsistent state tracking onAC prior toDTLSEstablishment

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 17 Dec 2007 11:12:00 -0800 (GMT-08:00)

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

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 17 Dec 2007 12:45:49 -0800

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:[email-masked]] 
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,

>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