Subject: [rtcweb] Using DTLS for ICE

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2012 11:30:50 -0700

One concern that I have with rtcweb is the amount of time it takes to
start a session.  Speaking as an Internet user well accustomed to long
round trip times, the fact that it could take up to 7 to get media
bothers me a little.  It turns out that this is unnecessary, with a
few tweaks.

I've written a draft on the subject:

  https://docs.google.com/document/d/1UZjCnqDmHcAOsETLZ4CRTmpHkm97PXMEebiRRqe8nXE/edit

I don't want to add to the reviewing burden or distract folks from
more important tasks.  But I've had some interest.  I plan to submit
this once draft submissions reopen.

--Martin

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Mar 2012 09:29:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Thomson
> Sent: Tuesday, March 13, 2012 11:31 AM
> To: [email-masked]
> Subject: [rtcweb] Using DTLS for ICE
> 
> bothers me a little.

As EKR commented in your googledocs, the DTLS cookie exchange isn't
necessary (or useful) if you're already doing ICE, so the un-optimized
case is at least one round-trip less than that.

> It turns out that this is unnecessary, with a
> few tweaks.
> 

It seems like a good idea worth considering.

-d

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Mar 2012 13:33:45 -0700

> case is at least one round-trip less than that.

Not you too.  As I told EKR, that's mostly just there for effect.  And
now you've gone an spoiled the effect.

But I did think that there is a window of opportunity for DoS if you
allow for the possibility of spoofed source IP+port.  I mean, that's
the scenario that the cookie was invented for, right?  After all, you
have to store all those ClientHello messages, valid or not.  Without
the cookie, you have no assurance that they are valid.  The STUN
messages have MESSAGE-INTEGRITY, but the ClientHello could have come
from anyone.

I guess that checking source IP+port would be sufficient for most
folks.  That does mean that you effectively force the attacker to
obtain the candidate pair details before he can DoS you, and the
window of opportunity is fairly narrow.

--Martin

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Mar 2012 14:14:41 -0700

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2012 1:34 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [rtcweb] Using DTLS for ICE
> 
> folks.

Exactly.  After doing ICE with that IP+port, then DTLS handshakes
can happen with that IP+port.  If ICE hasn't been done with that 
IP+port, DTLS handshakes should not happen with that IP+port.

But it's a nit.  I'm not worried about that nit of how ICE and
DTLS can work best together.  That should be written down somewhere,
but it is just background in your document.  I don't want to
concentrate on that.

>  That does mean that you effectively force the attacker to

You have proposed a useful optimization that 
reduces the round trips by, essentially, using the initial DTLS 
handshake messages in lieu of the ICE handshake messages.
What you are doing is collapsing the two.  I think that is a good
optimization, and I would like to pursue it.   Another approach, 
which I would like to discuss/compare with your proposal, is 
to put the initial DTLS handshake messages into the ICE 
messages themselves, as new STUN attributes.  This changes how
DTLS does its handshake, but your proposal changes how ICE
does its handshake.  There are pros/cons of either change.
Might be worth discussing over cookies.  EKR likes cookies.

-d