Subject: [Perc] Consensus call: SSRCs are immutable

From: Richard Barnes <[email-masked]>
Date: Wed, 11 Nov 2015 13:49:53 -0500

tl;dr: Do we have consensus that PERC should regard SSRCs as something
that an MDD MUST NOT change?  Please reply by Nov. 25.

At the PERC meeting at IETF 94, there was a discussion of which
portions of an SRTP packet an MDD should be allowed to modify.  At the
end of this discussion, there was pretty much unanimous agreement in
the room that MDDs should *not* be allowed to modify SSRC.  The only
people who were not explicitly in agreement were a couple of folks who
said they wanted to think about it.

This email is a formal call to confirm the consensus in the room.  If
you have any objections to the conclusion reached at the meeting --
especially if you were not at the meeting -- please reply to this
message no later than Wednesday, November 25.

Thanks,
--Richard

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 11 Nov 2015 19:13:57 +0000

> On Nov 11, 2015, at 1:49 PM, Richard Barnes <[email-masked]> wrote:
> 

I’d like to have a convincing story about how SSRC uniqueness is guaranteed before we make this decision.

Having the KDF hand out SSRC values would be one possibility, but it has architectural implications — there are parts of the RTP architecture that implicitly assume endpoints can self-assign SSRC values as needed, e.g. RFC 7160.

Alternately, the MDD could probably make collisions visible (even for sources that aren’t currently being routed) by forwarding/generating RTCP as necessary, but we need to make sure this scales for large conferences, and that it doesn’t open up the possibility for a malicious MDD to do anything too nasty.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 Nov 2015 21:52:24 +0000

Richard,

>that an MDD MUST NOT change?  Please reply by Nov. 25.

I thought we had agreement on this point.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 Nov 2015 21:58:39 +0000

Jonathan,

>guaranteed before we make this decision.

Do we need to the MDDs or KDF to guarantee uniqueness?  If two endpoints 
happen to select the same SSRC value, they can switch to a new SSRC 
value.  We expect collisions to be rare, but endpoints should be able to 
handle collisions and switch to a new SSRC to maintain uniqueness.

Issues with that?

Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Nov 2015 00:34:49 +0200

Hi,
Agree with Jonathan and want to add that collision detection when the endpoint assign SSRC should also work for the cascaded case as described in Magnus' draft and if the MDD assigns SSRCs it should not complicate using RFC5576 SSRC attribute.
Roni

