Subject: [MMUSIC] Faster ICE by role reversal?

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 15:16:45 -0700

RFC 5245 states that the controlling peer is the offerer, period.
This delays the start of nomination until the answer arrives.

What do folks think about an ICE option like the following?

The option is added to the offer to say: I'm OK if the answerer
nominates.  The answerer echoes the option to indicate that it will
nominate.

The answerer nominating would allow it to send a DTLS ClientHello and
the USE-CANDIDATE check in immediate succession.  That removes the
signaling return path from the session setup time when doing
aggressive nomination.  And it would let us use Jonathan's "aggressive
nomination without USE-CANDIDATE" technique all the time.  We could
then effectively deprecate aggressive nomination, since there are no
real latency gains to be had.

I've probably missed something critical here, so take this opportunity
to tell me that I'm stupid.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Jul 2014 22:56:31 +0000

> to tell me that I'm stupid.

The offerer can’t send its own connectivity checks until it receives an answer, because it needs the remote ufrag and password.  Without this, it doesn’t have any valid pairs, and so can’t send any media.

This suggestion might still save half an RTT, though? I’d need to work through a full ladder diagram to figure it out.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 16:00:09 -0700

> The offerer can’t send its own connectivity checks until it receives an answer, because it needs the remote ufrag and password.  Without this, it doesn’t have any valid pairs, and so can’t send any…

Of course.  But you could do all the computation necessary for
generating the ServerHello and accompanying messages (which in TLS 1.3
is quite a bit).

> This suggestion might still save half an RTT, though? I’d need to work through a full ladder diagram to figure it out.

That's the idea.  I haven't plotted it all out either, but I think
that this is the fastest possible start assuming that you don't send
any DTLS messages prior to getting a successful connectivity check
response.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Jul 2014 23:05:23 +0000

> any DTLS messages prior to getting a successful connectivity check

Actually, if the answerer (controlled endpoint) can send on any Valid pair, as in my suggestion, I don’t think you need the ICE role reversal for this optimization.  It can send ClientHello as soon as its first check succeeds, despite never having received any remote checks (with or without USE-CANDIDATE).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 16:28:27 -0700

> Actually, if the answerer (controlled endpoint) can send on any Valid pair, as in my suggestion, I don’t think you need the ICE role reversal for this optimization.  It can send ClientHello as soon…

You win.  I think that you just made ICE faster with no mechanism.
That's better than faster ICE with some mechanism.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Jul 2014 16:42:07 -0700

On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox <[email-masked]> wrote:

> >> The offerer can’t send its own connectivity checks until it receives an
> answer, because it needs the remote ufrag and password.  Without this, it
> doesn’t have any valid pairs, and so can’t send any media.
> >
> >> This suggestion might still save half an RTT, though? I’d need to work
> through a full ladder diagram to figure it out.
> >
> Actually, if the answerer (controlled endpoint) can send on any Valid
> pair, as in my suggestion, I don’t think you need the ICE role reversal for
> this optimization.  It can send ClientHello as soon as its first check
> succeeds, despite never having received any remote checks (with or without
> USE-CANDIDATE).
>
> This makes a lot of sense and we should do it. Implementations not
expecting media before choosing a selected pair (on the controlling side
this time) may eat the packet, but it won't be fatal.

---

From: Dan Wing <[email-masked]>
Date: Wed, 30 Jul 2014 19:00:45 -0700

> Actually, if the answerer (controlled endpoint) can send on any Valid pair, as in my suggestion, I don’t think you need the ICE role reversal for this optimization.  It can send ClientHello as soon…

Yep, ICE allows sending media once the pair becomes Valid  (middle of page 69, http://tools.ietf.org/html/rfc5245#page-69).  It is very reasonable that ClientHello is permitted to be sent to a Valid pair, too.

Towards the desire to remove a round trip, has there been consideration to folding the STUN messaging into the ClientHello?

-d

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 20:03:48 -0700

On Jul 30, 2014 7:00 PM, "Dan Wing" <[email-masked]> 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 ?

Yeah. It doesn't actually reduce round trips here because you still want to
confirm consent before doing the whole proof-of-possession thing. 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.

---

From: Dan Wing <[email-masked]>
Date: Thu, 31 Jul 2014 00:01:49 -0700

> 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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 31 Jul 2014 12:37:19 +0200

> Like http://tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-00 ?

The draft says:

-----------------------
   This requires additional state retention - especially at the (DTLS)
   server - when multiple connectivity checks are sent and received.
   This information does not add significantly to the state burden
   imposed by ICE.  Assuming that the client does not alter the
   configuration for each session, the Random and Cookie fields will
   vary in every ClientHello.
-----------------------

I will just talk about ICE-Lite servers in case they implement that spec:

- With "normal" ICE the Lite server manages ICE requests and once one
with USE-CANDIDATE arrives it is done.
- After that the ICE Lite server should just accept DTLS packets
coming from that source IP:port, and discard everything else.
- This means that just a single DTLS context must be set.

In the case of DTLS-ICE (draft above), the server should:

- Create a DTLS context for each different source address from which
it receives DTLS packets, which means keeping a map/list of source
addresses and associated DTLS contexts for each one.

Nothing too hard, but it is worth mentioning it.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jul 2014 10:43:26 -0700

On 31 July 2014 00:01, Dan Wing <[email-masked]> 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.