Subject: [Capwap] New Issue 226 proposed text

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 25 Jan 2007 15:16:37 -0800

All,

Based on the discussions during the interim meeting, reviewing the
previously sent proposed text., here are the following issues that were
raised (and associated text):

1. Idle->DTLS Setup. There is text that was ambiguous on the
pre-configuration of Acs on the WTP.

2. We need to handle the case where a DTLS authentication fails. The
authentication occurs after the authorization callout.

3. DTLS Setup -> Authorize state change needs to have a pointer on
identity format 

4. Authorization. We need to provide some guidance on how authorization
occurs for both certificate and PSK based DTLS sessions. We need to
explain
how a "wildcard" can be used to allow any DTLS session.

5. DTLS PSK. We need to provide the identity format, which should be
based
on the MAC address. We want separate PSKs per WTP. This brought up the
need
to define the use of IDs in both PSK and certificate based approaches.

6. We need an Authorization Failure counter.

7. Need clear text on the fact that the number of instances of the state
machine, and timers on both the WTP and AC.

8. A typo in the Join -> DTLS TD. In the AC section, the text uses WTP
incorrectly, should be AC.

9. Issue with Reset -> DTLS Teardown. Currently, the text causes both
the
WTP and the AC to shutdown the session. There is no point in doing so.
The
change is to only have the AC initiate the DTLS shutdown when it
receives
the Reset Response from the WTP.

10. There are two missing state transitions: Configure -> DTLS Teardown
and
Image Data -> DTLS Teardown.

11. Section 2.4.4.1. We need to remove the third sentence of the first
paragraph
since we do not want to support any arbitrary DTLS crypto mode.

12. The DTLS Teardown->Idle. The text is currently wrong because it
states that
the AC or WTP is to invoke the DTLSDisconnectPeer command. The state
transition
should instead talk about clearing up DTLS context information, timers,
and
optionally any DTLS resources that may have been used on the data plane.

So I will once more include all of the text (in its completeness) that
addresses
the original 226 issues, and the above ones as well. I apologize for the
size of
this text, but I believe it is better to be inclusive than to simply
include
snippets.

2.3.  CAPWAP State Machine Definition
[...]
                                       /-------------------------\
                                      w|                         |
                                 5+----------+ x +------------+  |
                                  |   Run    |-->|   Reset    |-\|
                                  +----------+   +------------+ ||
                               u      ^           ^     ^      y||
                +------------+--------/           |     |       ||
                | Data Check |             /-------/    |       ||
                +------------+<-------\   |             |       ||
                                     t|  s|    4       o|       ||
               +--------+     +-----------+     +--------------+||
               |  Join  |---->| Configure |---->|  Image Data  |||
               +--------+  q  +-----------+  r  +--------------+||
                ^  p|                  V|                    x| ||
                |   |                   \-------------------\ | ||
                |   \--------------------------------------\| | ||
                \------------------------\                 || | ||
         /--------------<----------------+--------------\  || | ||
         | /------------<-------------\  |              |  || | ||
         | |                         m|  |n            z|  vv v   vv
         | |   +----------------+   +--------------+   +-----------+
         | |   |   DTLS Setup   |   | DTLS Connect |   |  DTLS TD  |
         | |   +----------------+   +--------------+   +-----------+
         | |    g|  ^     ^   |h         ^               ^
         v v     |  |     |   |          |               |
         | |     |  |     |   \-------\  |   /-----------/
         | |     |  |     |           |  |   |
         | |     v  |e   f|      2    v  |j  |k
         | \->+------+   +------+   +-----------+
         |    | Idle |-->| Disc |   | Authorize |
         \--->+------+ a +------+   +-----------+
              b|    ^           |c
               |    |      /----/
               v   d|      |
              +---------+  |
              | Sulking |<-/
            3 +---------+

                 Figure 3: CAPWAP Integrated State Machine
[...]
   Since the WTP only communicates with a single AC, it only has a
   single instance of the CAPWAP state machine.  The AC, on the other
   hand, has a separate instance of the CAPWAP state machine per WTP it
   is communicating with.