-----Original Message-----
From: Perc [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: Wednesday, November 11, 2015 9:14 PM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [Perc] Consensus call: SSRCs are immutable

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

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 11 Nov 2015 22:36:45 +0000

> On Nov 11, 2015, at 4:58 PM, Paul E. Jones <[email-masked]> wrote:
> 
> Jonathan,
> 
> 
> Do we need to the MDDs or KDF to guarantee uniqueness?  If two endpoints happen to select the same SSRC value, they can switch to a new SSRC value.  We expect collisions to be rare, but endpoints should be able to handle collisions and switch to a new SSRC to maintain uniqueness.
> 
> Issues with that?

The endpoints can switch to a new SSRC value, provided they know that the other one selected the same SSRC value as they did.  For them to know this requires that the MDD forward correct information about the other endpoint’s source.

We’d need to specify what an MDD must do, and make sure that a misbehaving MDD that doesn’t do this can’t cause any security vulnerabilities.

---

From: John Mattsson <[email-masked]>
Date: Wed, 11 Nov 2015 23:39:32 +0100

On Wed, Nov 11, 2015 at 8:13 PM, Jonathan Lennox <[email-masked]> wrote:

> Having the KDF hand out SSRC values would be one possibility, but it has architectural implications — there are parts of the
> RTP architecture that implicitly assume endpoints can self-assign SSRC values as needed, e.g. RFC 7160.

Doesn't RFC7160 only assume that the client can use different
SSRCs/Change SSRC? I think having the KMF handing out a slice of SSRCs
would work.

> Alternately, the MDD could probably make collisions visible (even for sources that aren’t currently being routed) by
> forwarding/generating RTCP as necessary, but we need to make sure this scales for large conferences, and that it doesn’t open
> up the possibility for a malicious MDD to do anything too nasty.

I think it does, and by fooling endpoints into changing SSRC changes,
the MDD could cause collisions. I don't think the MDD can be allow to
affect e2e SSRCs in any way.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Nov 2015 17:40:22 -0500

Le 2015-11-11 17:36, Jonathan Lennox a écrit :
> The endpoints can switch to a new SSRC value, provided they know that
> the other one selected the same SSRC value as they did.  For them to
> know this requires that the MDD forward correct information about the
> other endpoint’s source.

Specifically, you mean the MDD must forward SR/RR, correct? Or are you
considering some other mechanism?

Simon

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Nov 2015 16:44:04 -0600

> affect e2e SSRCs in any way.

Sure, but if it could, say, present an authenticated time-local packet 
with a colliding SSRC, that should serve the purpose.

/a

---

From: John Mattsson <[email-masked]>
Date: Thu, 12 Nov 2015 00:01:50 +0100

On Wed, Nov 11, 2015 at 11:44 PM, Adam Roach <[email-masked]> wrote:
>>> Alternately, the MDD could probably make collisions visible (even for
>>> sources that aren’t currently being routed) by
>>> forwarding/generating RTCP as necessary, but we need to make sure this
>>> scales for large conferences, and that it doesn’t open
> Sure, but if it could, say, present an authenticated time-local packet with
> a colliding SSRC, that should serve the purpose.

Well, but a malicious MDD may like collisions and would not forward
such things, and I do not think the probability of collisions is small
enough. Also the KMF or some other trusted node would need to now the
e2e SSRCs to distribute a secure binding between the inband identifier
(e2e SSRC) and some more human readable identifier.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 Nov 2015 19:26:57 -0500

Such a malicious MDD would only cause the conference to perform poorly.  I don't see a security issue here. Rather, it's like having an MDD just discard all media packets or forward only some of them.

Paul

---

From: Emil Ivov <[email-masked]>
Date: Thu, 12 Nov 2015 07:40:10 -0600

Hey all,

> that an MDD MUST NOT change?  Please reply by Nov. 25.

I skipped out on PERC for a few months so apologies if I am missing 
something.

So, how would this limitation work with simulcast? The predominant way 
of implementing simulcast today is by having it transparent to 
receivers, who only ever see one stream. This implies having the MDD 
re-write some or all SSRCs for the various resolution streams.

If we are preventing the MDD from doing that then are we saying that 
this way of doing simulcast will be incompatible with PERC? What am I 
missing?

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 Nov 2015 08:33:45 -0600

> this way of doing simulcast will be incompatible with PERC? What am I 

The SSRC doesn't need to stay constant, as long as the mapping to the 
m-line can be properly determined. Without bundle, that mapping comes 
from the 5-tuple. With bundle, it's the MID.

Plan B is dead, yo.

/a

---

From: Emil Ivov <[email-masked]>
Date: Thu, 12 Nov 2015 08:53:04 -0600

On 12.11.15 г. 8:33, Adam Roach wrote:
> The SSRC doesn't need to stay constant,

You mean, on the receiver?

> as long as the mapping to the

OK, so you are saying that receivers would basically ignore the SSRC 
when they feed stuff to their depacketizers/decoders and would only care 
about MID (or maybe RID?).

I guess I am slightly bothered by the fact that no implementation out 
there would be able to do this today (we still need to consider what 
would happen to timestamp and sequence number rewriting) ... but if we 
are confident that they would all fall into line then I guess it's all 
peachy! :)

> Plan B is dead, yo.

Does Plan B know? ;)

More seriously, this has very little to do with signalling. It's about 
levels of termination in RTP B2BUAs. The point of handling simulcast as 
a single stream on the receiving end is not only about matching it to an 
m= line, but mostly about keeping it simple: you only ever get one thing 
and it's just that its resolution changes sometimes.

Emil

-- 
https://jitsi.org

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 12 Nov 2015 15:05:00 +0000

The issues discussed below are really related to selective forwarding / active speaker switching, not simulcast. The same issues remain with any form of source selection and selective forwarding toward receivers, independent of simulcast. Specifically, even without simulcast, the MSM and SFU RTP topologies which rewrite SSRC would not be allowed in PERC per the proposed rule on E2E SSRC. 

Mo

