Subject: [Capwap] Inconsistent state tracking on AC prior to DTLS Establishment

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 12 Oct 2007 14:18:23 -0700

All,

In order to avoid exposing the AC to DoS attacks, the CAPWAP specific
states that the AC may maintain state prior to the establishment of the
DTLS session. See text below:

   Discovery to DTLS Setup (f):  This transition occurs to establish a
      secure DTLS session with the peer.
[...]
      AC:  The AC initiates this transition by invoking the DTLSListen
         command (see Section 2.3.2.1), which informs the DTLS stack
         that it is willing to listen for an incoming session.  The AC
         MAY have maintained state information when it received the
         Discovery Request message to provide optional qualifiers in the
         DTLSListen command to only accept session requests from a
         specific WTP.  Note that maintaining state information based on
         an unsecured Discovery Request message MAY lead to a Denial of
         Service attack.  Therefore the AC SHOULD ensure that the state
         information is freed after a period, which is implementation
         specific.

This means that implementations may not maintain any state until the
secure channel is setup. However, there are three state transitions,
namely Idle to Sulking, DTLS Setup to Idle and Sulking to Sulking that
include specific guidance on AC behavior that necessitates that state be
maintained at this point. This inconsistency needs to be resolve, so I
would propose that for the three state transitions, text along the lines
of "If WTP state is being maintained at this point on the AC, ..."
(where ... is replaced with the appropriate action to take. 

Thoughts?

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

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