Subject: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination)

From: Justin Uberti <[email-masked]>
Date: Sun, 3 Aug 2014 11:06:40 -0700

On Sun, Aug 3, 2014 at 9:22 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> 2014-08-03 17:44 GMT+02:00 Iñaki Baz Castillo <[email-masked]>:
> > So why not the opposite?: Add the DTLS ClientHello packet into a new
> > STUN attribute (may be called "DTLS_PACKET"). Issues above solved:
> >
> > - STUN is processed as normal.
> >
> > - The *same* DTLS HelloClient can be set into *different* ICE Binding
> > requests, so there is a single DTLS handshake.
> >
> > - From the point of view of the sender, it is the same scenario in
> > which the sender sends a ICE Binding request followed by a DTLS
> > HelloClient, but with the guarantee that the ICE request will arrive
> > "first" :)
> >
> > - From the point of view of the receiver, it first receives (and
> > validates) the ICE Binding request, then generates the ICE response
> > and then processes the DTLS HelloClient contained in the "DTLS_PACKET"
> > attribute of the Binding request. This adds very little complexity to
> > existing implementations.
>
>
> More on this:
>
> - If the receiver supports the "DTLS_PACKET" STUN attribute it will
> add the DTLS ServerHello response (along with others) into the
> "DTLS_PACKET" of the ICE Binding Response.
>
> - If the ICE response has no "DTLS_PACKET" attribute then the client
> must send a "common" DTLS ClientHello.
>
> - DTLS packets to be exchanged after the STUN exchange (regardless
> DTLS_PACKET was supported or not) can be directly sent over UDP/TCP.
>
>
I agree it would be better to have the DTLS packet inside of STUN, rather
than the converse. I would also suggest that we make this agnostic of the
encapsulated protocol, e.g. allow for something like TURN's DATA attribute
to carry generic data in a binding request.

Note that it the actual upside here may turn out to be somewhat limited
given TLS 1.3's zero-RTT handshake modes.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Aug 2014 13:30:48 -0700

> given TLS 1.3's zero-RTT handshake modes.

That's a good point.  We've talked about loading the material
necessary to do 0RTT into signaling.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Aug 2014 09:08:04 -0400

Le 2014-08-03 14:06, Justin Uberti a écrit :
> I agree it would be better to have the DTLS packet inside of STUN,
> rather than the converse. I would also suggest that we make this
> agnostic of the encapsulated protocol, e.g. allow for something like
> TURN's DATA attribute to carry generic data in a binding request.

Another idea: put the DTLS and STUN next to each other. Since the STUN 
header contains the STUN message length, you can put data after it in 
the same UDP packet.

Not saying it's a better idea, just something we could consider doing.

Simon

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 4 Aug 2014 15:11:33 +0200

2014-08-04 15:08 GMT+02:00 Simon Perreault <[email-masked]>:
> header contains the STUN message length, you can put data after it in the
> same UDP packet.
>

Please don't forget STUN and DTLS over TCP, which is carried as per
http://tools.ietf.org/html/rfc4571.

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Aug 2014 09:22:12 -0400

> http://tools.ietf.org/html/rfc4571.

Assuming you meant RTP over TCP...

As this optimization would be for DTLS, I was assuming UDP only...

Simon

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 4 Aug 2014 15:31:27 +0200

> As this optimization would be for DTLS, I was assuming UDP only...

No, I mean STUN, DTLS and RTP over TCP.

http://tools.ietf.org/html/rfc6544

Section 3:

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

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

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Aug 2014 09:44:31 -0400

> http://tools.ietf.org/html/rfc6544

Woah! I had not realized that RFC4571 included STUN and DTLS. *sigh*

Thanks,
Simon

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 4 Aug 2014 15:49:13 +0200

2014-08-04 15:44 GMT+02:00 Simon Perreault <[email-masked]>:
> Woah! I had not realized that RFC4571 included STUN and DTLS.

It does not. It just defines a mechanism for encapsulating RTP packets
into TCP, but the same mechanism is perfectly valid for any other kind
of packets and thus RTC 6544 makes use of it for STUN and DTLS.

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Aug 2014 09:50:41 -0400

> of packets and thus RTC 6544 makes use of it for STUN and DTLS.

Yes, that's what I meant.

Thanks,
Simon