> from the 5-tuple. With bundle, it's the MID.

OK, so you are saying that receivers would basically ignore the SSRC when they feed stuff to their depacketizers/decoders and would only care about MID (or maybe RID?).

I guess I am slightly bothered by the fact that no implementation out there would be able to do this today (we still need to consider what would happen to timestamp and sequence number rewriting) ... but if we are confident that they would all fall into line then I guess it's all peachy! :)

Does Plan B know? ;)

More seriously, this has very little to do with signalling. It's about levels of termination in RTP B2BUAs. The point of handling simulcast as a single stream on the receiving end is not only about matching it to an m= line, but mostly about keeping it simple: you only ever get one thing and it's just that its resolution changes sometimes.

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 Nov 2015 09:13:11 -0600

On 11/12/15 08:53, Emil Ivov wrote:
> when they feed stuff to their depacketizers/decoders and would only 
> care about MID (or maybe RID?). 

No, since the MID isn't sent in every packet. There's a mapping from the 
m-line to the MID (this doesn't change), and from MID to an SSRC (this 
can change). Existing implementations are required to handle these kinds 
SSRC changes; see RFC 3550, section 8.2.

/a

---

From: Emil Ivov <[email-masked]>
Date: Thu, 12 Nov 2015 16:00:26 -0600

> SSRC changes; see RFC 3550, section 8.2.

Indeed they are and many do ... for different meanings of the word 
"handle". The point of an SSRC re-writing SFU is to remove any 
assumptions about how exactly such clients would react.

And, Mo Zanaty (mzanaty) wrote:
 > Specifically, even without simulcast, the MSM and SFU RTP topologies
 > which rewrite SSRC would not be allowed in PERC per the proposed rule
 > on E2E SSRC.

Mo, are you stating this as a choice that has already been made by PERC?

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 Nov 2015 18:02:24 -0600

> assumptions about how exactly such clients would react. 

What I'm hearing, then, is that perhaps the PERC framework might benefit 
from a small warning to implementors that they can't take lazy, 
out-of-spec shortcuts that might have worked in other contexts.

/a

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 13 Nov 2015 00:19:34 +0000

See Mo: inline. 

> SSRC changes; see RFC 3550, section 8.2.

Indeed they are and many do ... for different meanings of the word "handle". The point of an SSRC re-writing SFU is to remove any assumptions about how exactly such clients would react.

Mo: John proposed this in his presentation and there were no objections, but there were also some notable absentees that may have opinions (you, Bernard, etc.), and Jonathan wanted to think longer about it. Hence the chairs asking the list to confirm or discuss. 

Emil

-- 
https://jitsi.org

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 13 Nov 2015 15:26:05 +0100

On Thu, 12 Nov 2015 18:02:24 -0600
Adam Roach <[email-masked]> wrote:

> What I'm hearing, then, is that perhaps the PERC framework might
> benefit from a small warning to implementors that they can't take
> lazy, out-of-spec shortcuts that might have worked in other contexts.
> 

I don't understand the hostility to this approach: depending on the
scenario it's simple, things work, consistency is preserved on the
receiver side if you do things right and everybody's happy. SSRC
rewriting is sometimes needed, which is part of the reasoning that
eventually led to draft-ietf-straw-b2bua-rtcp, for instance, and ruling
it out doesn't seem sensible. Besides, although this may or may not be
an interesting fact in the matter, it's currently the only way to get
something working as far as SFUs are concerned in the WebRTC ecosystem
(still waiting for Firefox and Chrome to implement The Same Plan).

I personally agree with Emil that immutable SSRCs sound like an
unneeded constraint, at least from the arguments I've read, that adds
complexity where it's not strictly necessary.

Lorenzo

---

From: Luis Lopez <[email-masked]>
Date: Fri, 13 Nov 2015 16:00:49 +0100

The more I think about this the more I agree with Lorenzo and Emil. Making MSM and SFU topologies incompatible with PERC is a quite strong restriction which may significantly increase the complexity of implementing PERC on middleboxes which are currently relying of SSRC rewriting, and there are many (simulcast, voice activity switching, etc.) Before having a final decision about this, I would appreciate to see arguments on why this is necessary for PERC or on why this significantly improves the security and privacy properties of PERC. Otherwise, IMO we should think twice about accepting this as a consensus solution.

Best.

Luis.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 13 Nov 2015 15:54:37 +0000

We should back up to the real requirement which led to the proposal. See slide 6 in Paul's presentation (slides-94-perc-3). John proposed an anti-spoofing requirement which was unanimously agreed. This means perc requires some e2e source identification which middle boxes can't spoof. SSRC is the natural choice for RTP. There were proposals to allow rewriting SSRC while also conveying the E2E SSRC, but it was clear this adds more complexity than simply not allowing rewrites.

So if you want to allow rewriting SSRC, you should first think about and state your opinion on the fundamental issues of anti-spoofing requirements and using SSRC as the E2E source identification.

If complexity is your concern, there is certainly no simpler solution than immutable E2E SSRC. All other solutions which allow rewrites add complexity. 

Mo

On Nov 13, 2015, at 10:01 AM, Luis Lopez <[email-masked]> wrote:

Best.

Luis.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 13 Nov 2015 11:52:47 -0600

> We should back up to the real requirement which led to the proposal. See slide 6 in Paul's presentation (slides-94-perc-3). John proposed an anti-spoofing requirement which was unanimously agreed.…

This sounds reasonable to me. It would basically come down to adding a
hdrext that will be created by a PERC entity (the MDD) and consumed by
a PERC entity (the PERC layer of the endpoint) while still allowing
the SFU the liberty to funnel whatever it needs to the same codec
chain.

In order to provide some perspective: about a year ago we implemented
simulcast in Jitsi Videobridge with *no* ssrc rewriting. Endpoints
would see all the streams and switch between them as necessary.

That did work, but it did NOT work well.

Currently the WebRTC API does not provide enough information and
timely notifications for these switches to happen smoothly. We had to
rely on data channel signaling from the SFU that indicated when
switching had to happen. The resulting user experience was really not
great and most of the time a switch in streams ended up being
perceptible to the user. Trying to solve these glitches meant barely
improving the quality while incurring significant extra complexity at
both the SFU and the endpoint. Additionally, the added endpoint
complexity also had to be re-implemented on all platforms we wanted to
support (e.g. browser, iOS, android).

All in all it was pretty much a failed experiment.

So we went and redid everything with SSRC overwriting. That worked!

We are not alone. To quote Adam himself [0]:

   the vast majority of the use cases that make sense for
   simulcast involve browsers talking to an MCU (or similar server),
   sending multiple encodings per track in the browser-to-MCU direction,
   but receiving only one encoding per track in the MCU-to-browser direction

So again: adding an extra extension carrying the original SSRC (or
maybe even some other auth ID) sounds trivial to me in comparison to
the complexity that banning SSRC rewriting would incur.

Emil

[0] https://lists.w3.org/Archives/Public/public-webrtc/2015Aug/0028.html

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Fri, 13 Nov 2015 12:06:05 -0600

On 11/13/15 11:52 AM, Emil Ivov wrote:
> simulcast in Jitsi Videobridge with*no*  ssrc rewriting. Endpoints
> perceptible to the user.

This is solidly a Plan B issue, which means that it will be resolved 
when Chrome fixes this bug:
https://code.google.com/p/chromium/issues/detail?id=465349

With the approach defined by WebRTC/RTCWEB, these different SSRCs would 
all be treated as a single, unchanging MediaStreamTrack by the browser 
(which has the same result as your SSRC rewriting). Unless the 
application goes out of its way to look for SSRC changes, it won't even 
know they're going on.

It doesn't make any sense to make the security aspects of PERC more 
difficult to implement and more difficult to think about simply because 
one implementation is currently -- and temporarily -- out of specification.

/a

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 13 Nov 2015 20:58:25 +0000

Emil,

>the complexity that banning SSRC rewriting would incur.

Leaving IETF 93, I was left with the impression that we were going to 
allow rewriting SSRCs.  We had discussed this for two meetings and it 
seemed like folks were insistent on allowing it to change.  What was 
important -- even if we allow rewriting -- was to retain the original 
SSRC.  That is part of the motivation behind this text:
https://tools.ietf.org/html/draft-jennings-perc-double-00#section-4

We can encode things a little more efficiently than presented in that 
document, but the objective was just present a proposal for the 
end-to-end encryption that re-uses SRTP specs and allows for rewriting 
header fields.

It is trivial to replicate information in a header extension, but I will 
nonetheless note that it adds more processing complexity when decrypting 
the SRTP packet and it lengthens every single RTP packet.  Perhaps both 
are considered insignificant given the fact we're sending video streams, 
which requires a lot more processing and bandwidth.  It's still perhaps 
significant for audio flows.

So at 94, I was pleasantly surprised to hear general support for making 
the SSRC field immutable, albeit recognizing there were several people 
absent in the room.

I think what's most important is to get agreement that we will retain 
the SSRC value in some form end-to-end, since existing SRTP specs rely 
on it.

Secondarily, it's important to understand whether we can reasonably 
place a restriction on MDDs not to change the SSRC.

Paul

---

From: Emil Ivov <[email-masked]>
Date: Fri, 13 Nov 2015 17:07:30 -0600

On Fri, Nov 13, 2015 at 12:06 PM, Adam Roach <[email-masked]> wrote:
> This is solidly a Plan B issue,

It really, really isn't and it would be great if we stopped
distracting ourselves with signaling because this is a separate issue.

Chrome currently uses a SIM group in the SDP on the sending side and,
had anyone wanted to do that, it would have been trivial to reuse the
signaling on the receiving end. You could certainly say that Chrome's
implementation lacks the feature of allowing interchangeable SSRCs in
incoming streams, but I would never think the reason for that was
"because no one at Google could think of a Plan B-ish SDP syntax to
represent this with".

You could also just as easily choose to not implement that part even
with Unified, so again, signaling is entirely irrelevant to this whole
topic.

> which means that it will be resolved when
> Chrome fixes this bug:
> With the approach defined by WebRTC/RTCWEB, these different SSRCs would all
> be treated as a single, unchanging MediaStreamTrack by the browser (which
> has the same result as your SSRC rewriting). Unless the application goes out
> of its way to look for SSRC changes, it won't even know they're going on.
>
> difficult to implement and more difficult to think about simply because one
> implementation is currently -- and temporarily -- out of specification.

We used to think that the SIP universe would consist of proxies and
smart clients. We ended up with SBCs and very diverging client
implementations.

As long as there is a good chance for a non-trivial percentage of the
endpoints not to handle that out of the box, then people would rather
go and rewrite SSRCs

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Fri, 13 Nov 2015 17:21:26 -0600

On Fri, Nov 13, 2015 at 2:58 PM, Paul E. Jones <[email-masked]> wrote:
> Leaving IETF 93, I was left with the impression that we were going to allow
> rewriting SSRCs.  We had discussed this for two meetings and it seemed like
> folks were insistent on allowing it to change.  What was important -- even
> if we allow rewriting -- was to retain the original SSRC.  That is part of
> the motivation behind this text:
> document, but the objective was just present a proposal for the end-to-end
> encryption that re-uses SRTP specs and allows for rewriting header fields.
>
> nonetheless note that it adds more processing complexity when decrypting the
> SRTP packet and it lengthens every single RTP packet.  Perhaps both are
> considered insignificant given the fact we're sending video streams, which
> requires a lot more processing and bandwidth.  It's still perhaps
> So at 94, I was pleasantly surprised to hear general support for making the
> SSRC field immutable, albeit recognizing there were several people absent in
> the room.
>
> I think what's most important is to get agreement that we will retain the
> SSRC value in some form end-to-end, since existing SRTP specs rely on it.
>
> Secondarily, it's important to understand whether we can reasonably place a
> restriction on MDDs not to change the SSRC.

The point that I've been making is that, if we do that, we would
potentially compromise PERC adoption for most SFUs out there.

What we could easily do though is place the choice in the hands of the
implementors. It would suffice to only require a hdrext with the
original SSRC when it was actually overwritten.

This way, if you believe that the burden of the added processing and
bandwidth is greater for you than that of the extra complexity of not
overwriting SSRCs, then you wouldn't do it.

Emil

-- 
https://jitsi.org

---

From: "Roni Even" <[email-masked]>
Date: Sun, 15 Nov 2015 09:33:44 +0200

> > It is trivial to replicate information in a header extension, but I
> > will nonetheless note that it adds more processing complexity when
> > decrypting the SRTP packet and it lengthens every single RTP packet.
> > Perhaps both are considered insignificant given the fact we're sending
> > video streams, which requires a lot more processing and bandwidth.
> > It's still perhaps significant for audio flows.
> >
> > So at 94, I was pleasantly surprised to hear general support for
> > making the SSRC field immutable, albeit recognizing there were several
> > people absent in the room.
> >
on
> it.
potentially
> compromise PERC adoption for most SFUs out there.
> 
> implementors. It would suffice to only require a hdrext with the original
SSRC
> when it was actually overwritten.
[Roni Even] Who is the implementor here? This requires support both on the
MDD and the Perc endpoints. So when an MDD replaces the original SSRC it
MUST be sure that the receiver knows how to handle this case which
complicates interoperability.

---

From: Adam Roach <[email-masked]>
Date: Sun, 15 Nov 2015 05:01:49 -0600

> distracting ourselves with signaling because this is a separate issue.

No, it's not just signalling, precisely because of the way Plan B was 
intended to work.

One of the central theses of Plan B was that streams could be added and 
removed from a session with zero signaling. If you wanted a new track, 
you just started hurling a new SSRC at the other side, and the remote 
browser would create new MST objects to represent it. It was up to the 
application to be able to figure out how to handle the resulting mess.

One of my objections -- and your experience bore it out -- was that this 
would be a unsolvable morass of confusion for app developers, and that 
this would result in an unsatisfactory experience for users.

In any case, it's precisely this signaling-free ginning up of new, 
unsignaled, uncorrelated SSRCs that results in the problems you talk 
about. It's not a signaling issue *because* there is no signaling. Once 
your application is written on top of a system that explicitly signals 
new tracks, and which has an explicit track-to-MST mapping, the problem 
you've described evaporates.

/a

---

From: Emil Ivov <[email-masked]>
Date: Sun, 15 Nov 2015 09:29:08 -0600

On Sunday, 15 November 2015, Adam Roach <[email-masked]> wrote:

> removed from a session with zero signaling.  If you wanted a new track, you
> just started hurling a new SSRC at the other side, and the remote browser
> would create new MST objects to represent it. It was up to the application
> to be able to figure out how to handle the resulting mess.

> would be a unsolvable morass of confusion for app developers, and that this
> would result in an unsatisfactory experience for users.
>
> unsignaled, uncorrelated SSRCs that results in the problems you talk about.
> It's not a signaling issue *because* there is no signaling. Once your
> application is written on top of a system that explicitly signals new
> tracks, and which has an explicit track-to-MST mapping, the problem you've
> described evaporates.

I think you may be confusing Plan B and No Plan. Chrome  and Plan B have
always required explicit MS to SSRC  mapping and just throwing SSRCs at
Chrome without signalling them has never worked. (Not that I agree with
your assertions about how non-requiring signaling is a failed approach but
I really don't want to go there .... we have plouted this thread woth
signaling discussions long enough).

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Sun, 15 Nov 2015 09:32:50 -0600

Hey Roni,

On Sunday, 15 November 2015, Roni Even <[email-masked]> wrote:

> > On Fri, Nov 13, 2015 at 2:58 PM, Paul E. Jones <[email-masked]
> <javascript:;>>
> > wrote:
> > > Emil,
> > >

Yes, you are right. The choice would have to be made by the MDD
implementor. Endpoints would have to support both possibilities.

Emil

> > [email-masked] <javascript:;>

-- 
https://jitsi.org

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Nov 2015 13:34:40 +0100

Den 2015-11-12 kl. 01:26, skrev Paul E. Jones:
> Such a malicious MDD would only cause the conference to perform poorly.
> I don't see a security issue here. Rather, it's like having an MDD just
> discard all media packets or forward only some of them.

I think that will highly depend on if the solution has a higher layer 
endpoint identifier such that a receiver that has the group key from the 
KMF can determine that the received packets with a particular SSRC is in 
fact coming from two different end-points. To me this will require that 
an endpoint distributing its E2E media stream key needs to include a 
endpoint identifier. If that is not happening then a MDD can perform the 
splicing attack, and gets incentive to split the conference media 
stream's visibility in an attempt to generate SSRC collisions which the 
end-points are not aware of.