2.3.1.  CAPWAP Protocol State Transitions

   The following text discusses the various state transitions, and the
   events that cause them.  This section does not discuss interactions
   between DTLS- and CAPWAP-specific states.  Those interactions, as
   well as DTLS-specific states and transitions, are discussed in
   Section 2.3.2.

   Idle to Discovery (a):  This transition occurs once device
      initialization is complete.

      WTP:  The WTP enters the Discovery state prior to transmitting the
         first Discovery Request message (see Section 5.1).  Upon
         entering this state, the WTP sets the DiscoveryInterval timer
         (see Section 4.6).  The WTP resets the DiscoveryCount counter
         to zero (0) (see Section 4.7).  The WTP also clears all
         information from ACs it may have received during a previous
         Discovery phase.

      AC:  The AC does not maintain state information for the WTP upon
         reception of the Discovery Request message, but it SHOULD
         respond with a Discovery Response message (see Section 5.2).
         This transition is a no-op for the AC.

   Idle to Sulking (b):  This transition occurs to force the WTP and AC
      to enter a quiet period to avoid repeatedly attempting to
      establish a connection.

      WTP:  The WTP enters this state when the FailedDTLSSessionCount or
         the FailedDTLSAuthFailCount counter reaches
         MaxFailedDTLSSessionRetry variable (see Section 4.7).  Upon
         entering this state, the WTP shall start the SilentInterval
         timer.  While in the Sulking state, all received CAPWAP and
         DTLS protocol messages received shall be ignored.

      AC:  The AC enters this state with the specific WTP when the
         FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter
         reaches MaxFailedDTLSSessionRetry variable (see Section 4.7).
         Upon entering this state, the AC shall start the SilentInterval
         timer.  While in the Sulking state, all received CAPWAP and
         DTLS protocol messages received from the WTP shall be ignored.

   Discovery to Discovery (2):  In the Discovery state, the WTP
      determines which AC to connect to.

      WTP:  This transition occurs when the DiscoveryInterval timer
         expires.  If the WTP is configured with a list of ACs, it
         transmits a Discovery Request message to every AC from which it
         has not received a Discovery Response message.  For every
         transition to this event, the WTP increments the DiscoveryCount
         counter.  See Section 5.1 for more information on how the WTP
         knows the ACs to which it should transmit the Discovery Request
         messages.  The WTP restarts the DiscoveryInterval timer
         whenever it transmits Discovery Request messages.

      AC:  This is a no-op.

   Discovery to Sulking (c):  This transition occurs on a WTP when
      Discovery or connectivity to the AC fails.

      WTP:  The WTP enters this state when the DiscoveryInterval timer
         expires or the DiscoveryCount variable is equal to the
         MaxDiscoveries variable (see Section 4.7).  Upon entering this
         state, the WTP shall start the SilentInterval timer.  While in
         the Sulking state, all received CAPWAP protocol messages
         received shall be ignored.

      AC:  This is a no-op.

   Sulking to Idle (d):  This transition occurs on a WTP when it must
      restart the discovery phase.

      WTP:  The WTP enters this state when the SilentInterval timer (see
         Section 4.6) expires.  The FailedDTLSSessionCount,
         DiscoveryCount and FailedDTLSAuthFailCount counters are reset
         to zero.

      AC:  The AC enters this state when the SilentInterval timer (see
         Section 4.6) expires.  The FailedDTLSSessionCount,
         DiscoveryCount and FailedDTLSAuthFailCount counters are reset
         to zero.

   Sulking to Sulking (3):  The Sulking state provides the silent
      period, minimizing the possibility for Denial of service attacks.

      WTP:  All packets received from the AC while in the sulking state
         are ignored.

      AC:  All packets receive from the WTP while in the sulking state
         are ignored.

   Idle to DTLS Setup (e):  This transition occurs to establish a secure
      DTLS session with the peer.

      WTP:  The WTP initiates this transition by invoking the DTLSStart
         command, which starts the DTLS session establishment with the
         chosen AC.  When the discovery phase is bypassed, it is assumed
         the WTP has a locally configured AC.

      AC:  The AC initiates this transition by invoking the DTLSListen
         command, which informs the DTLS stack that it is willing to
         listen for an incoming session.  The AC MAY provide optional
         qualifiers in the DTLSListen to only accept session requests
         from specific WTP.

   Discovery to DTLS Setup (f):  This transition occurs to establish a
      secure DTLS session with the peer.

      WTP:  The WTP initiates this transition by invoking the DTLSStart
         command (see Section 2.3.2.1), which starts the DTLS session
         establishment with the chosen AC.  The decision of which AC to
         connect to is the result of the discovery phase, which is
         described in Section 3.2.

      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 in order to provide optional qualifiers in
         the DTLSListen command to only accept session requests from
         specific WTP.  Note that maintaining state information based on
         an unsecured discovery request 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.

   DTLS Setup to Idle (g):  This transition occurs when the DTLS Session
      failed to be established.

      WTP:  The WTP initiates this state transition when it receives a
         DTLSEstablishFail notification from DTLS (see Section 2.3.2.2).
         This error notification aborts the secure DTLS session
         establishment.  When this notification is received, the
         FailedDTLSSessionCount counter is incremented.

      AC:  The WTP initiates this state transition when it receives a
         DTLSEstablishFail notification from DTLS (see Section 2.3.2.2).
         This error notification aborts the secure DTLS session
         establishment.  When this notification is received, the
         FailedDTLSSessionCount counter is incremented.

   DTLS Setup to Authorize (h):  This transition occurs an incoming DTLS
      session is being established, and the DTLS stack needs
      authorization to proceed with the session establishment.

      WTP:  This state transition occurs when the WTP receives the
         DTLSPeerAuthorize notification (see Section 2.3.2.2).  Upon
         entering this state, the WTP performs an authorization check
         against the AC's credentials.  See Section 2.4.4 for more
         information on AC authorization.

      AC:  This state transition occurs when the AC receives the
         DTLSPeerAuthorize notification (see Section 2.3.2.2).  Upon
         entering this state, the AC performs an authorization check
         against the WTP's credentials.  See Section 2.4.4 for more
         information on WTP authorization.

   Authorize to DTLS Connect (j):  This transition occurs to notify the
      DTLS stack that the session should be established.

      WTP:  This state transition occurs when the WTP has either opted
         to forgo the authorization check of the AC's credentials, or
         the credentials were successfully authorized.  This is done by
         invoking the DTLSAccept DTLS command (see Section 2.3.2.1).

      AC:  This state transition occurs when the AC has either opted to
         forgo the authorization check of the WTP's credentials, or the
         credentials were successfully authorized.  This is done by
         invoking the DTLSAccept DTLS command (see Section 2.3.2.1).

   Authorize to DTLS Teardown (k):  This transition occurs to notify the
      DTLS stack that the session should be aborted.

      WTP:  This state transition occurs when the WTP was unable to
         authorize the AC, via its credentials.  The WTP then aborts the
         DTLS session, which is done by invoking DTLSAbortSession (see
         Section 2.3.2.1).

      AC:  This state transition occurs when the AC was unable to
         authorize the WTP, via its credentials.  The AC then aborts the
         DTLS session, which is done by invoking DTLSAbortSession (see
         Section 2.3.2.1).

   DTLS Connect to Idle (m):  This transition occurs when the DTLS
      Session failed to be established.

      WTP:  This state transition occurs when the WTP receives either a
         DTLSAborted or DTLSAuthenticateFail notification (see
         Section 2.3.2.2), indicating that the DTLS session was not
         successfully established.  When this transition occurs due to
         the DTLSAuthenticateFail notification, the
         FailedDTLSAuthFailCount is incremented, otherwise the
         FailedDTLSSessionCount counter is incremented.

      AC:  This state transition occurs when the AC receives either a
         DTLSAborted or DTLSAuthenticateFail notification (see
         Section 2.3.2.2), indicating that the DTLS session was not
         successfully established.  When this transition occurs due to
         the DTLSAuthenticateFail notification, the
         FailedDTLSAuthFailCount is incremented, otherwise the
         FailedDTLSSessionCount counter is incremented.

   DTLS Connect to Join (n):  This transition occurs when the DTLS
      Session is successfully established.

      WTP:  This state transition occurs when the WTP receives the
         DTLSEstablished notification (see Section 2.3.2.2), indicating
         that the DTLS session was successfully established.  When this
         notification is received, the FailedDTLSSessionCount counter is
         set to zero.

      AC:  This state transition occurs when the AC receives the
         DTLSEstablished notification (see Section 2.3.2.2), indicating
         that the DTLS session was successfully established.  When this
         notification is received, the FailedDTLSSessionCount counter is
         set to zero.

   Join to DTLS Teardown (p):  This transition occurs when the join
      process failed.

      WTP:  This state transition occurs when the WTP receives a Join
         Response with a Result Code message element containing an
         error, or if the Image Identifier provided by the AC in the
         Join Response differs from the WTP's currently running firmware
         version and the WTP has the requested image in its non-volatile
         memory.  This causes the WTP to initiate the DTLSShutdown
         command (see Section 2.3.2.1).  This transition also occurs if
         the WTP receives one of the following DTLS notifications:
         DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect.

      AC:  This state transition occurs when the AC transmits a Join
         Response with a Result Code message element containing an
         error.  This causes the AC to initiate the DTLSShutdown command
         (see Section 2.3.2.1).  This transition also occurs if the AC
         receives one of the following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect

   Join to Configure (g):  This state transition is used by the WTP and
      the AC to exchange configuration information.

      WTP:  The WTP enters the Configure state when it successfully
         completes the Join operation.  If it determines that its
         version number and the version number advertised by the AC are
         compatible, the WTP transmits the Configuration Status message
         (see Section 8.2) to the AC with a snapshot of its current
         configuration.  The WTP also starts the ResponseTimeout timer
         (see Section 4.6).  If the version numbers are not compatible,
         the WTP will immediately transition to Image Data state (see
         transition (g)).  If the AC determines that a new firmware
         image should be installed on the WTP, the AC initiates a
         firmware download by sending an Image Data Request Message with
         an Initiate Download message element to the WTP

      AC:  This state transition occurs immediately after the AC
         transmits the Join Response message to the WTP.  If the AC
         receives the Configuration Status message from the WTP, the AC
         must transmit a Configuration Status Response message (see
         Section 8.3) to the WTP, and may include specific message
         elements to override the WTP's configuration.  If the AC
         instead receives the Image Data Request from the WTP, it
         immediately transitions to the Image Data state (see transition
         (g)).

   Configure to Reset (s):  This state transition is used to reset the
      connection either due to an error during the configuration phase,
      or when the WTP determines it needs to reset in order for the new
      configuration to take effect.

      WTP:  The WTP enters the Reset state when it receives a
         Configuration Status Response indicating an error or when it
         determines that a reset of the WTP is required, due to the
         characteristics of a new configuration.

      AC:  The AC transitions to the Reset state when it receives a
         Change State Event message from the WTP that contains an error
         for which the AC's policy does not permit the WTP providing
         service.

   Configure to DTLS Teardown (V):  This transition occurs when the
      configuration process aborts due to a DTLS error.

      WTP:  The WTP enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY decide to tear down the DTLS
         session if it receives frequent DTLSDecapFailure notifications.

      AC:  The AC enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY decide to tear down the DTLS
         session if it receives frequent DTLSDecapFailure notifications.

   Configure to Image Data (r):  This state transition is used by the
      WTP and the AC to download executable firmware.

      WTP:  The WTP enters the Image Data state when it successfully
         comletes DTLS session establishment, and determines that the
         Image Identifier provided by the AC in the Join Request differs
         from its currently running firmware, and that the WTP does not
         have the requested firmware in its non-volatile memory.  The
         WTP transmits the Image Data Request (see Section 9.1) message
         requesting that a download of the AC's latest firmware be
         initiated.

      AC:  This state transition occurs when the AC receives the Image
         Data Request message from the WTP.  The AC must transmit an
         Image Data Response message (see Section 9.2) to the WTP, which
         includes a portion of the firmware.

   Image Data to Image Data (4):  The Image Data state is used by WTP
      and the AC during the firmware download phase.

      WTP:  The WTP enters the Image Data state when it receives an
         Image Data Response message indicating that the AC has more
         data to send.

      AC:  This state transition occurs when the AC receives the Image
         Data Request message from the WTP while already in the Image
         Data state, and it detects that the firmware download has not
         completed.

   Image Data to Reset (o):  This state transition is used to reset the
      DTLS connection prior to restarting the WTP after an image
      download.

      WTP:  When an image download completes, the WTP enters the Reset
         state.  The WTP MAY also transition to this state upon
         receiving an Image Data Response from the AC (see Section 9.2)
         indicating a failure.

      AC:  The AC enters the Reset state when the image download is
         complete, or if an error occurs during the image download
         process.

   Image Data to DTLS Teardown (x):  This transition occurs when the
      firmware download process aborts due to a DTLS error.

      WTP:  The WTP enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY decide to tear down the DTLS
         session if it receives frequent DTLSDecapFailure notifications.

      AC:  The AC enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY decide to tear down the DTLS
         session if it receives frequent DTLSDecapFailure notifications.

   Configure to Data Check (t):  This state transition occurs when the
      WTP and AC confirm the configuration.

      WTP:  The WTP enters this state when it receives a successful
         Configuration Status Response message from the AC.  The WTP
         initializes the HeartBeat timer (see Section 4.6), and
         transmits the Change State Event Request message (see
         Section 8.7).

      AC:  This state transition occurs when the AC receives the Change
         State Event Request message (see Section 8.7) from the WTP.
         The AC responds with a Change State Event Response (see
         Section 8.8) message.  The AC must start the
         NeighborDeadInterval timer (see Section 4.6).

   Data Check to Run (u):  This state transition occurs once the linkage
      between the control and data channels has occured, which causes
      the WTP and AC to enter their normal state of operation.

      WTP:  The WTP enters this state when it receives a successful
         Change State Event Response from the AC.  The WTP initiates the
         data channel, which MAY require the establishment of a DTLS
         session, starts the DataChannelKeepAlive timer (see
         Section 4.6) and transmits a Data Channel Keep Alive (see
         Section 4.3.1).  The WTP then starts the
         DataChannelDeadInterval timer (see Section 4.6).

      AC:  This state transition occurs when the AC receives the Data
         Channel Keep Alive (see Section 4.3.1), whose Session ID
         message element matches the one included by the WTP in the Join
         Request.  Note that if the AC's policy is to require the data
         channel to be encrypted, this process would also require the
         establishment of the data channel's DTLS session.  Upon
         receiving the Data Channel Keep Alive, the AC transmits its own
         Data Channel Keep Alive.

   Run to DTLS Teardown (u):  This state transition occurs when an error
      has occured in the DTLS stack, causing the DTLS session to be
      torndown.

      WTP:  The WTP enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY decide to tear down the DTLS
         session if it receives frequent DTLSDecapFailure notifications.

      AC:  The AC enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY decide to tear down the DTLS
         session if it receives frequent DTLSDecapFailure notifications.

   Run to Run (5):  This is the normal state of operation.

      WTP:  This is the WTP's normal state of operation.  There are many
         events that result this state transition:

         Configuration Update:  The WTP receives a Configuration Update
            Request message(see Section 8.5).  The WTP MUST respond with
            a Configuration Update Response message (see Section 8.6).

         Change State Event:  The WTP receives a Change State Event
            Response message, or determines that it must initiate a
            Change State Event Request message, as a result of a failure
            or change in the state of a radio.

         Echo Request:  The WTP receives an Echo Request message (see
            Section 7.1), to which it MUST respond with an Echo Response
            message(see Section 7.2).

         Clear Config Request:  The WTP receives a Clear Configuration
            Request message (see Section 8.9).  The WTP MUST reset its
            configuration back to manufacturer defaults.

         WTP Event:  The WTP generates a WTP Event Request message to
            send information to the AC (see Section 9.5).  The WTP
            receives a WTP Event Response message from the AC (see
            Section 9.6).

         Data Transfer:  The WTP generates a Data Transfer Request
            message to the AC (see Section 9.7).  The WTP receives a
            Data Transfer Response message from the AC (see
            Section 9.8).

         Station Configuration Request:  The WTP receives a Station
            Config Request message (see Section 10.1), to which it MUST
            respond with a Station Config Response message (see
            Section 10.2).

      AC:  This is the AC's normal state of operation:

         Configuration Update:  The AC sends a Configuration Update
            Request message (see Section 8.5) to the WTP to update its
            configuration.  The AC receives a Configuration Update
            Response message (see Section 8.6) from the WTP.

         Change State Event:  The AC receives a Change State Event
            Request message (see Section 8.7), to which it MUST respond
            with the Change State Event Response message (see
            Section 8.8).

         Echo:  The AC sends an Echo Request message Section 7.1 or
            receives the corresponding Echo Response message, see
            Section 7.2 from the WTP.

         Clear Config Response:  The AC receives a Clear Configuration
            Response message (see Section 8.10).

         Station Config:  The AC sends a Station Configuration Request
            message (see Section 10.1) or receives the corresponding
            Station Configuration Response message (see Section 10.2)
            from the WTP.

         Data Transfer:  The AC receives a Data Transfer Request message
            from the AC (see Section 9.7) and MUST generate a
            corresponding Data Transfer Response message (see
            Section 9.8).

         WTP Event:  The AC receives a WTP Event Request message from
            the AC (see Section 9.5) and MUST generate a corresponding
            WTP Event Response message (see Section 9.6).

   Run to Reset (x):  This state transition is used when the AC or WTP
      wish to tear down the connection.  This may occur as part of
      normal operation, or due to error conditions.

      WTP:  The WTP enters the Reset state when it receives a Reset
         Request from the AC.

      AC:  The AC enters the reset state when it transmits a Reset
         Request to the WTP.

   Reset to DTLS Teardown (y):  This transition occurs when the CAPWAP
      reset is complete to terminate the DTLS session.

      WTP:  This state transition occurs when the WTP receives a Reset
         Response.  This causes the WTP to initiate the DTLSShutdown
         command (see Section 2.3.2.1).

      AC:  This state transition occurs when the AC transmits a Reset
         Response.  The AC does not invoke the DTLSShutdown command (see
         Section 2.3.2.1).

   DTLS Teardown to Idle (z):  This transition occurs when the DTLS
      session has been shutdown.

      WTP:  This state transition occurs the WTP has successfully
         cleaned up all resources associated with the control plane DTLS
         session.  The data plane's DTLS session also needs to be
         shutdown, and all resources freed, if a DTLS session was
         established for the data plane.  Any timers set for the current
         instance of the state machine are also cleared.

      AC:  This state transition occurs the AC has successfully cleaned
         up all resources associated with the control plane DTLS
         session.  The data plane's DTLS session also needs to be
         shutdown, and all resources freed, if a DTLS session was
         established for the data plane.  Any timers set for the current
         instance of the state machine are also cleared.

