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 <> Fri, 01 August 2014 08:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B9431A036F for <>; Fri, 1 Aug 2014 01:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pf34eUIDzmP8 for <>; Fri, 1 Aug 2014 01:16:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FBA21A0377 for <>; Fri, 1 Aug 2014 01:16:14 -0700 (PDT)
Received: by with SMTP id q107so5341747qgd.40 for <>; Fri, 01 Aug 2014 01:16:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=GlXvarv4U9Em77z8RjLZy9gcyaYosRmYSfIO2NRct3E=; b=XseGVo9g1WfNf6QvvlukQxKfX04iySDPAojvBwGFOQIAcicHOZz+d+1TMyudT4NZno rlCOU2zc2h6T6yQCuC4XoNQd5WtrW/TICkP0F53CG/zGNo1nPS7W+AyGESYLgB3M7sVd +tLem3PRmJOC1cbjHVJS5YGwDzhQlp7mf8DVmU/6ZVhWJ2AjiSbCfSzwtOYlMuhXUn3w s4gKPNhNExpWqRaBzee8CVP5YyUtDSSvzh/VBJ7vK+A8+6kvBykyduq3qyOrs4FJnFez GPpnMbjgJoO8lh1XtjlVFV63lmzD3odIZ/Vj4uRgW7qrSiiUBZyHdW2Bg3+5Axth445E 2rrw==
X-Gm-Message-State: ALoCoQl82dijwzZBiPenhBzk4/Of5MFdJ9/SqpJBKsVWIXCRwNNAdahF6fQyxo3hBy5o6aKik/68
X-Received: by with SMTP id e3mr6263128qar.5.1406880973397; Fri, 01 Aug 2014 01:16:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 1 Aug 2014 01:15:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Fri, 1 Aug 2014 10:15:53 +0200
Message-ID: <>
To: Justin Uberti <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Jonathan Lennox <>, mmusic <>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Aug 2014 08:16:20 -0000

2014-08-01 3:06 GMT+02:00 Justin Uberti <>om>:
> On Thu, Jul 31, 2014 at 5:34 PM, Martin Thomson <>
> wrote:
>> On 31 July 2014 15:40, Iñaki Baz Castillo <> wrote:
>> > - For DTLS it means complexity in the sense that a separate DTLS
>> > session/context is required for each "transport".
>> Not really.  DTLS "says" that, but it doesn't functionally rely on a
>> stable 5-tuple in any real fashion.
>> Other protocols that rely on UDP are likely to be similar.  Reliance
>> in name only.
> Think of ICE as a virtual socket.

I assume you mean "DTLS" rather than "ICE".

> At higher layers, you don't know the
> address of the remote endpoint or exactly how it will be contacted, but you
> know if you send something on the virtual socket it will make it to the
> remote endpoint. That's all DTLS needs to know.

Sure. But for that, in case of UDP, you need a *separate* DTLS
"virtual socket" for each different UDP remote address from which you
receive DTLS packets (you don't want to pass two different ClientHello
to the same DTLS virtual socket, assuming that each DTLS virtual
socket handles a single DTLS session/context, right?).

Well, I will try to explain my concern better:

- Let's assume that peerA is a full ICE agent and announces two host
candidates (due to two interfaces eth0 and eth1 connected to

- peerB is also full ICE agent which announces a single host candidate.

- To simplify, both agree on rtcp-mux and so on.

- peerA is the controlling and uses aggressive nomination.

- At some point peerB receives a ICE USE-CANDIDATE in its socket
coming from peerA's eth0 and another ICE USE-CANDIDATE in its same
socket coming from peerA's eth1. Let's name those paths "pair1" and
"pair2", both of them are "valid" (regardless which is the
"selected"/"nominated" one).

- And since it is being said in this thread that "ICE is not supposed
to find a *single* transport path" then peerA sends two different DTLS
ClientHello, one over pair1 and the other over pair2.

- Both ClientHello reach the *same* socket on peerB. If peerB holds a
single DTLS "virtual socket" (this is: a single DTLS session/context)
then the second ClientHello will be discarded by the DTLS session (as
it has already received a previous ClientHello with different seq
number and so on). And it would be difficult for peerB to know whether
it must send back its DTLS generated response packets to peerA's eth0
or eth1.

Is it clear now what I mean?

There are two ways to handle this "issue":

1) Ignore any DTLS packet received over a non selected/nominated ICE
pair (so both peers must compute the same selected pair after ICE
procedures and just use *that* for sending DTLS).

2) Allow DTLS packets received over any valid ICE pair (those from
which the remote peer has sent valid and authenticated Binding
requests with USE-CANDIDATE). For this a separate DTLS
session/context/virtual-socket is needed for each valid ICE pair.

PS: In the text above I'm assuming that peerA initiates two different
DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to
go, may we assume/mandate at least that peerA MUST perform a *single*
DTLS handshake (regardless packets are sent and received via pair1 or
pair2 or via both of them)?

Thanks a lot.

Iñaki Baz Castillo