Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Mar 2019 08:38:10 -0700

It’s a very reasonable request to ask for more info here but given that huge amounts of WG meeting were devoted to this, I am certain not going to try and explain the whole splicing attack.

However to get to the heart of why the MID is different than the SSRC in the splicing attack,  the key thing with the splicing attack is the attacker gets the receiver to use a valid, but not really the correct, SRTP crypto context. As outlined in https://tools.ietf.org/html/rfc3711#section-3.2 <https://tools.ietf.org/html/rfc3711#section-3.2> , the crypto context looked up from dest IP:port and SSRC. So changing the SSRC allows the attacker in the splicing attack to switch to a crypto context of the attackers choosing (and one the attacker has keys for). Changing the other things such as the MID does not allow this. 

> On Feb 24, 2019, at 1:01 AM, Alexandre GOUAILLARD <[email-masked]> wrote:
> 
> Cullen,
> 
> Would you mind to give more detail as to why you think it's different? From where we stand, both approaches end-up deceiving the receiver into believing some media is coming from one source while it's not. With that definition of "effect", both the src splicing attack and Sergio proposed attack have the same effect.
> Agreed, PERC addresses the case where it is due to SSRC manipulation, but if it does not address the other ways to achieve the same effect, it still fail at protecting the receiver, at the perceived huge cost of removing the capacity to support other important use cases cited before.
> 
> Do you have an implementation of PERC, as promised at IETF'99, for us and others to test against?
> 
> Beyond the difference, do you think that the scenario sergio proposed:
> - is a real problem ?
> - should be addressed ?
> 
> Sergio,
> feel free to prepare a working demo to make your point. If I understand correctly, what you propose can be done today already quite easily.
> 
> 
> 
> 
> 
> On Sun, Feb 24, 2019 at 10:11 AM Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> In the media framework it is stated the following regarding SSRC splicing attacks:
>> 
>>    The splicing attack is an attack where a Media Distributor receiving
>>    multiple media sources splices one media stream into the other.  If
>>    the Media Distributor is able to change the SSRC without the receiver
>>    having any method for verifying the original source ID, then the
>>    Media Distributor could first deliver stream A and then later forward
>>    stream B under the same SSRC as stream A was previously using.  By
>>    not allowing the Media Distributor to change the SSRC, PERC mitigates
>>    this attack.
>> However, if BUNDLE and MID are used, and there is no ssrc signaling done in SDP, the following RTP demuxing rules from BUNDLE spec applies:
>> 
>>    If the packet has a MID, and the packet's extended sequence number
>>    is greater than that of the last MID update, as discussed in
>>    [RFC7941], Section 4.2.6 <https://tools.ietf.org/html/rfc7941#section-4.2.6>, update the MID associated with the RTP
>>    stream to match the MID carried in the RTP packet, then update the
>>    mapping tables to include an entry that maps the SSRC of that RTP
>>    stream to the "m=" section for that MID.
>> Given that MID is by definition HBH as it must match the negotiated SDP O/A, then the MD could arbitrarily change the MID for an RTP packet and associate it with whatever transceiver it wishes, effectively having the same effect than the SSRC splicing attack (at least in perc double where all participants share the same inner e2e key and there).
>> 
>> 
> 
> No, it would not have the same effect at all. 
> 
> 
> _______________________________________________
> Perc mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>
> 
> 
> -- 
> Alex. Gouaillard, PhD, PhD, MBA
> ------------------------------------------------------------------------------------
> President - CoSMo Software Consulting, Singapore
> ------------------------------------------------------------------------------------
> sg.linkedin.com/agouaillard <http://sg.linkedin.com/agouaillard>
> 
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 1 Mar 2019 17:23:31 +0100

