Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

Iñaki Baz Castillo <ibc@aliax.net> Fri, 08 August 2014 11:29 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920801B2ADF for <mmusic@ietfa.amsl.com>; Fri, 8 Aug 2014 04:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 oTFmKXnTxtkd for <mmusic@ietfa.amsl.com>; Fri, 8 Aug 2014 04:29:39 -0700 (PDT)
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AB21B2A6B for <mmusic@ietf.org>; Fri, 8 Aug 2014 04:29:39 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id v10so974208pde.38 for <mmusic@ietf.org>; Fri, 08 Aug 2014 04:29:38 -0700 (PDT)
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:content-transfer-encoding; bh=4vsx8y9ak+7Fp1fSwvIFsMDvB3gqpWFPIqKzzlys+qI=; b=RHzSl0okk6rdXwGPCIfNHhGU/vtIF5dpzrbaxCllT3DGdfmqtNNMpdi+mwV31Gtbyi mCM+UfsrqvGm3VUlwdZO/id3TBUKm2o5miOI2LcLm+ljeSVCRzcVr7uFv18sHX4kdd7C ojhCa5+3Rfskcw3U8OvBeXfN/uUfnZMfqwI1rHkvyE9SmdvH3/QYTeD9ae5SY6eEX81M +tr9p0BUiPqqlIULtinJAqgpFTkz8xDkLjSLRJNh+pd1mAGQY6B/MN5nC/Fxg4GRqbzx YBHE3nJMYdqTUNjINMXNm90qdV6OXDEKqwyXiEJqRmBxjSOGHu/KsbmDwBvZPOxq8K7/ kgXA==
X-Gm-Message-State: ALoCoQkK5eKiIbIUC23kDr+CVcMyAOlkynDZ/lI7xGLcillvWnudzpHpCffa1aGwRwLtM5bXTVc9
X-Received: by 10.68.213.34 with SMTP id np2mr541895pbc.167.1407497378735; Fri, 08 Aug 2014 04:29:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.70.61.40 with HTTP; Fri, 8 Aug 2014 04:29:18 -0700 (PDT)
In-Reply-To: <CAMvTgccmqfBs6UkRmKRfH1ezfF3bJaMS3=GaOu095hQc9ZW9dQ@mail.gmail.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <CAOJ7v-1jLK7dWDkWHKwHJ6qXicZWDNrAqOtw9R=6zAcWzkh5+g@mail.gmail.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <CAOJ7v-0HEjQQ+j0cAVc5r3Y4LxaoGF7EN2twGG6vTuMmEeragQ@mail.gmail.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <CAOJ7v-1HzGoUNXjvXph0-8WfpM6-vFJ+yDWhVw1_1grfrVD1Vw@mail.gmail.com> <B2794643-ADB5-4B66-98DC-841990C85437@vidyo.com> <CAOJ7v-2O3TwNcsKqp48PjDRu+Yu_+jEurecbO2GctD4Hsuu+NA@mail.gmail.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> <CAOJ7v-1aF0L=fXSP6Fkb1nvukB8+mnKeYfbB9sMAUsufJpy-eg@mail.gmail.com> <CALiegfmLtzMWSNqR_PTRttdau9jCrSavfLygBGxwNAQECt1uhg@mail.gmail.com> <CAOJ7v-0d2BRm31kCDPyObHH1dG2WiPRk8bhODfQFvvfqWm0J1g@mail.gmail.com> <CALiegfko5yWiz1ZUzAnfMTk8zbn9-HJqXWy-uV1oi82q3vtc0A@mail.gmail.com> <CAMvTgccmqfBs6UkRmKRfH1ezfF3bJaMS3=GaOu095hQc9ZW9dQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Fri, 8 Aug 2014 13:29:18 +0200
Message-ID: <CALiegf=ThDqZu-BrTsBg=Xraidjp07SXrDmvjVRipVpVQT8Jtg@mail.gmail.com>
To: Kevin Dempsey <kevindempsey70@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DjkBKdr3GCnOiaFacMkwhCpFudg
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 11:29:40 -0000

2014-08-08 13:21 GMT+02:00 Kevin Dempsey <kevindempsey70@gmail.com>om>:
> Does the new TCP connection require an ICE restart? If so, then I think an
> new DTLS handshake (and fingerprint check) should be required as the server
> may not be connected to the same endpoint anymore.


Why is ICE restart required at all? We are stating that ICE is a
virtual socket regardless how many valid pairs (UDP or TCP) it
handles. The peer can send media (so also DTLS) over any of those
valid pairs at any time without requiring ICE restart (am I wrong?).

My scenario is a good example of how good ICE can be by itself,
without requiring "restart" or a new SDP O/A signaling. Upon TCP
disconnection there is no need to perform a new DTLS handshake since
the "ICE virtual socket" was still open and both Chrome and the server
have already agreed on which layer 4 tuples can be used to carry media
and DTLS stuff is done. Both peers should be able to change the valid
pair at any time without requiring signaling or ICE restart.


NOTE: Issue open in Chrome:
https://code.google.com/p/chromium/issues/detail?id=401923










> On 8 August 2014 11:49, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>>
>> 2014-07-31 21:08 GMT+02:00 Justin Uberti <juberti@google.com>om>:
>> > As discussed earlier, DTLS does not require a separate context for each
>> > tuple. DTLS should be agnostic about the lower layer protocol (and we
>> > should
>> > probably create an errata to resolve this confusion).
>>
>> Hi Justin, I agree with that (and I like that), but Chrome does not
>> behave in that way. My experiment:
>>
>> - The server gives a UDP and TCP candidate to Chrome.
>>
>> - Chrome nominates UDP (ICE stuff), sends the DTLS handshake and then
>> media.
>>
>> - Later the server closes its UDP socket, so STUN requests from Chrome
>> are not replied.
>>
>> - At some point Chrome decides to open a TCP connection with the TCP
>> candidate. It also sends ICE stuff (OK).
>>
>> - The problem: Chrome *sends* a new DTLS handshake over the new TCP
>> connection.
>>
>> This is wrong since the server already has a *working* and
>> *established* DTLS session (which as you say MUST be transport
>> agnostic), so the new DTLS HelloClient is ignored by the DTLS
>> machinery at server side and thus, media is never sent.
>>
>>
>> IMHO Chrome should not attempt a new DTLS handshake given that it was
>> already done before over the "ICE virtual socket". You opinion please?
>>
>> BTW: Let me know if you want me to open a bug report, but I would love
>> having this clear :)
>>
>>
>>
>>
>> --
>> Iñaki Baz Castillo
>> <ibc@aliax.net>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>



-- 
Iñaki Baz Castillo
<ibc@aliax.net>