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

[Pat Calhoun (pacalhou) (pcalhoun]

Sounds good to me.

PatC 

-----Original Message-----
From: Scott Kelly [mailto:skelly [at] arubanetworks.com] 
Sent: Wednesday, August 13, 2008 2:00 PM
To: Pat Calhoun (pacalhou); Pasi.Eronen [at] nokia.com; 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
> > 
>