Subject: [MMUSIC] DTLS-over-SCTP, anyone?

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Feb 2016 14:33:16 +0000

Hi,

draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.

As we know, SCTP-over-DTLS is used for the WebRTC data channel.

My question is: does anyone intend to use DTLS-over-SCTP?

Regards,

Christer

---

From: "Schwarz, Albrecht (Nokia - DE)" <[email-masked]>
Date: Mon, 8 Feb 2016 15:12:40 +0000

Hello Christer,

the titel of the (future) RFC will not exclude any SCTP transport modes.
And a comprehensive and future safe protocol specification should cover all existing ones, which is "DTLS/SCTP/IP" as well as "SCTP/UDP/IP" (RFC 6951).
These two SCTP transport modes should be indicated as well, independent of potential intentions to be used soon.
Codepoint space could be reserved, placeholder sections tagged as "not yet supported" of "for further studies", etc, but the worst case would be any kind of interaction issues in future.

My view,
Albrecht

From: mmusic [mailto:[email-masked]] On Behalf Of EXT Christer Holmberg
Sent: Montag, 8. Februar 2016 15:33
To: mmusic <[email-masked]>
Subject: [MMUSIC] DTLS-over-SCTP, anyone?

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Feb 2016 11:29:51 -0500

Albrecht,

The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully
compatible with draft-ietf-mmusic-dtls-sdp. In particular, RFC 6083 does
not allow DTLS association span across multiple SCTP associations,
but draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association through
a transport change. The most likely solution to this is updating RFC 6083,
but, if no one is using DTLS-over-SCTP, it would be easier just to say
that DTLS-over-SCTP is not supported.

Regards,

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) <
[email-masked]> wrote:

> And a comprehensive and future safe protocol specification should cover
> all existing ones, which is “DTLS/SCTP/IP” as well as “SCTP/UDP/IP” (RFC
> 6951).
>
> Codepoint space could be reserved, placeholder sections tagged as “not yet
> supported” of “for further studies”, etc, but the worst case would be any
> kind of interaction issues in future.
>
>
>
> My view,
>
> Albrecht
>
>
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *EXT
> Christer Holmberg
> *Sent:* Montag, 8. Februar 2016 15:33
> *To:* mmusic <[email-masked]>
> *Subject:* [MMUSIC] DTLS-over-SCTP, anyone?
>
>
>
> Hi,
>
>
>
> draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A procedures for
> SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Feb 2016 20:36:00 +0000

Albrecht, was there an answer to my question in there somewhere? :)

Regards,

Christer

From: Schwarz, Albrecht (Nokia - DE) [mailto:[email-masked]]
Sent: 08 February 2016 17:13
To: Christer Holmberg <[email-masked]>; mmusic <[email-masked]>
Subject: RE: DTLS-over-SCTP, anyone?

Hello Christer,

My view,
Albrecht

From: mmusic [mailto:[email-masked]] On Behalf Of EXT Christer Holmberg
Sent: Montag, 8. Februar 2016 15:33
To: mmusic <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] DTLS-over-SCTP, anyone?

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Feb 2016 20:45:45 +0000

Hi,

> The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully compatible with draft-ietf-mmusic-dtls-sdp.
> In particular, RFC 6083 does not allow DTLS association span across multiple SCTP associations, but
> draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association through a transport change. The most likely
> solution to this is updating RFC 6083, but, if no one is using DTLS-over-SCTP, it would be easier just to say

*If* we decide to keep DTLS-over-SCTP in the draft, my suggestion would be to say that “DTLS preservation over transport change” does not apply to DTLS-over-SCTP, with a reference to RFC 6083.

Then, if someone at some point updates RFC 6083, the SCTP-SDP spec also has to be updated.

I do NOT want to delay draft-sctp-sdp until a possible RFC 6083 update has been done (assuming people would agree to do it in the first place).

Regards,

Christer

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Christer,

the titel of the (future) RFC will not exclude any SCTP transport modes.
And a comprehensive and future safe protocol specification should cover all existing ones, which is “DTLS/SCTP/IP” as well as “SCTP/UDP/IP” (RFC 6951).
These two SCTP transport modes should be indicated as well, independent of potential intentions to be used soon.
Codepoint space could be reserved, placeholder sections tagged as “not yet supported” of “for further studies”, etc, but the worst case would be any kind of interaction issues in future.

My view,
Albrecht

From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of EXT Christer Holmberg
Sent: Montag, 8. Februar 2016 15:33
To: mmusic <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] DTLS-over-SCTP, anyone?

Hi,

Regards,

Christer

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 9 Feb 2016 12:57:10 +1100

Hello

I think the fact that the draft doesn't support DTLS-over-SCTP has been 
known for some time. No one has been pushing for its inclusion. I'd be 
happy if it was left out to be able to progress the draft.