2.3.2.  CAPWAP/DTLS Interface

   This section describes the DTLS Commands used by CAPWAP, as well as
   the notifications received from DTLS to the CAPWAP protocol stack.

2.3.2.1.  CAPWAP to DTLS Commands

   Four commands are defined for the CAPWAP to DTLS API.  These
   "commands" are conceptual, and may be implemented as one or more
   function calls.  This API definition is provided to clarify
   interactions between the DTLS and CAPWAP components of the integrated
   CAPWAP state machine.

   Below is a list of the minimal command API:

   o  DTLSStart is sent to the DTLS module to cause a DTLS session to be
      established.  Upon invoking the DTLSStart command, the WaitDTLS
      timer is started.  The WTP is the only CAPWAP device that
      initiates this DTLS command, as the AC does not initiate DTLS
      sessions.

   o  DTLSListen is sent to the DTLS module to allow the DTLS to listen
      for incoming DTLS session requests.

   o  DTLSAccept is sent to the DTLS module to allow the DTLS session
      establishment to continue successfully.

   o  DTLSAbortSession is sent to the DTLS module to cause the session
      that is in the process of being established, to be aborted.  This
      command is also sent when the WaitDTLS timer expires.  When this
      command is executed, the FailedDTLSSessionCount counter is
      incremented.

   o  DTLSShutdown is sent to the DTLS module to cause session teardown.

   o  DTLSMtuUpdate is called by the CAPWAP protocol to modify the MTU
      size used by the DTLS module.  The default value size is 1468.

