Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

[Sergio Garcia Murillo <[e-mail]>]

On 13/02/2019 23:48, Nils Ohlmeier wrote:
> While implementation convenience was part of the discussion it was 
> raised a few times that the people in favor of allowing SSRC 
> mutability never provided any written description of why mutating the 
> SSRC is not a problem as pointed out by the design team.

All SFUs I am aware of performs SSRC rewriting, it is much more than 
implementation convenience.

I assume that the ssrc rewriting security issue comes from the splicing 
attack described in:

https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01


        7.2.4
        <https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4>.
        Splicing Attack



    The splicing attack is an attack where a MDD receiving multiple media
    sources splices one media stream into the other.  If the MDD would be
    able to change the SSRC without the receiver having any method for
    verifying the orignal source ID, then the MDD could first deliver
    stream A.  And if the sequence numbers and other information allows
    it, the MDD can forward stream B under the same SSRC as stream A was
    previously forwarded.

    This attack is mitigated by requiring each rtp stream to have unique
    source IDs that are provided to the receiver.  That way the receiver
    would detect when the source ID switches for these streams.


Note that this attack happens also for perc double even without ssrc 
rewriting as there is no way of verifying that a particular ssrc is from 
a given participant as all participants share the same key and there is 
no protocol in place for mapping ssrcs to participants.

Also note that we have solved this in one of our deployments using PERC 
lite allowing ssrc rewriting and app key management, using a different 
ssrc for the OHB payload used for inner encryption and the outer/HBH rtp 
packet. The inner/OHB ssrc(=participant Id) is then assigned by the key 
management server together with the encryption key for each participant 
so it can be used for mapping ssrcs to participants and allows verifying 
the origin of a packet end to end.


Best regards

Sergio