Subject: Re: [MMUSIC] SCTP-SDP: SDP connection attribute considerations

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2014 15:41:30 -0500

On 11/27/14 3:54 PM, Christer Holmberg wrote:
> Hi,
>
> For SCTP-SDP, the general idea is that the SDP connection attribute is
> used in the same way as for TCP,
>
> i.e. an attribute ‘new’ value means that a new SCTP association shall be
> created.
>
> For ‘SCTP’ there should be no issues. The procedures are more or less
> identical as for TCP (the difference being that both endpoints initiate
> the SCTP association).
>
> ---
>
> For ‘DTLS/SCTP’, there are some decisions to make:
>
> -If the transport layer protocol is UDP, I assume a ‘new’ value will not
> automatically re-establish the DTLS connection – only the SCTP
> association will be re-established.

Why?

If some part of the 5-tuple changes then it will be *necessary* to 
establish a new DTLS connection. Even if the 5-tuple doesn't change, 
aren't there going to be cases where you want to reestablish the DTLS?

> -However, if the transport layer protocol is TCP, does that mean that a
> ‘new’ value will mean that BOTH the TCP connection, AND the SCTP
> association, will be re-established? IF the TCP connection is also
> re-established, then I guess the DTLS connection will be re-established.

There are all consequences of using the same atttribute to control 
independent behavior at two different layers of the protocol stack.

The *right* fix would be to have one attribute for the DTLS behavior and 
another for the SCTP behavior.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 08:56:49 +0000

Hi,

>> i.e. an attribute 'new' value means that a new SCTP association shall 
>> be created.
>>
>> For 'SCTP' there should be no issues. The procedures are more or less 
>> identical as for TCP (the difference being that both endpoints 
>> initiate the SCTP association).
>>
>> ---
>>
>> For 'DTLS/SCTP', there are some decisions to make:
>>
>> -If the transport layer protocol is UDP, I assume a 'new' value will 
>> not automatically re-establish the DTLS connection - only the SCTP 
> If some part of the 5-tuple changes then it will be *necessary* to establish a new DTLS connection.

Correct - I should have clarified that I am talking about the case there the 5-tuple does not change.

> Even if the 5-tuple doesn't change, aren't there going to be cases where you want to reestablish the DTLS?

Maybe there are. But, this is related to the question whether you need to signal that in SDP.

>> -However, if the transport layer protocol is TCP, does that mean that 
>> a 'new' value will mean that BOTH the TCP connection, AND the SCTP 
> There are all consequences of using the same atttribute to control independent behavior at two different layers of the protocol stack.

Yes.

> The *right* fix would be to have one attribute for the DTLS behavior and another for the SCTP behavior.

We could for sure define an SDP "sctp-setup" attribute, IF people see a need for it.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2014 12:07:30 -0500

> Maybe there are. But, this is related to the question whether you need to signal that in SDP.

If the fingerprint changes, then doesn't the DTLS need to be 
renegotiated? (Regardless of whether 'new' is specified.)

> We could for sure define an SDP "sctp-setup" attribute, IF people see a need for it.

ISTM the issue is about there being multiple *layers* that are being 
negotiated, rather than specifically what protocol those layers are.

So the only time you need to specify this is when there is ambiguity 
about which layer it might be.

Perhaps we could define an extension to a=setup and a=connection. E.g.

          setup-attr           =  "a=setup:" role [ " " proto]
          role                 =  "active" / "passive" / "actpass"
                                  / "holdconn"

(where proto is as defined in SDP). When absent it would default to the 
entire proto field from the m-line. Other valid values would be prefixes 
of the proto in the m-line. So, for the case at hand, we could have
	m=application 12345 DTLS/SCTP webrtc-datachannel
	a=setup:active DTLS/SCTP
	a=setup:passive DTLS

That would be entirely equivalent to:

	m=application 12345 DTLS/SCTP webrtc-datachannel
	a=setup:active
	a=setup:passive DTLS

And in general we could have:

	m=foo 12345 A/B/C/D fmt1 fmt2 ...
	a=setup:<direction> A/B/C/D
	a=setup:<direction> A/B/C
	a=setup:<direction> A/B
	a=setup:<direction> A

And do the same thing for a=connection.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 17:23:10 +0000

Hi,

> If the fingerprint changes, then doesn't the DTLS need to be renegotiated? (Regardless of whether 'new' is specified.)
>
>>>> -However, if the transport layer protocol is TCP, does that mean 
>>>> that a 'new' value will mean that BOTH the TCP connection, AND the 
>>>> SCTP association, will be re-established? IF the TCP connection is 
>>>> also re-established, then I guess the DTLS connection will be re-established.
>>>
> ISTM the issue is about there being multiple *layers* that are being negotiated, rather than specifically what protocol those layers are.
>
> So the only time you need to specify this is when there is ambiguity about which layer it might be.
>
> (where proto is as defined in SDP). 

That would assume that the protocol you want to control is actually explicitly part of the SDP proto field value.

> When absent it would default to the entire proto field from the m-line. Other valid values would be prefixes of the proto in the m-line. 
> So, for the case at hand, we could have

It's an interesting idea, but I think it would be very complicated.

Also keep in mind that DTLS-SRTP (and other protocols using DTLS) already use the setup attribute both for the connection protocol (if present) establishment direction and TLS role detection.

Also keep in mind that, for the SCTP association, we don't need to indicate who is active and who is passive, as both endpoints try to establish the SCTP association.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2014 12:50:59 -0500

> It's an interesting idea, but I think it would be very complicated.

Syntactically it is pretty simple.
Conceptually it is a bit complex because it makes you really think about 
the protocol layering.

> Also keep in mind that DTLS-SRTP (and other protocols using DTLS) already use the setup attribute both for the connection protocol (if present) establishment direction and TLS role detection.

Hmm. I guess it is true that what I have proposed means that in the case of

	m=audio 12345 DTLS/SRTP ...
	a=setup:active

Really applies to the SRTP over the DTLS, not the DTLS itself, and to 
refer specifically to the DTLS it would be necessary to override the 
default, with:

	m=audio 12345 DTLS/SRTP ...
	a=setup:active DTLS

Possibly that could be resolved by stating that the default for the 
proto is the longest prefix of the proto in the m-line for which a=setup 
is defined.

> Also keep in mind that, for the SCTP association, we don't need to indicate who is active and who is passive, as both endpoints try to establish the SCTP association.

Then why use a=setup for it?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 17:54:58 +0000

Hi,

...

> Then why use a=setup for it?

To negotiate the TLS role.

And, again, I am talking about DTLS/SCTP and SCTP/DTLS. For "pure" SCTP the setup attribute is not needed at all.

Regards,

Christer