Subject: [MMUSIC] Plain SCTP in sctp-sdp

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2016 19:53:56 -0400

Hi All,

We have ended up with an interesting security situation
in draft-ietf-mmusic-sctp-sdp after removal of SCTP/DTLS.

First the background:

The whole issue is rooted in the fact that SCTP and recently departed
SCTP/DTLS form one family of protocols and UDP/DTLS/SCTP, TCP/DTLS/SCTP,
and curiously absent UDP/SCTP and TCP/SCTP form another. Each of those
protocol families are implemented and operate in distinctly different
manners.

1. SCTP and SCTP/DTLS require OS support. UDP/DTLS/SCTP and TCP/DTLS/SCTP are
implemented on top of TCP or UDP in user level libraries.

2. SCTP and SCTP/DTLS cannot run over ICE. UDP/DTLS/SCTP and TCP/DTLS/SCTP can
run over ICE.

3.  SCTP and SCTP/DTLS cannot work with NAT. UDP/DTLS/SCTP and
TCP/DTLS/SCTP are
NAT friendly.

4. In SCTP/DTLS, DTLS association can be terminated and new association can
be established over the same SCTP transport. In UDP/DTLS/SCTP and
TCP/DTLS/SCTP, a new DTLS association cannot be re-established over the
same UDP or TCP transport.

5. In SCTP/DTLS, the same DTLS association cannot migrate to another SCTP
or any other transport. In UDP/DTLS/SCTP and TCP/DTLS/SCTP, the same DTLS
association can migrate between multiple UDP and TCP transport, especially
during selected candidate change in ICE.

6. SCTP and SCTP/DTLS support multihoming. UDP/DTLS/SCTP and TCP/DTLS/SCTP do
not.

7.  UDP/DTLS/SCTP and TCP/DTLS/SCTP are needed for RTCWeb. SCTP and
SCTP/DTLS are needed for something else. In fact we are still looking for
people who needs these protocols and their use cases.

There are probably more differences, but trying to define rules for both
families of protocols in the same document leads to disorder and confusion,
which were especially evident in case of SCTP/DTLS. Because of this, it was
decided to get rid of SCTP/DTLS in the document.

Now the problem:

We ended up with insecure protocol from one family (SCTP) and two secure
protocols from the other family (UDP/DTLS/SCTP and TCP/DTLS/SCTP) in the
same document. If anybody does a security review of this document, it will
be evident that there is no secure version SCTP protocol. I do not think we
should define negotiation procedure for a new protocol now, which provides
no encryption option. So, since plain SCTP is not needed by RTCWeb, I
propose remove plain SCTP from draft-ietf-mmusic-sctp-sdp to avoid any
security flags which can prevent progress of this draft. If somebody needs
SDP negotiation of SCTP and SCTP/DTLS in the future, such procedures can be
defined in another document. I think the result will be cleaner and more
logical for both drafts. SCTP removal should be a small editorial change
and should not considerably slow down the document progress.

As a side note, not having an insecure protocols from the second
family (UDP/SCTP
and TCP/SCTP) is a much smaller problem, since they are not required by
RTCWeb and should not produce any security related concerns. If we see a
use case for such protocols (I do, for instance) we can define these
protocols in the bis version of draft-ietf-mmusic-sctp-sdp.

What do you all think?
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Sep 2016 12:06:07 -0400

On 9/15/16 7:53 PM, Roman Shpount wrote:
> 1. SCTP and SCTP/DTLS require OS support. UDP/DTLS/SCTP and
> TCP/DTLS/SCTP are implemented on top of TCP or UDP in user level libraries.
>
> 2. SCTP and SCTP/DTLS cannot run over
> ICE. UDP/DTLS/SCTP and TCP/DTLS/SCTP can run over ICE.
>
> 3.  SCTP and SCTP/DTLS cannot work with
> NAT. UDP/DTLS/SCTP and TCP/DTLS/SCTP are NAT friendly.
>
> 4. In SCTP/DTLS, DTLS association can be terminated and new association
> can be established over the same SCTP transport. In UDP/DTLS/SCTP and
> 5. In SCTP/DTLS, the same DTLS association cannot migrate to another
> SCTP or any other transport. In UDP/DTLS/SCTP and TCP/DTLS/SCTP, the
> same DTLS association can migrate between multiple UDP and TCP
> transport, especially during selected candidate change in ICE.
>
> 6. SCTP and SCTP/DTLS support
> multihoming. UDP/DTLS/SCTP and TCP/DTLS/SCTP do not.
>
> SCTP/DTLS are needed for something else. In fact we are still looking
> for people who needs these protocols and their use cases.
>
> families of protocols in the same document leads to disorder and
> confusion, which were especially evident in case of SCTP/DTLS. Because
> of this, it was decided to get rid of SCTP/DTLS in the document.

