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

I suggest to add something like the following, to make sure it’s clear:

“An offerer and answerer MUST use the SDP 'connection' attribute even if it
 is known that both support the SDP 'tls-id' attribute.
  NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is not explicitly
  present, the implicit default value is 'new'.”

Regards,

Christer

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 10 April 2017 22:32
To: Roman Shpount <roman@telurix.com>
Cc: mmusic-chairs@ietf.org; mmusic (E-mail) <mmusic@ietf.org>; Ben Campbell <ben@nostrum.com>
Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Hi,

>A think for all the normal cases m=connection attribute must be specified when >TLS is used. There is no way to know if remote party supports tls-id when offer >is sent, so if m=connection is not specified, then it is unclear how the offer is >going to be processed.

I was thinking more about subsequent offers and answers, when it is known whether both endpoints support tls-id.

But, I am fine to keep using the connection attribute also in that case, together with tls-id. So, if the connection attribute is not present, is shall be interpreted as ‘new’, according to RFC 4145.

Regards,

Christer

On Mon, Apr 10, 2017 at 3:10 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
And XXX stands for section 5.1 :)

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; 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: 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

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic