Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

[Iñaki Baz Castillo <[e-mail]>]

2014-08-03 17:02 GMT+02:00 Martin Thomson <[e-mail]>om>:
> If we were to couple DTLS with the connectivity check, it seems like we
> would have to require some tweaks to the process in order to avoid the
> problem you describe. I think that you have identified a real problem. It
> might be that we need to exclude that transaction identifier from the
> integrity check to fix that, which is a non-trivial change. The obvious
> solution - requiring identical transaction identifiers - removes the on-push
> guarantee, at least to the extent that an attacker can modify signaling and
> spoof valid source addresses.

I don't like the idea of including an ICE Binding request into a DTLS
packet. ICE requests are supposed to "open the path" and thus STUN
packets should be the first ones. Instead, DTLS is "application data
to be carried over the open path". We must respect that.

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.

Thoughts?


-- 
Iñaki Baz Castillo
<[e-mail]>