"By not allowing the Media Distributor to change the SSRC, PERC mitigates this attack."
[BA] The security threat is mis-stated, and the "fix" is worse than the problem.
In most situations modifying the SSRC will not represent an attack, just an attempt on the part of the SFU to weave received simulcast streams together to form a single stream so that an endpoint that does not support simulcast reception can render it. So the "fix" is inherently incompatible with endpoints that can not receive simulcast, not a good tradeoff.
The actual threat to worry about is not "splicing" but "deep fakes" where an attacker with access to cleartext audio and video can modify the media (such as putting someone else's face on another body), while still retaining synchronization between audio and video to make the "fake" believable. Addressing this kind of attack requires control of endpoint access to cleartext media and recording APIs. AFAICT, PERC does not prevent this kind of attack because of key sharing.
"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)."
[BA] MID modification is quite likely in scenarios such as "dominant speaker" where the video (and audio) will switch between participants as they take turns speaking. Again, in most situations, this does not constitute an attack, and where it does, PERC will not be of much help.
On Thu, Feb 21, 2019 at 9:57 AM Sergio Garcia Murillo <sergio.garcia.murillo@xxxxxxxxx> 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, 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).
Best regards
Sergio
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc
