Subject: [Perc] SSRC rewriting

From: Emil Ivov <[email-masked]>
Date: Wed, 1 Feb 2017 13:51:58 -0600

Hey all,

Back in Berlin I took an action item to write a draft that describes how 
one can resolve the security concerns around SSRC rewriting.

I dropped the ball on that, apologies, but can now pick it up again.

The issue is that I am not able to find anything that actually describes 
the problem (other than a mere mention of how SSRC splicing could maybe 
be a risk) and, personally, I am not able to think of a way one could 
mount a successful attack that way.

Is this described anywhere?

Thanks,
Emil

-- 
https://jitsi.org

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 6 Feb 2017 15:17:27 -0800

I have a vague memory some of the Ericsson folks put together a pretty reasonable set of slides on it. Perhaps those might be a starting point. 

> On Feb 1, 2017, at 11:51 AM, Emil Ivov <[email-masked]> wrote:
> 
> Hey all,
> 
> Back in Berlin I took an action item to write a draft that describes how one can resolve the security concerns around SSRC rewriting.
> 
> The issue is that I am not able to find anything that actually describes the problem (other than a mere mention of how SSRC splicing could maybe be a risk) and, personally, I am not able to think of a way one could mount a successful attack that way.
> 
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Emil Ivov <[email-masked]>
Date: Mon, 06 Feb 2017 23:24:16 +0000

Sounds good. Anyone has a reference to them?

Emil

On Mon, 6 Feb 2017 at 17:17, Cullen Jennings <[email-masked]> wrote:

>
> I have a vague memory some of the Ericsson folks put together a pretty
> reasonable set of slides on it. Perhaps those might be a starting point.
>
> the problem (other than a mere mention of how SSRC splicing could maybe be
> a risk) and, personally, I am not able to think of a way one could mount a
> successful attack that way.
> >
sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 Feb 2017 18:05:53 -0600

So Magnus and I just had an entire discussion about this without 
realizing we were offline. I am attaching the exchange here.

The takeaways for me are the following:

1. Up till now I am not aware of any attack that is specifically 
introduced by SSRC overwriting in the SFU.

2. We have a bigger issue to solve around SSRC enforcement.

Magnus please feel free to correct me or add anything I missed.

Cheers,
Emil

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 14 Feb 2017 16:35:01 -0800

Magnus said:

"If one allows multiple conference participants to use the same SSRC value,
then one can still do replacement. So one either need unique source SSRCs
or a binding to another ID that is maintained end-to-end. Previous PERC
discussions have been unclear in what direction this ends up in."

[BA] In the RTP translator topology, this concern does not arise, since the
SSRCs of the participants are required to be unique, and therefore it is
necessary for participants to detect conflicts with other participants in
the conference.  However, in the situation where the SFU terminates
RTP/RTCP, and conflicts can only occur between an individual participant
and the SFU, there is no guarantee that one participant won't have a
conflicting SSRC with another one.  This is not a problem for RTP, but it
*is* a problem for PERC if one assumes that key lookup is tied to the
original SSRC, since the receiver now does not know which key to use to
decrypt a payload from a given original SSRC.

 Magnus also said:

"So, if one recovers the original SSRC and that is enforced to be unique by
other mechanisms than the SFUs, then I don’t think you have an issue from
the SFU as attacker. One important aspect here is that the SFU must not be
able to manipulate some participant to use the same SSRC as another
participant. Thus, the SSRC handling needs to meet certain criteria.

[BA] If you are going to require SSRC uniqueness among all participants,
then aren't you in effect requiring the RTP translator topology.  I am
trying to understand the situation in which simultaneously:

a. The SSRC of each participant is unique.

b. The SFU modifies SSRCs.

c. The SFU does not terminate RTP/RTCP.

On Tue, Feb 14, 2017 at 4:05 PM, Emil Ivov <[email-masked]> wrote:

> So Magnus and I just had an entire discussion about this without realizing
> we were offline. I am attaching the exchange here.
>