Re: [rtcweb] Consent alternative

[Magnus Westerlund <[e-mail]>]

On 2013-11-22 18:55, Martin Thomson wrote:
> I know that I've been a fan of consent via ICE, but with the decision
> in Berlin to move to DTLS only, several of us have observed that
> perhaps RFC 6520 might be a better alternative.
> 
> We've put together an exploration of the idea here:
> 
> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
> 
> The best part of this is that it changes the dynamics (for the better,
> I think).  You don't need to send extra packets if you are actively
> using the flow.  That means that 1:1 sessions won't need to spend
> extra cycles or bytes on keeping the session live.
> 
> There are some gotchas for multiparty sessions, but I believe those to
> be manageable.

Hi,

I have looked briefly on this and wonder if this isn't vulnerable to
active attacks from a attacker (Alice) that likes to use a set of WebRTC
browsers, including (Bob) to generate DDOS traffic towards the target
(Charlie).

So Alice has a web-service which see has attracted a user base or
subverted an existing one for her purpose. The users of said web-service
includes Bob.

So Alice gets Bob's browser to establish a PeerConnection with Alice,
establishing an DTLS security context between them. Then using the
regular signaling Alice triggers an ICE reneg, to move the transport
address target for the Alice to Bob PC to become between Bob and
Charlie. This will require that Alice can intercept or spoof binding
requests response to the Bob's binding requests, especially anyone
promoting it for use so that Bob thinks the ICE reneg succeeds with
Charlie's transport address.

When that has happened, Alice can send periodically Bob DTLS messages
with source address spoofed like they come from Charlie's transport
address to maintain consent. Alice also can use the Stats API and the
HTTP/Websocket connection to Alice web service to forge DTLS protected
RTCP report block messages for the traffic Bob sends to Charlie.

Comparing the ICE based mechanism and the DTLS based consent mechanisms
I would draw the following conclusions.

1. If one doesn't have any chance to intercept STUN binding requests at
all, they are equally secure.

2. If the attacker has some limited or very expensive method for
intercepting Bob's STUN binding requests, then he might be able to mount
the above attack using DTLS consent as he only needs interception
initially when moving Bob to the target, compared to continuously as
long as he like to maintain the attack using the ICE based method.

Cases when this might apply is when Bob are in a poorly protected shared
network and Alice or Alice agent likes to leave the network after having
initiated the attack, rather than have to remain.

This change of properties is due to that the consent is associated with
the DTLS connections security context, rather than constant return
routability with random token property that ICE has.

Cheers


Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------