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

[Pat Calhoun (pacalhou) (pcalhoun]

Done - thanks!

PatC 

-----Original Message-----
From: Charles Clancy [mailto:tcc [at] umd.edu] 
Sent: Tuesday, July 29, 2008 2:05 PM
To: Pat Calhoun (pacalhou)
Cc: Scott G. Kelly; capwap [at] frascone.com; Pasi.Eronen [at] nokia.com
Subject: Re: [Capwap] Issue 153: Linking of control and data channels

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