Re: [Perc] Drop support for E2E RTP header extensions

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

On 12/05/2017 2:05, Cullen Jennings wrote:
>
> OK, I think I see what is causing the confusion...
>
> For a given header extension like say "urn:3gpp:video-orientation:6" 
> you are thinking that there needs to be a way for the conference 
> system to tell the endpoint if that given header is E2E encrypted or 
> only HBH. That is not how PERC is working, PERC has the specification 
> on header extensions when used in a PERC context tell the thing 
> sending the RTP what it needs to do or leaving it as an implementation 
> choice. The endpoint or browser is compiling that decisions in to the 
> code.
>
And that will cause problems. If the MD requires an extension to be HBH 
in order to be properly and the endpoint send it E2E, or some E2E and 
others HBH. If we decide to support E2E header extensions we have to 
provide a mechanism on the SDP to negotiate them. We just can leave it 
as an implementation choice.

> Of course the SDP can be used to decide if 
> "urn:3gpp:video-orientation:6" is in use or not but not how it is 
> encrypted.
>
(more on this below)

>> [...] One thing is integrity and another is E2E. Could you name some 
>> of those use cases?
>
> Uh, not getting what you mean by E2E here ? An example of something 
> that in some case might want end to end integrity is urn:3gpp:roi-sent
>

I mean E2E encrypted. Currently E2E extensions are not encrypted, just 
integrity protected. The MD will still be able to read their contents, 
but not modify it. AFAIK, if we want to encrypt them we would also need 
to support RFC 6904 when applying the inner crypto.

Best regards
Sergio