Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions

From: Charles Clancy <[email-masked]>
Date: Fri, 01 Aug 2008 05:37:53 -0400

Suggested text changes to address the comments:

Replace this 2.4.1 text:

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

with this text:

    DTLS, as specified, provides its own retransmit timers with an
    exponential back-off.  [RFC4347] does not specify how long
    retransmissions should continue.  Consequently, timing out incomplete
    DTLS handshakes is entirely the responsibility of the CAPWAP module.

I'm not sure what needs to be addressed in 2.4.3.  Pasi -- can you be 
more specific?

--
Dr. Charles Clancy                     www.ltsnet.net/~clancy
Senior Researcher, Laboratory for Telecommunications Sciences

Pat Calhoun (pacalhou) wrote:
> Pasi's comment was:
> 
>    Section 2.4.1: "DTLS will never terminate the handshake due to
>    non-responsiveness; instead, DTLS will continue to 
>    increase its back-off timer period" While RFC 4347 doesn't specify
> how
>    long you should continue retransmitting, the 
>    intent certainly was not to continue indefinitely.
>  
>    Section 2.4.3 text about DTLS retransmissions is slightly inaccurate;
>    DTLS handshake isn't strictly request/response, 
>    and both parties (not just the DTLS client) retransmit based on
> timers
>    (in some situations).
> 
> It is unclear to me as to whether these are simply observations, or
> request for change. That said, I would like either Charles or Scott to
> reply.
> 
> PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 1 Aug 2008 10:12:24 -0700

Got it - waiting for Pasi on 2.4.3.

PatC 

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Friday, August 01, 2008 2:38 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]; [email-masked]
Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions

Replace this 2.4.1 text:

with this text:

    DTLS, as specified, provides its own retransmit timers with an
    exponential back-off.  [RFC4347] does not specify how long
    retransmissions should continue.  Consequently, timing out
incomplete
    DTLS handshakes is entirely the responsibility of the CAPWAP module.

---

From: <[email-masked]>
Date: Thu, 7 Aug 2008 12:29:09 +0300

Hi Charles,

Your suggested change looks good.

Best regards,
Pasi 

> From: ext Charles Clancy [mailto:[email-masked]] 
> Sent: 01 August, 2008 12:38
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki); 
> [email-masked]
> Subject: Re: Issue 168: DTLS and Retransmissions
>

---

From: <[email-masked]>
Date: Fri, 8 Aug 2008 01:41:41 +0300

Section 2.4.3 assumes that only the WTP retransmits DTLS
messages if it doesn't get a reply (and AC retransmits
a reply only when it gets a retransmitted request from
the WTP).

That's not the case: both parties retransmit if the handshake
isn't done yet. For example, the AC will also keep retransmitting 
ServerHello (and Certificate/ServerKeyExchange/ServerHelloDone)
if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.)
from the WTP.

Best regards,
Pasi

> From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: 01 August, 2008 20:12
> To: Charles Clancy
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Aug 2008 12:39:30 -0700

Ok, well I'm still looking to Charles and Scott to weigh in, but how
about we replace the following text:

<current text>
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 possibilities, 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 a
      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.
</current text> 

With:

<new text>
2.4.3.  DTLS Error Handling

   If the AC or WTP does not respond to any DTLS messages sent by its
   peer, the DTLS specification calls for the message to be
   retransmited.  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 DTLS Alert message to the AC to indicate session termination.
</new text>

PatC
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, August 07, 2008 3:42 PM
To: Pat Calhoun (pacalhou); [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions

Section 2.4.3 assumes that only the WTP retransmits DTLS messages if it
doesn't get a reply (and AC retransmits a reply only when it gets a
retransmitted request from the WTP).

That's not the case: both parties retransmit if the handshake isn't done
yet. For example, the AC will also keep retransmitting ServerHello (and
Certificate/ServerKeyExchange/ServerHelloDone)
if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.)
from the WTP.

Best regards,
Pasi

---

From: "Scott Kelly" <[email-masked]>
Date: Wed, 13 Aug 2008 14:00:26 -0700

Sorry, I've been out of circulation for a while and am just catching up.

Pasi's point is that handshake messages are an exception to the current
text, as DTLS will re-transmit these on its own. Rather than stripping
out the existing text (which is informative and helpful for implementers
and people troubleshooting issues), I think it might be better to update
it to reflect Pasi's point.

How about this:

   If the AC does not respond to any DTLS handshake messages sent by the

   WTP, the DTLS specification calls for the WTP to retransmit these
messages
   according to the current value of the exponential back-off timer. 
   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 handshake messages sent by
the AC, 
   the CAPWAP protocol allows for three possibilities, 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 DTLS
implementation
      on the WTP will retransmit its last outstanding handshake message,

      since it did not receive a reply.

<leave everything else as is...>

--Scott

> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Wednesday, August 13, 2008 12:40 PM
> To: [email-masked]; [email-masked]; Scott Kelly
> Cc: [email-masked]
> messages if it
> isn't done
> >     handshake due to non-responsiveness; instead, DTLS will 
> continue 
> > to

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Aug 2008 14:31:54 -0700

Sounds good to me.

PatC 

-----Original Message-----
From: Scott Kelly [mailto:[email-masked]] 
Sent: Wednesday, August 13, 2008 2:00 PM
To: Pat Calhoun (pacalhou); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions

How about this:

--Scott

> Section 2.4.3 assumes that only the WTP retransmits DTLS messages if 
> it doesn't get a reply (and AC retransmits a reply only when it gets a