2.3.2.2.  DTLS to CAPWAP Notifications

   DTLS notifications are defined for the DTLS to CAPWAP API.  These
   "notifications" are conceptual, and may be implemented in numerous
   ways (e.g. as function return values).  This API definition is
   provided to clarify interactions between the DTLS and CAPWAP
   components of the integrated CAPWAP state machine.  It is important
   to note that the notifications listed below MAY cause the CAPWAP
   state machine to jump from one state to another using a state
   transition not listed in section Section 2.3.1.  When a notification
   listed below occurs, the target CAPWAP state shown in Figure 3
   becomes the current state.

   Below is a list of the API notifications:

   o  DTLSIncomingSession is sent to the CAPWAP protocol stack during
      the DTLS session establishment once the peer's identity has been
      received.  This notification MAY be used by the CAPWAP protocol
      stack in order to authorize the session, based on the peer's
      identity.  The authorization process will lead to the CAPWAP
      protocol stack initiating either the DTLSAccept or
      DTLSAbortSession commands.

   o  DTLSEstablished is sent to the CAPWAP module to indicate that that
      a secure channel now exists, using the parameters provided during
      the DTLS initialization process.  When this notification is
      received, the FailedDTLSSessionCount counter is reset to zero.
      When this notification is received, the WaitDTLS is stopped.

   o  DTLSEstablishFail is sent when the DTLS session establishment has
      failed, either due to a local error, or due to the peer rejecting
      the session establishment.  When this notification is received,
      the FailedDTLSSessionCount counter is incremented.

   o  DTLSAuthenticateFail is sent when the DTLS session establishment
      failed due to an authentication error.  When this notification is
      received, the FailedDTLSAuthFailCount counter is incremented.

   o  DTLSAborted is sent to the CAPWAP module to indicate that session
      abort (as requested by CAPWAP) is complete; this occurs to confirm
      a DTLS session abort, or when the WaitDTLS timer expires.  When
      this notification is received, the WaitDTLS is stopped.

   o  DTLSReassemblyFailure may be sent to the CAPWAP module to indicate
      DTLS fragment reassembly failure.

   o  DTLSDecapFailure may be sent to CAPWAP to indicate an
      decapsulation failure.  DTLSDecapFailure may be sent to CAPWAP to
      indicate an encryption/authentication failure.  This notification
      is intended for informative purposes only, and is not intended to
      cause a change in the CAPWAP state machine.  See Section 12.3 for
      more information.

   o  DTLSPeerDisconnect is sent to the CAPWAP module to indicate the
      DTLS session has been torn down.  Note that this notification is
      only received if the DTLS session has been established.

