Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
Christer Holmberg <christer.holmberg@ericsson.com> Mon, 28 August 2017 10:12 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 AE38B13202D for <mmusic@ietfa.amsl.com>; Mon, 28 Aug 2017 03:12:30 -0700 (PDT)
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, 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] 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 7q_hcjEv65tH for <mmusic@ietfa.amsl.com>; Mon, 28 Aug 2017 03:12:28 -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 A797B1201F8 for <mmusic@ietf.org>; Mon, 28 Aug 2017 03:12:27 -0700 (PDT)
X-AuditID: c1b4fb3a-5ffff700000051a3-b7-59a3ec88a4bd
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.62.20899.88CE3A95; Mon, 28 Aug 2017 12:12:25 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 12:12:24 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Adam Roach <adam@nostrum.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts
Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKZooIA
Date: Mon, 28 Aug 2017 10:12:23 +0000
Message-ID: <D5C9C7CB.20655%christer.holmberg@ericsson.com>
References: <f353ad39-4ee5-4661-8e99-7fab6e394e91@nostrum.com>
In-Reply-To: <f353ad39-4ee5-4661-8e99-7fab6e394e91@nostrum.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.16]
Content-Type: multipart/alternative; boundary="_000_D5C9C7CB20655christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7jW7nm8WRBhtu8ljs+buI3WLq8scs DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAldG9+N25oLFVRXbF/1ibWDsSu5i5OCQEDCR eDHTv4uRi0NI4AijxObOiUwQzhJGifOnljCCFLEJWEh0/9MGMUUE3CTmnUoHMYUFDCVOnGHp YuQEihpJXD7+gBnG3vFtLzuIzSKgKjGhYR1YnFfAWmLFhVlgtpCAncSZO29YQWxOAXuJyVNP gNUzCohJfD+1hgnEZhYQl7j1ZD6YLSEgILFkz3lmCFtU4uXjf6wgJ4gK6Em82+8JEVaU2Hm2 nRmiNUGire0y1FpBiZMzn7BMYBSZhWTqLCRls5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45Swj hG0tcX7iJUZkNQsYOVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbZwS2/rXYwHnzueIhR gINRiYf36bPFkUKsiWXFlbmHGCU4mJVEeCtfAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7 ECEkkJ5YkpqdmlqQWgSTZeLglGpgLF2dHlV8dY/oBAFd8y1VVomT7qvO2cpwmeNZsvnf5mdz vxuWnbaPLGGZZCN/ctaRqUdehvpuUVCc8DNPfKuChfiJcyurb6lbrGJYuiP84b8529p+Bs77 Wb/Gq7/7luCVnRPDRcs21hZIeO93TOiIl886+XIl++uLX+OiMowVJs+Id6n1f/v1qRJLcUai oRZzUXEiAKTiruWvAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/MyDJEQwurtp5QOsBKWf7He_o6XI>
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
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: Mon, 28 Aug 2017 10:12:31 -0000
Hi Adam, I don’t know if you left the following out by mistake, if you assumed the issue had been solved, or if I simply missed it, but just in case: >DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute >values, and the combination of both values identify the DTLS association." > >JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as >in the offer.” As I said earlier (and I think others who have commented agree) this needs to be fixed in JSEP. Regards, Christer From: mmusic <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>> on behalf of "adam@nostrum.com<mailto:adam@nostrum.com>" <adam@nostrum.com<mailto:adam@nostrum.com>> Date: Friday 25 August 2017 at 23:30 To: "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>> Subject: [MMUSIC] DTLS-SDP and JSEP Conflicts MMUSIC -- [I will be posting a separate message to RTCWEB directing interested parties to discuss this issue on the MMUSIC mailing list] During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some conflicts between the procedures in DTLS-SDP and JSEP were identified. This note is an attempt to summarize them. I have also made an initial proposal, for each conflict, regarding which document needs to change, in and which way. Issue 1 (quoting EKR), which raises a couple of additional sub-issues: 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 need 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. My observations/recommendations: 1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP needs to be removed so as to enable interoperation with non-JSEP implementations. 2. (Issue 1b) Additionally the final sentence of that bullet ("If this is an answer, the tls-id value, if present, MUST be the same as in the offer") conflicts with the definition of tls-id ("the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association"). In this case, the DTLS-SDP document would appear to be correct (the fact that the two parties choose different IDs is integral to the mechanism's design), so JSEP needs to change. 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change. Issue 2 (quoting EKR): 2. S 4 says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- id' attribute is 'IDENTICAL', which means that the attribute value must be identical across all media descriptions being multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. This is not actually what JSEP requires: different categories. To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, repeating the guidance from [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes I suspect this is old text. (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, while DTLS-SDP does not. This is a largely aesthetic decision (although the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more closely tracks consensus anyway). /a
- [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Taylor Brandstetter
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Bernard Aboba
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Paul Kyzivat
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg