Subject: [Perc] Double encryption - E2E SSRC collision on inner crypto

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 12:46:00 +0200

Hi all,

I have realized about an edge case that I don't think we have taken into 
account.

It is unlikely, but possible that two different peers use the same SSRC 
when sending data to the SFU. The SFU will protect against this HBH ssrc 
collision by re-writing the ssrcs to all the participants.

The inner crypto will be applied on the original ssrcs from OHB and if 
my understanding is correct, that will cause the SRTP session to fail to 
authenticate the packets from one of the peers due to the sequence 
number jumps.

Can anyone confirm if this scenario is correct? Do we have any solution 
for this?

Best regards

Sergio

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 Apr 2017 11:32:16 -0500

On 4/24/17 05:46, Sergio Garcia Murillo wrote:
> It is unlikely, but possible that two different peers use the same 
> SSRC when sending data to the SFU. The SFU will protect against this 
> HBH ssrc collision by re-writing the ssrcs to all the participants. 

The issue of SSRC collision detection and resolution is covered at 
length and with normative language in 
<https://tools.ietf.org/html/rfc3550#section-8.2>. The entities involved 
in this process are exclusively media sources, not media intermediaries.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Apr 2017 10:27:36 -0700

Sergio --

Because PERC utilizes the original SSRC as a means to determine the key
utilized to encrypt the payload, SSRC uniqueness is required across all
members of the conference.

This then raises the question of how SSRC conflicts are detected between
the participants and which of the RTP topologies defined in RFC 7667 can be
used with PERC.

For example, while it might be desirable for a PERC SFU to support SSRC and
Sequence Number rewriting, a PERC SFU doing this still has to enable the
endpoints to be aware of the original SSRCs, so as to avoid conflicts.

Effectively, it seems like asking for two distinct RTP topologies to be in
use at the same time.

>From the point of view of the original SSRCs, it seems that an RTP
translator topology is needed. However, if an SFU is doing SSRC and
Sequence Number rewriting, then it is acting as a Selective Forwarding
Middlebox (Section 3.7) with respect to the rewritten SSRCs.

On Mon, Apr 24, 2017 at 3:46 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> The inner crypto will be applied on the original ssrcs from OHB and if my
> understanding is correct, that will cause the SRTP session to fail to
> authenticate the packets from one of the peers due to the sequence number
> jumps.
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 21:19:27 +0200

On 24/04/2017 19:27, Bernard Aboba wrote:
> Sergio --
>
> Because PERC utilizes the original SSRC as a means to determine the 
> key utilized to encrypt the payload, SSRC uniqueness is required 
> across all members of the conference.
>
Hi Bernard,

Aren't you referring to EKT? AFAIK in double encryption there is a 
single E2E key shared by all participants.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 21:37:28 +0200

On 24/04/2017 19:27, Bernard Aboba wrote:
> This then raises the question of how SSRC conflicts are detected 
> between the participants and which of the RTP topologies defined in 
> RFC 7667 can be used with PERC.
>
> For example, while it might be desirable for a PERC SFU to support 
> SSRC and Sequence Number rewriting, a PERC SFU doing this still has to 
> enable the endpoints to be aware of the original SSRCs, so as to avoid 
> conflicts.
>
> Effectively, it seems like asking for two distinct RTP topologies to 
> be in use at the same time.
>
I agree, and i don't see an easy way of solving this without ensuring 
the SSRC uniqueness. For EKT maybe ssrc assignment may be done by the 
key distributor when providing the key to the endpoint, but for double 
encryption I would prefer a simpler approach, like reducing the 
randomness space of SSRC to latest 16bits, and set the first 16bits to a 
"participant id" set by the KD or the SFU.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 21:42:54 +0200

On 24/04/2017 18:32, Adam Roach wrote:
> <https://tools.ietf.org/html/rfc3550#section-8.2>. The entities 
> involved in this process are exclusively media sources, not media 
> intermediaries.

I am not aware of a single SFU that handles SSRC collision that, they 
all overwrite the SSRC to avoid it. The E2E SSRC collision will happen 
with the SSRC values of the OHB when doing the inner crypto, so RTP 
mechanism don't apply.

Best regards
Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Apr 2017 13:26:56 -0700

Sergio said:

"I am not aware of a single SFU that handles SSRC collision that, they all
overwrite the SSRC to avoid it."

[BA] I am also not aware of an SFU that does selective dropping that is
designed as an RTP translator.   While in theory it may be possible to
design such an SFU, such a design would not fit naturally into any of the
RTP topologies described in RFC 7667, which creates considerable
complexity.

An SFU needs to rewrite sequence numbers and control the contents of the
RTCP SRs sent to the endpoints or else the endpoints will think that the
packets dropped by the SFU represent gaps that need to be repaired.

An SFU also needs to support congestion control and HBH repair, which means
that it needs to read the contents of RTCP SRs, RRs, congestion control and
feedback messages sent by the endpoints, apply RTX/FEC to fill in gaps, as
well as originating congestion control and feedback messages (as well as
RTX/FEC).

Trying to do these things while maintaining the illusion that the SFU is
functioning as an RTP translator requires the SFU to forward some RTCP
packets (e.g. BYE, SDES), while modifying the contents of other RTCP
packets (SRs, RRs) to present a consistent view to endpoints, and acting
upon and originating still other RTCP packets (e.g. feedback messages) with
the SSRCs of other endpoints.

It's easy to see why developers would choose to avoid this complexity.

On Mon, Apr 24, 2017 at 12:42 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

>> The issue of SSRC collision detection and resolution is covered at length
>> and with normative language in <https://tools.ietf.org/html/r
>> fc3550#section-8.2>. The entities involved in this process are
>> exclusively media sources, not media intermediaries.
>>
>
> I am not aware of a single SFU that handles SSRC collision that, they all
> overwrite the SSRC to avoid it. The E2E SSRC collision will happen with the
> SSRC values of the OHB when doing the inner crypto, so RTP mechanism don't
> apply.
>
> Best regards
> Sergio
>
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Apr 2017 16:39:22 -0400

Le 2017-04-24 à 15:42, Sergio Garcia Murillo a écrit :
> all overwrite the SSRC to avoid it.

Mine handles it as described in RFC 3550. Works perfectly. In production
with lots of traffic.

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]