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

[Pat Calhoun (pacalhou) (pcalhoun]

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
>