Subject: [rtcweb] How to reset DTLS over TCP if the connection is closed

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 8 Aug 2014 12:01:00 +0200

Hi, let's assume the following scenario:

- Browser and server (ICE-Lite) with just TCP candidates.

- Browser sends the DTLS handshake over the TCP nominated (and single)
connection.

- Media begins.

- Later the TCP connection is abruptly closed. The client want to
"reset" the communication.

So at this point I expect that:

1) Browser MUST open a new TCP connection (obviously).

2) When done it must send Binding Request for the server to allow media from it.

3) Browser MUST NOT perform again the DTLS handshake.

The rationale on bullet 3) is that ICE is supposed to be a "virtual
socket" and thus a single DTLS handshake must be done regardless which
UDP/TCP/SCTP/X.25 transport is used to carried the DTLS data between
peers.

4) Said that, and assuming that there is also a UDP ICE valid pair, I
also expect (and this is a bit exotic but IMHO it SHOULD work) that
the browser should be able to send a DTLS Close Alert over the UDP
valid pair (this is, even when the DTLS handshake and RTP is being
sent over the TCP nominated pair).

Well, I'm pretty sure of all the above, but I consider it a bit exotic
and would like to hear opinions :)

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 11 Aug 2014 15:27:57 -0700

> 1) Browser MUST open a new TCP connection (obviously).

Yes, per http://tools.ietf.org/html/rfc6544#section-11.1

> 2) When done it must send Binding Request for the server to allow media

Yes, as indicated in that same section.

> UDP/TCP/SCTP/X.25 transport is used to carried the DTLS data between

Yes, the DTLS layer is not affected.

> sent over the TCP nominated pair).

Any DTLS close alert would nuke the entire DTLS connection, which is
currently fatal in Chrome.

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 12 Aug 2014 09:00:15 +0000

Justin,
question for clarification:

if finally TCP would be selected as L4 protocol (instead of UDP), then TLS would be used instead of DTLS, right?
(If yes, then discussion would be about “reset TLS over TCP …” in understanding).

-Albrecht

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Dienstag, 12. August 2014 00:28
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed

On Fri, Aug 8, 2014 at 3:01 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:
Hi, let's assume the following scenario:

- Media begins.

Any DTLS close alert would nuke the entire DTLS connection, which is currently fatal in Chrome.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 12 Aug 2014 11:33:54 +0200

> would be used instead of DTLS, right?

No. It is STUN, DTLS and SRTP/SRTCP over TCP.

RFC 6544 (ICE TCP) allows both DTLS and TLS:

                       +----------+
                       |          |
                       |    App   |
            +----------+----------+     +----------+----------+
            |          |          |     |          |          |
            |   STUN   |  (D)TLS  |     |   STUN   |    App   |
            +----------+----------+     +----------+----------+
            |                     |     |                     |
            |      RFC 4571       |     |      RFC 4571       |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         TCP         |     |         TCP         |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         IP          |     |         IP          |
            +---------------------+     +---------------------+

              Figure 1: ICE TCP Stack with and without (D)TLS

but AFAIK WebRTC just uses DTLS and not TLS (note that we are not
talking about TURN in which TLS is supported).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 12 Aug 2014 12:19:58 +0200

> currently fatal in Chrome.

Sure, I just meant that, theoretically, the DTLS alert can be sent
over any valid pair (even if it is not the selected one).

Thanks a lot. This is now clear for me, but IMHO we have a serious
problem given that RFC 5764 insists on "A single DTLS-SRTP session
only protects data carried over a single UDP source and destination
port pair".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Aug 2014 09:25:30 -0700

On Tue, Aug 12, 2014 at 2:33 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> > if finally TCP would be selected as L4 protocol (instead of UDP), then
> TLS
> > would be used instead of DTLS, right?
>
Exactly. Even when TCP is used as a L4 protocol, there can still be packet
losses, as we will never buffer data when entering a flow control state.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Aug 2014 09:27:53 -0700

> over any valid pair (even if it is not the selected one).

Yes.

> only protects data carried over a single UDP source and destination