These are all interesting factors that influence the applicability of 
these various protocol stacks to particular circumstances/deployments.

> same document. If anybody does a security review of this document, it
> will be evident that there is no secure version SCTP protocol. I do not
> think we should define negotiation procedure for a new protocol now,
> which provides no encryption option.

Really? Does that mean that TCP and UDP are mistakes and shouldn't have 
been defined?

Note especially with SCTP that it is possible to layer a security 
protocol over individual SCTP streams. So it could be a useful platform 
for other things, in the same way that UDP and TCP are.

> So, since plain SCTP is not needed
> by RTCWeb, I propose remove plain SCTP from draft-ietf-mmusic-sctp-sdp
> to avoid any security flags which can prevent progress of this draft. If

I didn't realize that RTCweb was the only intended consumer of this 
draft. This is an MMUSIC draft, and MMUSIC has a broader scope than just 
rtcweb.

	Thanks,
	Paul

> somebody needs SDP negotiation of SCTP and SCTP/DTLS in the future, such
> procedures can be defined in another document. I think the result will
> be cleaner and more logical for both drafts. SCTP removal should be a
> small editorial change and should not considerably slow down the
> document progress.
>
> As a side note, not having an insecure protocols from the second family
> (UDP/SCTP and TCP/SCTP) is a much smaller problem, since they are not
> required by RTCWeb and should not produce any security related concerns.
> If we see a use case for such protocols (I do, for instance) we can
> define these protocols in the bis version of draft-ietf-mmusic-sctp-sdp.
>
> What do you all think?

---

From: Roman Shpount <[email-masked]>
Date: Fri, 16 Sep 2016 13:06:31 -0400

> these various protocol stacks to particular circumstances/deployments.

The differences are listed here to show that you need one set of procedures
for O/A negotiation of SCTP and SCTP/DTLS and another set for
UDP/DTLS/SCTP, TCP/DTLS/SCTP. It is possible to define both procedures in
the same document, but it makes such procedures much harder to understand
and implement. In some sense these protocols have more differences then
they have in common. SCTP and SCTP encapsulated in other protocol end up
behaving like two very different things.

Now the problem:
> Note especially with SCTP that it is possible to layer a security protocol
> over individual SCTP streams. So it could be a useful platform for other
> things, in the same way that UDP and TCP are.

I am not talking about the protocols. I am talking about defining O/A
negotiation framework which does not allow to negotiate a secure
connection. It is not very hard to define SCTP and DTLS/SCTP, but it is
very confusing to do this in parallel with UDP/DTLS/SCTP and TCP/DTLS/SCTP.
We know what the secure option for SCTP is. It is SCTP/DTLS. It is
documented and defined in RFC 6083. The fact that it constantly confused
with DTLS/SCTP even though this is a very different protocol makes it a
very bad candidate for the same document, but does not mean it cannot be
negotiated using O/A. We also have determined that parties interested in
UDP/DTLS/SCTP and TCP/DTLS/SCTP are different from parties interested in
SCTP and SCTP/DTLS. Since these are different protocols, each group should
write their own document.

> I didn't realize that RTCweb was the only intended consumer of this draft.
> This is an MMUSIC draft, and MMUSIC has a broader scope than just rtcweb.

It is not the only consumer for this draft, but we are under the time
pressure to complete this draft since it is a dependency for RTCWeb.
Because of this, it makes sense to remove any controversial parts of the
draft that are not relevant to RTCWeb and address these protocols in a
different document (especially since they are logically unrelated).

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2016 17:37:48 +0000

Hi,

