Re: [Perc] Request for decision review

[Emil Ivov <[e-mail]>]

Hey Paul,

On 16.05.16 г. 16:47, Paul E. Jones wrote:
> Emil,
>
>> The second problem mentioned by Cullen on May 10 is the one about
>> splicing that's also described here:
>> https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4
>>
>>
>> This can be resolved by simply having an rtp-hdrext attached and
>> signed by the sender that carries the original SSRC. That part will
>> not be allowed to change and needs to be copied over by the MDD/SFU
>> together with the rests of the immutable parts.
>
> I don't think there is even an additional signing process required.

No of course not. I just meant that it would be part of the data that is 
signed E2E.

> The
> sender of the packet will encrypt the packet containing the original
> SSRC value, with the authentication including that SSRC field.  If the
> MDD preserves that value in the OHB (described in the "double" draft),
> then the receiving endpoint could restore the original SSRC value in the
> packet header before attempting to decrypt.  If the wrong SSRC is
> provided, the packet will fail authentication.

So ... I admit I haven't fully wrapped my head around the OBH thing just 
yet. Specifically I don't understand the wording about how it should be 
placed after the original header extensions and why that even matters 
given that it's removed before verification ...

I also don't understand exactly how it allows for changing other fields, 
such as the timestamp, or whether it is meant to allow for changing of 
(which) header extensions.

That said, I agree that if we tweak these definitions then using the OBH 
could work.

> Having two SSRC numbering spaces that can overlap is unfortunate,
> though.  Using libraries like libsrtp, we would need to have an E2E
> context and a HBH context.  That is, we have to initialize the library
> twice, because every SSRC and related cryptograhic parameters, replay
> database, etc. expects a single number space.  Thus, to decrypt a packet
> we would have to do this:
>
>     srtp_unprotect(hbh_context, packet);
>     do_perc_stuff(packet);  // Such as dealing with the OHB field
>     srtp_unprotect(e2e_context, packet);
 >
> We could hide that extra step by having the library create the second
> context under-the-covers or creating a wrapper layer around libsrtp (or
> whatever SRTP library is employed).  If we did not create overlapping
> number spaces, this could be avoided.

I don't get it. Given your sample above, it sounds to me that this issue 
is bound to happen exactly when you are not changing the SSRC because 
you have two crypto contexts for the same SSRC.

You are actually avoiding that issue if you can be certain of using 
different SSRCs in HBH and E2E, which you can't anyway in either of the 
solutions we are discussing.

What am I missing?

> I personally think having overlapping number spaces is messy.  And for
> what?  I still fail to see how performing a 1:1 mapping of an SSRC value
> does anything to make building the MDD any easier.

I am not sure if my previous explanations were unclear or unconvincing 
so I am just going to try and explain again:

The way simulcast is being implemented in SFUs today is by having all 
the logic at the sender and at the SFU. There is never any of it in the 
receiver. This essentially means that the sender feeds two or three 
SSRCs to the SFU. The SFU then makes sure that what goes out on the 
other side is one single and coherent RTP flow with a single SSRC. This 
allows it to handle all the logic of layer switching including things 
like requesting keyframes, detecting layer drops, detecting keyframes 
during layer switches, timestamp uplifts and others.

The receiver in this picture lives with the impression that it only ever 
gets a single video stream that simply happens to change its resolution 
every now and again.

This makes things much simpler and quicker than trying to have the 
receiver detect and juggle with layers, request keyframes and such ...

No receiver does that today and PERC would be a much tougher sell if you 
tried to get people to not only implement a new SRTP layer but also 
force them into adopting receiver side simulcast support which virtually 
no one does today.

> In fact, I see it as
> just more complexity.  And, it's more complexity for the endpoint (as I
> note above), juggling E2E and HBH SSRC values.

I really fail to understand how immutable SSRCs would fix your issue 
above (and again, I am probably the one missing something here) but even 
with that I can assure you that having one extra libsrtp call is 
incomparably simpler than trying to get a receiver to handle simulcast 
layer switching.

Emil

-- 
https://jitsi.org