2.4.  Use of DTLS in the CAPWAP Protocol

   DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP
   protocol.  In this document DTLS and CAPWAP are discussed as
   nominally distinct entitites; however they are very closely coupled,
   and may even be implemented inseparably.  Since there are DTLS
   library implementations currently available, and since security
   protocols (e.g.  IPsec, TLS) are often implemented in widely
   available acceleration hardware, it is both convenient and forward-
   looking to maintain a modular distinction in this document.

   This section describes a detailed walk-through of the interactions
   between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP
   to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be
   encountered during the normal course of operation.

2.4.1.  DTLS Handshake Processing

   Details of the DTLS handshake process are specified in [9].  This
   section describes the interactions between the DTLS session
   establishment process and the CAPWAP protocol.  Note that the
   conceptual DTLS state is shown below to help understand the point at
   which the DTLS states transition.  In the normal case, the DTLS
   handshake will proceed as follows (NOTE: this example uses
   certificates, but preshared keys are also supported):

           ============                         ============
               WTP                                   AC
           ============                         ============
           ClientHello           ------>
                                 <------       HelloVerifyRequest
                                                   (with cookie)

           ClientHello           ------>
           (with cookie)
                                 <------       ServerHello
                                 <------       Certificate
                                 <------       ServerHelloDone

           (WTP callout for AC authorization
                    occurs in CAPWAP Auth state)

           Certificate*
           ClientKeyExchange
           CertificateVerify*
           [ChangeCipherSpec]
           Finished              ------>

                                (AC callout for WTP authorization
                                 occurs in CAPWAP Auth state)

                                               [ChangeCipherSpec]
                                 <------       Finished

   DTLS, as specified, provides its own retransmit timers with an
   exponential back-off.  However, it will never terminate the handshake
   due to non-responsiveness; rather, it will continue to increase its
   back-off timer period.  Hence, timing out incomplete DTLS handshakes
   is entirely the responsiblity of the CAPWAP protocol.

   The DTLS implementation used by CAPWAP MUST support TLS Session
   Resumption.  Session resumption is used to establish the DTLS session
   used for the data channel.  The DTLS implementation on the WTP MUST
   return some unique identifier to CAPWAP so it can be used later to
   establish a DTLS-encrypted data channel, if necessary.

2.4.2.  DTLS Session Establishment

   The WTP, either through the Discovery process, or through pre-
   configuration, determines the AC to connect to.  The WTP uses the
   DTLSStart command to request that a secure connection be established
   to the selected AC.  Prior to initiation of the DTLS handshake, the
   WTP sets the WaitDTLS timer.  Upon receiving the DTLSIncomingSession
   DTLS notification, the AC sets the WaitDTLS timer.  If the
   DTLSEstablished notification is not received prior to timer
   expiration, the DTLS session is aborted by issuing the
   DTLSAbortSession DTLS command.  This notification causes the CAPWAP
   state to transition back to the Idle state.  Upon receiving a
   DTLSEstablished notification, the WaitDTLS timer is deactivated.

2.4.3.  DTLS Error Handling

   If the AC does not respond to any DTLS messages sent by the WTP, the
   DTLS specification calls for the WTP to retransmit these messages.
   If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession
   command, causing DTLS to terminate the handshake and remove any
   allocated session context.  Note that DTLS MAY send a single TLS
   Alert message to the AC to indicate session termination.

   If the WTP does not respond to any DTLS messages sent by the AC, the
   CAPWAP protocol allows for three possiblities, listed below.  Note
   that DTLS MAY send a single TLS Alert message to the AC to indicate
   session termination.

   o  The message was lost in transit; in this case, the WTP will re-
      transmit its last outstanding message, since it did not receive
      the reply.

   o  The WTP sent a DTLS Alert, which was lost in transit; in this
      case, the AC's WaitDTLS timer will expire, and the session will be
      terminated.

   o  Communication with the WTP has completely failed; in this case,
      the AC's WaitDTLS timer will expire, and the session will be
      terminated.

   The DTLS specification provides for retransmission of unacknowledged
   requests.  If retransmissions remain unacknowledged, the WaitDTLS
   timer will eventually expire, at which time the CAPWAP module will
   terminate the session.

   If a cookie fails to validate, this could represent a WTP error, or
   it could represent a DoS attack.  Hence, AC resource utilization
   SHOULD be minimized.  The AC MAY log a message indicating the
   failure, but SHOULD NOT attempt to reply to the WTP.

   Since DTLS handshake messages are potentially larger than the maximum
   record size, DTLS supports fragmenting of handshake messages across
   multiple records.  There are several potential causes of re-assembly
   errors, including overlapping and/or lost fragments.  The DTLS module
   MUST send a DTLSReassemblyFailure notification to CAPWAP.  Whether
   precise information is given along with notification is an
   implementation issue, and hence is beyond the scope of this document.
   Upon receipt of such an error, the CAPWAP protocol implementation
   SHOULD log an appropriate error message.  Whether processing
   continues or the DTLS session is terminated is implementation
   dependent.

   DTLS decapsulation errors consist of three types: decryption errors,
   and authentication errors, and malformed DTLS record headers.  Since
   DTLS authenticates the data prior to encapsulation, if decryption
   fails, it is difficult to detect this without first attempting to
   authenticate the packet.  If authentication fails, a decryption error
   is also likely, but not guaranteed.  Rather than attempt to derive
   (and require the implementation of) algorithms for detecting
   decryption failures, these are reported as authentication failures.
   The DTLS module MUST provide a DTLSDecapFailure notification to
   CAPWAP when such errors occur.  If a malformed DTLS record header is
   detected, the packets SHOULD be silently discarded, and the receiver
   MAY log an error message.

   There is currently only one encapsulation error defined: MTU
   exceeeded.  As part of DTLS session establishment, CAPWAP informs
   DTLS of the MTU size.  This may be dynamically modified at any time
   when CAPWAP sends the DTLSMtuUpdate command to DTLS (see
   Section 2.3.2.1).  DTLS returns this notification to CAPWAP whenever
   a transmission request will result in a packet which exceeds the MTU.