On 01/03/2019 16:38, Cullen Jennings wrote:
> However to get to the heart of why the MID is different than the SSRC 
> in the splicing attack,  the key thing with the splicing attack is the 
> attacker gets the receiver to use a valid, but not really the correct, 
> SRTP crypto context. As outlined in 
> https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto context 
> looked up from dest IP:port and SSRC. So changing the SSRC allows the 
> attacker in the splicing attack to switch to a crypto context of the 
> attackers choosing (and one the attacker has keys for). Changing the 
> other things such as the MID does not allow this. 

You are describing how ssrc splicing works, not what are its effects, or 
why it is an issue. I think I have found the origin of the ssrc 
rewriting issue and the splicing attack for perc in here:

https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerations-00.txt 

3.9.  SSRC

    The SSRC identifies the source of the RTP packet.  As each SSRC has
    its own RTP sequence number space as well as timestamp sequence,
    collisions shall be avoided.  For the PERC usage it is also important
    that a receiving endpoint can separate two different originating
    sources and to map the SSRC to a human readable name (or alias).  The
    important security related issue is that unless the originating RTP
    stream can be identified the MDD could create one outgoing stream
    that selects packets from either of them.  This may be challenging
    due to replay protection, but not impossible depending on how the
    sequence number and timestamps align.  To avoid having multiple
    identifers for the RTP packet stream, the design team has proposed
    that the SSRC shall be unique and the original value preserved to the
    receiving endpoint.

    Even if the originating endpoints have unique SSRCs, it is not clear
    if the same requirement will be extended to the MDD, and then
    especially media switching RTP mixers that have their own SSRCs.
    Thus translation of SSRC as a method for dealing with SSRC collisions
    may need to be dealt with.

    The original SSRC needs to be authenticated end-to-end to prevent the
    splicing attack described above.

So the main issue here is that  "endpoint can separate two different 
originating sources and to map the SSRC to a human readable name (or 
alias)". By modifying the MIDs the MD is able to do exactly that, and 
have the same effect than splicing attack without having to rewrite the 
ssrcs, that is, the endpoint will not be able to differentiate rtp 
packets coming from two different sources as the MID is used for routing 
and not the ssrc.

Best regards

Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Mar 2019 09:19:31 -0800

Sergio said:

"So the main issue here is that  "endpoint can separate two different
originating sources and to map the SSRC to a human readable name (or
alias)". By modifying the MIDs the MD is able to do exactly that, and have
the same effect than splicing attack without having to rewrite the ssrcs,
that is, the endpoint will not be able to differentiate rtp packets coming
from two different sources as the MID is used for routing and not the ssrc."

[BA] Let me attempt to unpack this. There are two issues here, which relate
to:

1. Effects of changing the RTP header SSRC

2. Effects of manipulating the original" SSRC associated with the e2e
keys.

Taking each in turn:

1. Changing the RTP header SSRC affects the routing of audio/video seen by
the user but does not affect the integrity of media, which is protected by
the e2e keys. By changing the RTP header SSRC it is possible to "splice"
the media or cause the a/v rendered in audio/video tags to switch between
users (e.g. dominant speaker protection).  As we have discussed this is
very common and causes few problems today, so it really can't be thought of
as an "attack".

2. I believe this is the aspect Cullen is referring to, which provides an
attacker with the ability to fool an endpoint into accepting as authentic a
manipulated payload.  This can be used to create a "deep fakes" so it is a
genuine attack.

Addressing this doesn't require outlawing the modification of the RTP
header SSRC.  If the original SSRC is included in the payload in cleartext
and integrity protected along with the rest of the payload, then the
payload crypto-context is unaffected by modifications to the SSRC included
in the RTP header.  The endpoint determines the appropriate keys for
integrity protection and payload decryption from the payload SSRC, not the
RTP header SSRC.

Of course, for this to work, conference participants cannot be allowed to
masquerade as each other.  That is, if multiple conference endpoints
possess the e2e keys used to encrypt and integrity protect payload data,
then they can source "deep fake" media that appears to originate from
another party.  As you have pointed out, this is a fundamental problem that
the PERC framework does not address.

