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

Eric Rescorla <ekr@rtfm.com> Thu, 16 February 2017 15:19 UTC

Return-Path: <ekr@rtfm.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 F0CEA129D03 for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 07:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 Q85MNzlZwuZ4 for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 07:19:25 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 77872129D08 for <mmusic@ietf.org>; Thu, 16 Feb 2017 07:19:23 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id v200so9520153ywc.3 for <mmusic@ietf.org>; Thu, 16 Feb 2017 07:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P/dVOxwyXemFBZLYduYlrLR2A5UrtiClCNlOAlJTrEE=; b=srSKsFG7Zp7aU+C5GceSshTX5915DyIsFG+2CHd5KE84Sgk6HApHXsXCLG9ogeWL4T TbKzDsmWzWVvFVdaspvm3pxROZmDYmseedOtAlpUJ0hE+MCpm3BmSRYwg0xlFpB4xikp HXTKTxjU7P8X+qFw9Pqbgy1ivSUJ3AggXZq9r6vPyU//bndlfqEyAyLdfYLE9kmAPdGy u6bizrtlM+YujZEbutF4Inu2ejuZ61UejNNEjC5fzMLKd6IHPPvxgQEPx3AfWSn5cmkP wPujBqyFqO/0GoD6NooBZ/yYJK9vnMK6l21IFVUUTZDZaDftXmVTr/nYqp6T6YM/dAZ6 VNPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P/dVOxwyXemFBZLYduYlrLR2A5UrtiClCNlOAlJTrEE=; b=VevgSkjrgyHDxyU/SqmKzU263T+WVhN4YhaMSnhYdHewd+rN9Vu3JQvBLdOpgLOqKZ zAEW1kaOkogieGq1TvSNRurWBBiO8prDcAWw/5bwouTErIShZYmCiai59Vn0hoBCXgfl KRW+AP2QlwGhSIPXwSoyHcT5UlyfM10yYEgV1ZSBnDuzNKlZG4lLU+j+DsKFaeIvBpR5 aR6LLHjU1lyNaglkUv1vYECQJP6NsSTKpK2rXQ/t2ExI6vGx41LzfrkV+Gt0wpF5o22l k086tuo6i/4q0ytxsmOkVDCMDEXCgmPaS8ccQ7CUEnKLGzCa+/Gy8xH1haR9SejyFEn4 VA4w==
X-Gm-Message-State: AMke39m58wCm90lRPlx4Ni0dPnLm5wjMEf2Yult4foRWfUN6ztzo1MZCmlmH11qyRxCl+ICag8qJdirAkmTBOA==
X-Received: by 10.129.137.129 with SMTP id z123mr2029065ywf.327.1487258362702; Thu, 16 Feb 2017 07:19:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.224.131 with HTTP; Thu, 16 Feb 2017 07:18:42 -0800 (PST)
In-Reply-To: <CABcZeBMpR+jE7jB4O=k_LPGhEBZPwUpo7vFnov4xvvhw_mYUAg@mail.gmail.com>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 16 Feb 2017 07:18:42 -0800
Message-ID: <CABcZeBMHDcyFLEv=YaD+xSOiWgLzZc8+6cRyxB5CnFhdMW8bMw@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="94eb2c06bf386614900548a75243"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ePrasI0UYhZXnyRgRsrZqu-D-tk>
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>, Christer Holmberg <christer.holmberg@ericsson.com>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmusic-sctp-sdp@ietf.org>
Subject: Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)
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: Thu, 16 Feb 2017 15:19:27 -0000

P.S. I am very familiar with the Firefox implementation of this, and I can
tell you
that it would be very painful to use TLS when TCP was used and DTLS when
UDP is used, and the modest network overhead for using DTLS is, IMO,
a better choice.

-Ekr



On Thu, Feb 16, 2017 at 7:12 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Thu, Feb 16, 2017 at 7:05 AM, Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net> wrote:
>
>> By making the transport stack overly complicated? That really gives me
>> headache…
>>
>
> It doesn't make the transport stack overly complicated. It makes it
> modular. The way
> that this works is that the transport system (typically ICE) provides a
> generic
> transport that appears to be a datagram transport, even if it's actually
> TCP, and
> so the thing on top of it just acts as it if were datagram. This is
> necessary because
> you may actually switch between TCP and UDP during the life of the
> connection.
>
>
> But let me get back the the other question you asked: Is the TCP variant
>> really needed here? Is this implemented or are there any plans to implement
>> that?
>>
>
> I think you misunderstood me. People absolutely intend to carry this data
> over
> TCP (it's basically the best scenario when you have (a) a centralized
> service
> and (b) a UDP-blocking Firewall). We in fact implement this with Firefox.
> The only question is what should appear in the m= proto line.
>
> -Ekr
>
>
>> Mirja
>>
>>
>>
>> > Am 16.02.2017 um 16:02 schrieb Eric Rescorla <ekr@rtfm.com>:
>> >
>> > 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
>> >
>> >
>>
>>
>