Subject: [MMUSIC] ICE-tcp proposed issue resolution for TLS then STUN or STUN then TLS

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 11:30:37 -0400

I'm working on a revision of ICE-tcp, which I hope to complete before 
the deadline this Monday.

As folks may recall, the main outstanding issue is the question of "TLS 
then STUN" or "STUN then TLS". In particular, the question is whether, 
during ICE negotiations, you first do the STUN connectivity checks over 
the TCP connection, and then, once done, proceed with TLS ("STUN then 
TLS"). Or, once you open the TCP connection, do you immediately do TLS 
negotiations and then once those are done, begin STUN.

We had a decent email thread on this in the beginning of April. There 
wasn't a clear consensus on it, though I think it weighed slightly in 
favor of "STUN then TLS". One of the things that came up during the 
discussion is that "STUN then TLS" will be faster, since it avoids the 
several-RTT TLS handshakes for connections which don't actually get 
connected or selected. With "STUN then TLS", you'll only end up doing 
the TLS handshakes once, for the selected candidate pair. Another issue 
that came up is that "STUN then TLS" matches how we are doing this for 
UDP, where STUN and DTLS are peers. THe main concern with "STUN then 
TLS" was its implementation complexity. I initially thought this would 
require custom TLS stacks in fact, but later it came out that most TLS 
stacks allow a socket abstraction and thus one could implement a socket 
abstraction that demuxed the STUN and TLS prior to feeding the TLS into 
the stack.

So, based on all of this, my plan for the next revision is to specify 
"STUN then TLS". In particular, the stack is going to be:

Please view in a fixed-width
    font such as Courier.

                +-----------+
                |    App    |
                |           |
     +----------+-----------+
     |          |           |
     | STUN     |    TLS    |
     +----------+-----------+
     |                      |
     |     cotrans shim     |
     +----------------------+
     |                      |
     |         TCP          |
     +----------------------+
     |                      |
     |         IP           |
     +----------------------+

The cotrans shim is RFC 4571. This is a trivial shim that simply defines 
a length field for framing. Though its defined for RTP it is not RTP 
specific at all and you could use it with anything. ICE-tcp has, for a 
few revisions, required this shim for any application protocol, not just 
RTP.

So, during ICE, you'll establish the TCP handshake and run STUN checks 
over the shim. Once ICE is done, and the USE-CANDIDATE flag has been 
sent in a STUN message sent over that shimmed TCP connection, TLS 
procedures start ontop of the same shim. Once the TLS is established, 
the app runs ontop of the TLS session.

In terms of keepalives, the current ICE text as defined still applies; 
STUN (outside of the TLS) is recommended. But you can use something at 
the app layer if you want. It had been suggested during the email thread 
that we could run STUN and TLS as peers only initially, and then once 
TLS is established run the shim and STUN over TLS. I think this is 
massively confusing, since we are doing things at multiple layers. You'd 
need to synchronize this change through something like a STARTTLS 
mechanism and that adds more roundtrips. I don't see the benefit.

In terms of who sends the ClientHello, I am thinking of using the 
RFC4145 attributes for this, but with ICE-tcp they EXCLUSIVELY indicate 
the TLS directionality. TCP directionality is determined by the ICE 
parameters.

Given the proximity to the deadline I doubt there will be much 
discussion or time to disagree before the the deadline arrives. Thats 
fine, we can always change it. I am hoping to use the time between now 
and the meeting, and the time at the meeting itself, to conclude on 
this, and so we can finish this spec.

Thanks,
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: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 6 Jul 2007 09:18:56 +0300

Hello,

I also vaguely recall some people complaining that embedded devices would have 
a hard time generating crypto-parameters for more TLS sessions than needed in 
TLS then STUN case.

Anyway...

> few revisions, required this shim for any application protocol, not just

I must have forgotten something, but why would ICE-TLS need a shim of ICE-TCP 
does not? or if you prefer: how come ICE-TCP can do without shim and ICE-TLS 
cannot?

Also, if both TCP and TLS used the same shim/non-shim/whatever, there would be 
essentially no need for specifying TLS at all (it would just be part of the 
application layer from STUN/ICE perspective) - with the exception of 
specifying who sends ClientHello.

(...)
> massively confusing, since we are doing things at multiple layers.

Yes, sounds very confusing to me too.

> the TLS directionality. TCP directionality is determined by the ICE

Yes. I suppose COMEDIA attributes will also be used as default if the answerer 
does not support ICE-TCP.

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Jul 2007 08:54:28 -0400

> does not? or if you prefer: how come ICE-TCP can do without shim and ICE-TLS 

It does have a shim, the same one.

> specifying who sends ClientHello.

And that you need to use TLS, yes. But overall the interaction with ICE 
is minimal when its structured this way.

> does not support ICE-TCP.

Exactly. So, if the peer is not ICE capable but using comedia, then the 
comedia attributes signal BOTH TCP and TLS directionality. If the peer 
is ICE capable, the comedia attributes signal TLS directionality only. 
TCP directionality is determined by the ICE parameters.

-Jonathan R.