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

[Pasi.Eronen (Pasi.Eronen]

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