[MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 10 April 2017 19:09 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 49F7A129AC5; Mon, 10 Apr 2017 12:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YlX4l_1FMao7; Mon, 10 Apr 2017 12:09:16 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net []) (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 8CBF6127601; Mon, 10 Apr 2017 12:09:15 -0700 (PDT)
X-AuditID: c1b4fb30-abffb70000006667-e6-58ebd85710b3
Received: from ESESSHC018.ericsson.se (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 14.56.26215.758DBE85; Mon, 10 Apr 2017 21:09:13 +0200 (CEST)
Received: from ESESSMB102.ericsson.se ([]) by ESESSHC018.ericsson.se ([]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:09:11 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic (E-mail)" <mmusic@ietf.org>
CC: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, Ben Campbell <ben@nostrum.com>
Thread-Topic: SDP connection attribute optional [was: DTLS-SDP: TLS support added]
Thread-Index: AdKyNUrA9tbRCyqiRcKnD0Le75fq9g==
Date: Mon, 10 Apr 2017 19:09:44 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E1CCESESSMB102erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdQzfyxusIgw9TdC3md55mtzi/cz2T xdTlj1kcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxt6z8xFizPrjiyvImxgXFFXBcj J4eEgInEj7W9jF2MXBxCAusZJdpfTGGBcJYwSsx5v4m1i5GDg03AQqL7nzZIg4hArMSOnl52 EJtZIFxizpszYCXCAr4S6+fxQZSESBxdP5UdwtaTuDS1jRnEZhFQlXi18QkTiM0LVP5nxRtG EJtRQEzi+6k1TBAjxSVuPZnPBHGbgMSSPeeZIWxRiZeP/7FC2EoSK7ZfYoSoz5eYdnMiI8RM QYmTM5+wTGAUmoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIHxcnDLb4MdjC+fOx5iFOBgVOLhfdD/OkKINbGsuDL3EKME B7OSCK/eIaAQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9FyKEBNITS1KzU1MLUotgskwcnFIN jCVnvu5UknLg7rfyNhVxzfwfsNC8+a+uQUzsTicXrT3LlY/9dHW2+HOm7NCTM+/5dk5UCuxv mlXCGt4hpPWkhn3R59Iz9mu6Jid87gqyqHU5/E/7QvTZ0xxP5s/SPycalX9y4fYFX4SaFP+1 ROSGzeVRd8x9HBvWfu8Lu+n/892pwudigpPllFiKMxINtZiLihMBDSqLQ5MCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/g7O716LnuC5bHEWxxgIKu7fW2jc>
Subject: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]
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, 10 Apr 2017 19:09:18 -0000


Section XXX of RFC 4145 says:

   "When an offerer generates an 'm' line that uses TCP, it SHOULD provide a
   connection attribute for the 'm' line unless the application using
   the 'm' line has other means to deal with connection reestablishment."

Now, if both endpoints support the 'tls-id' attribute, that would be "other means".

However, section of RFC 4145 says:

   "The default value of the connection attribute in both offers and

   answers is 'new'."

So, I think we need to say something. Either:

1)      If both endpoints support tls-id, they don't need to care about the connection attribute (or the default value in case the attribute is not present); OR

2)      We mandate that the connection attribute is present, with an 'existing' value, whenever an existing connection is to be maintained.

Option 2) seems most safe, i.e., we continue using the 'connection' attribute and its semantics even if both endpoints support the 'tls-id' attribute.




From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: [MMUSIC] DTLS-SDP: TLS support added


Based on the decision in Chicago to allow usage of the SDP 'dtls-id' attribute also for TLS connections, I have created a pull request:


Note that the name of the attribute has now been changed to 'tls-id'.

The approach I've taken is: rather than talking about both DTLS and TLS throughout the document, I've basically added a section describing the TLS-specific considerations - mainly regarding the interaction with the SDP 'connection' attribute.

Now, I think we do need some text on WHY we also cover TLS connections since, as far as creating new connections is concerned, the 'connection' attribute can be used. We know that it would be needed for draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been adopted yet, so I don't think we can use it as justification at this point?

Note that this pull request does NOT include any of the changes to be done based on the gen-art/sec-dir reviews. I have updated the 4572-update reference, though.