Subject: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection?

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 13:55:47 +0000

Hi,

In the TLS role determination section of the SDP-SCTP draft, the text says:

                             "Once a DTLS connection has been established, if the 'active/passive' status of the
                             endpoints change (as result of an offer/answer exchange) during a session, a
                             new DTLS connection MUST be established. Therefore, endpoints SHOULD NOT change
                             the 'active/passive' status during a session, unless they want to establish a
                             new DTLS connection."

I have received a question whether this also affects the underlying TCP connection (in case of 'TCP/DTLS/SCTP') and the SCTP association (in case of 'SCTP/DTLS').

My suggestion would be to NOT re-establish the underlying TCP/SCTP association just because the DTLS connection is re-established. Also, I could not find anything in RFC 6083 that would indicate that the SCTP association would have to be re-established.

(IF a user also wants the underlying TCP/SCTP association to be re-established, he/she uses the SDP connection attribute with a 'new' value.)

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Feb 2015 16:29:33 +0100

On 02/13/2015 02:55 PM, Christer Holmberg wrote:
> “Once a DTLS connection has been established, if the 'active/passive' 
> status of the
>
> new DTLS connection.”
> I have received a question whether this also affects the underlying 
> TCP connection (in case of ‘TCP/DTLS/SCTP’) and the SCTP association 
> (in case of ‘SCTP/DTLS’).
>
> My suggestion would be to NOT re-establish the underlying TCP/SCTP 
> association just because the DTLS connection is re-established. Also, 
> I could not find anything in RFC 6083 that would indicate that the 
> SCTP association would have to be re-established.
>

Seems reasonable to me - but since this is an MMUSIC draft 
(draft-ietf-mmusic-sctp-sdp) and has the potential to be used outside of 
RTCWEB, shoudn't this go on the mmusic mailing list?

> (IF a user also wants the underlying TCP/SCTP association to be 
> re-established, he/she uses the SDP connection attribute with a ‘new’ 
> value.)
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Fri, 13 Feb 2015 11:23:07 -0500

On Fri, Feb 13, 2015 at 8:55 AM, Christer Holmberg <
[email-masked]> wrote:

>                              “Once a DTLS connection has been established,
> if the 'active/passive' status of the
>
>                              endpoints change (as result of an
> offer/answer exchange) during a session, a
>
> I have received a question whether this also affects the underlying TCP
> connection (in case of ‘TCP/DTLS/SCTP’) and the SCTP association (in case
> of ‘SCTP/DTLS’).
>
>
>
> association just because the DTLS connection is re-established. Also, I
> could not find anything in RFC 6083 that would indicate that the SCTP
> association would have to be re-established.
>
>
>
As far as I know the only way to demultiplex DTLS packets is based on the
underlying transport. Unless you can guarantee that no packets from the
previous DTLS connection will arrive on the new connection reusing the same
underlying transport some interesting problems can occur. Unless someone
proposes a way to demux two DTLS connections on the same transport, I would
suggest that new underlying transport should always be used for new DTLS
connection and that DTLS connection settings should not be changed unless
the transport is changed as well.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 23:35:22 +0000

Hi Roman,
In the TLS role determination section of the SDP-SCTP draft, the text says:
                             “Once a DTLS connection has been established, if the 'active/passive' status of the
                             endpoints change (as result of an offer/answer exchange) during a session, a
                             new DTLS connection MUST be established. Therefore, endpoints SHOULD NOT change
                             the 'active/passive' status during a session, unless they want to establish a
                             new DTLS connection.”
I have received a question whether this also affects the underlying TCP connection (in case of ‘TCP/DTLS/SCTP’) and the SCTP association (in case of ‘SCTP/DTLS’).
My suggestion would be to NOT re-establish the underlying TCP/SCTP association just because the DTLS connection is re-established. Also, I could not find anything in RFC 6083 that would indicate that the SCTP association would have to be re-established.
(IF a user also wants the underlying TCP/SCTP association to be re-established, he/she uses the SDP connection attribute with a ‘new’ value.)

>As far as I know the only way to demultiplex DTLS packets is based on the underlying transport. Unless you can >guarantee that no packets from the previous DTLS connection will arrive on the new connection reusing the same >underlying transport some interesting problems can occur.