2.4.4.  DTLS EndPoint Authentication and Authorization

   DTLS supports endpoint authentication with certificates or preshared
   keys.  The TLS algorithm suites for each endpoint authentication
   method are described below.

2.4.4.1.  Authenticating with Certificates

   Note that only block ciphers are currently recommended for use with
   DTLS.  To understand the reasoning behind this, see [16].  At
   present, the following algorithms MUST be supported when using
   certificates for CAPWAP authentication:

   o  TLS_RSA_WITH_AES_128_CBC_SHA

   The following algorithms SHOULD be supported when using certificates:

   o  TLS_DH_RSA_WITH_AES_128_CBC_SHA

   The following algorithms MAY be supported when using certificates:

   o  TLS_RSA_WITH_AES_256_CBC_SHA

   o  TLS_DH_RSA_WITH_AES_256_CBC_SHA

2.4.4.2.  Authenticating with Preshared Keys

   Pre-shared keys present significant challenges from a security
   perspective, and for that reason, their use is strongly discouraged.
   However, [6] defines several different methods for authenticating
   with preshared keys, and we focus on the following two:

   o  PSK key exchange algorithm - simplest method, ciphersuites use
      only symmetric key algorithms

   o  DHE_PSK key exchange algorithm - use a PSK to authenticate a
      Diffie-Hellman exchange.  These ciphersuites give some additional
      protection against dictionary attacks and also provide Perfect
      Forward Secrecy (PFS).

   The first approach (plain PSK) is susceptible to passive dictionary
   attacks; hence, while this alorithm MUST be supported, special care
   should be taken when choosing that method.  In particular, user-
   readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD
   be strongly discouraged.

   The following cryptographic algorithms MUST be supported when using
   preshared keys:

   o  TLS_PSK_WITH_AES_128_CBC_SHA

   o  TLS_DHE_PSK_WITH_AES_128_CBC_SHA

   The following algorithms MAY be supported when using preshared keys:

   o  TLS_PSK_WITH_AES_256_CBC_SHA

   o  TLS_DHE_PSK_WITH_AES_256_CBC_SHA

2.4.4.3.  Certificate Usage

   Certificate authorization by the AC and WTP is required so that only
   an AC may perform the functions of an AC and that only a WTP may
   perform the functions of a WTP.  This restriction of functions to the
   AC or WTP requires that the certificates used by the AC MUST be
   distinguishable from the certificate used by the WTP.  To accomplish
   this differentiation, the x.509 certificates MUST include the
   Extended Key Usage (EKU) certificate extension [4].

   The EKU field indicates one or more purposes for which a certificate
   may be used.  It is an essential part in authorization.  Its syntax
   is as follows:

              ExtKeyUsageSyntax  ::=  SEQUENCE SIZE (1..MAX) OF
KeyPurposeId

              KeyPurposeId  ::=  OBJECT IDENTIFIER

   Here we define two KeyPurposeId values, one for the WTP and one for
   the AC.  Inclusion of one of those two values indicates a certificate
   is authorized for use by a WTP or AC, respectively.  These values are
   formatted as id-kp fields.

             id-kp  OBJECT IDENTIFIER  ::=
                 { iso(1) identified-organization(3) dod(6) internet(1)
                   security(5) mechanisms(5) pkix(7) 3 }

              id-kp-capwapWTP  OBJECT IDENTIFIER  ::=  { id-kp 19 }

              id-kp-capwapAC   OBJECT IDENTIFIER  ::=  { id-kp 18 }

   For an AC, the id-kp-capwapAC EKU MUST be present in the certificate.
   For a WTP, the id-kp-capwapWTP EKU MUST be present in the
   certificate.

   Part of the CAPWAP certificate validation process includes ensuring
   that the proper EKU is included and only allowing the CAPWAP session
   to be established if the extension properly represents the device.

   The certificate common name (CN) for both the WTP and AC MUST be the
   MAC address of that device.  The MAC address SHALL be formatted as
   ASCII HEX, e.g. 01:23:45:67:89:ab.

   ACs and WTPs SHOULD authorize (e.g. through access control lists)
   certificates of devices to which they are connecting, based on the
   MAC address and organizational information specified in the O and OU
   fields.  The identities specified in the certificates bind a
   particular DTLS session to a specific pair of mutually-authenticated
   and authorized MAC addresses.

2.4.4.4.  PSK Usage

   When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST
   contain the "PSK identity hint" field and the ClientKeyExchange
   message MUST contain the "PSK identity" field.  These fields are used
   to help the WTP select the appropriate PSK for use with the AC, and
   then indicate to the AC which precise key is being used.  When PSKs
   are provisioned to WTPs and ACs, both the PSK Hint and PSK Identity
   for the key MUST be specified.

   The PSK Hint SHOULD uniquely identify the AC and the PSK Identity
   SHOULD uniquely identify the WTP.  It is RECOMMENDED that these hints
   and identities be the ASCII HEX-formatted MAC addresses of the
   respective devices, since each pairwise combination of WTP and AC
   SHOULD have a unique PSK.  The PSK hint and identity SHOULD be
   sufficient to perform authorization, as simply having knowledge of a
   PSK does not necessarily imply authorization.

   If a single PSK is being used for multiple devices on a CAPWAP
   network, which is NOT RECOMMENDED, the PSK Hint and Identity can no
   longer be a MAC address, so appropriate hints and identities SHOULD
   be selected to identify the group of devices to which the PSK is
   provisioned.

[...]

12.  Security Considerations

   This section describes security considerations for the CAPWAP
   protocol.  It also provides security recommendations for protocols
   used in conjunction with CAPWAP.

