Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 17 February 2017 13:46 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA391299F5; Fri, 17 Feb 2017 05:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 KBTTd8dj37ap; Fri, 17 Feb 2017 05:46:20 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F909129477; Fri, 17 Feb 2017 05:46:19 -0800 (PST)
X-AuditID: c1b4fb3a-f72d4980000021e0-bc-58a6fea9a035
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 64.B0.08672.9AEF6A85; Fri, 17 Feb 2017 14:46:17 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 14:46:15 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Roman Shpount <rshpount@turbobridge.com>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tbXVz?= =?utf-8?Q?ic-sctp-sdp-23:_(with_DISCUSS)?=
Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAAAH3gIAAE4kggAAVhACAAUmXgIAAF8fg
Date: Fri, 17 Feb 2017 13:46:13 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4C0069E5@ESESSMB209.ericsson.se>
References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <CABcZeBPPFUe-ZtW9Lt636OhoMH8ws2oVi94YQJeUQKXteC-XRg@mail.gmail.com> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <CABcZeBMpR+jE7jB4O=k_LPGhEBZPwUpo7vFnov4xvvhw_mYUAg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <CAD5OKxvtxyVn1r1pJhPCYMON-bTwWYjCvxts4K1ucgxaGFcCSg@mail.gmail.com> <55E6C40E-DF5E-4A61-8F02-D5B6E75A8D4C@kuehlewind.net>
In-Reply-To: <55E6C40E-DF5E-4A61-8F02-D5B6E75A8D4C@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7iu7Kf8siDK790bd4tW4+s8WK1+fY Ld5f0LWY8Wcis8WL6x+ZLc7vXM9kMXX5YxaL6093sThweEz5vZHVY8mSn0weLR8XsnpMftzG 7LH171+2ANYoLpuU1JzMstQifbsErowFR66zF2wwqHj4sqCBcYJ+FyMHh4SAiUTr8twuRi4O IYF1jBLbZ3axdzFyAjmLGSX6ZqqA1LAJWEh0/9MGCYsIxEv82dPMDGIzC0xgkjj4LxykV1ig iVFi3eIWVhBHRKCZUeL0hgcsIM0iAnkS5w/qgDSwCKhKHH2xgA3E5hXwlVgycSbUrmmsElP6 K0BsTgEniS+tv1hBbEYBMYnvp9YwQSwTl7j1ZD6YLSEgILFkz3lmCFtU4uXjf6wQtpLEotuf mUDWMgtoSqzfpQ/RqigxpfshO8RaQYmTM5+wTGAUnYVk6iyEjllIOmYh6VjAyLKKUbQ4tbg4 N93ISC+1KDO5uDg/Ty8vtWQTIzDuDm75bbWD8eBzx0OMAhyMSjy8BfuWRgixJpYVV+YeYpTg YFYS4TV4uyxCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6p Bsa1nTtZI+b57o/vZ1SXCfs5+fviSx5tkVGXnJkVFj6vUd1yzSNqquYcJ3HnyQpyfHf2sYc6 O0w3skn0WqgVy6Hf5ff/yqNXn8ybln1dlb7z94vI3c6SZxvZFcOszFWj1Lbyis7o+fqzykYx KDfNSo/rUOKOxrMNOUHSHZtnzFl25FDlEwUTTSWW4oxEQy3mouJEAPUautq3AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/c9DiQVtHePhGd5cPj-8RucvciEw>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "fandreas@cisco.com" <fandreas@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmusic-sctp-sdp@ietf.org>
Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?=
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 17 Feb 2017 13:46:22 -0000

Hi,

>Regarding the m= line (and I’m by far not expert here, so excuse me if that doesn't make sense), I guess for the ICE case you
>could also just use DTLS/SCTP, no? Wouldn't that resolve the oddity that you announce one thing and use another? And then 
>you can maybe have an additional tag for the transport used for the non-ICE cases…? Mainly wondering if there is maybe a clearer solution here?

That has been discussed, but the decision was to not do it within this draft.

There have been generic discussions about defining "ICE tags". But, that would be done as a separate task, and would cover other transports than this.

Regards,

Christer



> Am 16.02.2017 um 18:39 schrieb Roman Shpount <rshpount@turbobridge.com>om>:
> 
> Hi All,
> 
> I think a little bit of background will help here.
> 
> UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC 5245).
> 
> In ICE environments, during the nomination process, end points go through multiple candidate pairs, until the most preferred pair is found. During this selection process, data can be sent as soon as the first working pair is found, but the process still continues and candidate pairs can change while data is sent. Furthermore, if end points roam, for instance when mobile end point switches from mobile internet to wifi, end points will initiate an ICE restart, which will trigger a new nomination process between the new set of candidates and likely result in new nominated candidiate pair. When these candidates change, the same DTLS association continues to run, regardless whether it is running over udp or tcp candidate pair. Because of this, ICE tcp requires using RFC 4571 framing when sending data (https://tools.ietf.org/html/rfc6544#section-10.1). Otherwise, if TLS were used, a new TLS or DTLS session would be required every time candidate pair switches between tcp and udp candidates. In order to simplify transition between different underlying transports, DTLS is used for both udp and tcp candidates and TCP/DTLS/SCTP transport tag is defined to differentiate it from other protocols.
> 
> As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m= line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m= line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.
> 
> I hope this addresses your concern and explains why TCP/DTLS/SCTP is defined instead of TLS/SCTP.
> 
> Regards,
> _____________
> Roman Shpount
> 
> On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> Hi,
> 
>  
> 
> …
> 
>  
> 
> >The only question is what should appear in the m= proto line.
> 
>  
> 
> Even if nobody puts it in the m= line, I think it’s useful to keep it in the document, as it gives an overview how it’s realized etc.
> 
>  
> 
> It doesn’t cause any harm to keep it, and it’s “future proof” IF someone wants to use it without ICE at some point.
> 
>  
> 
> Regards,
> 
>  
> 
> Christer
> 
>  
> 
> 
> > Am 16.02.2017 um 16:02 schrieb Eric Rescorla <ekr@rtfm.com>om>:
> >
> > As Christer says. This design is optimized for making the media 
> > stack simpler, which using TLS here would not do.
> >
> > -Ekr
> >
> >
> >
> >
> > On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> > Hi,
> >
> > --------------------------------------------------------------------
> > --
> > DISCUSS:
> > --------------------------------------------------------------------
> > --
> >
> > >>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?
> > >>>
> > >> Because the way it is realized is by transporting SCTP on top of 
> > >> DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and transporting DTLS on top of TCP (defined in RFC 4571).
> > >
> > > I got this but DTLS is a mapping to use TLS with UDP because UDP 
> > > is an unreliable datagram transport. If you use TCP, you should use TLS. And rfc4571 is not a mapping of DTLS to TCP.
> >
> > The framing mechanism of RFC 4571 is used, with DTLS packets sent instead of RTP packets.
> >
> > Regards,
> >
> > Christer
> >
> >
> 
>  
> 
>