Subject: [MMUSIC] ICE tcp diffs

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Nov 2007 13:07:20 -0500

As folks may have noticed, and updated ICE-tcp is now available:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-05.txt

the changes from -04 are:

* fixed bugs in pseudocode
   SO_REUSEPORT -> SO_REUSEADDR
   for loop needs to go from 0 to MAX, not 1 to MAX

* clarified that secure media is always DTLS-SRTP, even over a TCP
   connection. Forbid RTP over TLS.

* added checks on sender side to make sure application data doesn't
   match a stun packet, and if it does, suggests to use a different
   number of bytes to make the data not look like a stun message based
   on the length checks

* previously, if a clients tcp connection to a turn server failed
   during the middle of a session, the client would reconnect and
   perform a 'move'. Moves have been removed from turn so now the draft
   says to reconnect and restart ICE for the stream

I did not add ice-lite to ICE-tcp; I started on it to see how it would 
look, but ran out of time before finishing. That is the main issue I 
want to discuss in Vancouver.

The other thing to note is that ICE-tcp depends on TURN-tcp, which is a 
new draft that has been split off from the main TURN spec, and will move 
at a slower pace (and only once the core UDP TURN stuff is done).

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Nov 2007 10:22:20 +0100

>   connection. Forbid RTP over TLS.

Jonathan,

I am not certain I get all the implications of this. This limitations
does it only apply when I have a DTLS-SRTP over UDP candidate for the
same media flow? So can I run TCP/TLS/RTP only with connectivity checks
or do I then loose any possibility for using ICE to ensure that
simultaneous open really worked as intended?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Nov 2007 10:26:43 -0500

We had agreed in Chicago that there should only be one way to do secure 
media, and that this should be independent of the underlying transport 
protocol. The previous ice-tcp draft allowed TCP/TLS/RTP and 
TCP/DTLS-SRTP. The current one reflects our agreement that secure media 
is always with DTLS-SRTP, and that this works over either UDP or TCP.

-Jonathan R.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Nov 2007 17:19:07 +0100

> is always with DTLS-SRTP, and that this works over either UDP or TCP.

So in other words no to my question. I don't think it is significant
problem. You get very similar performance and only the implementation
burden might be different depending from where you started.

Cheers

Magnus Westerlund

---

From: Alan Johnston <[email-masked]>
Date: Fri, 30 Nov 2007 14:21:08 -0600

Jonathan,

I'm a little puzzled by your use of DTLS-SRTP (which is one mechanism to 
key SRTP) in this context.  The resulting media session is normal 
SRTP.   There are a variety of ways to key SRTP and surely ICE TCP does 
not mandate the use of DTLS-SRTP as the keying method?

I suspect that what you really want to say is to use SRTP over TCP 
instead of RTP over TLS.

Thanks,
Alan

Jonathan Rosenberg wrote:
> We had agreed in Chicago that there should only be one way to do 
> secure media, and that this should be independent of the underlying 
> transport protocol. The previous ice-tcp draft allowed TCP/TLS/RTP and 
> TCP/DTLS-SRTP. The current one reflects our agreement that secure 
> media is always with DTLS-SRTP, and that this works over either UDP or 
> TCP.
>
> -Jonathan R.
>
> Magnus Westerlund wrote:

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Nov 2007 15:56:37 -0500

Fair point; this document is not meant to make a normative statement on 
what the one and only keying mechanism is. You are correct that, it 
should be saying to use SRTP over TCP and never RTP over TLS. I'll fix.

-Jonathan R.

---

From: Alan Johnston <[email-masked]>
Date: Fri, 30 Nov 2007 15:04:33 -0600

Good - that makes perfect sense.  Thanks for the clarification.

Thanks,
Alan

Jonathan Rosenberg wrote:
> Fair point; this document is not meant to make a normative statement 
> on what the one and only keying mechanism is. You are correct that, it 
>> I'm a little puzzled by your use of DTLS-SRTP (which is one mechanism 
>> to key SRTP) in this context.  The resulting media session is normal 
>> SRTP.   There are a variety of ways to key SRTP and surely ICE TCP 
>> does not mandate the use of DTLS-SRTP as the keying method?
>>
>>> transport protocol. The previous ice-tcp draft allowed TCP/TLS/RTP 
>>> and TCP/DTLS-SRTP. The current one reflects our agreement that 
>>> secure media is always with DTLS-SRTP, and that this works over 
>>> either UDP or TCP.
>>>
>>> -Jonathan R.
>>>
>>> Magnus Westerlund wrote: