Subject: RE: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Apr 2007 22:00:33 -0700

And TLS session resumption should be useful to avoid doing a 
public key or DH against each ICE candidate.

-d

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Saturday, March 31, 2007 4:25 PM
> To: Rémi Denis-Courmont
> Cc: [email-masked]
> Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS
> 
> Given EKR and Rémi's analysis of the situation, it sounds to 
> me like we 
> get to choose between making implementors work harder and making CPUs 
> work harder.
> 
> I would argue that the key to a successful protocol is a low 
> implementation complexity. Even for low-end mobile devices, CPUs are 
> relatively fast (133 MHz is the low-low-low end nowadays) and getting 
> faster all the time -- so the extra TLS handshakes, while a 
> waste of CPU 
> time, are going to be rather insignificant in the grand scheme of 
> things. (As to battery life: consider that these wasted cycles will 
> typically occur only at the start of a session, so there should be 
> negligible impact on total power used).
> 
> Finally, given that ICE-TCP is being considered for 
> applications other 
> than TCP (cf. Aki's ICE-MSRP draft), I'd want to stay away from any 
> solution that assumes the use of RTP TCP framing.
> 
> /a
> 
> Rémi Denis-Courmont wrote:
> > On Thursday 29 March 2007 17:25:41 ext EKR wrote:
> >   
> >>> Well, one idea on the demux is if we are using the 
> contrans framing,
> >>> the TLS runs ONTOP of the framing so the demux is trivial.
> >>>       
> >
> > My memory might be failing, but I thought RTP/TCP framing 
> only adds a bytes 
> > length word. That is sufficient to differenciate RTP from 
> STUN, sure... but 
> > does it work for TLS vs STUN at all?
> >
> >   
> >>> One thing I wasnt sure of is whether the stacks allow 
> these shimes to
> >>> exist only prior to the handshake completing or through the entire
> >>> duration of the tls connection?
> >>>       
> >> At least with OpenSSL, all the time. If people want, I 
> could do a survey
> >> of the relevant stacks and see what they do. It won't be 
> this week or
> >> next, though...
> >>     
> >
> > At least, OpenSSL, GnuTLS and DotNet 
> System.Net.Security.SslStream. Not very 
> > confident about the other ones. And in any case, this 
> requires a bunch of 
> > extra custom code because they all assume a socket handle 
> by default, so you 
> > end up writing new I/O callbacks and re-assembling buffers. 
> I am not very 
> > fond of that idea.
> >
> > I would rather go for STUN then TLS then (proto-specific 
> keep-alives OR 
> > STUNoTLS). As far as I can tell, it would be faster and 
> slightly less 
> > disruptive to application developpers.
> >
> > Regards,
> >
> >   
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 5 Apr 2007 10:20:14 +0300

> public key or DH against each ICE candidate.

This raises two questions (sorry if they were already addressed, I might have 
missed it):
1/ Does ICE-TCP only ever maintains one candidate active TCP connection at a 
time?
2/ What are the requirement for TLS to allow resumption if you change from one 
TCP connection to another one (I vaguely recall that some error cases stalled 
the session for security reasons)? there may be a need to close extra ICE-TCP 
connection in some particular way, maybe...

Anyone?

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Apr 2007 09:39:54 -0400

one clarification, Adam. ICE-tcp currently REQURIES that every 
application protocol using ice-tcp, utilize the cotrans framing, even if 
its not RTP.

I understand this is an issue with MSRP because its framing works 
differently, but I think it ought to be work using some basic buffering 
and timeout techniques, just like TCP uses to decide when to send something.

-Jonathan R.

Adam Roach wrote:

> Given EKR and Rémi's analysis of the situation, it sounds to me like we 
> faster all the time -- so the extra TLS handshakes, while a waste of CPU 
> Finally, given that ICE-TCP is being considered for applications other 
>>>> Well, one idea on the demux is if we are using the contrans framing,
>> My memory might be failing, but I thought RTP/TCP framing only adds a 
>> bytes length word. That is sufficient to differenciate RTP from STUN, 
>> sure... but does it work for TLS vs STUN at all?
>>
>>  
>>
>>>> One thing I wasnt sure of is whether the stacks allow these shimes to
>>> At least with OpenSSL, all the time. If people want, I could do a survey
>>> of the relevant stacks and see what they do. It won't be this week or
>>> next, though...
>>>     
>>
>>
>> At least, OpenSSL, GnuTLS and DotNet System.Net.Security.SslStream. 
>> Not very confident about the other ones. And in any case, this 
>> requires a bunch of extra custom code because they all assume a socket 
>> handle by default, so you end up writing new I/O callbacks and 
>> re-assembling buffers. I am not very fond of that idea.
>>
>> I would rather go for STUN then TLS then (proto-specific keep-alives 
>> OR STUNoTLS). As far as I can tell, it would be faster and slightly 
>> less disruptive to application developpers.
>>
>> Regards,
>>
>>   
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com