Re: [rtcweb] Consent alternative

[Dan Wing <[e-mail]>]

On Dec 4, 2013, at 10:59 AM, Martin Thomson <[e-mail]> wrote:

> On 3 December 2013 16:24, Dan Wing <[e-mail]> wrote:
>> Requiring sending an ICE request (and receiving an ICE response) would also _almost_ work -- that is, when remote party claims to change their IP address not only is an ICE request from their IP address needed, but also need to send an ICE request to their new IP address and get an ICE response (same as you are saying to send them a DTLS heartbeat to their new address).
> 
> Yes, almost.  If ICE restart didn't also correspond with a change in
> ufrag/pwd it might.  As it stands, ICE restart and new victim look
> exactly the same.
> 
>> To thwart that, an ICE attacker would need to be on-path and we could envision places where B (the attacker in your enumerated list above) is on a shared network with C (victim), such as shared WiFi.
> 
> In general, I find that on-path attackers aren't especially
> interesting when it comes to DoS attacks.  Shared WiFi seems like it
> might avoid the "directly on path" part, though since the attacker
> disadvantages themselves as much as their victim, I don't worry.

Sure.  But the attacker doesn't need to remain on that shared network to continue the attack, so the attacker is not (necessarily) disadvantaging themselves -- the attacker just needed to see the packets on the wire and send a command-and-control message to another host that generates the spoofed ICE consent packets.  

> 
>> DTLS heartbeat prevents that attack because B (the attacker) doesn't know the necessary secrets to generate the DTLS heartbeat message (whereas with ICE, B would know the ICE username and ICE password).  If I have all that correct for how ICE consent could be attacked, it shows a security advantage of DTLS consent over ICE consent.
> 
> Yes.  That is definitely an advantage.

-d