However, it can be addressed if trust is rooted in hardware (e.g. the TPM)
and that e2e keys are not accessible to the endpoints (either Javascript or
the browser).  AFAICT, PERC key management doesn't meet this requirement,
but some content protection schemes claim to do so.

On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo <
[email-masked]> wrote:

> However to get to the heart of why the MID is different than the SSRC in
> the splicing attack,  the key thing with the splicing attack is the
> attacker gets the receiver to use a valid, but not really the correct, SRTP
> crypto context. As outlined in
> attackers choosing (and one the attacker has keys for). Changing the other
> things such as the MID does not allow this.
>
>
> why it is an issue. I think I have found the origin of the ssrc rewriting
> issue and the splicing attack for perc in here:
>
> alias)". By modifying the MIDs the MD is able to do exactly that, and have
> the same effect than splicing attack without having to rewrite the ssrcs,
> that is, the endpoint will not be able to differentiate rtp packets coming
> from two different sources as the MID is used for routing and not the ssrc.
>
>
> Best regards
>
> Sergio

---

From: Emil Ivov <[email-masked]>
Date: Sun, 3 Mar 2019 07:15:35 +0000

On Fri 1 Mar 2019 at 15:38, Cullen Jennings <[email-masked]> wrote:

>
> It’s a very reasonable request to ask for more info here but given that
> huge amounts of WG meeting were devoted to this, I am certain not going to
> try and explain the whole splicing attack.
>

Throughout the considerable WG time devoted to this so called attack, you
have never really bothered to present anything but handwaiving about it.
This is beyond ridiculous.

As Bernard points out, any actual attempt to think of splicing here results
in schemes that are as easy to thwart  as adding a simple comparison with
the SSRC in the OHB.

Emil

> Would you mind to give more detail as to why you think it's different?
> From where we stand, both approaches end-up deceiving the receiver into
> believing some media is coming from one source while it's not. With that
> definition of "effect", both the src splicing attack and Sergio proposed
> attack have the same effect.
> Agreed, PERC addresses the case where it is due to SSRC manipulation, but
> if it does not address the other ways to achieve the same effect, it still
> fail at protecting the receiver, at the perceived huge cost of removing the
> capacity to support other important use cases cited before.
>
> feel free to prepare a working demo to make your point. If I understand
> correctly, what you propose can be done today already quite easily.
>
>
>
>
>
> On Sun, Feb 24, 2019 at 10:11 AM Cullen Jennings <[email-masked]> wrote:
>
>>
>>
>> On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo <
>> However, if BUNDLE and MID are used, and there is no ssrc signaling done
>> in SDP, the following RTP demuxing rules from BUNDLE spec applies:
>>
>> Given that MID is by definition HBH as it must match the negotiated SDP
>> O/A, then the MD could arbitrarily change the MID for an RTP packet and
>> associate it with whatever transceiver it wishes, effectively having the
>> same effect than the SSRC splicing attack (at least in perc double where
>> all participants share the same inner e2e key and there).
>>
>>
> sg.linkedin.com/agouaillard
>
>    -
>
-- 
sent from my mobile

---

From: Justin Uberti <[email-masked]>
Date: Sun, 3 Mar 2019 18:25:52 -0800

On Sat, Mar 2, 2019 at 11:15 PM Emil Ivov <[email-masked]> wrote:

> As Bernard points out, any actual attempt to think of splicing here
> results in schemes that are as easy to thwart  as adding a simple
> comparison with the SSRC in the OHB.
>

I have to agree with Emil and Bernard - since the middlebox is only
mutating the outer SSRC, it can't control the SRTP context used for the
inner decryption (and if it did mutate the inner SSRC, this would be
immediately detectable).

Perhaps I'm missing something - since it sounds like this particular
concern was discussed at length in previous IETF meetings, could you send
along a link to a prior presentation that lays out the problem?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 4 Mar 2019 09:42:03 +0100

