Subject: [Capwap] Proposed resolution for Issue 226

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 22 Nov 2006 17:56:55 -0800

All,

At the meeting in San Diego, there seemed to be general agreement that
it was unnecessary to describe the DTLS state machine within the CAPWAP
specification. I presented an overview of the changes that would be
required, and this e-mail contains the actual proposed text that I would
like to submit to the list.

NOTE: This is unfortunately, a rather lengthy e-mail. I have decided to
include complete state machine text as opposed to snippets, otherwise it
makes it rather difficult to really understand the proposal.

2.3.  CAPWAP State Machine Definition
[...]
       /==============>=====================\
       "                                    "
       "  /==========<===============\      "
       "  "                          "t     v
       "  "   +-----------------------------------------------------+
       "  "   |                       DTLS                          |
       "  "   +-----------------------------------------------------+
       "  "   ^   "p              ^                        ^        DTLS
       "  ~~~~"~~~"~~~~~~~~~~~~~~~"~~~~~~~~~~~~~~~~~~~~~~~~"~~~~~~~~~~~~
       "  "   "   "               "                        "      CAPWAP
       "  "   "   "               "                        "
       "  "   "   "   /-----------+---<-----------+        "
       "  "  q"   v   v           "r              |d       "
       "  "  +--------+  b+-----------+    +----------+    "
       ^  v  |  Idle  |-->| Discovery |--->|  Sulking |    "
       "  "  +--------+ a +-----------+ c  +----------+    "
       "  "                 |e            /----------------+-----\
       "  "                 |             |                "u    |
       "  "                 |    +----------+ o+-------------+   |
       "  "                 |    |   Run    |->|    Reset    |   |
       "  "                 |   n+----------+  +-------------+   |
       "  "                 |         ^         ^       ^        |
       "  "                 |         |   /-----/       |        |s
       "  "                 v        m|  k|             |l       v
       "  \==>+--------------+  +------------+ I      +------------+j
       "      |    Join      |->|  Configure |------->| Image Data |
       \======+--------------+ g+------------+        +------------+
             f

                 Figure 3: CAPWAP Integrated State Machine

2.3.1.  CAPWAP Protocol State Transitions

[...]

   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 DTLS (q):  This transition occurs when the WTP initiates a 
      DTLS session request, or when a previous DTLS session request has
      timed out.

      WTP:  If the WTP has not already initiated a DTLS session request,
         the WTP selects the best AC based either on its configuration
         and initiates a DTLSStart (c1) to the AC (see Section 2.3.2)
         and starts the WaitDTLS timer.  If the WaitDTLS timer has
         expired, the WTP initiates a DTLSAbort (c4).

      AC:  This transition occurs when the AC receives the first DTLS
         packet from the WTP.  The AC starts the WaitDTLS timer.  If the
         WaitDTLS timer has expired, the AC initiates a DTLSAbort (c4).

   Discovery to DTLS (r):  This transition occurs when the WTP initiates
      a DTLS session request.

      WTP:  The WTP selects the best AC based either on information it
         gathered during the Discovery Phase or on its configuration.
         It then initiates a DTLSStart (c1) to the AC (see
         Section 2.3.2) and starts the WaitDTLS timer.

      AC:  This transition is invalid as the AC SHOULD NOT maintain WTP
         Discovery state.

   DTLS to idle (p):  This transition occurs when the DTLS session
      establishment has failed, or the session has been aborted or
      terminated.

      WTP:  Occurs when either a DTLSSessionEstablished (n3)
         notification is not received within WaitDTLS Timer or upon
         receiving an DTLSAuthenticateFail (n2), DTLSAuthorizationFail
         (n2), DTLSPeerDisconnect (n6), DTLSIdle (n5) or
         DTLSReassemblyFailure (n7) notifications.  See Section 2.3.3
         for more information on DTLS notifications.

      WTP:  Occurs when either a DTLSSessionEstablished notification is
         not received within WaitDTLS Timer or upon receiving an
         DTLSAuthenticateFail (n2), DTLSAuthorizationFail (n2),
         DTLSPeerDisconnect (n6), DTLSIdle (n5) or DTLSReassemblyFailure
         (n7) notifications.  See Section 2.3.3 for more information on
         DTLS notifications.

   Discovery to Discovery (b):  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 and 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.

      AC:  This is a no-op.

   DTLS to Join (t):  This transition occurs the DTLS session is
      established.

         WTP:  The WTP receives a DTLSEstablished (n3) notification,
         stating that the session is established.  See Section 2.3.3 for
         more information on DTLS notifications.

         AC:  The AC receives a DTLSEstablished (n3) notification,
         stating that the session is established.  See Section 2.3.3 for
         more information on DTLS notifications.

   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 (i)).  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
         (i)).

   Join to DTLS (f):  This transition occurs when the WaitDTLS timer
      expires prior to the completion of the join process.

      WTP:  If the WaitDTLS timer has expired, the WTP initiates a
         DTLSAbort (c4).

      AC:  If the WaitDTLS timer has expired, the AC initiates a
         DTLSAbort (c4).

   Configure to Image Data (i):  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 its
         version number and the version number advertised by the AC are
         different.  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 (j):  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.

   Configure to Reset (k):  This state transition is used to reset the
      connection to the AC prior to restarting the WTP with a new
      configuration.

      WTP:  The WTP enters the Reset state 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 the
         DTLSPeerDisconnect (n6) notification (see Section 2.3.3 for
         more information on DTLS notifications).

   Image Data to Reset (l):  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, and terminates the DTLS connection, sending a
         DTLSShutdown command to the DTLS state machine.

      AC:  The AC enters the Reset state upon receipt of a DTLSIdle (n5)
         notification (see Section 2.3.3 for more information on DTLS
         notifications).

   Configure to Run (m):  This state transition occurs when the WTP and
      AC enter their normal state of operation.

      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.6).

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

   Run to Run (n):  This is the normal state of operation.
