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

[Cullen Jennings <[e-mail]>]

So if the MD requires the extension to be modifiable and the client does not want that, you are right, it is not going to work. I few this as a feature not a bug. I think that when the extensions is defined for use in the PERC framework, we need to decide which category it is in. The basic premise of the PERC is we do not fully trust the MD so letting the MD decide what it can parts of the RTP it is allowed to modify has some problems. That said, I agree it is possible that in the future there might be an extension where we do need the MD to be able to control which way it is handled and in that case, that extension could define SDP to negotiate that. 

The WG discussed the requirements around this along and you see the consensus of the  01.11.2016 meeting at https://www.ietf.org/proceedings/interim-2016-perc-01/minutes/minutes-interim-2016-perc-1

Some things that were marked as needing E2E integrity are the video orientation (CVO) and the synchronization metadata. I don't see anything that would cause us to change the desire to have E2E integrity for theses. 





> On May 12, 2017, at 2:18 AM, Sergio Garcia Murillo <[e-mail]> wrote:
> 
> 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. 

yes, agree, and the framework drafts says 

   If there is a need to encrypt one or more RTP header extensions end-
   to-end, an encryption key is derived from the end-to-end SRTP master
   key to encrypt header extensions as per [RFC6904].


> 
> Best regards
> Sergio
>