IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 03 April 2015 18:00 UTC

Return-Path: <christer.holmberg@ericsson.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 53C141ACE9C for <mmusic@ietfa.amsl.com>; Fri, 3 Apr 2015 11:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 vTavqRz2Il_Y for <mmusic@ietfa.amsl.com>; Fri, 3 Apr 2015 11:00:09 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B441ACE95 for <mmusic@ietf.org>; Fri, 3 Apr 2015 11:00:08 -0700 (PDT)
X-AuditID: c1b4fb3a-f79146d0000070a3-e8-551ed526c9cf
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B4.5B.28835.625DE155; Fri, 3 Apr 2015 20:00:06 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Fri, 3 Apr 2015 20:00:06 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact
Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA//2gvgD/+fe8oP/z6QIA/+ef7Tg=
Date: Fri, 03 Apr 2015 18:00:05 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D78A6B6@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> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se>, <CAD5OKxu+AVMK8z=JQ7MZ4xomkCzrZCqtiCFHSO=RYnCvDceNBw@mail.gmail.com>
In-Reply-To: <CAD5OKxu+AVMK8z=JQ7MZ4xomkCzrZCqtiCFHSO=RYnCvDceNBw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D78A6B6ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rlftqlyowde5lhZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgy9h2+zFLwWrvi9Jlm9gbG B6pdjJwcEgImEjf/TWaBsMUkLtxbz9bFyMUhJHCUUeLNon3sEM5iRonlU2cBZTg42AQsJLr/ aYM0iAioSvz9PpkJxGYW8JV4ueALM4gtLGAp8W3DFCaIGiuJ3glLmEHmiAh0MUq0TvsGNodF QEVi+0MOkBpeoN5b3TPB6oUE1rNLnGwrBrE5BQIldl3dDHYcI9Bx30+tgdolLtH0ZSUrxNEC Ekv2nGeGsEUlXj7+xwpRky+xePE8Roj5ghInZz5hmcAoMgtJ+ywkZbOQlEHEDSS+vL8NZWtL LFv4mhnC1pfofn+aCVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzASDu45bfVDsaD zx0PMQpwMCrx8C5IkQsVYk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAj EwenVAOj+6G95W7b7VZP89tpJzR70suwq1x9HEZcT0KsfM9cYAl4G2uu/T7y65TARdu/Tq06 JG/7UOKDwc7YS9Pyjx/5UNOUePTdfxENL5fZGmsOKsauZGhvvBPD472s7uf5HMm3GX4zA90X PH0z7d66uqtnbubIzp3D6x5U//X8fqVpnUF/NS1lPxXVKrEUZyQaajEXFScCAF0o1UWVAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/2WAoWiPO782spQ4-Tpkb6MIPksM>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Fri, 03 Apr 2015 18:00:12 -0000

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

v2.23.0 | Report a Bug | By Email