<PRC> This section is deleted - no changes to this section.

   Run to Reset (o):  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 (u):  This state transition is used when the AC reset
      is confirmed.

      WTP:  This state transition occurs when WTP transmits a Reset
         Response to the AC.

      AC:  This state transition occurs after the AC receives a Reset
         Response from the WTP.  The AC then issues a
         DTLSSessionShutdown (c3) command to the DTLS stack.  See
         Section 2.3.2 for more information on DTLS commands.

   Run to Image Data (s):  This state transition occurs when the AC
      transmits an Image Data Request to the WTP, with the Initiate
      Download message element.  The means by which the AC decides to
      download firmware is undefined, but could occur through an
      administrative action.

      WTP:  The WTP enters this state when it receives an an Image Data
         Request to the WTP, with the Initiate Download message element.
         The WTP responds by transmitting an Image Data Request with the
         Image Filename message element included..

      AC:  This state transition occurs when the AC decides that an WTP
         is to update its firmware by sending an Image Data Request to
         the WTP, with the Initiate Download message element.

2.3.2.  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  c1: DTLSStart is sent to the DTLS module to cause a DTLS session
      to be established.

   o  c2: DTLSRehandshake is sent to the DTLS module to cause initiation
      of a rehandshake (DTLS rekey).

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

   o  c4: DTLSAbort is sent to the DTLS module to cause session teardown
      when the WaitDTLS timer expires.

