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

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Fri, 11 November 2011 17:31 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 6EC7421F8AF3 for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 09:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level:
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 EseUJAQz9Bf2 for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 09:31:29 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27121F8AD3 for <rtcweb@ietf.org>; Fri, 11 Nov 2011 09:31:28 -0800 (PST)
Received: from [192.168.1.200] (p508FD391.dip.t-dialin.net [80.143.211.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 71D611C0C0BCE; Fri, 11 Nov 2011 18:31:27 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CABcZeBOJdFzmVqd02_a=-psKvqDAujAkoWRsFYFK=fNWj+QDqA@mail.gmail.com>
Date: Fri, 11 Nov 2011 18:31:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <360EF6F3-E5E6-4690-BAA2-211F3CAFDF1F@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> <CABcZeBOJdFzmVqd02_a=-psKvqDAujAkoWRsFYFK=fNWj+QDqA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1251.1)
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:31:29 -0000

On Nov 11, 2011, at 6:14 PM, Eric Rescorla wrote:

> 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).
OK, you you only pass those packets to DTLS, which belong to the 5 tuple
which you have already communicated with, and discard the others, it is OK.
So SCTP needs one RTT, DTLS two.

Thanks for the clarification.

Best regards
Michael
> 
> 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
>