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

Roman Shpount <roman@telurix.com> Thu, 02 April 2015 19:09 UTC

Return-Path: <roman@telurix.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 819C31A873D for <mmusic@ietfa.amsl.com>; Thu, 2 Apr 2015 12:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 tRivx-B8UByC for <mmusic@ietfa.amsl.com>; Thu, 2 Apr 2015 12:09:32 -0700 (PDT)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3411A1B3C for <mmusic@ietf.org>; Thu, 2 Apr 2015 12:09:32 -0700 (PDT)
Received: by ierf6 with SMTP id f6so76365016ier.2 for <mmusic@ietf.org>; Thu, 02 Apr 2015 12:09:32 -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:date :message-id:subject:from:to:cc:content-type; bh=vdxxncT2rs3GvDTD7Bs1TTr9MdfwQBIoGVra0a9kjA4=; b=bDK0PePp3VvZteBPYr5gvOjwOd5rqmZlXa0UzjRhUxlg8MMKw8dzh1Iw3TDRFmd98S 0VQcCl9+A4Hp69BIWCUDnQpLkhjnfj86Q6rEVuAEJBltUrrbvnqLWsU50C4kx0ValQUz qNOg7bAqnaFlUNLcDZuvXRNwdMJiRTTdU6IkuCZAFco4ziTYNkyL88kIMBCkdAbmOemg f3LAZulp+CnUQ04HLdb0npfPyj/V/+3iXSC8Il0yqr4d5GoVU5OV2NfgAg4hhndJmXUu LTazm1/BVIEoy7Z7p4to7PwFS3XUqnP0bmug8TIhyQe3H6y0iAq+0x2WP04WUblo2MpD NasQ==
X-Gm-Message-State: ALoCoQmLk2MA9PBCnrkPWTJ9Uhe/I2qfVx4eQCN5j6+MV35RaSTAzUMSvcovkeNHXpxvMCyQsXL8
X-Received: by 10.42.240.4 with SMTP id ky4mr81336109icb.70.1428001772103; Thu, 02 Apr 2015 12:09:32 -0700 (PDT)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com. [209.85.223.178]) by mx.google.com with ESMTPSA id 130sm3848610ioz.10.2015.04.02.12.09.30 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 12:09:30 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so85902319ied.1 for <mmusic@ietf.org>; Thu, 02 Apr 2015 12:09:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.107.36 with SMTP id gz4mr22492939igb.25.1428001769695; Thu, 02 Apr 2015 12:09:29 -0700 (PDT)
Received: by 10.36.110.141 with HTTP; Thu, 2 Apr 2015 12:09:29 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <CAD5OKxvGbJj_rRtLX7rjzkPZ6R8Wg92L2Y6gz1VtpV_etzaSiw@mail.gmail.com> <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>
Date: Thu, 02 Apr 2015 15:09:29 -0400
Message-ID: <CAD5OKxt31gQNqbZZ9+9sYn3tZnPfc88JLSxaWhR+aFcnSjy_Bg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="047d7b1117bf38b1d80512c2922a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/aWK31tja5bJcf2wyBfo8yCoueRg>
Cc: mmusic <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: Thu, 02 Apr 2015 19:09:34 -0000

Hi Christer,

On Thu, Apr 2, 2015 at 4:43 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Of course, whatever solution will be for the ICE case, it could also be
> applicable for the non-ICE case. But, the non-ICE case is easier, because
> we know a change in the 5-tuple will trigger a new DTLS connection - no
> matter if the fingerprint etc change or not.
>

We still have ambiguity here. The slides seem to imply that if the
fingerprint stayed the same but 5-tuple changed, this is the same DTLS
connection. The current proposed text says that this a new connection.


> One possible way would be to use the SDP connection attribute, with a
> "new" value. However, usage of the attribute is currently not allowed for
> SRTP-DTLS.
>
>
I would be fine with this. For instance new DTLS connection is only
established when connection "new" attribute is present or if fingerprint or
setup role changes. Connection "new", or fingerprint and setup role changes
are only allowed if underlying transport changes as well in such a way that
packets for the new connection can be demuxed from the packets for the old
DTLS connection based on the transport. This should be backwards compatible
and will address all of my issues.

Do you know why connection attribute was disallowed in SRTP-DTLS?


> There was also a suggestion to use SIP replace, but we need to define an
> SDP mechanism.
>

Agreed. This problem should be orthogonal to SIP signaling and should be
resolved within SDP.


> So, the question is: how do we know whether we are communicating with a
> new device?
>
> Again, for the non-ICE case I think we can use a 5-tuple change as
> indicator.
>
> For ICE, it seems like we can't use fingerprint, and we can't use ufrag.
> What about if BOTH the fingerprint and ufrag change?
>
>
The problem we are dealing with is when several devices use a
pre-provisioned site-wide certificate. For instance we typically use domain
certificates for SIPS on multiple servers and would like to use them for
DTLS as well. Since the certificate is the same, the fingerprint is the
same across multiple devices. When third party call control is used in such
deployment, the connection can move from one device to another, but the
fingerprint will stay the same. So we have a situation where fingerprint
stays the same, but ufrag changes. The problem is how to distinguish this
from ICE-restart, where fingerprint stays the same but ufrag changes. One
option is to examine the candidate list and apply see that it does not
intersect with the currently used candidates, but this seems extremely
brittle. The other option is to add something like connection new attribute
and to make sure new DTLS connection is set.

Regards,
_____________
Roman Shpount