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

Roman Shpount <rshpount@turbobridge.com> Thu, 16 February 2017 17:39 UTC

Return-Path: <rshpount@turbobridge.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 192FE126CD8 for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 09:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level:
X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.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 gIgNvawb8tS9 for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 09:39:51 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 2ABCD12964F for <mmusic@ietf.org>; Thu, 16 Feb 2017 09:39:45 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id u25so22309879qki.2 for <mmusic@ietf.org>; Thu, 16 Feb 2017 09:39:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=novmeJZEqdT7T4qGb6hn5XvP6B9/EUgaDi3POVqubGQ=; b=uT4laqr46FNzEZHF1D0euHnynp1hx1nRJTGHq9OHjwSj/AdLxuHp6P4ujPjPxnbgvb zWFCJepGJcKRWEWT+3wzzo7CYRQV9GXKPWdv81eEPsvao6lxFf0aOLATJYEe4yJ31q8N C07k1KKwvFNypJ1pVVDKhakmRHBy1PJYWCk60=
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=novmeJZEqdT7T4qGb6hn5XvP6B9/EUgaDi3POVqubGQ=; b=KqaBvXX+BFKVIVfCEI035c6jQ1k9pxIWbZWyMGpDA1aLeHS71Ev1KNn14U1hBN5XO9 AQyY7HEkmYeEjX6SzfYgbn9pMs1MLyX993vK0+L374hhZVDWW+lDD1fANW7+ENuytNjE KsGKU9PoLSyD3BIkCGv039C9ZjdUwaYZwVlJpaCG+rn/MvsY57efLjYXB0ud7RMZT0YB aTH7DkERkAEoYhmEFGCHVpftClIsOn0CK4OznH56Cmsfq2+KVxHEI8S32IFtKta92GWc 7VH2796tqRRfSZI3GKeV0G4W0mcOd+IYGanSfdLe6R7bfaT5GXvwpUfpBafMt+g+xK2C ZDbQ==
X-Gm-Message-State: AMke39lipkOdotQ9QsTmzdlD5fd74+FpZQozK3H9lPiI9VwAiiob/WZi2FvCJ9bdrm2OLQ==
X-Received: by 10.55.122.130 with SMTP id v124mr3001389qkc.19.1487266784264; Thu, 16 Feb 2017 09:39:44 -0800 (PST)
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com. [209.85.220.173]) by smtp.gmail.com with ESMTPSA id o16sm3825294qkl.67.2017.02.16.09.39.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 09:39:43 -0800 (PST)
Received: by mail-qk0-f173.google.com with SMTP id p22so22530189qka.0; Thu, 16 Feb 2017 09:39:43 -0800 (PST)
X-Received: by 10.55.17.206 with SMTP id 75mr3122678qkr.34.1487266783165; Thu, 16 Feb 2017 09:39:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.131.66 with HTTP; Thu, 16 Feb 2017 09:39:42 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C00443C@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>
From: Roman Shpount <rshpount@turbobridge.com>
Date: Thu, 16 Feb 2017 12:39:42 -0500
X-Gmail-Original-Message-ID: <CAD5OKxvtxyVn1r1pJhPCYMON-bTwWYjCvxts4K1ucgxaGFcCSg@mail.gmail.com>
Message-ID: <CAD5OKxvtxyVn1r1pJhPCYMON-bTwWYjCvxts4K1ucgxaGFcCSg@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary=001a1146c91e4c04fd0548a94835
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/E6fwFSz3bS2oi0bOGhWeMex37Vs>
X-Mailman-Approved-At: Thu, 16 Feb 2017 13:55:57 -0800
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] =?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: Thu, 16 Feb 2017 17:53:24 -0000

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
> >
> >
>
>
>