On 03/03/2019 8:15, Emil Ivov wrote:
>
> On Fri 1 Mar 2019 at 15:38, Cullen Jennings <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     It’s a very reasonable request to ask for more info here but given
>     that huge amounts of WG meeting were devoted to this, I am certain
>     not going to try and explain the whole splicing attack.
>
>
> Throughout the considerable WG time devoted to this so called attack, 
> you have never really bothered to present anything but handwaiving 
> about it. This is beyond ridiculous.
>

For one of our clients that required per packet identity assurance,  we 
have solved it by including the participant id in the inner encrypted 
payload that is transported end to end, instead of relying in spurious 
ssrc to participant mappings.

Best regards

Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 4 Mar 2019 09:48:47 +0100

On 04/03/2019 3:25, Justin Uberti wrote:
>         It’s a very reasonable request to ask for more info here but
>         given that huge amounts of WG meeting were devoted to this, I
>         am certain not going to try and explain the whole splicing attack.
>
>
>     Throughout the considerable WG time devoted to this so called
>     attack, you have never really bothered to present anything but
>     handwaiving about it. This is beyond ridiculous.
>
>     As Bernard points out, any actual attempt to think of splicing
>     here results in schemes that are as easy to thwart  as adding a
>     simple comparison with the SSRC in the OHB.
>
> mutating the outer SSRC, it can't control the SRTP context used for 
> the inner decryption (and if it did mutate the inner SSRC, this would 
> be immediately detectable).

Moreover, in PERC there is no mechanism to correlate the ssrc to an 
specific participant or how to coordinate the information between the 
peers in the conference. So, in WebRTC context, that must be implemented 
by the js application, which we agreed was not a trusted party.

Even if we defined a protocol for doing that which is implemented 
natively on browsers, the best we will be able to do is to add an 
identity attribute to the media stream tracks. But then again, the UI is 
implemented by the app js, which will be responsible of putting the 
correct participant label on top of the correct label. And even if we 
trust the application, there are browser extensions than can modify the 
html content and easily switch the content of the participant labels text.

Best regards

Sergio

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Mar 2019 12:46:07 +0000

Hi,

Regarding the splicing attack there are at least one aspect I don't think have come up yet in this discussion and which relates to the SSRC and the MD.

Bernard is correct that what is important is that the source SSRC that is pointing to the e2e key context are unique and not collidable to prevent enabling a splicing attack. If the MD translate them that is not an issue as long as the source SSRC is determinable and verifiable through the e2e integrity mechanisms.

What has been less discussed is that non-malicious MD can actually prevent attacks by tracking which original SSRC is coming from where. That way an attacker trying to introduce a splice or an replay of an source SSRC can be blocked before it gets circulated to other MDs or endpoints. Thus help mitigating this attack.

For me it at least this is one of the reasons why it is good to keep the original SSRC easily accessible. This combined with the set of changes anyway needed to support PERC it looked like keeping the SSRC static was the simplest solution from my perspective.

The discussion of the Splicing attack original was in the context of the field manipulations that could be allowed. I think the basics is in this presentation:
https://www.ietf.org/proceedings/94/slides/slides-94-perc-2.pdf

There are also some requirements John Mattsson presented from Ericsson's perspective on these issues at the same meeting (IETF 94): Slide 6 of
https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf

This is only to provide my perspective from the time I was involved in the WG. I did disengage fairly soon after this meeting so I lack the full perspective on the WG operations and what is documented in the draft now.

Cheers

Magnus

On 2019-03-01 18:20, Bernard Aboba wrote:
Sergio said:

"So the main issue here is that  "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc."

[BA] Let me attempt to unpack this. There are two issues here, which relate to:

2. Effects of manipulating the original" SSRC associated with the e2e keys.

Taking each in turn:

