IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 10 April 2017 19:10 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 A2877129AB6; Mon, 10 Apr 2017 12:10:33 -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 ANMVubtpVZae; Mon, 10 Apr 2017 12:10:31 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 4B121129AD2; Mon, 10 Apr 2017 12:10:25 -0700 (PDT)
X-AuditID: c1b4fb2d-d97ff700000033e1-0d-58ebd89e88cd
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id F2.DF.13281.E98DBE85; Mon, 10 Apr 2017 21:10:23 +0200 (CEST)
Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:10:22 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "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: AdKyNUrA9tbRCyqiRcKnD0Le75fq9gAATjfw
Date: Mon, 10 Apr 2017 19:10:55 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7n+78G68jDDY2aVrM7zzNbnF+53om i6nLH7M4MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBlLX1xiKrhSXtF4rIO1gXFTZhcj J4eEgInEz+YlrF2MXBxCAusZJd7M3csIkhASWMIo8fWbaxcjBwebgIVE9z9tkLCIgLpE6+Y+ VhCbWSBcYs6bM2C2sECwxMPOqawQNSESR9dPZYewjSQ+/v4IFmcRUJW4/+opWJxXwFdi/q6f UKt8JW5PO80GYnMK+EmcfTERLM4oICbx/dQaJohd4hK3nsxngrhZQGLJnvPMELaoxMvH/1gh bCWJFdsvMULU50t8etTPCLFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaG sc8ceMyELL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmB8HdzyW3cH4+rXjocYBTgY lXh4H/S/jhBiTSwrrsw9xCjBwawkwnu1AyjEm5JYWZValB9fVJqTWnyIUZqDRUmc12HfhQgh gfTEktTs1NSC1CKYLBMHp1QDY32l35rm/kPn9a32X32fzDhhauWqd0npt3Z9+W5rPbmGWTVg /wuGR59V/zRk2bXregkYHjINPhNw+rz7kYC9fM5+qfZ3KxYnr5/8v7Hnp/2ZFeGly1tr8yNP fj04S/uMYsqLu76ZdvlHum6d7rOryBaKXPZrw3kJxe3+6fvW/99/eq3PxuObcpRYijMSDbWY i4oTAeX98M+rAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/uEwgWRgiJ1CNmcmEfCfJVyN0JfY>
Subject: Re: [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:10:34 -0000

And XXX stands for section 5.1 :)

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <christer.holmberg@ericsson.com>; mmusic (E-mail) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Hi,

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.

Comments?

Regards,

Christer


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<mailto:mmusic@ietf.org>>
Cc: mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>; Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>
Subject: [MMUSIC] DTLS-SDP: TLS support added

Hi,

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:

https://github.com/cdh4u/draft-dtls-sdp/pull/26

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.

Regards,

Christer

v2.23.0 | Report a Bug | By Email