12.1.  CAPWAP Security

   As it is currently specified, the CAPWAP protocol sits between the
   security mechanisms specified by the wireless link layer protocol
   (e.g.IEEE 802.11i) and AAA.  One goal of CAPWAP is to bootstrap trust
   between the STA and WTP using a series of preestablished trust
   relationships:

         STA            WTP           AC            AAA
         ==============================================

                            DTLS Cred     AAA Cred
                         <------------><------------->

                         EAP Credential
          <------------------------------------------>

           wireless link layer
           (e.g.802.11 PTK)
          <--------------> or
          <--------------------------->
              (derived)

   Within CAPWAP, DTLS is used to secure the link between the WTP and
   AC.  In addition to securing control messages, it's also a link in
   this chain of trust for establishing link layer keys.  Consequently,
   much rests on the security of DTLS.

   In some CAPWAP deployment scenarios, there are two channels between
   the WTP and AC: the control channel, carrying CAPWAP control
   messages, and the data channel, over which client data packets are
   tunneled between the AC and WTP.  Typically, the control channel is
   secured by DTLS, while the data channel is not.

   The use of parallel protected and unprotected channels deserves
   special consideration, but does not create a threat.  There are two
   potential concerns: attempting to convert protected data into un-
   protected data and attempting to convert un-protected data into
   protected data.  These concerns are addressed below.

12.1.1.  Converting Protected Data into Unprotected Data

   Since CAPWAP does not support authentication-only ciphers (i.e. all
   supported ciphersuites include encryption and authentication), it is
   not possible to convert protected data into unprotected data.  Since
   encrypted data is (ideally) indistinguishable from random data, the
   probability of an encrypted packet passing for a well-formed packet
   is effectively zero.

12.1.2.  Converting Unprotected Data into Protected Data (Insertion)

   The use of message authentication makes it impossible for the
   attacker to forge protected records.  This makes conversion of
   unprotected records to protected records impossible.

12.1.3.  Deletion of Protected Records

   An attacker could remove protected records from the stream, though
   not undetectably so, due the built-in reliability of the underlying
   CAPWAP protocol.  In the worst case, the attacker would remove the
   same record repeatedly, resulting in a CAPWAP session timeout and
   restart.  This is effectively a DoS attack, and could be accomplished
   by a man in the middle regardless of the CAPWAP protocol security
   mechanisms chosen.

12.1.4.   Insertion of Unprotected Records

   An attacker could inject packets into the unprotected channel, but
   this may become evident if sequence number desynchronization occurs
   as a result.  Only if the attacker is a MiM can packets be inserted
   undetectably.  This is a consequence of that channel's lack of
   protection, and not a new threat resulting from the CAPWAP security
   mechanism.

12.2.  Session ID Security

   Since DTLS does not export a unique session identifier, there can be
   no explicit protocol binding between the DTLS layer and CAPWAP layer.
   As a result, implementations MUST provide a mechanism for performing
   this binding.  For example, an AC MUST NOT associate decrypted DTLS
   control packets with a particular WTP session based solely on the
   Session ID in the packet header.  Instead, identification should be
   done based on which DTLS session decrypted the packet.  Otherwise one
   authenticated WTP could spoof another authenticated WTP by altering
   the Session ID in the encrypted CAPWAP header.

   It should be noted that when the CAPWAP data channel is unencrypted,
   the WTP Session ID is exposed and possibly known to adversaries and
   other WTPs.  This would allow the forgery of the source of data-
   channel traffic.  This, however, should not be a surprise for
   unencrypted data channels.  When the data channel is encrypted, the
   Session ID is not exposed, and therefore can safely be used to
   associate a data and control channel.  The 64-bit length of the
   Session ID mitigates online guessing attacks where an adversarial,
   authenticated WTP tries to correlate his own data channel with
   another WTP's control channel.  Note that for encrypted data
   channels, the Session ID should only be used for correlation for the
   first packet immediately after the initial DTLS handshake.  Future
   correlation should instead be done via identification of a packet's
   DTLS session.

12.3.  Interference with a DTLS Session

   If a WTP or AC repeatedly receives packets which fail DTLS
   authentication or decryption, this could indicate a DTLS
   desynchronization between the AC and WTP, a link prone to
   undetectable bit errors, or an attacker trying to disrupt a DTLS
   session.

   In the state machine (section 2.3), transitions to the DTLS tear down
   state can be triggered by frequently receiving DTLS packets with
   authentication or decryption errors.  The threshold or technique for
   deciding when to move to the tear down state should be chosen
   carefully.  Being able to easily transition to DTLS TD allows easy
   detection of malfunctioning devices, but allows for denial of service
   attacks.  Making it difficult to transition to DTLS TD prevents
   denial of service attacks, but makes it more difficult to detect and
   reset a malfunctioning session.  Implementers should set this policy
   with care.

12.4.  Use of Preshared Keys in CAPWAP

   While use of preshared keys may provide deployment and provisioning
   advantages not found in public key based deployments, it also
   introduces a number of operational and security concerns.  In
   particular, because the keys must typically be entered manually, it
   is common for people to base them on memorable words or phrases.
   These are referred to as "low entropy passwords/passphrases".

   Use of low-entropy preshared keys, coupled with the fact that the
   keys are often not frequently updated, tends to significantly
   increase exposure.  For these reasons, we make the following
   recommendations:

   o  When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP
      SHOULD have a unique PSK.  Since WTPs will likely be widely
      deployed, their physical security is not guaranteed.  If PSKs are
      not unique for each WTP, key reuse would allow the compromise of
      one WTP to result in the compromise of others

   o  Generating PSKs from low entropy passwords is NOT RECOMMENDED.

   o  It is RECOMMENDED that implementations that allow the
      administrator to manually configure the PSK also provide a
      capability for generation of new random PSKs, taking RFC 1750 [2]
      into account.

   o  Preshared keys SHOULD be periodically updated.  Implementations
      may facilitate this by providing an administrative interface for
      automatic key generation and periodic update, or it may be
      accomplished manually instead.

   Every pairwise combination of WTP and AC on the network SHOULD have a
   unqiue PSK.  This prevents the domino effect (see Guidance for AAA
   Key Management [14]).  If PSKs are tied to specific WTPs, then
   knowledge of the PSK implies a binding to a specified identity that
   can be authorized.

   If PSKs are shared, this binding between device and identity is no
   longer possible.  Compromise of one WTP can yield compromise of
   another WTP, violating the CAPWAP security hierarchy.  Consequently,
   sharing keys between WTPs is NOT RECOMMENDED.

12.5.  Use of Certificates in CAPWAP

   For public-key-based DTLS deployments, each device SHOULD have unique
   credentials, with an extended key usage authorizing them to act as
   either a WTP or AC.  If devices do not have unique credentials, it is
   possible that by compromising one, any other one using the same
   credential may also be considered to be compromised.

   Certificate validation involves checking a large variety of things.
   Since the necessary things to validate are often environment-
   specific, many are beyond the scope of this document.  In this
   section, we provide some basic guidance on certificate validation.

   Each device is responsible for authenticating and authorizing devices
   with which they communicate.  Authentication entails validation of
   the chain of trust leading to the peer certificate, followed by the
   the peer certificate itself.  At a minimum, devices SHOULD use SSH-
   style certificate caching to guarantee consistency.  If devices have
   access to a certificate authority, they SHOULD properly validate the
   trust chain.  Implementations SHOULD also provide a secure method for
   verifying that the credential in question has not been revoked.

   Note that if the WTP relies on the AC for network connectivity (e.g.
   the AC is a layer 2 switch to which the WTP is directly connected),
   there is a chicken and egg problem, in that the WTP may not be able
   to contact an OCSP server or otherwise obtain an up to date CRL if a
   compromised AC doesn't explicitly permit this.  This cannot be
   avoided, except through effective physical security and monitoring
   measures at the AC.

   Proper validation of certificates typically requires checking to
   ensure the certificate has not yet expired.  If devices have a real-
   time clock, they SHOULD verify the certificate validity dates.  If no
   real-time clock is available, the device SHOULD make a best-effort
   attempt to validate the certificate validity dates through other
   means.  Failure to check a certificate's temporal validity can make a
   device vulnerable to man-in-the-middle attacks launched using
   compromised, expired certificates, and therefore devices should make
   every effort to perform this validation.

12.6.  AAA Security

   The AAA protocol is used to distribute EAP keys to the ACs, and
   consequently its security is important to the overall system
   security.  When used with TLS or IPsec, security guidelines specified
   in RFC 3539 [5] SHOULD be followed.

   In general, the link between the AC and AAA server SHOULD be secured
   using a strong ciphersuite keyed with mutually authenticated session
   keys.  Implementations SHOULD NOT rely solely on Basic RADIUS shared
   secret authentication as it is often vulnerable to dictionary
   attacks, but rather SHOULD use stronger underlying security
   mechanisms.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jan 2007 19:02:46 -0500

Hi All,

At the interim meeting, we had an extensive discussion of DTLS- 
related issues and gained consensus that the attached changes would  
address issues #87 (Use of DTLS for CAPWAP data channel), #226  
(Transition to join state) and #227 (Need Shim Header to indicate  
crypto property of packet).  We would now like to confirm that  
consensus on the mailing list.

If you have any blocking objection to making the changes outlined  
below and closing issues #87, #226 and #227, please respond to this  
message with your concerns by Monday, February 5th.  Editorial or non- 
blocking comments on the text should be sent in response to Pat's  
original message.

There was also a proposal made during the interim meeting to optimize  
out the shim header when DTLS is not in use.  In keeping with our  
previously published agenda, we did not consider the new proposal at  
the meeting.  It will be proposed on the list, and a new issue will  
be opened to discuss that proposal.

Thanks,
Margaret

Begin forwarded message:

> From: "Pat Calhoun (pacalhou)" <[email-masked]>
> Date: January 25, 2007 6:16:37 PM EST
> To: <[email-masked]>
> Subject: [Capwap] New Issue 226 proposed text
>
> All,
>
> Change

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 30 Jan 2007 16:24:21 -0800

The new preamble header optimization issue is 244.

Pat Calhoun

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 4:03 PM
> To: capwap
> Subject: [Capwap] CONSENSUS CONFIRMATION: Issues 87, 226 & 229
> 
> 
> Hi All,
> 
> >       WTP:  The WTP enters this state when the 
> SilentInterval timer  
> > (see
> >    DTLS Setup to Authorize (h):  This transition occurs an 
> incoming  
> > DTLS
> >    Authorize to DTLS Connect (j):  This transition occurs 
> to notify  
> > the
> >          forgo the authorization check of the WTP's 
> credentials, or  
> > the
> >    Join to Configure (g):  This state transition is used by 
> the WTP  
> > and
> >          version number and the version number advertised 
> by the AC  
> > are
> >          firmware download by sending an Image Data Request 
> Message  
> > with
> >       or when the WTP determines it needs to reset in order 
> for the  
> > new
> >          from its currently running firmware, and that the 
> WTP does  
> > not
> >    Image Data to Reset (o):  This state transition is used 
> to reset  
> > the
> >          message element matches the one included by the 
> WTP in the  
> > Join
> >       WTP:  This is the WTP's normal state of operation.  
> There are  
> > many
> >             Request message(see Section 8.5).  The WTP MUST 
> respond  
> > with
> >          Response.  The AC does not invoke the DTLSShutdown 
> command  
> > (see
> >          Section 2.3.2.1).
> >
> >          cleaned up all resources associated with the 
> control plane  
> > DTLS
> >    o  DTLSEstablished is sent to the CAPWAP module to 
> indicate that  
> > that
> >    o  DTLSEstablishFail is sent when the DTLS session 
> establishment  
> > has
> >       cause a change in the CAPWAP state machine.  See 
> Section 12.3  
> > for
> >       more information.
> >
> >    If the AC does not respond to any DTLS messages sent by 
> the WTP,  
> > the
> >    If the WTP does not respond to any DTLS messages sent by 
> the AC,  
> > the
> >    a transmission request will result in a packet which 
> exceeds the  
> > MTU.
> >
> >                  { iso(1) identified-organization(3) dod(6) 
> internet 
> > (1)
> >    The certificate common name (CN) for both the WTP and AC 
> MUST be  
> > the
> >    message MUST contain the "PSK identity" field.  These 
> fields are  
> > used
> >    channels, the Session ID should only be used for 
> correlation for  
> > the
> >    In the state machine (section 2.3), transitions to the 
> DTLS tear  
> > down
> >    authentication or decryption errors.  The threshold or 
> technique  
> > for
> >    denial of service attacks, but makes it more difficult 
> to detect  
> > and
> >       deployed, their physical security is not guaranteed.  
> If PSKs  
> > are
> >       capability for generation of new random PSKs, taking 
> RFC 1750  
> > [2]
> >       into account.
> >
> >    access to a certificate authority, they SHOULD properly 
> validate  
> > the