RTCWEB is *currently* the only customer for the document, as far as I know, nobody has indicated interest for anything else than UDP/DTLS/SCTP and TCP/DTLS/SCTP. That's one reason we removed SCTP/DTLS.

I have no problem to remove plain SCTP, and re-name the draft to something like "Secure Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", "DTLS Protected Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", or something like that...

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 16 September 2016 19:06
To: [email-masked]
Subject: Re: [MMUSIC] Plain SCTP in sctp-sdp

On 9/15/16 7:53 PM, Roman Shpount wrote:
> Hi All,
>
> We have ended up with an interesting security situation in 
> draft-ietf-mmusic-sctp-sdp after removal of SCTP/DTLS.
>
> First the background:
>
> SCTP/DTLS form one family of protocols and UDP/DTLS/SCTP, 
> TCP/DTLS/SCTP, and curiously absent UDP/SCTP and TCP/SCTP form 
> another. Each of those protocol families are implemented and operate 
> in distinctly different manners.
>
> TCP/DTLS/SCTP are NAT friendly.
>
> 4. In SCTP/DTLS, DTLS association can be terminated and new 
> association can be established over the same SCTP transport. In 
> UDP/DTLS/SCTP and TCP/DTLS/SCTP, a new DTLS association cannot be 
> re-established over the same UDP or TCP transport.
>
> There are probably more differences, but trying to define rules for 
> both families of protocols in the same document leads to disorder and 

These are all interesting factors that influence the applicability of these various protocol stacks to particular circumstances/deployments.

> Now the problem:
>
> We ended up with insecure protocol from one family (SCTP) and two 
> secure protocols from the other family (UDP/DTLS/SCTP and 
> TCP/DTLS/SCTP) in the same document. If anybody does a security review 
> of this document, it will be evident that there is no secure version 
> SCTP protocol. I do not think we should define negotiation procedure 
> for a new protocol now, which provides no encryption option.

Really? Does that mean that TCP and UDP are mistakes and shouldn't have been defined?

Note especially with SCTP that it is possible to layer a security protocol over individual SCTP streams. So it could be a useful platform for other things, in the same way that UDP and TCP are.

> to avoid any security flags which can prevent progress of this draft. 

I didn't realize that RTCweb was the only intended consumer of this draft. This is an MMUSIC draft, and MMUSIC has a broader scope than just rtcweb.

	Thanks,
	Paul

> somebody needs SDP negotiation of SCTP and SCTP/DTLS in the future, 
> such procedures can be defined in another document. I think the result 
> will be cleaner and more logical for both drafts. SCTP removal should 
> be a small editorial change and should not considerably slow down the 
> document progress.
>
> family (UDP/SCTP and TCP/SCTP) is a much smaller problem, since they 
> are not required by RTCWeb and should not produce any security related concerns.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Sep 2016 17:06:37 -0400

Seems like a reasonable suggestion to me.

Anybody else have any opinions ?

Thanks

-- Flemming (as individual)

On 9/16/16 1:37 PM, Christer Holmberg wrote:
> .

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Sep 2016 17:09:49 -0400

Just to be clear, my preference is to remove SCTP and leave only
UDP/DTLS/SCTP and TCP/DTLS/SCTP. I think this will make it a much cleaner
document. I think trying to define a protocol that no one writing the
document is planning to use (plain SCTP) would do more harm then good.

Regards,
_____________
Roman Shpount

On Thu, Sep 22, 2016 at 5:06 PM, Flemming Andreasen <[email-masked]>
wrote:

>> RTCWEB is *currently* the only customer for the document, as far as I
>> know, nobody has indicated interest for anything else than UDP/DTLS/SCTP
>> and TCP/DTLS/SCTP. That's one reason we removed SCTP/DTLS.
>>
>> I have no problem to remove plain SCTP, and re-name the draft to
>> something like "Secure Stream Control Transmission Protocol (SCTP)-Based
>> Media Transport in the Session Description Protocol (SDP)", "DTLS Protected
>> Stream Control Transmission Protocol (SCTP)-Based Media Transport in the
>> Session Description Protocol (SDP)", or something like that...
>>
>> Regards,
>>
>> Christer
>>
>> protocol over individual SCTP streams. So it could be a useful platform for
>> other things, in the same way that UDP and TCP are.
>>