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

Martin Thomson <martin.thomson@gmail.com> Sun, 03 August 2014 15:02 UTC

Return-Path: <martin.thomson@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 8C41D1A035B for <mmusic@ietfa.amsl.com>; Sun, 3 Aug 2014 08:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Fqjpk12mRiSt for <mmusic@ietfa.amsl.com>; Sun, 3 Aug 2014 08:02:32 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41301A0359 for <mmusic@ietf.org>; Sun, 3 Aug 2014 08:02:31 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id f8so5034613wiw.3 for <mmusic@ietf.org>; Sun, 03 Aug 2014 08:02:30 -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=cvR2MH0xo+JZS5Mp/gFrELEVoiVal6e3smxP+X2S0sY=; b=OyPxWeE3SK4jbBpybraQjn1WWp4VTyTKnYj41IihZ4GYn1MKZafHDyzIdBAWc8oJFd BCYgikZSPTNfLwokRcfCU3orYp35vsj1VbmBDvyVrBQRXTk6m4mGXLIgJ4HkeQScWG4X qxar5HmL+CubbAsn87nqfXAc2PzWG0y1wK0tpWciEa/TaZeFbd38Uv8xBkijVOe2PGlz hukwQ7g+I57kFH3SUNoQa9rayRwdIOjXFSIE6kq9YBoH3m9yPe0yBnZxYhjP5i6nDAeg j/8lOyGTIsWEIDnUoXHPkzxNaWiL9NmyT5SbdBWEahGqn2316LjuAxq6M3dqi7F/kuLz bdew==
MIME-Version: 1.0
X-Received: by 10.180.92.38 with SMTP id cj6mr22661003wib.64.1407078150170; Sun, 03 Aug 2014 08:02:30 -0700 (PDT)
Received: by 10.194.6.229 with HTTP; Sun, 3 Aug 2014 08:02:29 -0700 (PDT)
Received: by 10.194.6.229 with HTTP; Sun, 3 Aug 2014 08:02:29 -0700 (PDT)
In-Reply-To: <CALiegfn2H9ZUsni=T1Axm+_-p+OO_2bH51xvwTftTgaL7=2Vew@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-13UZi4w7Vfr2dkghaosrwVYkTw5G2shq0JUvLPy30vTw@mail.gmail.com> <CAOJ7v-0s6EVa4KxQY99wB-BaDGr5EZwVunxrW4BBgVJLEuWhiQ@mail.gmail.com> <CAPvvaa+sKWtGSaWvo6Vx=vhMbbhmLQKr2o9Z3Wjkm2-5TXDjHw@mail.gmail.com> <CAPvvaaJDT0cgWhNkeKMKWUnHvRgZaEb9VXjV3+wHCx15_Z6+wg@mail.gmail.com> <CAPvvaaLNjZr-3NmdJOAV-Ov6qQ1gZoEOF1dk4W52gEOUq4214g@mail.gmail.com> <CALiegf=QASGR2+FuY7TKoJYrdvqbDxyUyKxvMQ13do5YX4GUyw@mail.gmail.com> <CABkgnnXvs_7fjQfCjeXMn4_RZExc8mYAQzqvq_fznc+kwGkKqA@mail.gmail.com> <CALiegfmp5YJwO62+fUN8AB=-A8rbenko_P7r35jo_CdUT6MWbA@mail.gmail.com> <CABkgnnXzNVgrYK6gjWmdyBoJ1Cog45XTP7F3yzaqOmm=GTypzA@mail.gmail.com> <CAOJ7v-1wzU0yMs21XYOpersa9f8u0=1n-mJ1BNrO-rEu3x9K5w@mail.gmail.com> <CALiegf=DJVZgEruEEGY4J7YiQk1jpzcDkztrT+Nosyrbjn0q5g@mail.gmail.com> <CABkgnnV0mBKgPj+9zNPcmTTLAGsz42eTMuAo14bnneSOowmR8w@mail.gmail.com> <CALiegfnn0Vs-TeTn29fhC4Hb9RFVZOAzx7ZQHRCVBDp=VF+ObQ@mail.gmail.com> <CAPvvaaLQwrxO9VcsjFNd+Mon49iC=jqREY3HOorbRW=EY7a=hQ@mail.gmail.com> <CALiegfm=oMYK7hb3ezjt5P3ZDMdCy2YG9vVqiJa8kOgjD6X=yQ@mail.gmail.com> <CAPvvaa+3rGuyj2=bsO8UDqhe878f18dUkF41jV9FbVqadc=mvw@mail.gmail.com> <CALiegfn2H9ZUsni=T1Axm+_-p+OO_2bH51xvwTftTgaL7=2Vew@mail.gmail.com>
Date: Sun, 3 Aug 2014 08:02:29 -0700
Message-ID: <CABkgnnVwdOmeu4TwsArW4fv+J98Ln1GswTVjPzvvTHmPSa+1eQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=f46d043c7faa4fefc904ffbae95c
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ze9AwBQ_HIcrGmJM0mRo7FPQt70
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: Sun, 03 Aug 2014 15:02:33 -0000

On Aug 3, 2014 7:20 AM, "Iñaki Baz Castillo" <ibc@aliax.net> wrote:
> - In that case both ICE Requests are different (different
> transactionId and so on) so both DTLS HelloClient packets must also be
> different, and hence we are talking about *two* separate DTLS
> handshakes, which means that PeerB MUST handle two different DTLS
> sessions into the same local candidate/interface.

I think that you are jumping to conclusions here. What Dan suggested isn't
really part of what Emil is talking about, it is an additional
optimization. As such, it's orthogonal.

If we were to couple DTLS with the connectivity check, it seems like we
would have to require some tweaks to the process in order to avoid the
problem you describe. I think that you have identified a real problem. It
might be that we need to exclude that transaction identifier from the
integrity check to fix that, which is a non-trivial change. The obvious
solution - requiring identical transaction identifiers - removes the
on-push guarantee, at least to the extent that an attacker can modify
signaling and spoof valid source addresses.