Alternatively we can do what I think Albrecht is suggesting. Reserve 
proto values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate 
their use by SDP should be defined in a future specification. I don't 
think its worth solving that problem now.

Regards, Christian

On 9/02/2016 7:45 AM, Christer Holmberg wrote:
> compatible with draft-ietf-mmusic-dtls-sdp.
>
> > draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association 
> through a transport change. The most likely
>
> > solution to this is updating RFC 6083, but, if no one is using 
> DTLS-over-SCTP, it would be easier just to say
>
> **If** we decide to keep DTLS-over-SCTP in the draft, my suggestion 
> would be to say that “DTLS preservation over transport change” does 
> not apply to DTLS-over-SCTP, with a reference to RFC 6083.
>
> I do NOT want to delay draft-sctp-sdp until a possible RFC 6083 update 
> has been done (assuming people would agree to do it in the first place).
>
> Regards,
>
> Christer
>
> _____________
> Roman Shpount
>
> On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Christer,
>
>     And a comprehensive and future safe protocol specification should
>     cover all existing ones, which is “DTLS/SCTP/IP” as well as
>     “SCTP/UDP/IP” (RFC 6951).
>
>     These two SCTP transport modes should be indicated as well,
>     independent of potential intentions to be used soon.
>
>     Codepoint space could be reserved, placeholder sections tagged as
>     “not yet supported” of “for further studies”, etc, but the worst
>     case would be any kind of interaction issues in future.
>
>     My view,
>
>     Albrecht
>
>     *From:*mmusic [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *EXT Christer Holmberg
>     *To:* mmusic <[email-masked] <mailto:[email-masked]>>
>     draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A
>     procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Feb 2016 19:05:00 -0500

I think we can add the following to section 7.1 of dtls-sdp:

If DTLS is transmitted over a reliable transport and if DTLS procedures for
retransmissions are not used, for instance as described in RFC 6083 for
DTLS over SCTP, then DTLS association MUST NOT span across multiple
transports. Using 'dtls-connection' attribute with an 'existing' value in
combination with change of such a reliable transport should be treated as
an error and DTLS association MUST be terminated.

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 8:57 PM, Christian Groves <
[email-masked]> wrote:

> Alternatively we can do what I think Albrecht is suggesting. Reserve proto
> values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate their use
> by SDP should be defined in a future specification. I don't think its worth
> solving that problem now.
>
> Regards, Christian
>
>> **If** we decide to keep DTLS-over-SCTP in the draft, my suggestion would
>> be to say that “DTLS preservation over transport change” does not apply to
>> DTLS-over-SCTP, with a reference to RFC 6083.
>>
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hello Christer,
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Feb 2016 10:29:53 +0000

Hi Roman,

> If DTLS is transmitted over a reliable transport and if DTLS procedures for retransmissions are not used, for instance as described in
> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span across multiple transports. Using 'dtls-connection' attribute with 
> an 'existing' value in combination with change of such a reliable transport should be treated as an error and DTLS association MUST be 
> terminated.

Your text as such looks ok. But, do we really want to add it as a generic restriction in draft-dtls-sdp? Shouldn't it be specific for DTLS-over-SCTP instead? What if someone defines DTLS-over-<new-fancy-reliable-transport> and they DO allow span?

Regards,

Christer

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 8:57 PM, Christian Groves <[email-masked]> wrote:
Hello

I think the fact that the draft doesn't support DTLS-over-SCTP has been known for some time. No one has been pushing for its inclusion. I'd be happy if it was left out to be able to progress the draft.

Alternatively we can do what I think Albrecht is suggesting. Reserve proto values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate their use by SDP should be defined in a future specification. I don't think its worth solving that problem now.

Regards, Christian

Hi,

> that DTLS-over-SCTP is not supported.

**If** we decide to keep DTLS-over-SCTP in the draft, my suggestion would be to say that “DTLS preservation over transport change” does not apply to DTLS-over-SCTP, with a reference to RFC 6083.

Regards,

Christer

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) <[email-masked] <mailto:[email-masked]>> wrote:

    Hello Christer,

    the titel of the (future) RFC will not exclude any SCTP transport
    modes.

    My view,

    Albrecht

    Hi,

    Regards,

    Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Feb 2016 14:34:56 -0500

Hi Christer,

On Wed, Feb 10, 2016 at 5:29 AM, Christer Holmberg <
[email-masked]> wrote:

