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> Sun, 03 August 2014 15:45 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 390461A0068 for <mmusic@ietfa.amsl.com>; Sun, 3 Aug 2014 08:45:21 -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 q84TgCw78TiE for <mmusic@ietfa.amsl.com>; Sun, 3 Aug 2014 08:45:19 -0700 (PDT)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8F51A0055 for <mmusic@ietf.org>; Sun, 3 Aug 2014 08:45:19 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id eu11so8581011pac.3 for <mmusic@ietf.org>; Sun, 03 Aug 2014 08:45:19 -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=TT+1l9aLi15Bzn+q3Uhp2kt6T3gd9NZLi17fOWARn0g=; b=QQWoQlm/FYyPguDsxg5JDWawrgjawASij/e4cyUgQbk8OHfHaBIZWPiT7BXgn6ZWpM HPvSi4cJvNfDyZgKlVU1vthXje3wKY51Pm45CV8PY2bP0+VkkTNotAqyUtCVENxsTgeZ So7j5Mlm0PZzJGnyR/7vcWUq+rQj8gUqIzmSqqi651YS4zr/XL/VV33rCt3H/HFshenj B94fcg5TIztJ4pv1mg9ABEb9b79vWVzPSQyqBB7s64GzTKRpAboldTGrPA1UZlhu7te1 LKV2YySB1hROlamKpIbsu/OZHYa7jmXKXx8fP2x5e4Gmq6QJMVm/KyTGDG3UyI7W+MxE 05Sg==
X-Gm-Message-State: ALoCoQnd5za41i6pfHksZb4HEvN1BeF58Afm0edTsjY65KMlvjtARugHZz6fa93PGYlhx2trt9Dr
X-Received: by 10.70.1.100 with SMTP id 4mr1192941pdl.147.1407080719309; Sun, 03 Aug 2014 08:45:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.70.61.40 with HTTP; Sun, 3 Aug 2014 08:44:58 -0700 (PDT)
In-Reply-To: <CABkgnnVwdOmeu4TwsArW4fv+J98Ln1GswTVjPzvvTHmPSa+1eQ@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> <CABkgnnVwdOmeu4TwsArW4fv+J98Ln1GswTVjPzvvTHmPSa+1eQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Sun, 3 Aug 2014 17:44:58 +0200
Message-ID: <CALiegf=rzvYaBx4dvBKCrsq0O-PPV39zFi4Sx7g4W8c2L3LziA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2WcbMekOXlaE_gEZ9LHZysK4_zg
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:45:21 -0000

2014-08-03 17:02 GMT+02:00 Martin Thomson <martin.thomson@gmail.com>om>:
> 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.

I don't like the idea of including an ICE Binding request into a DTLS
packet. ICE requests are supposed to "open the path" and thus STUN
packets should be the first ones. Instead, DTLS is "application data
to be carried over the open path". We must respect that.

So why not the opposite?: Add the DTLS ClientHello packet into a new
STUN attribute (may be called "DTLS_PACKET"). Issues above solved:

- STUN is processed as normal.

- The *same* DTLS HelloClient can be set into *different* ICE Binding
requests, so there is a single DTLS handshake.

- From the point of view of the sender, it is the same scenario in
which the sender sends a ICE Binding request followed by a DTLS
HelloClient, but with the guarantee that the ICE request will arrive
"first" :)

- From the point of view of the receiver, it first receives (and
validates) the ICE Binding request, then generates the ICE response
and then processes the DTLS HelloClient contained in the "DTLS_PACKET"
attribute of the Binding request. This adds very little complexity to
existing implementations.

Thoughts?


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