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> Thu, 31 July 2014 22:11 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 674851A019A for <mmusic@ietfa.amsl.com>; Thu, 31 Jul 2014 15:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level:
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, 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 kKOFntMq-EwH for <mmusic@ietfa.amsl.com>; Thu, 31 Jul 2014 15:11:24 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED3A1A0188 for <mmusic@ietf.org>; Thu, 31 Jul 2014 15:11:23 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so4879310qgf.35 for <mmusic@ietf.org>; Thu, 31 Jul 2014 15:11:22 -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=e8H3eMx7xYEpklu4HJ3KM45O4ZeCfkv57sNDayuTHfw=; b=ViwYTwUWlQtd7FUfkw7qgneZcKyw5GLpXo5Bg60mzImQ4saZmkwECm1GeNSKQwSGLc kcln6VHpzVuiT8qxg+EphxxIFbrIpLe7IeH+tTp0dDSWnyVxGiND3wY5Gp5Res9smoOo wOOaEBms0LmJHl860z7FdODIOORLTA0oZRKjU0ES8shJQKi/xAiUNXs2PvxPr7G37vgX siK/tbSfTYovY8/6cvgQZc/EBc+fDyZp32DZ/jmL4XeofAUnhuNlQa5sNtt1HSC8Cff2 MsUcw4hZ5NSLTuxOENE/K6rWKpY/xVYW5F3prdA/pnr5j52W6tBopYDLvR2XYDQ2PyLt f46A==
X-Gm-Message-State: ALoCoQmdktOzZYAwrtidzXKtyYSJTI8JtCJLvCS+lesolOnTlsqWpo/FP+UKbIFxkrD48MblaXWP
X-Received: by 10.224.131.71 with SMTP id w7mr1928800qas.91.1406844682369; Thu, 31 Jul 2014 15:11:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 15:11:02 -0700 (PDT)
In-Reply-To: <CAOJ7v-0d2BRm31kCDPyObHH1dG2WiPRk8bhODfQFvvfqWm0J1g@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>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Fri, 1 Aug 2014 00:11:02 +0200
Message-ID: <CALiegfn-YrHUYrgY6RFF+kgkkZ+ZNKXKgm6zkC0am1Mx4+Fp3w@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xlmoNobVw1DwiJff0iSOnWgjPOw
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: Thu, 31 Jul 2014 22:11:26 -0000

2014-07-31 21:08 GMT+02:00 Justin Uberti <juberti@google.com>om>:
>> Please, consider DTLS rather than secure media. Secure media is easy
>> to handle regardless where it comes from. DTLS is not as you need a
>> separate context for each tuple.
>>
>> If you mean that "the controlled must determine as selected pair that
>> on which it receives the *first* DTLS ClientHello, being a previously
>> validated ICE pair (so the source address is already known thanks to a
>> previous ICE transaction)" then that sounds better for me.
>
>
> 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).

Of course DTLS is low layer agnostic (so it can be carried over UDP,
TCP or whatever) but the fact is that it must be carried over a
"transport" (whatever a transport is). And when it is carried over UDP
it is needed that we create a separate DTLS session/context for each
remote address (IP:port). This is, you cannot open a UDP socket and
deliver there DTLS packets coming from different source addresses.
Instead you need to maintain a DTLS session/context per each source
address. So let's say that DTLS requires a separate transport for each
session (whichever a transport is a TCP connection, a UDP IP:port
tuple or any other data multiplexing solution).

For example, in the case of a ICE-Lite server this is what I expect:

1) The client sends ICE Binding requests and the server replies to
them (ok, a single UDP socket with responses sent to each source
address is ok).
2) At some point the client sends a Binding request with USE-CANDIDATE.
3) Upon that the server can safely determine that the remote address
is the source address from which that Binding request arrived, and can
*safely* ignore any DTLS or SRTP/SRTCP packet coming from any other
source address.

My concern is: is bullet 3) 100% true with the current set of
specifications plus the new proposed ICE mechanism? The fact is that
RFC 5764 states that a peer must be ready to receive "media" in any of
the offered ICE candidates, but that breaks everything, specifically
when it comes to DTLS (as said above that would require that the peer
creates a separate DTLS session for each different source address from
which "media" receipt is considered "valid").


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