Re: [rtcweb] Consent alternative

[Martin Thomson <[e-mail]>]

On 3 December 2013 21:08, Muthu Arul Mozhi Perumal (mperumal)
<[e-mail]> wrote:
> |I think that you have missed the point here. The point is that A and
> |B share a DTLS connection, and B uses ICE to convince A to send
> |packets for that connection to C.
>
> Can you describe that in terms of a real-world use case? I don't see how that is different from a 3PCC scenario where the 3PCC (e.g a call center agent) talks to both A and C, and transfers A to C (aka full-consult transfer).

I'm not describing a use case, I'm describing an attack.  A 3PCC
transfer should result in a new DTLS connection.  That's a completely
different scenario.

>
> |All this requires is that B is able to spoof the source address of
> |packets to appear as coming from C.
>
> B doesn't have to spoof anything at all -- for the ICE connectivity check to succeed b/w A and C, B just needs to send A's ice-ufrag and ice-pwd to C and vice versa.

Yes, B does have to spoof something.  If B's goal is to cause A to
send packets to C without consent from C (or, more precisely, even
when C initially consents, then ceases to consent), then spoofing is
necessary.