Re: [MMUSIC] Faster ICE by role reversal?

[Dan Wing <[e-mail]>]

On Jul 30, 2014, at 8:03 PM, Martin Thomson <[e-mail]> wrote:

> On Jul 30, 2014 7:00 PM, "Dan Wing" <[e-mail]> wrote:
> > Towards the desire to remove a round trip, has there been consideration to folding the STUN messaging into the ClientHello?
> 
> Like http://tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-00 ?
> 
Sortof.  What I had in mind was sending ClientHello with a new TLS extension, let's call the extension STUN Binding Request and let's say it contains exactly the same bits as the UDP payload of an actual STUN Binding Request.  When the server receives that UDP packet (containing both a DTLS ClientHello and embedded STUN Binding Request payload), it can do its normal STUN processing against that packet.  When it decides to send its STUN Binding Response, it does the processing necessary to generate its DTLS ServerHello.  It puts them together into the DTLS ServerHello response and replies to the ServerHello.  After that, over that 5-tuple, normal ICE processing can occur (such as for the periodic consent checks).

> Yeah. It doesn't actually reduce round trips here because you still want to confirm consent before doing the whole proof-of-possession thing.
> 
We should be able to optimize the case where we are not being attacked.  When attacked, we can incur an additional round trip.
> If you don't care about the associated DoS vector (and we might not need to worry about that if you can validate the ClientHello properly), a 1 round trip handshake would be very fast.
> 
The HelloVerifyRequest mitigation described in DTLS (http://tools.ietf.org/html/rfc4347#section-4.2.1) seems adequate.

-d