Capwap Mailing List: Re: Issue 168: DTLS and Retransmissions

[Pat Calhoun (pacalhou) (pcalhoun]

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

<updated section>
2.4.3.  DTLS Error Handling

   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.

   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 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: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com] 
Sent: Monday, August 18, 2008 12:02 PM
To: skelly [at] arubanetworks.com; Pat Calhoun (pacalhou); clancy [at] 
ltsnet.net
Cc: capwap [at] frascone.com
Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions

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

> -----Original Message-----
> From: ext Scott Kelly [mailto:skelly [at] arubanetworks.com]
> Sent: 14 August, 2008 00:00
> To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); 
> clancy [at] ltsnet.net
> Cc: capwap [at] frascone.com
> Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions
> 
> 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:
> 
> 2.4.3.  DTLS Error Handling
> 
>    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
> 
> > -----Original Message-----
> > From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
> > Sent: Wednesday, August 13, 2008 12:40 PM
> > To: Pasi.Eronen [at] nokia.com; clancy [at] ltsnet.net; Scott Kelly
> > Cc: capwap [at] frascone.com
> > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions
> > 
> > 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: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com]
> > Sent: Thursday, August 07, 2008 3:42 PM
> > To: Pat Calhoun (pacalhou); clancy [at] ltsnet.net
> > Cc: capwap [at] frascone.com
> > 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
> > 
> > > -----Original Message-----
> > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
> > > Sent: 01 August, 2008 20:12
> > > To: Charles Clancy
> > > Cc: capwap [at] frascone.com; Eronen Pasi (Nokia-NRC/Helsinki)
> > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions
> > > 
> > > Got it - waiting for Pasi on 2.4.3.
> > > 
> > > PatC
> > > 
> > > -----Original Message-----
> > > From: Charles Clancy [mailto:clancy [at] ltsnet.net]
> > > Sent: Friday, August 01, 2008 2:38 AM
> > > To: Pat Calhoun (pacalhou)
> > > Cc: capwap [at] frascone.com; Pasi.Eronen [at] nokia.com
> > > Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions
> > > 
> > > 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
> > > 
> > 
>