> > If DTLS is transmitted over a reliable transport and if DTLS procedures
> for retransmissions are not used, for instance as described in
> > RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span across
> multiple transports. Using 'dtls-connection' attribute with
> > an 'existing' value in combination with change of such a reliable
> transport should be treated as an error and DTLS association MUST be
> > terminated.
>
> Your text as such looks ok. But, do we really want to add it as a generic
> restriction in draft-dtls-sdp? Shouldn't it be specific for DTLS-over-SCTP
> instead? What if someone defines DTLS-over-<new-fancy-reliable-transport>
> and they DO allow span?
>
>
The reason multiple DTLS associations cannot span across several SCTP
association is due to SCTP association handling DTLS packet retransmission
and DTLS procedures for retransmissions not being used. We can make a
generic statement or limit this to RFC 6083 only, but I think, stating the
reason why DTLS association cannot span multiple transports is important.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Feb 2016 19:58:53 +0000

Hi,

>> Your text as such looks ok. But, do we really want to add it as a generic restriction in draft-dtls-sdp? Shouldn't it be
>> specific for DTLS-over-SCTP instead? What if someone defines DTLS-over-<new-fancy-reliable-transport> and they DO allow span?
>
> The reason multiple DTLS associations cannot span across several SCTP association is due to SCTP association handling DTLS packet 
> retransmission and DTLS procedures for retransmissions not being used. We can make a generic statement or limit this to RFC 6083 
> only, but I think, stating the reason why DTLS association cannot span multiple transports is important.

I agree.

But, again DTLS-over-SCTP is described in draft-sctp-sdp, so I think such text belongs there.

Regards,

Christer

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Feb 2016 15:41:44 -0500

On Wed, Feb 10, 2016 at 2:58 PM, Christer Holmberg <
[email-masked]> wrote:

> >>> If DTLS is transmitted over a reliable transport and if DTLS
> procedures for retransmissions are not used, for instance as described in
> >>> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span
> across multiple transports. Using 'dtls-connection' attribute with
> >> Your text as such looks ok. But, do we really want to add it as a
> generic restriction in draft-dtls-sdp? Shouldn't it be
> >> specific for DTLS-over-SCTP instead? What if someone defines
> DTLS-over-<new-fancy-reliable-transport> and they DO allow span?
> >
> association is due to SCTP association handling DTLS packet
> > retransmission and DTLS procedures for retransmissions not being used.
> We can make a generic statement or limit this to RFC 6083
How about saying the following in draft-dtls-sdp:

If DTLS is transmitted over a transport that prohibits spanning of DTLS
association across multiple transports, such as DTLS over SCTP as described
in RFC 6083, then 'dtls-connection' attribute MUST be set to 'new' every
time transport is changed.

And you can put the previous language in draft-sctp-sdp

This way each draft only specified things relevant to itself.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Feb 2016 07:09:27 +0000

Hi Roman,

Your suggestion looks good. I’ll take it as a WGLC comment, and add it in the post-WGLC version of the draft :)

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 10. helmikuuta 2016 22:42
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?

I agree.

If DTLS is transmitted over a transport that prohibits spanning of DTLS association across multiple transports, such as DTLS over SCTP as described in RFC 6083, then 'dtls-connection' attribute MUST be set to 'new' every time transport is changed.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Feb 2016 13:06:00 +0000

Hi Roman,

What about the following new section 3.2:

    “3.2.  Change of Local Transport Parameters

      If an endpoint modifies its local transport parameters (IP address
      and/or port), and if the modification requires a new DTLS
      association, the endpoint MUST either change its DTLS role, its
      fingerprint value and/or use the SDP 'dtls-connection' attribute with
      a 'new' value Section 4.

      If the underlying transport explicitly prohibits a DTLS
      association to span multiple transports, the SDP 'dtls-connection'
      attribute MUST be set to 'new' if the transport is changed.  An
      example of such case is when DTLS is carried over SCTP, as described
      in [RFC6083].”

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 11. helmikuuta 2016 9:09
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?

Hi Roman,

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 10. helmikuuta 2016 22:42
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?

I agree.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 11 Feb 2016 13:46:05 -0500

I am fine with this language except it should be "address and/or port"
not "IP address and/or port".

Regards,

_____________
Roman Shpount

On Thu, Feb 11, 2016 at 8:06 AM, Christer Holmberg <
[email-masked]> wrote:

> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 11. helmikuuta 2016 9:09
> *To:* Roman Shpount
>
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] DTLS-over-SCTP, anyone?
>
>
>
> Hi Roman,
>
>
>
> *From:* Roman Shpount [mailto:[email-masked] <[email-masked]>]
> *Sent:* 10. helmikuuta 2016 22:42
> *To:* Christer Holmberg
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] DTLS-over-SCTP, anyone?
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Feb 2016 19:46:00 +0000

>I am fine with this language except it should be "address and/or port" not "IP address and/or >port".

Correct. I thought I had fixed all that, but it seems like I forgot one instance :)

Regards,

Christer

On Thu, Feb 11, 2016 at 8:06 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,

Regards,

Christer

From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christer Holmberg
Sent: 11. helmikuuta 2016 9:09
To: Roman Shpount

Hi Roman,

Regards,

Christer

I agree.

Regards,
_____________
Roman Shpount