Don’t you have the same problem in case of DTLS re-keying?

AFAIR, DTLS covers that by stating the old keys shall be stored for a while, in case there are some “late” packets.

>Unless someone proposes a way to demux two DTLS connections on the same transport, I would suggest that new >underlying transport should always be used for new DTLS connection and that DTLS connection settings should not >be changed unless the transport is changed as well.

Does anyone have an opinion on this?

(I don’t expect DTLS connections to be re-established during a session very frequently.)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 23:38:06 +0000

Hi Harald,
 
>>My suggestion would be to NOT re-establish the underlying TCP/SCTP association just because the DTLS connection is re->>established. Also, I could not find anything in RFC 6083 that would indicate that the SCTP association would have to be re->>established.
>
>Seems reasonable to me - but since this is an MMUSIC draft (draft-ietf-mmusic-sctp-sdp) and has the potential to be used >outside of RTCWEB, shoudn't this go on the mmusic mailing list?

They will have their chance to comment during WGLC :)

Seriously, the reason I brought it here first is because the people actually implementing this (for WebRTC Data Channels) are more likely to be found here.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 13 Feb 2015 19:14:29 -0500

>  Don’t you have the same problem in case of DTLS re-keying?

You do have the same problem in case of DTLS re-key. This is why none of
the current browser implementations actually support it. At this point I
would be very curious to see if anybody implemented DTLS re-key or
re-negotiation over the same transport and would very much appreciate if
they tell us how exactly they did this.

Regards,
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Feb 2015 16:29:38 -0800

Harald said:

"My suggestion would be to NOT re-establish the underlying TCP/SCTP
association just because the DTLS connection is re->>established. Also, I
could not find anything in RFC 6083 that would indicate that the SCTP
association would have to be re->>established."

[BA] There is no reason to re-establish the underlying TCP/SCTP association
due to DTLS connection re-establishment or ICE re-start.  Similarly, there
is no reason a DTLS connection should need to be re-established just
because of an ICE re-start.

On Fri, Feb 13, 2015 at 3:38 PM, Christer Holmberg <
[email-masked]> wrote:

> >>                             "Once a DTLS connection has been
> established, if the 'active/passive' status of the
> connection (in case of 'TCP/DTLS/SCTP') and the SCTP
> >> association (in case of 'SCTP/DTLS').
> >>
> association just because the DTLS connection is re->>established. Also, I
> association would have to be re->>established.
> >
> (draft-ietf-mmusic-sctp-sdp) and has the potential to be used >outside of
> Seriously, the reason I brought it here first is because the people
> actually implementing this (for WebRTC Data Channels) are more likely to be
> found here.
>
> Regards,
>
> Christer
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Feb 2015 08:55:27 -0500

> they tell us how exactly they did this.

Uh?

I did implement DTLS re-key / re-negotiation as specified. Then I tested
it. It works. I don't know what problem you're alluding to.

Simon

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 16 Feb 2015 14:44:40 +0000

>>"My suggestion would be to NOT re-establish the underlying TCP/SCTP association just because the DTLS connection is re->>established. Also, I could not find anything in RFC 6083 that would indicate that the SCTP association would have to be re->>established."
[Raju] I think the decision to re-establish TCP/SCTP should be per a=connection attribute. A value “new” should trigger both TCP and SCTP re-establishment (independent of DTLS re-establishment).
Per the SDP-SCTP 10.3 and 10.4:

-          a=setup applies to TCP and DTLS only (not SCTP).

-          a=connection applies to TCP and SCTP (not DTLS)
So, if a client wants to re-establish DTLS only then it should include “a=connection:existing”.
If a client wants to re-establish DTLS along with TCP/SCTP then it should include “a=connection:new”.
In either case relevant a=setup attributes must be include to trigger DTLS re-establishment.

>As far as I know the only way to demultiplex DTLS packets is based on the underlying transport. >Unless you can >guarantee that no packets from the previous DTLS connection will arrive on the >new connection reusing the same >underlying transport some interesting problems can occur.
[Raju] I believe packets from old DTLS connection appearing on new will be dropped the same way DTLS rekeying handles packets using old key after MSL timeout [1]. So, I don’t think a new TCP/SCTP transport connection need to be established.

