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

Justin Uberti <juberti@google.com> Fri, 13 March 2015 18:51 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC31A8AD8 for <rtcweb@ietfa.amsl.com>; Fri, 13 Mar 2015 11:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dU4uZTkItOsj for <rtcweb@ietfa.amsl.com>; Fri, 13 Mar 2015 11:51:16 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6531F1A8AD3 for <rtcweb@ietf.org>; Fri, 13 Mar 2015 11:51:16 -0700 (PDT)
Received: by igdh15 with SMTP id h15so2190304igd.3 for <rtcweb@ietf.org>; Fri, 13 Mar 2015 11:51:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1Vv5xZLWtjYxvIwCmtT1rOeB3L5rcntaItEuCfS/0nY=; b=K/o/I0PkrN6/SpPcuJcSsS9Wtfavrz/FH6JWeYq6FjjRKs0tEUO9hNzG0QvP90YiZf FV+Sav4b1eCI4+5bi2y0nItChNtLL4JTZnR9ElK60ZiBoLGzBFQjwCwGvLz/zW6vZmyk 4mh75bVP+KIj/xT5f8tJ7WEpcqFP+AWZXwAWZhsqCR/m1IqoD8HRLk6xJXzhudn1z72I uAQwQA2003Zu/r7xOONX7Ygbkw7UvIuaQ7IeQOGRS03LtNliMup90ajFe8UFjP2nwBBR Wuwsv+4yd+IpG3/e0WwtVL4fBnpfO+gU6H3NeGBuwYCBXB88ZeXlJYU3a2sMsu5WorW1 Ry8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1Vv5xZLWtjYxvIwCmtT1rOeB3L5rcntaItEuCfS/0nY=; b=FfQZ3x5VUeHRvW3+hUOOQ/Qo3wtkX0Qz80JbmOGPgN4C/v5SuDMmKz/GKueEKT5a5b CV4yzHPp47E6g1RmKgQ7cpbmKgWmBk44EjFJ42vcc22GFIHdOmWKqb4LT3G+3+IdzirL TWEINbt8UhyWowkhST+fqJw6E6Pgv3pid7GZwe1KSgH422syk0ZzoJIBUSJdDMuvPLJD aRFHxbTzJL8+KM7HsPrLfc+5FtODLlvs/0IALkjNguDobEVhjmHIZb6B453jJ6DRKc5j E5fy1h5NwxY2i7MCi8AC6vr9zoNiChYHYJu3ASu6Gb0i/wH+OYv4ExS8zHwI0WRuGr4c 6SFQ==
X-Gm-Message-State: ALoCoQmZbmFKVYm7m/fScpPQMgwl+fXntEW7sKNt7XNbB2iL8Jz8EuCUiz7KquntHMw/VicCoZ8f
X-Received: by 10.107.165.68 with SMTP id o65mr69979554ioe.56.1426272675840; Fri, 13 Mar 2015 11:51:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.64.42 with HTTP; Fri, 13 Mar 2015 11:50:55 -0700 (PDT)
In-Reply-To: <5503147C.3060506@alvestrand.no>
References: <54F74B02.1070902@jive.com> <CA5E97EE-99F8-44D8-B05B-C9EFDED1A9BB@vidyo.com> <2F467A7E-7A6C-4B1B-985A-0D9C089BE973@cisco.com> <CAOJ7v-1TjZOZ5G31vy_Gt73ADGLRay1RHVeMi=H6Q4=N1b6HLA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D7367A0@ESESSMB209.ericsson.se> <CALiegfmyp=v6thk4eLz7nL1BHh2Qj7jmC84tdG7ufg8HPXsVKA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D7369C9@ESESSMB209.ericsson.se> <CAD5OKxtCswToNzoZnnqJ5M66mjNjKJoA++WYNqN5155n+CWXsA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D736AC0@ESESSMB209.ericsson.se> <CAD5OKxs1grSqAG32mf__wtsjpo68jZmKonbd+EsJmYNsDHUbFQ@mail.gmail.com> <CAOJ7v-3YypG1s9KXOCA+Fo58SuVuUk5-thcSc0k3N2j=4ZmJoA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D737A76@ESESSMB209.ericsson.se> <CAD5OKxs+OEDp9pYrZHw237PfsNunao=PSC89dRhWiFcMwEQUXg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D739611@ESESSMB209.ericsson.se> <CAOJ7v-3bCxVP9fNuRFp_sVBXh4msnF1=fVZrefE0jejMzY8VQQ@mail.gmail.com> <5503147C.3060506@alvestrand.no>
From: Justin Uberti <juberti@google.com>
Date: Fri, 13 Mar 2015 11:50:55 -0700
Message-ID: <CAOJ7v-23_H2jjgG6GrOd1MPv9M-iDbzsdF=L9e5xJsEbH=21PA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary="001a1141bc5a3292f505112ffce8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/yB_XNaI-R-zErE900bKwFRpB-hA>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 18:51:18 -0000

On Fri, Mar 13, 2015 at 9:46 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  On 03/13/2015 04:12 PM, Justin Uberti wrote:
>
>
>
> On Fri, Mar 13, 2015 at 4:05 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> 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.