Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Wed, 16 August 2017 00:10 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 A07211323C4 for <mmusic@ietfa.amsl.com>; Tue, 15 Aug 2017 17:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 PwmqijbN7qAr for <mmusic@ietfa.amsl.com>; Tue, 15 Aug 2017 17:10:01 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 543151323B0 for <mmusic@ietf.org>; Tue, 15 Aug 2017 17:09:58 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id p68so13925861ywg.0 for <mmusic@ietf.org>; Tue, 15 Aug 2017 17:09:58 -0700 (PDT)
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=gm0CMASDVghIaM/Jk1JA+vgAY7uJhOGdyzE1IaA6QSA=; b=XJ/obmqVr+41trhzl7dYnoDit638mn2U571lts2Cx5KljarJf9cEdzlfaJRvsPLZBU VeKmRRncI4MvKiGshN2PrrtvmzDxcHCAFklpCg/OOLeV3NcjGWGgPT9uoc4iRV47Ac0R sAfvK04At9m/ELhDHCuKbsRDTMZzp2B4C2/5nq43f8JallzzAg8R83GCvBPYqEeLGpcR CsgqxyuQJyVnGwOw/rURur6jHw9D5szo12HfFydFfDUE8S8BTCCE9ihTVTdTmEi+xayd 13iQE2zEnMmqwgV8+zYuQiQ+wCEyGgGmgmkIhpZ3bL72g4IVYgPQbCJx7uM7lno4Dl7h hVRQ==
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=gm0CMASDVghIaM/Jk1JA+vgAY7uJhOGdyzE1IaA6QSA=; b=hPJ1kzx+kmop6Yy1kbwsrYDz34s3ke7pX7yMHI1pLIBaDYf51H29fdjYScM+CCw9fG Y8YdPlKgTE+5VVCOics3m3mDlIHKOYAH7Uu4RfZNFiYgnVjL/kB8rQjaZ3bk5uqaYvKG 2LHtlmXRvULtWw9bXr0Wnkqt6WMvCtxToqNT+XRloXrcnwPSafYt5rq8gH5p0eydrHhL QgyM0mW3gXCVcW5Vz4KL5p83TM7EZQP7FIbSO9jPuagk9aZf/DRKyQj+tvB0Fy7oGukb ByKJfsJmhZuJTR8HQAMBtf2rgI3vMDG2bqYyp1dedtRCHm3xI8wrpppKuD/dOBx+WrBu +DdA==
X-Gm-Message-State: AHYfb5gE4xTB1UE8Yr5CZ6LFo7DQCTTRV/rnye5ki+iBZIxMaCE/IR6P EGagby7djj/bjsUQBL/IsGXVCFv8zIAC
X-Received: by 10.129.165.150 with SMTP id c144mr24124061ywh.19.1502842197591; Tue, 15 Aug 2017 17:09:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.218.130 with HTTP; Tue, 15 Aug 2017 17:09:16 -0700 (PDT)
In-Reply-To: <CAD5OKxtCkiUb-xiRcqkkXbYiP+vtCMURRp0qnqWo-zvZ+oYUKA@mail.gmail.com>
References: <CAD5OKxtCkiUb-xiRcqkkXbYiP+vtCMURRp0qnqWo-zvZ+oYUKA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 15 Aug 2017 17:09:16 -0700
Message-ID: <CABcZeBP+asjxvqVta4jKe2EnONkQ7OEWeuL+Z2GWkhNR8=F+zw@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, lemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>, Justin Uberti <juberti@google.com>, Cullen Jennings <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c128e3c576e160556d3b712"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/RPw7izg5pjbfHVws0VHZOddoll0>
Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 16 Aug 2017 00:10:04 -0000
+Juberti, Cullen On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount <roman@telurix.com> wrote: > Eric, > > Thank you for your comments. > > On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla <ekr@rtfm.com> wrote: > >> 1. Assuming I understand this document correctly, it conflicts with >> the guidance in JSEP. Specifically, S 4 says: >> >> No default value is defined for the SDP 'tls-id' attribute. >> Implementations that wish to use the attribute MUST explicitly >> include it in SDP offers and answers. If an offer or answer does not >> contain a 'tls-id' attribute (this could happen if the offerer or >> answerer represents an existing implementation that has not been >> updated to support the 'tls-id' attribute), unless there is another >> mechanism to explicitly indicate that a new DTLS association is to be >> established, a modification of one or more of the following >> characteristics MUST be treated as an indication that an endpoint >> wants to establish a new DTLS association: >> >> o DTLS setup role; or >> >> o fingerprint set; or >> >> o local transport parameters; or >> >> o ICE ufrag value >> >> This seems to say that if there is no tls-id attribute, then an ICE >> restart >> (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't >> incredibly clear on this point, but 5.7.3 seems to say that tls-id >> neeed not be present: >> >> * tls-id value, which MUST be set according to >> [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer >> and the tls-id value is different from that presently in use, >> the DTLS connection is not being continued and the remote >> description MUST be part of an ICE restart, together with new >> ufrag and password values. If this is an answer, the tls-id >> value, if present, MUST be the same as in the offer. >> >> I believe that the first sentence is in error, as we clearly >> can't have JSEP implementations requiring that tls-id be present. >> >> ... >> >> o If the remote DTLS fingerprint has been changed or the tls-id has >> changed, tear down the DTLS connection. This includes the case >> when the PeerConnection state is "have-remote-pranswer". If a >> DTLS connection needs to be torn down but the answer does not >> indicate an ICE restart or, in the case of "have-remote-pranswer", >> new ICE credentials, an error MUST be generated. If an ICE >> restart is performed without a change in tls-id or fingerprint, >> then the same DTLS connection is continued over the new ICE >> channel. >> >> I think the best interpretation of this is that if tls-id is not present >> (and hence unchanged) then ICE restart does not cause DTLS restart. >> This is also my memory of the consensus in RTCWEB. In any case, these >> two documents clearly must match. >> > > In regard to ICE ufrag change without tls-id we just have to make a > choice. Both choices are bad since they both cause things to break when one > side would initiate new DTLS association and another side would not. I > would agree that not starting DTLS association on ICE restart is slightly > safer. In any case, tls-id is needed to avoid this ambiguity. For anything > compliant with the new draft, tls-di must be present. > I agree that going forward we need this. My sense is that the JSEP version is better, but I've CCed Cullen and Justin to see what they think. > > 3. S 7.1 says: >> If DTLS is transported on top of a connection-oriented transport >> protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, >> >> This is incorrect, because none of these protocols ack all IP packets. >> >> >> all DTLS packets associated with a previous DTLS association MUST be >> acknowledged (or timed out) before a new DTLS association can be >> established on the same instance of that transport (5-tuple). >> >> More generally, I'm not sure that this is useful, because the >> required semantic isn't *acknowledged* but rather that the receiver >> can appropriately demux. So, say you just stop sending DTLS on >> connection A and start sending on B, what's the delimiter, given >> that you don't require close_notify here? IIRC, we just decided to >> punt on this whole thing. Does anyone try to have successive >> connections over the same transport, even when it's connection oriented? >> > > > Please see my comment to Mirja Kühlewind regarding this. This text is here > because somebody thought this draft should cover DTLS-over-SCTP. Since you > are one of the authors of RFC6083, can you suggest what is appropriate > here for DTLS-over-SCTP implementations? My preference would be not to > cover DTLS-over-SCTP in this draft and limit it to only DTLS over UDP or > TCP. > I agree with you. I don't think it's helpful to cover this here. Is this a question for the WG. > S 5.1. >> media session immediately (see [RFC8122]). Note that it is >> permissible to wait until the other side's fingerprint(s) has been >> received before establishing the connection; however, this may have >> undesirable latency effects. >> >> I agree that it's permissible, but why would you do this? This does >> not seem like helpful guidance. >> > > There are implementations that do this to avoid unauthenticated media. > Fair enough. S 10. >> Please do something about the "NEW" constructions. I literally had to >> pull these into ediff to know what had changed. That's not useful to >> people. I'm not a fan of this construction in general, but at minimum >> you need to explain what has changed. >> > > This is the best we came up with so far. If you have a better option, > please suggest. > Please provide a summary of what's changed. > >> S 9. >> Regardless of the >> previous existence of a DTLS association, the SDP 'setup' attribute >> MUST be included according to the rules defined in [RFC4145] and if >> ICE is used, ICE restart MUST be initiated. >> >> What is the rationale for this rule? >> > > This just restates the requirement from https://tools.ietf.org/ > html/rfc5245#section-12.5 . Not doing so breaks third party call control, > since in this case it is not known if this offer is intended for an > existing connection or to establish connection with a new end point. > A citation here would help. -Ekr > > Regards, > ______________ > Roman Shpount >
- [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mm… Eric Rescorla
- Re: [MMUSIC] Eric Rescorla's Discuss on draft-iet… Roman Shpount
- Re: [MMUSIC] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MMUSIC] Eric Rescorla's Discuss on draft-iet… Christer Holmberg
- Re: [MMUSIC] Eric Rescorla's Discuss on draft-iet… Christer Holmberg