Agreed, this was written before the DTLS-ICE interaction had been fully
understood. Errata should be filed against 5764 so that it can be made more
consistent with ICE.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Aug 2014 09:32:39 -0700

> understood. Errata should be filed against 5764 so that it can be made more

Agreed. I think this is just a textual problem, though. It's pretty clear
what
has to happen.

-Ekr

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 13 Aug 2014 07:34:40 +0000

Right, this is roughly described in the overview section, which provides only informative statements, but not any normative behaviour.
The later sections talk about a "TLS or DTLS-SRTP session" (and not a TLS, DTLS or DTLS-SRTP session), which would be interpreted that the key exchange for SRTP uses DTLS-SRTP, but the "application" itself would use a TLS/RFC 4571/TCP transport.

If RFC 6544 would allow an "application/DTLS/RFC 4571/TCP" transport, then I would expect some information how the interactions between the DTLS and TCP layers are resolved in case of packet loss ("given the two separate functions how packet loss is handled by TCP and DTLS"), right?

For instance, RFC 6544 could state that a "RFC 6544 DTLS session" would need to be profiled for emulating TLS behaviour by a correspondent alignment of TCP retransmission timer and DTLS retransmission timer settings ... (might be feasible, but looks odd, why not TLS instead?).

Do I miss sth.?

Albrecht

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Dienstag, 12. August 2014 11:34
To: Schwarz, Albrecht (Albrecht)
Cc: Justin Uberti; [email-masked]
Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed

2014-08-12 11:00 GMT+02:00 Schwarz, Albrecht (Albrecht)
<[email-masked]>:
> TLS would be used instead of DTLS, right?

                       +----------+
                       |          |
                       |    App   |

but AFAIK WebRTC just uses DTLS and not TLS (note that we are not talking about TURN in which TLS is supported).

--
Iñaki Baz Castillo
<[email-masked]>

From: Schwarz, Albrecht (Albrecht) 
Sent: Dienstag, 12. August 2014 11:00
To: 'Justin Uberti'
Cc: [email-masked]
Subject: RE: [rtcweb] How to reset DTLS over TCP if the connection is closed

Justin,

-Albrecht

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Aug 2014 13:48:51 -0700

On Wed, Aug 13, 2014 at 12:34 AM, Schwarz, Albrecht (Albrecht) <
[email-masked]> wrote:

> Right, this is roughly described in the overview section, which provides
> only informative statements, but not any normative behaviour.
> The later sections talk about a "TLS or DTLS-SRTP session" (and not a TLS,
> DTLS or DTLS-SRTP session), which would be interpreted that the key
> exchange for SRTP uses DTLS-SRTP, but the "application" itself would use a
> TLS/RFC 4571/TCP transport.
>

If DTLS-SRTP/4571/TCP is permitted, then clearly application/DTLS/4571/TCP
must be permitted, especially in the context of BUNDLE.

You could of course use application/TLS/4571/TCP as well, but for real-time
applications I think that is generally inadvisable, since such applications
will typically not make any reliability guarantees regarding the ICE layer
(e.g. may discard outgoing packets when flow control is encountered)

> If RFC 6544 would allow an "application/DTLS/RFC 4571/TCP" transport, then
> I would expect some information how the interactions between the DTLS and
> TCP layers are resolved in case of packet loss ("given the two separate
> functions how packet loss is handled by TCP and DTLS"), right?

> For instance, RFC 6544 could state that a "RFC 6544 DTLS session" would
> need to be profiled for emulating TLS behaviour by a correspondent
> alignment of TCP retransmission timer and DTLS retransmission timer
> settings ... (might be feasible, but looks odd, why not TLS instead?).
>

TLS requires a reliable transport, but in the 6544 case, TCP is not being
used to guarantee reliability, but rather, provide connectivity in
situations where use of UDP is not possible. TCP optimizations for
real-time apps, such as Minion, will only exacerbate this. Therefore use of
TLS is contraindicated in these situations.

It would probably be worthwhile for DTLS and any higher-level protocols
(e.g. SCTP) to adjust their timers when running over TCP.