Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
Christer Holmberg <christer.holmberg@ericsson.com> Fri, 25 August 2017 11:05 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 20FC6132713; Fri, 25 Aug 2017 04:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KY5vVq4Cm77y; Fri, 25 Aug 2017 04:05:16 -0700 (PDT)
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 73F9C132707; Fri, 25 Aug 2017 04:05:15 -0700 (PDT)
X-AuditID: c1b4fb3a-617ff700000051a3-fc-59a0046994d8
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.DA.20899.96400A95; Fri, 25 Aug 2017 13:05:13 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 25 Aug 2017 13:05:13 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>, Roman Shpount <roman@telurix.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-mmusic-dtls-sdp@ietf.org" <draft-ietf-mmusic-dtls-sdp@ietf.org>, "mmusic-chairs@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>
Thread-Topic: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
Thread-Index: AQHTFiJ4U9eZ+Q1EiEiv1X0BiX5SzqKF+f8AgA8PuoA=
Date: Fri, 25 Aug 2017 11:05:12 +0000
Message-ID: <D5C5DFA4.20425%christer.holmberg@ericsson.com>
References: <CAD5OKxtCkiUb-xiRcqkkXbYiP+vtCMURRp0qnqWo-zvZ+oYUKA@mail.gmail.com> <CABcZeBP+asjxvqVta4jKe2EnONkQ7OEWeuL+Z2GWkhNR8=F+zw@mail.gmail.com>
In-Reply-To: <CABcZeBP+asjxvqVta4jKe2EnONkQ7OEWeuL+Z2GWkhNR8=F+zw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_D5C5DFA420425christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUyM2K7q24my4JIg7bpUhb/J85ntVjx+hy7 xfsLuhYdk9ksZvyZyGyxdaqQxfmd65kspi5/zGIx48JUZgdOjym/N7J6LNhU6rFkyU8mj8mP 25g9bk0pCGCN4rJJSc3JLEst0rdL4Mo4e34de8G8NYwVl7vmsjUwXpnA2MXIwSEhYCJx5X5h FyMXh5DAEUaJ+TN7GCGcJYwS61cdYQEpYhOwkOj+p93FyMkhIuAscaLtBRtIDbPATiaJNWtW sIAkhAVyJK6cfMsGUZQrcXJ9DzOEbSXRcOkEWJxFQFViz5ROMJtXwFri/5qHYL1CAtMZJab9 lgCxOQUCJW6/mcUOYjMKiEl8P7WGCcRmFhCXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rCB3igro Sbzb7wnxl6LE8n45iM4EiQmtBxkhtgpKnJz5hGUCo+gsJENnISmbhaQMIq4ncWPqFDYIW1ti 2cLXzBC2rsSMf4egaqwl3j47xIqsZgEjxypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwAg/ uOW31Q7Gg88dDzEKcDAq8fDyvZofKcSaWFZcmXuIUYKDWUmEVwSYHoR4UxIrq1KL8uOLSnNS iw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgTH/g62Cz5B+DQc2yTRkctokLy1// //RbUmnuDYUZbqZv9lVcaW+ZvaejIof1HfNkcb0e2+XmXjWznJpF1t57ueeQL+vqM1um+kwy j5/NOtP4i4FolTVTdng5w4sbRlIbI3aYrpX+mLNzzb9Ntw8arZ+y7e6vc8yeh+IfcWo1uff+ dw18t3C5ghJLcUaioRZzUXEiACpwXxrsAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/5hD4ssjglhz5FP1nWVQxI8RgAEA>
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: Fri, 25 Aug 2017 11:05:19 -0000
Cullen/Justin, do you have some input on this? Regards, Christer From: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> Date: Wednesday 16 August 2017 at 03:09 To: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> Cc: "iesg@ietf.org<mailto:iesg@ietf.org>" <iesg@ietf.org<mailto:iesg@ietf.org>>, "draft-ietf-mmusic-dtls-sdp@ietf.org<mailto:draft-ietf-mmusic-dtls-sdp@ietf.org>" <draft-ietf-mmusic-dtls-sdp@ietf.org<mailto:draft-ietf-mmusic-dtls-sdp@ietf.org>>, "mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>" <mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>>, Flemming Andreasen <fandreas@cisco.com<mailto:fandreas@cisco.com>>, "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>, Justin Uberti <juberti@google.com<mailto:juberti@google.com>>, Cullen Jennings <fluffy@cisco.com<mailto:fluffy@cisco.com>> Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>> Resent-To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> Resent-Date: Wednesday 16 August 2017 at 03:10 +Juberti, Cullen On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote: Eric, Thank you for your comments. On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla <ekr@rtfm.com<mailto: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