[1] https://tools.ietf.org/html/rfc5764#section-5.2
   Because of packet reordering, packets protected by the previous set
   of keys can appear on the wire after the handshake has completed.  To
   compensate for this fact, receivers SHOULD maintain both sets of keys
   for some time in order to be able to decrypt and verify older
   packets.  The keys should be maintained for the duration of the
   maximum segment lifetime (MSL).
…

If the authentication check on the packet fails

   and no MKI is being used, then the receiver MAY process the packet

   with the older set of keys.  If that authentication check indicates

   that the packet is valid, the packet should be accepted; otherwise,

   the packet MUST be discarded and rejected.

BR
Raju

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 Feb 2015 12:47:40 -0500

> it. It works. I don't know what problem you're alluding to.
How do you deal with late DTLS data packets or alerts for the previous
connection received on the new connection? If it is an open source, you can
simply point me to the relevant code.

I do know how to implement DTLS-SRTP re-key. It is dealing with new DTLS
session running over existing connection where packets from the previous
DTLS session can be present which is not completely clear to me.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 Feb 2015 12:51:19 -0500

On Mon, Feb 16, 2015 at 9:44 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>
>
> >As far as I know the only way to demultiplex DTLS packets is based on
> the underlying transport. >Unless you can >guarantee that no packets from
> the previous DTLS connection will arrive on the >new connection reusing the
> same >underlying transport some interesting problems can occur.
>
> [Raju] I believe packets from old DTLS connection appearing on new will be
> dropped the same way DTLS rekeying handles packets using old key after MSL
> timeout [1]. So, I don’t think a new TCP/SCTP transport connection need to
> be established.
>
>
>
This actually talks about DTLS-SRTP re-key that I have implemented before.
What is unclear to me is how DTLS is dealing with multiple DTLS sessions
(i.e. DTLS data and alerts) on the same transport connection. I cannot find
any documentation or implementations of such feature.
_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Feb 2015 12:56:51 -0500

> simply point me to the relevant code.

This may just be a terminology issue... DTLS re-key / re-negotiation
doesn't create a new connection.

> DTLS session can be present which is not completely clear to me.

Packets from an unrelated DTLS connection will simply be discarded. What
else are you looking for?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Feb 2015 12:58:01 -0500

> any documentation or implementations of such feature.

You can't do this, just like you can't have more than one TCP connection
per 5-tuple.

Simon

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 16 Feb 2015 20:01:35 +0000

On Mon, Feb 16, 2015 at 12:51 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
What is unclear to me is how DTLS is dealing with multiple DTLS sessions (i.e. DTLS data and alerts) on the same transport connection. I cannot find any documentation or implementations of such feature.

[Raju] DTLS is a protocol which is typically runs in application-space. You typically run just one DTLS session on top of underlying transport layer (TCP or UDP). As explained by Simon, DTLS rekeying does not result in a new DTLS association, but rather new handshake sequence on top of existing association.

However, during subsequent SDP O/A role change may trigger a new DTLS association to be setup. In such a case previous association should be gone and any transport layer packets (TCP or UDP) from the previous DTLS association may arrive on new DTLS association, but I think they will and should be discarded due to MAC failure (with bad_record_mac alert?).

Please note that this is not unique to TCP; though unreliable, UDP transport could also receive delayed pkts from previous DTLS association. Or someone could simply inject UPD pkts into mix. So, re-establishing TCP connection is not a solution and won’t help when UDP is used.

So, IMO a DTLS implementation should handle such out-of-band (OOB) pkts in a graceful way (i.e. without dropping the DTLS association).

Hope this helps!

Raju

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Feb 2015 13:26:43 +0000

Hi,

Based on the input, my suggestion is to add the following note to section 10.3.3 (TLS Role Determination):

“NOTE: The re-establishment of a DTLS connection as such does not affect the underlying transport protocol connection. However, as described above, the reason a new DTLS connection is established might be because some transport protocol parameters have changed.”

Regards,

Christer