Re: [Perc] Request for decision review

["Paul E. Jones" <[e-mail]>]

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.  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.

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 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.  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.

Paul