PERC Virtual Interim - 01.11.2016

Chairs - Richard Barnes, Suhas Nandakumar

Agenda
-------
* Intro and recap from last call
* Focus: Header extensions
* Question: Do we need E2E-protected header extensions at all?
* Or can the MDD do whatever it wants with extensions?
* Question: If the MDD is limited, what capabilities does it need with regard to extensions?
    * Change the [identifier numbers]
    * Append extensions
    * Append encrypted extensions
    * Remove extensions 
    * Read encrypted extensions
    * Other?

* Magnus: Discussion of header extensions
* Wrap-up: Where are we on the questions?


Summary/Conclusions from the call
---------------------------------

End to End Authentication Conclusion - IS DESIRABLE
	a) Removal of authenticated E2E header extension is NOT NEEDED
	b) Mutable with having original authenticated value is OPTIONAL

End to End Confidentiality Conclusion - IS DESIRABLE and NICE TO HAVE
    a) If a use-case demands for a strictly privacy reasons, E2E Conf might be needed 



Individual Extensions Considerations
-------------------------------------

Transmission Time offsets (RFC5450)
  -- less relevant and might be never be used.
  -- no decision made


SMPTE time-code mapping (RFC5484)
  -- same conclusion as RFC5450
  -- no decision made


Synchronisation metadata (RFC6051)
  -- MDD Modify 	: NO
  -- E2E Auth 		: YES
  -- E2E Conf		: NO


Client to Mixer Audio Level (RFC6464)
  2 plausible options
  Option 1:
    -- E2E Auth		: YES
    -- MDD modify 	: NO
    -- E2E Conf         : NO

    Use-case: Receiving end point being able to detect false audio level
    advertisement by the source. Given the MDD has no view into
    audio, clients end-points can lie easily.

  Option 2:
    -- E2E Auth		: NO
    -- MDD modify 	: YES, Remove at the last hop to the receiver
    -- E2E Conf         : NO
   One might want to use this option to save the bandwidth. Is there
   a real value in removing the extension ?

  * Document the security risk associated with the leaked media content.
  * Might be possible to indicate audio levels in a secure fashion in future.
  * Other option might be to forward all the stream regardless of the 
    audio level (continuous transmission)


Mixer to Client Audio Level (RFC6465)
    -- E2E Auth		: YES
    -- MDD modify 	: NO
    -- E2E Conf         : YES
    This might be needed while:
    	a) source end-point mixes
    	b) end to end contributing sources

    * Need to be confirmed on the list if we need to support source end-point
    mixing use-cases.
    * most cases the recommendation is not to use this approach


Coordination of video orientation (CVO)
    -- E2E Auth		        : YES
    -- MDD modify 	        : NO
    -- E2E Conf                 : ??? (MDD might need to see it in certain use-cases)


Region of Interest (ROI)
   -- Deferred till the group discusses RTCP in perc context.


SDES Information (CNAME)
    -- E2E Auth		        : YES
    -- MDD modify 	        : NO
    -- E2E Conf                 : NO

    * Assume RFC7022 is the way CNAMEs are constructed for PERC purposes.
    * If E2E RTCP is supported, E2E Auth might not be needed.



SDES MID and SDES RID
    -- E2E Auth		: NO
    -- MDD modify 	: YES
    -- E2E Conf         : NO

    * MDD needs to modify and might add a new one
    * From security standpoint, a malicious MDD might end up mixing up streams/layers
    * Do we need the original value in the case of modification for E2E Secure Signaling use-cases


RTP Framemarking
    -- E2E Auth		: YES (also depends on MDD being able to modify)
    -- MDD modify 	: NO (do we need to support last hop removal?)
    -- E2E Conf         : NO



Dealing with Header Extension ID, Negotiation & Misc
  * MDD needs to modify
  * how to handle negotiation of ID vs the usage of a particular extension. 
  * how does this work if the parameters are stripped and IDs are reused.
  * Concern about dealing with E2E header extensions that can be removed by the MDD
    due to far end not supporting a particular extension