Subject: [Capwap] Issue 185: DTLS Session Resumption is optional

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 16 Sep 2008 08:51:11 -0700

All,

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>

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: <[email-masked]>
Date: Tue, 16 Sep 2008 18:54:44 +0300

Pat Calhoun wrote:

>      resumption is typically used...." (since it's no longer 
>      an absolute requirement)
> 
> 	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.)

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 16 Sep 2008 08:58:31 -0700

I will have to defer to Scott or Charles for this question.

PatC 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 16, 2008 8:55 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: Issue 185: DTLS Session Resumption is optional

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.)

Best regards,
Pasi

---

From: "Scott Kelly" <[email-masked]>
Date: Tue, 16 Sep 2008 09:34:17 -0700

Comments below... 

> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Tuesday, September 16, 2008 8:59 AM
> To: [email-masked]; [email-masked]
> Cc: Scott Kelly; Charles Clancy

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

---

From: <[email-masked]>
Date: Tue, 16 Sep 2008 20:09:16 +0300

Scott Kelly wrote:

> > 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.

That's a good explanation, but you can't really figure it out
from the text :-) How about something like this?

"Session resumption is typically used to establish the DTLS session
used for the data channel. Since the data channel uses different port
numbers than the control channel, the DTLS implementation on the WTP
MUST provide an interface that allows the CAPWAP module to request
attempting session resumption despite of the port number (TLS
implementations usually attempt session resumption only when
connecting to the same IP address and port number). "

Best regards,
Pasi

---

From: "Scott Kelly" <[email-masked]>
Date: Tue, 16 Sep 2008 11:15:41 -0700

> connecting to the same IP address and port number). "

Suggesting slightly revised text:

"Session resumption is typically used to establish the DTLS session
used for the data channel. Since the data channel uses different port
numbers than the control channel, the DTLS implementation on the WTP
MUST provide an interface that allows the CAPWAP module to request
session resumption despite the use of the different port numbers 
(TLS implementations usually attempt session resumption only when
connecting to the same IP address and port number)."

Pat may want to further wordsmith this to match the surrounding text
(which I don't have in front of me just now).

--Scott

---

From: <[email-masked]>
Date: Tue, 16 Sep 2008 21:20:04 +0300

> (which I don't have in front of me just now).

Yes, this reads better than my attempt (where wording got complex
because I tried to say that session resumption can be attempted, but
it's just an attempt). Perhaps we could just add "Note that session 
resumption is not guaranteed to occur, and a full DTLS handshake 
may occur instead" to the end?

Best regards,
Pasi