Capwap Mailing List: Re: Issue 153: Linking of control and data channels

[Charles Clancy (tcc]

Pat,

Replace the whole section with the text below.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland


Pat Calhoun (pacalhou) wrote:
> Do you mean to replace all of the text, or are you proposing adding the
> second paragraph to replace the last one?
>
> PatC 
>
> -----Original Message-----
> From: Charles Clancy [mailto:clancy [at] cs.umd.edu] 
> Sent: Tuesday, July 29, 2008 11:17 AM
> To: Pat Calhoun (pacalhou)
> Cc: Scott G. Kelly; Charles Clancy; capwap [at] frascone.com;
> Pasi.Eronen [at] nokia.com
> Subject: Re: [Capwap] Issue 153: Linking of control and data channels
>
> Pat,
>
> We discussed this during the meeting.  Pasi suggested simplifying the
> text, and indicated that it shouldn't cause any interoperability
> problems.  I'm proposing the following text for section 4.4.3:
>
>     If the AC and WTP are configured to tunnel the data channel over
>     DTLS, the proper DTLS session must be initiated.  To avoid having to
>     reauthenticate and reauthorize an AC and WTP, the DTLS data channel
>     SHOULD be initiated using the TLS session resumption feature
>     <xref target="RFC4346"/>.
>
>     The AC DTLS implementation MUST NOT initiate a data channel session
>     for a DTLS session for which there is no active control
>     channel session.
>
>
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
>
>
> Pat Calhoun (pacalhou) wrote:
> > In which case I propose we close this issue and mark as rejected.
> >
> > Pasi?
> >
> > PatC
> >
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com]
> > Sent: Monday, July 28, 2008 6:17 PM
> > To: Charles Clancy; Pat Calhoun (pacalhou)
> > Cc: capwap [at] frascone.com; Pasi.Eronen [at] nokia.com
> > Subject: Re: [Capwap] Issue 153: Linking of control and data channels
> >
> > I agree with Charles.
> >
> > -----Original Message-----
> > > From: Charles Clancy <tcc [at] umd.edu>
> > > Sent: Jul 28, 2008 5:54 PM
> > > To: "Pat Calhoun (pacalhou)" <pcalhoun [at] cisco.com>
> > > Cc: capwap [at] frascone.com, Pasi.Eronen [at] nokia.com
> > > Subject: Re: [Capwap] Issue 153: Linking of control and data channels
> > >
> > > The goal of the text was to provide efficient interoperability, and 
> > > handle all the edge cases.  Typically when you use session 
> > > resumption, you're resuming a session that's ended.  Here we have two
>
> > > simultaneous DTLS sessions running, with the second one being a 
> > > resumption of the first.  We're using DTLS session resumption to 
> > > quickly open a second tunnel while the first is still running.  Given
>
> > > this use, I believe all
> > > the text in section 4.4.3 is necessary.
> > >
> > > The alternative would be to not say anything about it and leave it up
>
> > > to the DTLS implementations.  I think this would result in having to 
> > > do
> > > full authentications on the data channel more frequently than not.  
> > > It could also possibly allow you to establish a data channel without 
> > > a control channel.
> > >
> > > --
> > > t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> > > electrical & computer engineering, university of maryland
> > >
> > >
> > > Pat Calhoun (pacalhou) wrote:
> > > > Pasi's comment is:
> > > >
> > > >    The linking of control and data channels, and how DTLS session 
> > > > resumption is
> > > >    used here, seems unnecessarily complicated.  Normally session 
> > > > resumption is
> > > >    totally TLS internal optimization, and applications running over 
> > > > TLS don't
> > > >    know (and have no need to know) whether full or abbreviated TLS 
> > > > handshake was
> > > >    used. It seems this document wouldn't really need to say anything
>
> > > > about
> > > >    session resumption; if the WTP provides the Session ID in data 
> > > > channel, and AC
> > > >    checks that both DTLS connections were established by the same 
> > > > authenticated
> > > >    client, that seems sufficient.  This would seem to remove much 
> > > > implementation
> > > >    complexity; e.g. the requirement in 4.4.3 that "The AC DTLS 
> > > > implementation
> > > >    MUST NOT accept a session resumption request for a DTLS session 
> > > > in
> > > > which the
> > > >    control channel for the session has been torn down" doesn't 
> > > > follow
> > > > the usual
> > > >    TLS/DTLS module boundaries.
> > > >
> > > > Given the nature of the question, I would like to defer to Scott or 
> > > > Charles. I recall us going back and forth on this, and would like 
> > > > their guidance before we propose a change.
> > > >
> > > > PatC
> > > > _________________________________________________________________
> > > > To unsubscribe or modify your subscription options, please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capwap
> > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone.com/pipermail/capwap