2.3.3.  DTLS to CAPWAP Notifications

   Eight 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.

   Below is a list of the API notifications:

   o  n1: DTLSInitFailure is sent to the CAPWAP module to indicate an
      initialization failure, which may be due to out of memory or other
      internal error condition.

   o  n2: DTLSAuthenticateFail or DTLSAuthorizeFail is sent to the
      CAPWAP module to indicate peer authentication or authorization
      failures, respectively.

   o  n3: DTLSEstablished is sent to the CAPWAP module to indicate that
      that a secure channel now exists.

   o  n4: DTLSEncapFailure may be sent to CAPWAP to indicate an
      encapsulation failure.  DTLSDecapFailure may be sent to CAPWAP to
      indicate an encryption/authentication failure

   o  n5: DTLSIdle is sent to the CAPWAP module to indicate that session
      abort (as requested by CAPWAP) is complete; this occurs when the
      WaitDTLS timer expires, or when CAPWAP is executing an orderly
      session shutdown.

   o  n6: DTLSPeerDisconnect is sent to the CAPWAP module to indicate
      DTLS session teardown by peer.  Note that the n7 notification, can
      be received while in the Join, Configure, Image Data, Run and
      Reset states, and always causes a transition to the Reset state.

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

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.  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)

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

                                            (AC callout for WTP
                                              authorization)

                                               [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.

2.4.1.1.  Join Operations

   The WTP, either through the Discovery process, or through pre-
   configuration, determines the AC to connect to.  The WTP uses DTLS to
   establish a secure connection to the selected AC.  Prior to
   initiation of the DTLS handshake, the WTP sets the WaitDTLS timer.
   Upon receipt of a ClientHello message containing a valid cookie, the
   AC sets the WaitDTLS timer.  If the Join operation has not completed
   prior to timer expiration, the Join process is aborted, the WTP
   transitions back to Discovery state, and the AC transitions back to
   Idle state.  Upon successful completion of the Join process the
   WaitDTLS timer is deactivated.

2.4.2.  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 DTLSAbort
   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.  DTLS returns
   this notification to CAPWAP whenever a transmission request will
   result in a packet which exceeds the MTU.

2.4.3.  DTLS EndPoint Authentication

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

2.4.3.1.  Authenticating with Certificates

   Note that only block ciphers are currently recommended for use with
   DTLS.  To understand the reasoning behind this, see [13].  However,
   support for AES counter mode encryption is currently progressing in
   the TLS working group, and once protocol identifiers are available,
   they will be added below.  At present, the following algorithms MUST
   be supported when using certificates for CAPWAP authentication:

   o  TLS_RSA_WITH_AES_128_CBC_SHA

   o  TLS_RSA_WITH_3DES_EDE_CBC_SHA

   The following algorithms SHOULD be supported when using certificates:

   o  TLS_DH_RSA_WITH_AES_128_CBC_SHA

   o  TLS_DH_RSA_WITH_3DES_EDE_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.3.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_PSK_WITH_3DES_EDE_CBC_SHA

   o  TLS_DHE_PSK_WITH_AES_128_CBC_SHA

   o  TLS_DHE_PSK_WITH_3DES_EDE_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.3.3.  Certificate Usage

   When using certificates, both authentication and authorization must
   be considered.  Section 12.3 provides recommendations on how to
   authenticate a certificate and bind that to a CAPWAP entity.  This
   section deals with certificate authorization.

   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.

3.  CAPWAP Transport

[...]

6.1.  Join Request

[...]
   Upon completion of the DTLS handshake, which the WTP is notified via
   the DTLSEstablished notification, sends the Join Request message to
   the AC.  When the AC is notified of the DTLS session establishment,
   it does not clear the WaitDTLS timer until it has received the Join
   Request message, at which time it generates a Join Response message
   and sends it to the WTP, indicating success or failure.

   If the AC rejects the Join Request, it sends a Join Response message
   with a failure indication and initiates an abort of the DTLS session
   via the DTLSAbort command.

[...]
6.2.  Join Response

[...]
   The WTP, receiving a Join Response message, checks for success or
   failure.  If the message indicates success, the WTP clears the
   WaitDTLS timer for the session and proceeds to the Configure state.

   If the WaitDTLS Timer expires prior to reception of the Join Response
   message, the WTP MUST terminate the handshake, deallocate associated
   session state and initiate the DTLSAbort command.

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: Scott Kelly <[email-masked]>
Date: Thu, 30 Nov 2006 05:54:18 -0800

Hi Pat,

Comments inline below (with much text trimmed)...

> like to submit to the list.

I don't think we had general agreement on the semantic point. I think we 
agreed at the meeting to take the discussion to the list.

> 2.3.  CAPWAP State Machine Definition

I don't have time to give this the full treatment it deserves this 
morning, but I'll give a brief response now, and follow up within the 
next few days with additional detail if necessary. The short of it: 
we've agreed that the rekey state can be removed, and after mulling this 
over in depth, I think we can collapse the idle and init portions of the 
dtls state diagram into one box if people really deem this critical, but 
I think we need the others.

The current dtls portion of the state diagram is conceptual, and does 
not specify explicit dtls protocol states. Rather, it specifies critical 
interactions between the dtls module (hardware, library, or 
roll-yer-own) and the capwap state machine at various points in the dtls 
session initialization, establishment, running, and tear-down phases. 
I'm not sure why you object to a diagram that helps implementers get 
critical implementation details right.

Charles and I discussed this at length in San Diego, and I also spoke 
with others in the security community. The capwap implementation must 
exert control over the dtls implementation at critical points in the 
dtls interaction. In particular, capwap must be able to

1) kick dtls into a protocol initiation phase (or prevent it from 
entering one)

2) there must be an explicit call-out from dtls to capwap for 
authorization prior to completion of the handshake. This is a hard 
requirement. This doesn't imply you couldn't preload the cert/key for a 
given session, but a nominally correct specification must explicitly 
designate this call-out.

3) it is conceptually useful to illustrate the shutdown phase

Again, these are conceptual phases in dtls session management, and while 
there is clear interaction with the underlying dtls protocol state 
machine, it is not our intent to specify that state machine here. If 
language making that more clear would help, I'd be happy to try to craft 
some.

I think the diagram you sent in the previous email (repeated below) is 
the one we should use, perhaps with minor modification. If people feel 
very strongly I guess we can collapse the idle/init boxes into one init 
box, but I think that's the most minimalistic presentation that still 
captures the critical interactions.

             /-------------<----------------+--------------------\
             v                              |d                   |
          +------+  b+-----------+    +----------+               |
          | Idle |-->| Discovery |--->|  Sulking |               |
          +------+ a +-----------+ c  +----------+               |
           ^   |aa    ^ |e            /----------------------\   |
           |   V     f| v            k|                      |   |
        h +--------------+  +------------+ i +------------+j |   |
       /--|    Join      |->|  Configure |-->| Image Data |  |   |
       |  +--------------+ g+------------+   +------------+  |   |
       |   "c1,  ^  ^   ^        m|            ^    |l       |   |
       |   "c4   "  "   "         |    /-------/    |   /----/   |
       |   "     "  "   "         V    |s           v   V        |
       |   "     "  "   "   +------------+ o+------------+       |
       |   "     "  "   "   |    Run     |->|    Reset   |-------/
       |   "     "  "   "  n+------------+  +------------+   p
       |   "     "  "   "        "c2  ^       ^  c3"   ^
       \---"-----"--"---"--------"----"-------/    "   "     CAPWAP
    ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~
           "     "  "   "        "    "            "   "      DTLS
           v     "  "n2 \"""""\  "    "            v   "n6,n7
    /-->+------+ " W+------+  "  "    "      +------------+
    | /-| Idle | " C| Auth |--"~-"----"----->|  Shutdown  |-------\P
    | | +------+ "  +------+V "  "    " /--->|            |<----\ |
    | |X     Z|  "   ^  U|    "  " n4 " |    +------------+     | |
    | |       |  "   |   |    "  " n5," |                       | |
    | |       v  "n1 |Y  |  n3"  v  n8" |R                      | |
    | |      +--------+  |  +------------+                      | |
    | |      |  Init  |  \->|    Run     |                      | | <<=
NOTE REMOVAL OF REKEY STATE
    | |      +--------+     |            |                      | |
    | |                     +------------+                      | |
    | \---------------------------------------------------------/ |
    \-------------------------------------------------------------/

(I haven't edited this to collapse the idle/init states, but that could 
easily be done for the document if deemed important).

We went through discussions like this in IPsec. Some people thought 
specification of detailed packet processing and application of 
associated policy were overly prescribed. However, many of us agreed 
that explicitly detailing complex security interactions is important, 
and that's what you'll find in the current specs.

We also noted that people are free to implement things internally as 
they see fit. Anything which does not impact interoperability is fair 
game in your implementation. However, we, as specification writers, 
should provide a nominally correct implementation specification, and 
make clear the security implications of deviation at critical points.

Scott