Subject: [Capwap] Issue 153: Linking of control and data channels

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 28 Jul 2008 11:51:26 -0700

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

---

From: Charles Clancy <[email-masked]>
Date: Mon, 28 Jul 2008 20:54:52 -0400

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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Jul 2008 09:47:59 +0100

> guidance before we propose a change.

I'd like to add one fact to the discussion of complexity in this  
protocol...

We already have (at least) three implementations of the CAPWAP base  
protocol, including two completely independent implementations, that  
were tested together at an EPCglobal interoperability event last  
week.  We didn't run into any significant problems getting the  
different implementations to work together.  So, the level of  
complexity in the base spec doesn't seem to be causing  
interoperability problems in practice.

I'd personally prefer that we err on the side of keeping things  
stable at this point, rather than trying to simplify them.

Margaret

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 19:35:30 +0300

The need for efficiency is understandable, and I wouldn't have any
concerns if the spec simply said "MUST support TLS Session
Resumption".

However, the requirement that the CAPWAP Data Channel establishment
MUST NOT use full handshake (and possibly, Control Channel
establishment MUST NOT use session resumption -- although this part is
less clear), and the requirement "MUST NOT accept a session resumption
request for a DTLS session in which the control channel for the
session has been torn down" are more complex from TLS/DTLS perspective
than they seem.

These requirements don't lead to any performance improvements -- 
a sane implementation would anyway perform DTLS session resumption
whenever possible.

If the requirements here are kept as-is, you probably need to specify
some additional details (and this would be the first RFC ever that
touched these parts of TLS -- so given that there's no performance
gain, are you really sure you need to do this?)

- clearly say that DTLS MUST NOT accept (or initiate) full handshake
on port 5247, and (presumably) MUST NOT accept (or initiate) session
resumption on port 5246.

- specify how the DTLS/TLS implementation maintains its session cache
(current TLS RFCs allow deleting session cache entries at any time,
which wouldn't always work). Assuming that the data channel is
established only once, immediately following control channel
establishment, you need to keep the session cache entry around until
the data channel is established.  And you need to delete the session
cache entry when the control channel is closed.

- probably prohibit use of TLS renegotiation, or else explain how it
would work

Best regards,
Pasi

> -----Original Message-----
> From: ext Charles Clancy [mailto:[email-masked]] 
> Sent: 29 July, 2008 03:55
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: Re: [Capwap] Issue 153: Linking of control and data channels
> 
> 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.
> 
> --