Yes, this is a trade-off. But I don't see how we can secure the 
conference unless all end-points that is using the same group key has 
unique (or extremely low risk of collision smaller than <2^-80) 
identifiers to prevent the splicing attack.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Nov 2015 14:59:38 -0800

If you are assuming that all participants use a group key for
authentication/confidentiality, then you are going to have a hard time
authenticating the origin of packets, regardless of what identifiers are
being used.  At best you can ensure that a packet is being sent from one of
the current participants possessing the current group key.

We *really* need a threat model here, so we can understand whether we have
agreement on the basic security assumptions and can live with the
consequences of those assumptions.

On Wed, Nov 25, 2015 at 4:34 AM, Magnus Westerlund <
[email-masked]> wrote:

> fact coming from two different end-points. To me this will require that an
> endpoint distributing its E2E media stream key needs to include a endpoint
> identifier. If that is not happening then a MDD can perform the splicing
> attack, and gets incentive to split the conference media stream's
> visibility in an attempt to generate SSRC collisions which the end-points
> are not aware of.
>
> Yes, this is a trade-off. But I don't see how we can secure the conference
> unless all end-points that is using the same group key has unique (or
> extremely low risk of collision smaller than <2^-80) identifiers to prevent
> the splicing attack.
>
> Cheers
>
> Magnus Westerlund
>

---

From: John Mattsson <[email-masked]>
Date: Thu, 26 Nov 2015 12:14:25 +0000

Bernard Aboba <[email-masked]> wrote:

>>Mo said:
>>
>>"Specifically, even without simulcast, the MSM and SFU RTP topologies
>>which
>>rewrite SSRC would not be allowed in PERC per the proposed rule on E2E
>>SSRC."

>[BA] Given the popularity of the MSM and SFU RTP topologies,
>disallowing them in PERC is not very practical.  As Emil has noted,
>even simple use cases (like simulcast) are implemented with these
>topologies today.

[JM] I am starting to have doubts myself. I proposed the disallowing in
Yokohama based on the fact that SSRC and timestamp need to transferred e2e
and
that disallowing some topologies reduced the complexity of the PERC
solution.
But given the resistance to make other much smaller implementation changes
to
mitigate splicing attacks and to ensure metadata privacy, I as starting to
ask
myself why Ericsson should do the quite large task of changing topology…

JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Mon, 30 Nov 2015 15:25:49 +0000

> From: John Mattsson [mailto:[email-masked]]
> Sent: Thursday, November 26, 2015 4:14 AM
> To: Bernard Aboba; Magnus Westerlund
> Cc: Eric Rescorla; [email-masked]

[DB]  Not sure of popularity-level of MSMs, but the SFM [sect 3.7 of 7667 update] does allow for no-SSRC rewriting.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Nov 2015 16:31:00 +0100

Hi,

One important consideration for actually doing immutable SSRCs would be 
that end-to-end protected (authenticated or 
authenticated+confidentiality) RTCP actually becomes much more straight 
forward. Otherwise each end-point will still need to have some mapping 
table and try to verify that it is correct.

If you look at the end of the slide-set I sent out earlier today there 
is a section on RTCP and possible needs end-to-end.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Nov 2015 10:56:48 -0500

Hey Magnus,

Suppose the endpoint had access to the original SSRC (as in
draft-jennings-perc-double).  Does that have the same benefits as an
immutable SSRC from the point of view of what you're talking about?

--Richard

On Mon, Nov 30, 2015 at 10:31 AM, Magnus Westerlund
<[email-masked]> wrote:
> Hi,
>
> One important consideration for actually doing immutable SSRCs would be that
> end-to-end protected (authenticated or authenticated+confidentiality) RTCP
> actually becomes much more straight forward. Otherwise each end-point will
> still need to have some mapping table and try to verify that it is correct.
>
> If you look at the end of the slide-set I sent out earlier today there is a
> section on RTCP and possible needs end-to-end.
>
> Cheers
>
> Magnus
>
>
>> [DB]  Not sure of popularity-level of MSMs, but the SFM [sect 3.7 of 7667
>> update] does allow for no-SSRC rewriting.
>>
>>