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

[Justin Uberti <[e-mail]>]

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

> 2014-08-03 17:44 GMT+02:00 Iñaki Baz Castillo <[e-mail]>:
> > 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.