Re: [MMUSIC] Faster ICE by role reversal?

[Martin Thomson <[e-mail]>]

On 31 July 2014 00:01, Dan Wing <[e-mail]> wrote:
> 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).


That is an interesting idea.  I'd have to sit down and look at what
goes in a consent check to see if anything can be trimmed out.  Off
the cuff, I can't think of anything that we could safely remove,
except maybe the cookie and fingerprint code.  You still need
XOR-MAPPED-ADDRESS, PRIORITY, proof of possession of ice-pwd, and all
that junk.  I'm not sure about the transaction ID.  (D)TLS defers
proof of receipt more than I'd be comfortable with, I think.

And yes, HelloVerify seems OK.

On the plus side for something like this, indicating support is easy to address.

Maybe this is something we should be talking to Joe Hildebrand about.