Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

[Harald Alvestrand <[e-mail]>]

On 03/13/2015 04:12 PM, Justin Uberti wrote:
>
>
> On Fri, Mar 13, 2015 at 4:05 AM, Christer Holmberg
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>     > TLS (vs DTLS) cannot run on top of ICE since it is not a
>     protocol which can run on top of unreliable packet based transport
>     with no order guarantees. It would require a stream
>     > based transport to run below it in order to operate. If someone
>     defines TCP over ICE, that would make a good underlying stream
>     protocol to run below TLS. Once again, no one
>     > needed this so far.
>
>     Even if we had TCP over ICE, I still don't know whether we would
>     be able to run TLS on top. Because, in addition to reliability,
>     doesn't TLS also rely on the ordering provided by TCP? We would
>     need to make sure the ordering is maintained if endpoints use
>     multiple TCP 5-tuples.
>
>
> A few points:
> - Anything we are say "runs over ICE" is going to be tunneled over UDP
> or TCP, whichever ICE chooses to use as its underlying datagram
> transport. So the notion of running "plain TCP" over ICE is nonsensical.
>
> - Assuming we do run TCP over ICE, we can certainly run TLS on top.
> Since TCP is just treating the underlying ICE transport as a datagram
> transport, TCP retains all of its reliability and in-order properties.
> So TLS just sees that it is running over TCP, and doesn't care that it
> is ICE at the lowest layer. Note that this stacking of TLS/TCP/ICE is
> different from the case of running TLS over ICE-TCP, since ICE-TCP
> does not guarantee reliability or ordering.
>
> - Harald's point about the TCP checksum is true; if we were truly
> standardizing TCP-over-ICE, we would have to define an appropriate way
> to compute the TCP checksum given that said checksum makes assumptions
> about IP particulars. This would not be hard though.
>
> - Lastly, this is clearly a source of massive confusion, so I agree we
> should discuss it in detail in Dallas. I would be happy to help
> prepare presentation material if needed.

Can we define an use case for which there is a compelling need for
<whatever it is we're discussing> before spending too much meeting time
on it?

It's clearly very simple to define a protocol that is like TCP except
that the checksum doesn't include the addresses, and where the two
highest bits of the first byte aren't 00. It's not interoperable with
standard TCP, it can't take advantage of TCP accelerator hardware or be
detected by TCP-sensitive middle boxes (unless tweaked). But it's simple
to define.

It's also clearly very simple to run this protocol over ICE.

But why?

And is this scenario relevant for RTCWEB, which is trying to finish its
current set of options?