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

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Apr 2017 19:09:44 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <[email-masked]>
Cc: [email-masked]; Ben Campbell <[email-masked]>
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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Apr 2017 19:10:55 +0000

And XXX stands for section 5.1 :)

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <[email-masked]>; mmusic (E-mail) <[email-masked]>
Cc: [email-masked]; Ben Campbell <[email-masked]>
Subject: SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Hi,

   answers is 'new'."

Comments?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ben Campbell <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] DTLS-SDP: TLS support added

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 10 Apr 2017 15:19:53 -0400

Hi All,

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.

The only exception I can this of would be ICE TLS candidates, if ICE TLS
candidates would ever get defined. ICE procedures would overwrite a lot of
what we are going to define here, including how fingerprints are specified
and matched and when TLS connections are established. I believe this is
something that should be defined in ICE TLS document and update this
document, if necessary.

Regards.

_____________
Roman Shpount

On Mon, Apr 10, 2017 at 3:10 PM, Christer Holmberg <
[email-masked]> wrote:

> *From:* Christer Holmberg
> *Sent:* 10 April 2017 22:10
> *To:* Christer Holmberg <[email-masked]>; mmusic (E-mail)
> <[email-masked]>
> *Cc:* [email-masked]; Ben Campbell <[email-masked]>
> *Subject:* SDP connection attribute optional [was: DTLS-SDP: TLS support
> added]
>
>
>
> Hi,
>
>
>
>    “When an offerer generates an 'm' line that uses TCP, it SHOULD provide
> a
>
>    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”.
>
>
>
>    “The default value of the connection attribute in both offers and
>
>    answers is 'new'.”
>
>
>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Christer Holmberg
> *Sent:* 09 April 2017 10:15
> *To:* mmusic (E-mail) <[email-masked]>
> *Cc:* [email-masked]; Ben Campbell <[email-masked]>
> *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:
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Apr 2017 19:32:05 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:
And XXX stands for section 5.1 :)

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; mmusic (E-mail) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ben Campbell <[email-masked]<mailto:[email-masked]>>
Subject: SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Hi,

   “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”.

   answers is 'new'.”

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

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:

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?

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Apr 2017 19:40:53 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 10 April 2017 22:32
To: Roman Shpount <[email-masked]>
Cc: [email-masked]; mmusic (E-mail) <[email-masked]>; Ben Campbell <[email-masked]>
Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Hi,

Regards,

Christer

From: Christer Holmberg

Hi,

   answers is 'new'.”

Comments?

Regards,

Christer

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 10 Apr 2017 15:49:37 -0400

On Mon, Apr 10, 2017 at 3:40 PM, Christer Holmberg <
[email-masked]> wrote:

> *“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'.”*
>

If third party call control is used it is not known that the same end
points are communicating. Because of this it is never quite known what is
supported by the remote end point when offer is generated. Because of this
I would prefer this language to say that "Offerers should not make
assumptions about the support of SDP 'tls-id' attribute and MUST always use
SDP 'connection' attribute. To avoid ambiguity, answerers MUST always use
SDP 'connection' attribute as well.  NOTE: As defined in [RFC4145], if the
SDP 'connection' attribute is not explicitly present, the implicit default
value is 'new'."

Regards,
_____________
Roman Shpount