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

Kevin Dempsey <kevindempsey70@gmail.com> Fri, 08 August 2014 11:21 UTC

Return-Path: <kevindempsey70@gmail.com>
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 819941B2A4E for <mmusic@ietfa.amsl.com>; Fri, 8 Aug 2014 04:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level:
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 6IBfqLDgfNHh for <mmusic@ietfa.amsl.com>; Fri, 8 Aug 2014 04:21:22 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA121A02D1 for <mmusic@ietf.org>; Fri, 8 Aug 2014 04:21:22 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id ty20so4551177lab.32 for <mmusic@ietf.org>; Fri, 08 Aug 2014 04:21:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gzWICJYn14xMmbFiqMcNqHQHavvdADKvPCUhpmSBnxA=; b=f9w6kp1+Y/72UFQMRqgwyg33d323V/HbYqe9DtVlUUvSGTpobfnR3SFAUoJga6heTT jcGqk7fZlbNWa/iPF/0MDxlpeddQLGgNgWW1k2u5mgPOMZl+sf3Z0fM6/d9Zo9akUAon 0C2kOEB4FUSx7viCYuZfLSAjTIDlkhivDSmmEQNdweof1eJtRsd2p4JBqiFcZJwpoAMq jU1GJ3H1yqUIdFjG6HPxYeuY0wSYz5ItqeOzNOq7jZLivhipGIFK/1JBUkbicSc1Dv7e h2GcSmbvTCCvmnmLliS9zgn/rHexmcP3L36cLmWsjrBn2LAFiaewXqEZSpqqIaZ550Wb O5nw==
MIME-Version: 1.0
X-Received: by 10.152.87.34 with SMTP id u2mr21957036laz.12.1407496880520; Fri, 08 Aug 2014 04:21:20 -0700 (PDT)
Received: by 10.114.23.36 with HTTP; Fri, 8 Aug 2014 04:21:20 -0700 (PDT)
In-Reply-To: <CALiegfko5yWiz1ZUzAnfMTk8zbn9-HJqXWy-uV1oi82q3vtc0A@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>
Date: Fri, 8 Aug 2014 12:21:20 +0100
Message-ID: <CAMvTgccmqfBs6UkRmKRfH1ezfF3bJaMS3=GaOu095hQc9ZW9dQ@mail.gmail.com>
From: Kevin Dempsey <kevindempsey70@gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=001a11c237c696038c05001c6728
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8mOm1jrvJDbpSFrUwiASty0IeSo
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:21:24 -0000

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.


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
>