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

[Christer Holmberg <[e-mail]>]

Hi,

The thing that brought this whole thing up was DTLS.

So, unless people see a need for something else, maybe we should limit the scope to DTLS, and describe how a DTLS connection can span multiple candidate pairs (read: multiple 5-tuples)?

Otherwise we may end up spending lots of time for something which nobody really need…

Regards,

Christer

From: rtcweb [mailto:[e-mail]] On Behalf Of Justin Uberti
Sent: 13 March 2015 20:51
To: Harald Alvestrand
Cc: [e-mail]
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples



On Fri, Mar 13, 2015 at 9:46 AM, Harald Alvestrand <[e-mail]<mailto:[e-mail]>> wrote:
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?

To be clear, I am not advocating going off and doing work to make TCP run over ICE. My point was merely that essentially any protocol that runs over IP or some other datagram transport can be made to run over ICE with zero or minimal modifications; this is not well understood; and so this should be explicitly codified in ICE-bis.