1. Changing the RTP header SSRC affects the routing of audio/video seen by the user but does not affect the integrity of media, which is protected by the e2e keys.. By changing the RTP header SSRC it is possible to "splice" the media or cause the a/v rendered in audio/video tags to switch between users (e.g. dominant speaker protection).  As we have discussed this is very common and causes few problems today, so it really can't be thought of as an "attack".

2. I believe this is the aspect Cullen is referring to, which provides an attacker with the ability to fool an endpoint into accepting as authentic a manipulated payload.  This can be used to create a "deep fakes" so it is a genuine attack.

Addressing this doesn't require outlawing the modification of the RTP header SSRC.  If the original SSRC is included in the payload in cleartext and integrity protected along with the rest of the payload, then the payload crypto-context is unaffected by modifications to the SSRC included in the RTP header.  The endpoint determines the appropriate keys for integrity protection and payload decryption from the payload SSRC, not the RTP header SSRC.

Of course, for this to work, conference participants cannot be allowed to masquerade as each other.  That is, if multiple conference endpoints possess the e2e keys used to encrypt and integrity protect payload data, then they can source "deep fake" media that appears to originate from another party.  As you have pointed out, this is a fundamental problem that the PERC framework does not address.

However, it can be addressed if trust is rooted in hardware (e.g. the TPM) and that e2e keys are not accessible to the endpoints (either Javascript or the browser).  AFAICT, PERC key management doesn't meet this requirement, but some content protection schemes claim to do so..

On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo <[email-masked]<mailto:[email-masked]>> wrote:
On 01/03/2019 16:38, Cullen Jennings wrote:
However to get to the heart of why the MID is different than the SSRC in the splicing attack,  the key thing with the splicing attack is the attacker gets the receiver to use a valid, but not really the correct, SRTP crypto context. As outlined in https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto context looked up from dest IP:port and SSRC. So changing the SSRC allows the attacker in the splicing attack to switch to a crypto context of the attackers choosing (and one the attacker has keys for). Changing the other things such as the MID does not allow this.

You are describing how ssrc splicing works, not what are its effects, or why it is an issue. I think I have found the origin of the ssrc rewriting issue and the splicing attack for perc in here:

3.9.  SSRC

So the main issue here is that  "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc.

Best regards

Sergio

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

--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 4 Mar 2019 14:03:59 +0100

Hi Magnus,

Thanks for the insights which matches what I understood from the 
splicing attack.

While I acknowledge that being able to track the origin of the rtp 
packet media is a good (and even a must have) functionality:

  * There is no mechanism in PERC to coordinate/map ssrc values to
    origins/participants between the endpoints.
  * In WebRTC, for that information to be of any value, the js app must
    be trusted to do something mean full with it.

FWIW, PERC-Lite carried the original ssrc in the inner payload, and as 
said before in a previous email, we have improved it for a customer to 
carry the participant id in the encrypted payload instead of the ssrc 
value (much more useful).

Best regards
Sergio

