Subject: [MMUSIC] ICE-tcp open issue #1: simultaneous opens and TLS

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Mar 2007 23:37:54 -0500

What happens if a TCP candidate pair is simultaneous open, both sides 
open, and both succeed. Lets say TLS is supposed to be run on this 
connection. Who sends the ClientHello for TLS?

I'm hoping this has already been solved somewhere else. Otherwise we 
need to add a parameter to SDP to negotiate TLS client role.

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

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

---

From: Aki Niemi <[email-masked]>
Date: Wed, 07 Mar 2007 12:23:59 +0200

> connection. Who sends the ClientHello for TLS?

I thought about this while reading ICE-tcp, and just assumed that
whoever initiated the session (sent the SDP offer) automatically also
sends a ClientHello once a connection is established. Is there a reason
this would not work?

Cheers,
Aki

---

From: EKR <[email-masked]>
Date: Wed, 07 Mar 2007 07:43:37 -0800

> sends a ClientHello once a connection is established. Is there a reason

I think this would work, but RFC 4572 seems to indicate that you
signal who is who with "setup:passive" and "setup:passive"

-Ekr

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 11 Mar 2007 17:43:07 -0400

That doesn't work. Consider a call from a pstn gateway to a hardphone, 
both natted. Pstn gw has a cert and the hardphone does not. We'd like to 
have the hardphone send the clienthello so the tls connection looks like 
a 'normal' one from the cert-less hardphone to the gateway.

-Jonathan R.

---

From: EKR <[email-masked]>
Date: Sun, 11 Mar 2007 15:07:00 -0700

Jonathan Rosenberg <[email-masked]> writes:

> both natted. Pstn gw has a cert and the hardphone does not. We'd like
> to have the hardphone send the clienthello so the tls connection looks
> like a 'normal' one from the cert-less hardphone to the gateway.

So, your point is that there is a basic asymmetry here. In that case,
the sides need to say who is who. IIRC comedia provides mechanism
here...

-Ekr

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Mar 2007 07:12:06 -0400

The comedia mechanism describes rules for determining who opens a 
connection, and who waits to receive it. Its not specifically about TLS 
handshakes; the connection directionality determines that.

The same basic technique could work, of course. We could make up a new 
attribute, say ice-tls-role with values of client or server or both. It 
gets negotiated as part of the O/A exchange, and is completely 
orthogonal to TCP connection directionality.

What's interesting is what happens when the answerer sends the answer, 
and it is in transit when the answerer tries its tcp connection back 
towards the offerer, and it succeeds. The offerer wouldn't know its role 
yet based on the O/A exchange. If its role was "server", the answerer 
could proceed with ClientHello, in which case the offerer, upon getting 
that, would know that it has the role of server and proceed with TLS 
from there.

-Jonathan R.