> That's not the case: both parties retransmit if the handshake isn't 
> done yet. For example, the AC will also keep retransmitting 
> ServerHello (and

---

From: <[email-masked]>
Date: Mon, 18 Aug 2008 22:01:45 +0300

Scott and Pat,

This text still assumes that the WTP is responsible for retransmitting
the DTLS handshake messages (based on timer) if it doesn't receive
anything from the AC. That's not totally correct.

Pat's proposed text did get this right; but I agree that talking
explicitly about DTLS *handshake* messages (instead of just DTLS
messages) would be clearer.

Here's another attempt:

   If the AC or WTP does not respond to any DTLS handshake messages
   sent by its peer, the DTLS specification calls for the message to
   be retransmited. Note that during the handshake, when both the AC
   and the WTP are expecting additional handshake messages, they both
   retransmit if an expected message has not been received (note that
   retransmissions for CAPWAP Control messages work differently: 
   all CAPWAP Control messages are either requests or responses,
   and the peer who sent the request is responsible for retransmissions).

Best regards,
Pasi

> From: ext Scott Kelly [mailto:[email-masked]] 
> Sent: 14 August, 2008 00:00
> To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); 
> [email-masked]
> Cc: [email-masked]
> Pasi's point is that handshake messages are an exception to the
> current text, as DTLS will re-transmit these on its own. Rather than
> stripping out the existing text (which is informative and helpful
> for implementers and people troubleshooting issues), I think it
> might be better to update it to reflect Pasi's point.
> 
> How about this:
> 
>    If the AC does not respond to any DTLS handshake messages sent by
>    the WTP, the DTLS specification calls for the WTP to retransmit
>    these messages according to the current value of the exponential
>    back-off timer.  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 handshake messages sent
>    by the AC, the CAPWAP protocol allows for three possibilities,
>    listed below.  Note that DTLS MAY send a single TLS Alert message
>    to the AC to indicate session termination.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 07:25:58 -0700

So just to be clear, your request is to replace the first paragraph
only. The resulting section would read as follows:

<updated section>

   If the AC or WTP does not respond to any DTLS handshake messages sent
   by its peer, the DTLS specification calls for the message to be
   retransmited.  Note that during the handshake, when both the AC and
   the WTP are expecting additional handshake messages, they both
   retransmit if an expected message has not been received (note that
   retransmissions for CAPWAP Control messages work differently: all
   CAPWAP Control messages are either requests or responses, and the
   peer who sent the request is responsible for retransmissions).

   If the WTP does not respond to any DTLS handshake messages sent by
   the AC, the CAPWAP protocol allows for three possibilities, 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 DTLS
      implementation on the WTP will retransmit its last outstanding
      handshake message, since it did not receive a reply.

   The DTLS specification provides for retransmission of unacknowledged
   requests.  If retransmissions remain unacknowledged, the WaitDTLS
   timer will eventually expire, at which time the CAPWAP component 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, and SHOULD treat the message as though no cookie were
   present.

   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
   component MUST send a DTLSReassemblyFailure notification to the
   CAPWAP component.  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
   component 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,
   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, decryption failures are reported as
   authentication failures.  The DTLS component MUST provide a
   DTLSDecapFailure notification to the CAPWAP component 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
   exceeded.  As part of DTLS session establishment, the CAPWAP
   component informs the DTLS component of the MTU size.  This may be
   dynamically modified at any time when the CAPWAP component sends the
   DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1).
   The value provided to the DTLS stack is the result of the MTU
   Discovery process, which is described in Section 3.5.  The DTLS
   component returns this notification to the CAPWAP component whenever
   a transmission request will result in a packet which exceeds the MTU.
</updated section> 

PatC
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 18, 2008 12:02 PM
To: [email-masked]; Pat Calhoun (pacalhou); [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions

Scott and Pat,

Here's another attempt:

   and the peer who sent the request is responsible for
retransmissions).

Best regards,
Pasi

> stripping out the existing text (which is informative and helpful for 
> implementers and people troubleshooting issues), I think it might be 
> better to update it to reflect Pasi's point.
> 
> How about this:
> 

> >    DTLSAbortSession command, causing DTLS to terminate the handshake

> > and

> > it doesn't get a reply (and AC retransmits a reply only when it gets

> > a retransmitted request from the WTP).
> >

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 23:10:07 +0300

> only. The resulting section would read as follows:

No, the 2nd paragraph, the three bullets, and the paragraph following
the bullets also need work... but much of the text is really
redundant with the new 1st paragraph, so this could be shortened
(while fixing the incorrect parts at the same time) -- see below.

>    be retransmited.  Note that during the handshake, when both the
>    AC and the WTP are expecting additional handshake messages, they
>    both retransmit if an expected message has not been received
>    (note that retransmissions for CAPWAP Control messages work
>    differently: all CAPWAP Control messages are either requests or
>    responses, and the peer who sent the request is responsible for
>    retransmissions).
> 

Probably everything from the 2nd paragraph to here could be summarized
something like this:

   If the WTP or the AC does not receive an expected DTLS handshake
   message despite of retransmissions, the WaitDTLS timer will
   eventually expire, and the session will be terminated.  This can
   happen if communication between the peers has completely failed, or
   if one of the peers sent a DTLS Alert message which was lost in
   transit (DTLS does not retransmit Alert messages).

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 14:41:58 -0700

Scott/Charles, are we good with this? Can I close this issue with the
recommended text below?

PatC 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2008 1:10 PM
To: Pat Calhoun (pacalhou); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions

No, the 2nd paragraph, the three bullets, and the paragraph following
the bullets also need work... but much of the text is really redundant
with the new 1st paragraph, so this could be shortened (while fixing the
incorrect parts at the same time) -- see below.

Best regards,
Pasi