Capwap Mailing List: Re: Issue 185: DTLS Session Resumption is optional

[Scott Kelly (skelly]

Comments below... 

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] 
> Sent: Tuesday, September 16, 2008 8:59 AM
> To: Pasi.Eronen [at] nokia.com; capwap [at] frascone.com
> Cc: Scott Kelly; Charles Clancy
> Subject: RE: Issue 185: DTLS Session Resumption is optional
> 
> I will have to defer to Scott or Charles for this question.
> 
> PatC 
> 
> -----Original Message-----
> From: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com] 
> Sent: Tuesday, September 16, 2008 8:55 AM
> To: Pat Calhoun (pacalhou); capwap [at] frascone.com
> Subject: RE: Issue 185: DTLS Session Resumption is optional
> 
> Pat Calhoun wrote:
> 
> > Pasi has raised the following comment during the current WG 
> Last Call:
> > 
> >      Section 2.4.1, "Session resumption is used to 
> establish the DTLS
> >      session used for the data channel" should probably say "Session
> >      resumption is typically used...." (since it's no longer 
> >      an absolute requirement)
> > 
> > I am OK with the request, and would propose changing the 
> paragraph to:
> > 
> > <proposed text>
> >     The DTLS implementation used by CAPWAP MUST support TLS Session
> >     Resumption.  Session resumption is typically used to establish
> >     the DTLS session used for the data channel.  The DTLS
> >     implementation on the WTP MUST return some unique identifier
> >     to the CAPWAP module to enable subsequent establishment of a
> >     DTLS-encrypted data channel, if necessary.
> > </proposed text>
> 
> Why is this "some unique identifier" needed? (Normal apps using TLS --
> which usually involves session resumption, too -- don't need any such
> identifier; session resumption is something that "just happens"
> when possible, and the app doesn't need to know about it.)

I think it's needed (along with special DTLS behavior) because of the
way it's used: normally, TLS session resumption happens _for the same
channel_, where the channel is identified by the 5-tuple (saddr, daddr,
proto, sport, dport). In the capwap case, we are expecting DTLS to
establish the control channel, and then to use session resumption to
establish 1 or more data channel sessions (QoS requirements may dictate
the need for more than one data channel), each with their own unique
5-tuples.

Granted, this won't work with off-the-shelf DTLS implementations, but I
think the wg participants understand and accept this.

--Scott