On 04/03/2019 13:46, Magnus Westerlund wrote:
> Hi,
>
> Regarding the splicing attack there are at least one aspect I don't 
> think have come up yet in this discussion and which relates to the 
> SSRC and the MD.
>
> Bernard is correct that what is important is that the source SSRC that 
> is pointing to the e2e key context are unique and not collidable to 
> prevent enabling a splicing attack. If the MD translate them that is 
> not an issue as long as the source SSRC is determinable and verifiable 
> through the e2e integrity mechanisms.
>
> What has been less discussed is that non-malicious MD can actually 
> prevent attacks by tracking which original SSRC is coming from where. 
> That way an attacker trying to introduce a splice or an replay of an 
> source SSRC can be blocked before it gets circulated to other MDs or 
> endpoints. Thus help mitigating this attack.
>
> For me it at least this is one of the reasons why it is good to keep 
> the original SSRC easily accessible. This combined with the set of 
> changes anyway needed to support PERC it looked like keeping the SSRC 
> static was the simplest solution from my perspective.
>
> The discussion of the Splicing attack original was in the context of 
> the field manipulations that could be allowed. I think the basics is 
> in this presentation:
> There are also some requirements John Mattsson presented from 
> Ericsson's perspective on these issues at the same meeting (IETF 94): 
> Slide 6 of
> This is only to provide my perspective from the time I was involved in 
> the WG. I did disengage fairly soon after this meeting so I lack the 
> full perspective on the WG operations and what is documented in the 
> draft now.
>
> Cheers
>
> Magnus
>
>
>> have the same effect than splicing attack without having to rewrite 
>> the ssrcs, that is, the endpoint will not be able to differentiate 
>> rtp packets coming from two different sources as the MID is used for 
>> routing and not the ssrc."
>>
>> 1. Changing the RTP header SSRC affects the routing of audio/video 
>> seen by the user but does not affect the integrity of media, which is 
>> protected by the e2e keys.. By changing the RTP header SSRC it is 
>> possible to "splice" the media or cause the a/v rendered in 
>> audio/video tags to switch between users (e.g. dominant speaker 
>> protection).  As we have discussed this is very common and causes few 
>> problems today, so it really can't be thought of as an "attack".
>>
>> 2. I believe this is the aspect Cullen is referring to, which 
>> provides an attacker with the ability to fool an endpoint into 
>> accepting as authentic a manipulated payload. This can be used to 
>> create a "deep fakes" so it is a genuine attack.
>>
>> header SSRC.  If the original SSRC is included in the payload in 
>> cleartext and integrity protected along with the rest of the payload, 
>> then the payload crypto-context is unaffected by modifications to the 
>> SSRC included in the RTP header.  The endpoint determines the 
>> appropriate keys for integrity protection and payload decryption from 
>> the payload SSRC, not the RTP header SSRC.
>>
>> Of course, for this to work, conference participants cannot be 
>> allowed to masquerade as each other.  That is, if multiple conference 
>> endpoints possess the e2e keys used to encrypt and integrity protect 
>> payload data, then they can source "deep fake" media that appears to 
>> originate from another party.  As you have pointed out, this is a 
>> fundamental problem that the PERC framework does not address.
>>
>> However, it can be addressed if trust is rooted in hardware (e.g. the 
>> TPM) and that e2e keys are not accessible to the endpoints (either 
>> Javascript or the browser). AFAICT, PERC key management doesn't meet 
>> this requirement, but some content protection schemes claim to do so..
>>
>> On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>>     However to get to the heart of why the MID is different than the
>>>     SSRC in the splicing attack,  the key thing with the splicing
>>>     attack is the attacker gets the receiver to use a valid, but not
>>>     really the correct, SRTP crypto context. As outlined in
>>>     https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto
>>>     context looked up from dest IP:port and SSRC. So changing the
>>>     SSRC allows the attacker in the splicing attack to switch to a
>>>     crypto context of the attackers choosing (and one the attacker
>>>     has keys for). Changing the other things such as the MID does
>>>     not allow this. 
>>
>>
>>     You are describing how ssrc splicing works, not what are its
>>     effects, or why it is an issue. I think I have found the origin
>>     of the ssrc rewriting issue and the splicing attack for perc in here:
>>
>>     So the main issue here is that  "endpoint can separate two
>>     different originating sources and to map the SSRC to a human
>>     readable name (or alias)". By modifying the MIDs the MD is able
>>     to do exactly that, and have the same effect than splicing attack
>>     without having to rewrite the ssrcs, that is, the endpoint will
>>     not be able to differentiate rtp packets coming from two
>>     different sources as the MID is used for routing and not the ssrc.
>>
>>
>>     Best regards
>>
>>     Sergio
>>
> SE-164 80 Stockholm, Sweden | mailto:[email-masked]