Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt

Eric Rescorla <ekr@rtfm.com> Fri, 11 November 2011 17:15 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5E121F8AD9 for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 09:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.794
X-Spam-Level:
X-Spam-Status: No, score=-102.794 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CRYuD+jgnyZ for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 09:15:03 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C707821F8ABB for <rtcweb@ietf.org>; Fri, 11 Nov 2011 09:15:03 -0800 (PST)
Received: by vws5 with SMTP id 5so4307270vws.31 for <rtcweb@ietf.org>; Fri, 11 Nov 2011 09:15:02 -0800 (PST)
Received: by 10.52.29.9 with SMTP id f9mr22324831vdh.30.1321031702097; Fri, 11 Nov 2011 09:15:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.118.132 with HTTP; Fri, 11 Nov 2011 09:14:21 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de>
References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <CABcZeBOEUseuR-dHkxxnan1Gy0aKG+07DSTJAGzOt7ii_2aw3A@mail.gmail.com> <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 11 Nov 2011 09:14:21 -0800
Message-ID: <CABcZeBOJdFzmVqd02_a=-psKvqDAujAkoWRsFYFK=fNWj+QDqA@mail.gmail.com>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Nov 2011 17:15:04 -0000

On Fri, Nov 11, 2011 at 9:01 AM, Michael Tüxen
<Michael.Tuexen@lurchi.franken.de>; wrote:
> On Nov 11, 2011, at 3:51 PM, Eric Rescorla wrote:
>
>> On Fri, Nov 11, 2011 at 5:15 AM, Michael Tuexen
>> <Michael.Tuexen@lurchi.franken.de>; wrote:
>>> Hi Michael,
>>>>  o DTLS and SCTP handshakes must be performed serially (no matter which order they happen in), which increases the number of round-trips necessary to establish communication.
>>> That is correct. SCTP adds one RTT to whatever DTLS is requiring.
>>> So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the initial
>>> RTT required for the Cookie exchange).
>>> When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need for
>>> the DTLS Cookie).
>>
>> There's no need for the DTLS cookie in either case, actually, since ICE provides
>> the appropriate proof of return routability.
> I don't know much about ICE....
> So assume that the endpoint willing to accept DTLS connections.
> Can't I just send an ClientHello via plain UDP to the endpoint (assuming that I can reach it)?

When ICE is involved, there's no real concept of "an endpoint willing to
accept DTLS connections". At a high level, the way that ICE works is
that the communicating parties establish a session out of band and
then use the ICE handshake to bind one or valid 5-tuple flows to the
the session. Packets that arrive at one endpoint that aren't part of one
of these flows can more or less be discarded. (At least at this stage).

Since the purpose of the DTLS cookie is to prevent blind resource
consumption DoS attacks, and ICE inherently that you're not going
to be doing handshakes with random remote IP addresses, I don't
think there's much of an issue here.

-Ekr