Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 08 April 2015 17:01 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 502421B3485 for <mmusic@ietfa.amsl.com>; Wed, 8 Apr 2015 10:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 y64EjD2pUgXw for <mmusic@ietfa.amsl.com>; Wed, 8 Apr 2015 10:01:21 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459741B3482 for <mmusic@ietf.org>; Wed, 8 Apr 2015 10:01:21 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-04v.sys.comcast.net with comcast id DV0V1q0032VvR6D01V1L6z; Wed, 08 Apr 2015 17:01:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id DV1K1q00f3Ge9ey01V1Kvf; Wed, 08 Apr 2015 17:01:20 +0000
Message-ID: <55255EDF.3030903@alum.mit.edu>
Date: Wed, 08 Apr 2015 13:01:19 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>, Roman Shpount <roman@telurix.com>
References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <CAD5OKxum9Dt3vAxwAfa9LWiprSGkYHA1MrLspAee_-T8U=Ccvw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <CAD5OKxuj2TjgN2an9DywrQbBi38u38QSuuQb_eAoGU61DC8ENQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <CAD5OKxto0Cqmf9C1-Gg7O2+WQdaRwNGszKGQf4ccSUP7K9ZOEw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <CAD5OKxt4VCJGVLrzSib6HL+S8S90apwZ7_uRFygUfNeNddesFA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se>, <CAD5OKxu+AVMK8z=JQ7MZ4xomkCzrZCqtiCFHSO=RYnCvDceNBw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1255; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1428512480; bh=EwOvUJUvjrrx6uY2eCncA1nVGd8WjWXaWAex7cbtYLM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mFMXG0Ytc8pVUMNDIhiyNDXtCz/JA5M9S2ND0Nh95QxdLEuxMlhTAgleOX5Txa3Ar NIuzKc+nb34r+QGKWd2Je+Pknc1HrAIdKC5LMh5lrZBXSbXO95vTj4VOL+HUhwgbft WdzbAywBRt3fu+aWY0v5r9wYmB7a0ugaJq+wyZ7Gf4BNSFIW67v8xtMDc/iFA49QhR oyLERzcO+Yo0K2ukz5wOItSE1ETC7Blo7sdBH9BYiPFWJHpZ1BpNdPj0Msq19MD4jN aC/sda8gk0SUoAwK1/MbNyCWC7ub6TqCvDJ6ZeLhySPzrzKeKmyoEJ5X6ywi/xAYss W+Yx1g08Q6Llw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/UiZ0WF9Az6-0e4Vh44Lm9-GNCrE>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact
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: Wed, 08 Apr 2015 17:01:23 -0000

On 4/7/15 7:13 AM, Christer Holmberg wrote:
> Hi,
>
> Any comments on this from others? We need to solve it.
>
> Anyone has issues with allowing connection:new for SRTP-DTLS and
> SCTP-DTLS, and use that as a trigger to re-negotiate DTLS?

ISTM that this is being considered tactically. Maybe that is the best 
for now, but perhaps there should be consideration of a strategic 
approach to this as well.

What I mean is that this seems to be a back handed way to introduce 
multipath support into protocols (specifically DTLS) that don't support 
it. Perhaps multipath ought to be officially added to all the protocols 
that potentially need ICE, and then ICE would simply be one way to 
populate the paths.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 3. huhtikuuta 2015 21:00
> *To:* Roman Shpount
> *Cc:* mmusic@ietf.org; Paul Kyzivat
> *Subject:* Re: [MMUSIC] SCTP-SDP: Virtual Connection impact
>
> Hi,
>
> There are obviously "combinations" that are ambiguous, but you'll find
> that elsewhere too.
>
> Or, we simply define an order in which things (5-tuple changes,
> attribute values etc) are checked.
>
> Or, we do NOT use the attribute for non-ICE.
>
> Or, we do something else - but we DO need to solve this.
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
>
> ------------------------------------------------------------------------
>
> *From: *Roman Shpount <mailto:roman@telurix.com>
> *Sent: *‎03/‎04/‎2015 20:00
> *To: *Christer Holmberg <mailto:christer.holmberg@ericsson.com>
> *Cc: *Paul Kyzivat <mailto:pkyzivat@alum.mit.edu>; mmusic@ietf.org
> <mailto:mmusic@ietf.org>
> *Subject: *Re: [MMUSIC] SCTP-SDP: Virtual Connection impact
>
> On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg
> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>
> wrote:
>
>
> In any case, I don't think it would be too late to allow usage of the
> attribute for SRTP-DTLS. It would be a straight forward mechanism, which
> could be used both in the ICE and non-ICE case.
>
> I agree this is not too late to allow usage of the attribute for
> SRTP-DTLS or any other protocol running on top of DTLS, but there are
> several backward compatibility questions:
>
> First of all, should the DTLS connection be reset on the transport
> (5-tuple) change in the non-ICE case if fingerprint stayed the same and
> the connection attribute is not present? Current specification says that
> it should, so this needs to be preserved for backwards compatibility.
>
> Also, should sending connection attribute set to "existing" and changing
> the underlying transport be allowed? If backwards compatibility to be
> maintained, it should not.
>
> _____________
>
> Roman Shpount
>